Privacy as Table Stakes: Georgi Koreli on How Hinkal Is Making Stablecoin Settlement Confidential

Hinkal Co-Founder and CEO Georgi Koreli talks about why the public ledger is holding back institutional stablecoin volume, how privacy can be added on top of the chains and wallets businesses already use, and why compliance had to be built into the protocol rather than layered on top of it.

Stablecoins moved around $46 trillion on-chain last year. Strip out bot and exchange activity and the organic figure is roughly $9 trillion, already more than half of Visa's annual payment volume and growing considerably faster. Most of it is no longer trading. It is payments and settlement.

Georgi Koreli's argument is that those flows run into a constraint that has nothing to do with speed, cost, or regulation: the ledger they settle on is public. More than $1 billion in stablecoins has settled privately through Hinkal to date, with $187 million of that in June alone.

What Is Hinkal and What Problem Does It Solve?

Hinkal started as a privacy layer for DeFi and has since grown into stablecoin payments and settlement. For readers meeting Hinkal for the first time, what is it, and what does it let people and businesses actually do?

Hinkal is privacy infrastructure for stablecoins and on-chain finance. The simplest way to explain it is that your existing wallet gains a private balance.

You move funds in from the wallet you already use. From that private balance you can hold, send, receive, settle, and pay out, and while you do, the amounts you hold, the amounts you send, and the counterparties you send to are not readable on the public chain.

Nothing about your setup changes to make that work. You do not need to move to a new chain, hand your funds to a custodian, or learn how to use a new wallet. The private balance sits inside a smart contract on the chain you already operate on, and it is controlled by the same wallet keys you already use. Privacy is added to the infrastructure you already use.

The part that matters for a business is what remains possible alongside that. The settlement is still recorded on-chain, so it is verifiable. And if a regulator, an auditor, or a counterparty needs to see a transaction, a period, or the origin of specific funds, you can show them exactly that and nothing more, through viewing keys. So the activity is confidential to the market and provable to the parties entitled to see it.

A fully public ledger may be acceptable for an individual user. It is often disqualifying for a serious business or financial institution.

How Does a Private Stablecoin Payment Actually Work?

Walk us through what actually happens when an institution moves a stablecoin payment through Hinkal. What stays visible on-chain, and what can counterparties or competitors actually see?

It depends on the route the payment takes, and there are four.

1. Public to private

Funds move from a public wallet into a private balance controlled by the same keys. What an observer sees is a deposit into the Hinkal contract. Activity from that balance afterwards is not publicly visible.

2. Private to private

Both sides transact from private balances controlled by their own wallets. The transaction is submitted by a relayer rather than by your wallet, so the only addresses an observer sees are the relayer and the Hinkal smart contract. Your own address never appears as the sender, and the recipient, the amount, and the relationship between the two parties are never exposed as a wallet-to-wallet transfer.

3. Private to public

Funds move from a private balance out to any public address. The receiving address is visible, because it has to be, but the sender stays confidential.

4. Public to public

Funds enter from a public wallet and arrive at a public wallet, with Hinkal in between, and the deposit and the withdrawal cannot be linked. Neither party needs to understand shielded addresses or change how they work.

What stays public and verifiable is what should be: that a valid settlement occurred and that the protocol's state is correct.

The distinction I would draw is with systems that route funds between two public addresses. There, privacy comes from breaking the link between addresses that both remain public. With private balances, there are no public counterparty addresses to link in the first place. That is what makes it work for an institution.

How Can a Business Be Private and Compliant at the Same Time?

Privacy and compliance are often framed as opposites: regulators want visibility, institutions want confidentiality. How does Hinkal reconcile confidentiality with the auditability and reporting requirements banks and issuers are bound by?

They are framed as opposites, but they are the same problem seen from two sides.

A regulator or an auditor needs to be able to verify and check whatever they are entitled to check. The institution needs to be able to show it, accurately and in the scope requested. Neither of those things requires the information to be broadcast to everyone else. Both are selective disclosure, and the only real question is who is authorized to see what, and when.

The clearest way to understand it is to look at traditional finance. That system is regulated and compliant, and users still get the privacy that matters most. Your bank does not publish your balance, your salary, and your counterparties to your competitors. Regulators and auditors can see what they are entitled to see, when they need to, but the information is not broadcast.

