Hinkal API: Drop-In Privacy Infrastructure For Every Product

The next phase of stablecoin growth is institutional - payroll, vendor and contractor payments, B2B settlement, treasury operations, merchant payouts. Banks, payment processors, card networks, corporate treasuries, and crypto-native institutions are the ones bringing that volume on-chain.

Bessemer Venture Partners recently named privacy as one of five structural blockers preventing stablecoins from scaling into global financial infrastructure. They named two solutions: Hinkal and Canton.

The reason is simple. A public ledger is excellent for trustless settlement. It is a poor fit for institutional operations, where every payment publishes sender, recipient, and amount to the entire network. Institutions will not move treasury, payroll, or counterparty payments onto a ledger that broadcasts every flow.

Polygon read that early. After partnering with Visa, Meta, and Modern Treasury to position itself as the institutional chain, Polygon understood the next constraint: if it did not offer privacy to the institutions moving on-chain, those institutions would route their volume to whichever product did. Polygon integrated Hinkal as the privacy option inside Polygon Wallet - and turned the gap into a reason to stay.

That same dynamic now plays out one layer up. Every wallet, exchange, neobank, payment app, payroll platform, and B2B fintech serving institutional users faces the same constraint. The institutions are coming. If a product can not offer them private rails natively, those users will route to a product that can.

For that to happen at the speed the market is actually moving, integrating privacy has to be cheap. Not a six-month SDK rebuild. Not a custody overhaul. Not a chain migration. A handful of REST calls signed by the user's wallet.

That is why we built the Hinkal API.

What Hinkal API Is

Hinkal API is the same privacy protocol Polygon integrated, exposed as a drop-in surface any product can call. Privacy is added underneath your stack, on demand, per transaction. You keep your product UX, your custody model, and your relationship with the user.

Four things make the integration cheap where building privacy from scratch is not:

A REST API any backend can call. Python, Go, Java, .NET, Rust - anything that speaks HTTP.

Multi-chain from one surface. EVM chains, Solana, and Tron are all reachable through the same API. No chain-specific code on your side.

Non-custodial by design. The user signs every request with their own wallet. There are no API keys, no passwords, no Hinkal-issued credentials of any kind. The user's wallet is the credential. Hinkal never holds the user's funds and never holds the user's wallet key.

The privacy compute runs inside a confidential enclave. Every request is handled by code executing inside a sealed hardware environment whose memory is unreadable from outside the boundary - including by the host, by Google, and by Hinkal's own infrastructure. The shielded key that authorizes private operations is generated inside the enclave, stored only in encrypted form outside it (sealed with Google Cloud KMS), and decrypted only inside the enclave for the single operation that needs it, then discarded. No component outside the enclave ever sees the raw key. The privacy guarantee is not a policy. It is an architectural property of where the cryptographic work actually happens.

Whatever your product is - a wallet, an exchange, a neobank, a payment app, a payroll platform, a B2B settlement layer - Hinkal API drops underneath it. Your users keep using your product. They just get a private transfer option when they need one.

What The API Does Not Force On Your Users

Most privacy options come with a list of things your users have to trade-off. The API removes that list.

No wallet migration. Your users keep their existing wallet. The signing key never moves. No new app to install. No new seed phrase. The same wallet that signs every other action in your product signs the privacy ones.

No custody handover. Hinkal does not hold the user's funds at any point in the flow. The user signs a deposit, the user receives a private payout, and your product stays the only entity with a relationship to the user.

No chain lock-in. The same API surface works across EVM chains, Solana, and Tron. Adding a new chain to your product later does not require a fresh privacy integration.

No always-on privacy. Privacy is opt-in per transfer. The user - or your product on the user's behalf - decides which transactions go private and which stay public. You do not sacrifice transparency where you need it.

No compliance compromise. Chainalysis KYT screening runs on private transactions before they execute. Viewing keys for selective disclosure and downloadable transaction history are built in. Privacy here means opacity to the public ledger - not to your compliance team or your auditor.

You ship the product. The Hinkal API ships the privacy.

How The Integration Works

The API is built around a handful of calls. End-to-end integration is a handful of lines of code on your backend plus a standard wallet sign on the client.