That privacy was never about hiding from everyone. It is about keeping sensitive financial information away from the parties who could gain an advantage and use it against you. Public blockchains removed it. Today everything is exposed to anyone with an internet connection. Hinkal brings that traditional-finance norm back to public chains.

So when I say privacy, I do not mean hiding. I mean selective disclosure: confidential to counterparties and competitors, provable to a regulator or an auditor when required.

That is also what the rules actually ask for. The Travel Rule requires originator and beneficiary information to move with a transfer between the institutions that handle it. MiCA sets out how crypto-asset service providers screen, record, and report. Both regimes want the right parties informed, not everyone.

Hinkal is built to support that.

Compliance sits at the entry point: every deposit is screened by Chainalysis before it reaches the contract, so sanctioned or high-risk addresses never get in. Disclosure then runs through viewing keys, read-only permissions that a participant grants to a regulator or an auditor to reveal their history, in full or in part, while it stays hidden from everyone else.

We are built to support these regimes, not to replace an institution's own licensing.

What Are the Different Types of Blockchain Privacy Architecture?

There is more than one way to do privacy on-chain. How is Hinkal's approach different, and what do the other models get wrong for real institutional payments?

It is worth being precise that blockchain privacy is not one thing. There are at least six architectures being built right now, and they are not six flavours of the same product. They are six different fixes for different problems.

Most approaches break down for institutional payments in a specific way.

Dedicated privacy chains ask you to move your liquidity and users onto a separate chain, away from where the stablecoins and counterparties already are. That fragments liquidity, adds new trust assumptions, and takes institutions away from the public chains they already use. You are solving privacy by leaving the room where the money is.

Fully homomorphic encryption, the approach Zama and others are building, encrypts data so that amounts and balances are shielded. It is impressive cryptography, but it is computationally heavy and still maturing for production payments. Shielding the amount is also not the same as full privacy.

Privacy built on trusted hardware, using secure enclaves as in projects such as Secret or Oasis, relies on the hardware and its underlying trust assumptions. It also usually operates within a separate environment rather than on the public rails institutions already use.

Hinkal sits in the ZK-shielded row and borrows from the hybrid one. We provide private balances on the public chains institutions already operate on. Amounts, counterparties, and balance histories are shielded, settlement stays public and verifiable, and compliance screening and selective disclosure are built in.

Each of the other models gets one piece right. For institutional payments you need all of them at once, without leaving the chains where the money already lives.

What Are Hinkal's Four Products and Who Is Each One For?

You have built four distinct products rather than one single tool. What made you split it that way?

We do not really think of them as four products. The core infrastructure is the same underneath all of them: private balances controlled through your existing wallet keys, compliance screening, and selective disclosure. What changes is the entry point.

The Hinkal Integration Suite, which is our SDK and API, is our main distribution layer and strategically the most important of the four. Instead of asking every merchant, fintech, wallet, or enterprise to adopt a new standalone product, we let them embed Hinkal's privacy directly into the custody, wallet, payment, or treasury experience their users already know.

That is powerful because it does not break existing flows, and it hands product teams a new premium feature they can offer their own customers. This is already happening in production.

Teams like Polygon and The Vault are working with us to bring confidential settlement into products their users already run.

Hinkal Pay is the simplest way to experience the product through payments. It is a web app with a very low barrier to entry, recently rebuilt with a redesigned interface, so it works well as a first touchpoint for individuals, operators, or teams who want to understand the value of private payments quickly, without any integration work.

Hinkal Prime is the enterprise version of that experience. It is built for teams that need more operational control: batch payouts, multiple members, roles, approvals, and workflows that match how businesses actually move funds. In practice it is for teams running on-chain treasury operations, so payroll, vendor, affiliate, and payout flows.

Hinkal Wallet is the retail-oriented product, for users who want a more complete private wallet experience, where holding, sending, swapping, and managing funds privately is part of the core product itself.

As for which one a customer needs first, we let the pain pick it. A builder or a platform starts with the Integration Suite. Someone who just wants to feel the value starts with Pay. A treasury or operations team running payouts starts with Prime. A user who wants a full private wallet starts with the Wallet. One privacy engine, four ways in.

Hinkal SDK vs API: What Is the Difference?

Within the Integration Suite, how should a team decide between the SDK and the API?

They solve different integration problems, and the choice comes down to how much of the experience the team wants to own.

The API is for adding private execution underneath an existing stack. Integration is language-agnostic, so it is standard calls from any backend, whether that is Python, Go, Java, .NET, Rust, or Node.js. Requests are signed by the caller's wallet, which means user-level access is authorized without passwords or custodial key handling.

The cryptographic work, including proof generation, UTXO handling, and private balance reads, runs inside our secure enclave, so the team calling it never has to build any of that.

The SDK is for teams that want control of the front end. It gives programmatic access to the shielded pool, so deposits, transfers, withdrawals, swaps, and viewing-key management, with direct on-chain interaction. Wallet connection, transaction steps, balance display, and user-facing states all stay inside the product's own interface. That is what you use when the private balance needs to feel native to your product rather than bolted onto it.

Either way the integration is designed to be run by your own team, with a forward-deployed Hinkal engineer available throughout and afterwards if you want one.

What Does a Hinkal Integration Involve, and What Are the Trade-Offs?

From an integrator's point of view, what do they and their users get out of it, and what should they weigh going in?

The pitch to an integrator is: add privacy to the product you already operate instead of adopting a separate, standalone tool.

If you are a wallet, fintech, or payments team already running infrastructure such as Turnkey or Privy, Hinkal integrates on top of what you already have. For the integrator, this introduces a feature that was standard in traditional finance but is still missing from public chains. Their users gain confidential balances and transfers, and the integrator gains a premium feature it can offer without building privacy from scratch or disrupting its existing user flows.

That does not mean the integration is effortless, but it is bounded, and a team can execute it on its own. You are adding to your existing infrastructure rather than rebuilding it, so the work is scoped to adapting the private balance and deposit flow for your users. Teams do that independently. We also make a forward-deployed engineer available throughout and afterwards, so if something comes up mid-integration there is someone to ask, but it is there as a backstop rather than a dependency. Compliance is handled the same way: screening as funds enter, and disclosure to a regulator on request. The integrator fits that into its existing process rather than building it.

Compliance is handled the same way: screening as funds enter, and disclosure to a regulator on request. The integrator fits that into its existing process rather than building it.

At the same time, leaving privacy out also comes with a cost. When users' activity remains fully visible on-chain, competitors can see their pricing and volumes directly. So the real choice is not between privacy and no cost. It is between accepting a bounded integration cost today and leaving users exposed later.

There is a timing cost on top of that.

"Stablecoins will not reach real scale without privacy. It stops being a differentiator and becomes something users simply expect."

The team that adds privacy first keeps its users. The team that waits watches them leave for whoever offers it, then runs the same integration anyway. Framed that way, most teams understand quickly why the integration is worth doing now.

Is Confidential Settlement Becoming Table Stakes for Payment Rails?

Privacy is increasingly cited as one of the biggest blockers to stablecoins reaching institutional scale. Does confidential settlement become standard, or does it stay a specialist layer?

Privacy is one of the biggest blockers to stablecoins reaching institutional scale. The public ledger is what prevents serious flows from moving on-chain.

"A payment rail that exposes your counterparties and transaction amounts cannot support institutional volume, no matter how strong it is in every other respect. At that level, confidential settlement becomes table stakes."

The market is already starting to reflect that. More than $1 billion has moved privately through us, and we are not the only ones. The problem is being recognized more broadly, and the market is beginning to identify the companies working to solve it.

Then there is the scale of where stablecoins are heading. Citi projects a stablecoin market of around $4 trillion in its bull case, while Standard Chartered estimates roughly $2 trillion by 2028. You cannot run trillions of dollars in institutional settlement on rails that expose every counterparty and every amount to the public.

As the market grows, confidential settlement stops being optional and becomes part of what a serious payment rail is expected to provide. It is the infrastructure catching up with what businesses need once they begin moving meaningful volume on-chain.

Why Are Institutions Hesitant to Adopt Privacy Infrastructure?

What is the objection you hear most often from an institution evaluating Hinkal, and how do you answer it?