Authentication is the first thing your integration touches, and it is what makes the rest of the surface non-custodial. There are no API keys. Every request is authenticated by a signature from the caller's own EVM wallet. You pick one of two modes per the way your product is shaped. Either the user signs once and the resulting authorization is reused for 24 hours of transactions, or the user signs a transaction-scoped authorization for each individual action. Either way, the wallet is the only credential, and the wallet is the user's.

The transaction surface is what your backend actually calls. Deposits move funds from public to shielded balance. Withdrawals move shielded back to public. Transfers move privately between shielded accounts. Swaps exchange assets without revealing the trade. And the highest-level call, /private-send, takes one tokenAddress and one or more recipients and orchestrates an end-to-end private payout in a single order.

A multi-recipient private send completes in four steps. The user authenticates. Your backend posts the order and gets back an unsigned deposit transaction. The user signs and broadcasts the deposit from their own wallet. Once the deposit confirms on-chain, the API detects it and dispatches a private withdrawal to each recipient. Your backend polls the orderId until every recipient has been paid. The on-chain link between the deposit and any individual recipient is never visible.

Underneath those calls is a smart contract called a shielded pool. Funds inside the pool are recorded as cryptographic commitments - entries that record balances and ownership without revealing them on-chain. Every state change inside the pool is verified using a zero-knowledge proof: a cryptographic technique that lets the contract confirm a transaction is valid (sufficient balance, correct ownership, no double-spend) without seeing the sender, the recipient, or the amount.

From the outside, you can see deposits enter the pool and withdrawals exit it. You can not link a deposit to a withdrawal, and you can not see the activity in between. That is what makes the transaction graph unobservable - and what makes the privacy meaningful to the institutional user moving real volume through your product.

Architecture

The smart contract is the public surface of the protocol. The cryptographic work that drives it - reading the user's shielded balance, generating the zero-knowledge proofs that authorize each spend, and building the resulting on-chain transactions - happens inside a confidential enclave. The shielded key that authorizes those proofs is generated inside the enclave, sealed outside it with Google Cloud KMS, and only ever decrypted in enclave memory for a single operation before being discarded. Nothing outside the boundary - including Google, including Hinkal engineers, including the API host - ever sees the raw key. That is the structural reason the privacy guarantee holds: the parties that could break the privacy do not have the material to break it with.

Compliance, In Practice

Confidentiality is about who can see, when, and under what authority - not about hiding everything by default. The API ships the controls auditors, regulators, and partners actually use:

Chainalysis KYT monitoring. Sanctions screening and risk scoring run on every private transaction before it executes. A flagged address never enters the shielded pool. Privacy and compliance are not a tradeoff at the protocol layer.

Viewing keys for selective disclosure. Grant a regulator, auditor, or partner read access to specific records - without making the full history public. Scoped, time-bounded, revocable.

Downloadable transaction history. Scoped by time range, in a standard format ready to hand to a third party.

Your product keeps the compliance posture it already has. The API does not introduce a new one.

Where This Fits

The API is built for products bringing institutional users on-chain - and for the institutional users moving real volume through them:

Wallets adding a private rail without rebuilding their stack.

Exchanges offering private withdrawals to institutional accounts.

Neobanks and payment apps where stablecoin rails coexist with traditional ones.

Payroll, contractor-payment, and B2B-billing platforms whose customers can not have counterparty exposure on a public ledger.

DEXs and aggregators competing for institutional order flow.

Fintech infrastructure providers whose customers ask for privacy as a feature.

The pattern is consistent: every product here is competing for institutional volume, and every product here will lose that volume the moment a competitor offers what they do not.

Moment

Three things are now true at the same time. The market has named privacy as a structural blocker for stablecoin scale. The most institution-aligned chain has shipped privacy at the wallet layer to keep those institutions. And the same privacy protocol is now available as a drop-in API any product can call, with the cryptographic work sealed inside a confidential enclave and the user's own wallet as the only credential.

That is the moment. The Hinkal API is live.

→ Read the API docs: ‍

https://hinkal.docs.buildwithfern.com/enclave-api/overview

‍