The hardest objection is regulatory. Privacy tools carry significant baggage in this industry, and Tornado Cash and the sanctions around it still shape how the entire category is perceived. So beneath the technical questions, the real concern is: is a privacy solution like Hinkal legally and reputationally safe for us to use?

Our answer is that compliance is not added on top of the privacy. It is built into the way the protocol works. Every deposit is screened before entering the confidential contract, which means flagged or sanctioned addresses are prevented from entering. At the same time, a participant can prove the lawful origin of their funds to a regulator or auditor whenever required, without exposing their full activity to everyone else.

It comes back to the same principle: privacy and compliance are two sides of the same problem.

The tools that gave on-chain privacy a bad reputation took the opposite approach. They pooled funds to break the transaction trail and did not ask where the money came from. We deliberately started from the other end, because a privacy solution that ignores compliance becomes a liability for the very institutions it is supposed to serve.

The second objection is more practical: is the product ready for production, and how difficult is it to integrate?

• On readiness, the protocol has undergone independent security audits.
• On integration, the work is bounded by the SDK and API rather than requiring a full rebuild.

How Did Hinkal Get From DeFi to Stablecoin Payments?

You started in DeFi. How did you get here?

Hinkal initially focused on DeFi use cases such as position management and staking, because that was where the problem was most visible. Traders and funds did not want every position, balance, and strategy exposed in real time.

But the underlying need extends far beyond trading. A company paying a supplier or settling a cross-border transaction faces the same problem. It needs the transaction to be verifiable, and it needs to remain compliant and auditable, without publishing commercially sensitive information to competitors.

Moving into payments and settlement was therefore not really a pivot. It was a natural extension of the same privacy infrastructure into a much larger market.

Stablecoins are becoming part of the settlement infrastructure for the next decade of finance, and settlement at that scale requires confidentiality between counterparties. Privacy is not an optional feature that can be added later. It is a fundamental requirement for serious money movement, and that is the problem Hinkal is built to solve.

What Is the Future of Privacy in Stablecoin Settlement?

Play it forward five years. If privacy becomes a default for stablecoins, what does settlement look like, and what is Hinkal's role in getting there?

Ask most people in this space where we will be in five years and you will hear roughly the same things: more money moving on-chain, banks tokenizing deposits, payments running around the clock, and more of those transactions carried out by AI agents rather than by people manually clicking buttons.

I agree with that. What gets left out is that none of it can really operate on a completely public ledger.

Once the money moving on-chain becomes more significant, whether in the form of tokenized deposits, corporate treasuries, or institutional settlement, the current level of transparency stops working. A bank does not publish its balances, counterparties, and payment activity today, and it is not going to start doing that simply because it is using a blockchain.

Privacy becomes even more important as agents begin moving money continuously on behalf of people and businesses. If all of that activity is public, anyone watching can begin to understand your behaviour, relationships, and financial patterns. Pseudonymity has never been the same thing as privacy, and I think that distinction will become much clearer over the next five years.

So I do not see confidential settlement as something that gets added later. It is part of what makes the larger on-chain economy possible in the first place.

Hinkal's role is to provide that layer inside the wallets, payment products, and treasury systems people already use. Ideally the user should not need to think about the privacy infrastructure at all. They should simply be able to move money without exposing information that should never have been public in the first place.

About Hinkal

Hinkal is privacy infrastructure for stablecoins and on-chain finance. Hinkal gives existing wallets a private balance, so that amounts, counterparties, and balance histories remain confidential while settlement stays public and verifiable on the chains institutions already use.

Compliance screening runs at the point of deposit, and selective disclosure through viewing keys allows participants to prove activity to regulators and auditors without exposing it to anyone else. Hinkal operates across Ethereum, Solana, Tron, and major EVM networks, and more than $1 billion in stablecoins has settled privately through the protocol.

The company was founded in 2023 by Georgi and Nika Koreli and incubated at the Stanford Blockchain Accelerator.

About Stablecoin Insider

Stablecoin Insider is the leading media and research platform covering stablecoins, digital payments, on-chain finance, treasury infrastructure, and the evolving global financial system. The publication focuses on enterprise adoption, fintech innovation, banking transformation, and the broader stablecoin ecosystem.