Hinkal API: Drop-In Privacy For Every Product Where Serious Capital Flows
Institutional payment volume is moving to stablecoin rails every quarter. Payroll. Vendor and contractor payments. B2B settlement. Treasury rebalancing. Merchant payouts. That volume runs on public ledgers, meaning balances, counterparties, and cash flow patterns are visible by default. For the firms moving real volume through a product, that exposure is a deal-breaker. They will route their flow to whichever product solves it.
Bessemer Venture Partners just named privacy one of five structural blockers preventing stablecoins from scaling into global financial infrastructure. They named Hinkal one of two solutions. Polygon read the same signal early. After positioning itself as the institutional chain with Visa, Meta, and Modern Treasury, Polygon integrated Hinkal as the privacy option inside Polygon Wallet. The logic was simple: institutions will not bring real volume on-chain to a venue that broadcasts every flow. Polygon chose to be the venue that does not.
That dynamic now plays out one layer up. Every wallet, exchange, neobank, payment app, payroll platform, and B2B fintech serving institutional users faces the same choice. The institutions are coming. The product that ships a private rail wins the volume. The product that waits watches it route past.
For that to happen at the speed the market is actually moving, integrating privacy has to be a light engineering lift. Not a six-month SDK rebuild. Not a custody overhaul. Not a chain migration. A handful of API calls.
That is why the Hinkal API exists. To help you be that product where serious capital flows.
What the Hinkal API gives your product
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 wallet UX, your custody model, and your relationship with the user. Six properties make that integration possible where building privacy from scratch is not.
Language-agnostic integration. Standard API calls from any backend stack: Python, Go, Java, .NET, Rust, Node.js. Anything that speaks HTTP can drive the integration. No SDK lock-in. No new dependencies in your client. No language commitment.
Non-custodial by default. Users sign transactions with their own EVM wallet. Hinkal orchestrates the private execution flow without taking custody. There are no API keys, no passwords, no Hinkal-issued credentials of any kind. The user's wallet is the credential. Your custody model does not change.
A simple transaction lifecycle. Get a quote, create an order, sign the required transactions, and track execution. The shape product teams already know from any modern payments API. No new mental model to internalize.
Status tracking built in. Every order is trackable end to end: pending -> in-progress -> successful / failed / expired. Your backend gets one polling surface. Your product gets one place to render state to the user. No bespoke webhook plumbing per chain.
Chain-aware transaction payloads. EVM, Solana, and TRON transaction formats are handled through one privacy execution flow. Your product integrates once. The chain-specific shape of each payload is the API's responsibility, not yours.
Compliant by design. Chainalysis KYT screening runs before any private transaction executes. Viewing keys give regulators and auditors selective disclosure. Downloadable transaction history is ready to hand to a third party out of the box. Your compliance posture stays exactly as it is today.
Whatever your product is, Hinkal API drops underneath it. Your users keep using your product. They 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 give up. The API removes that list.
No wallet migration. Your users keep their existing EVM 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 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 API ships the privacy.
The integration lifecycle, end to end
The integration runs on the lifecycle your team already knows from every modern payments API. Quote, order, sign, track.
Quote. Your backend asks the API what a private send will cost. Source chain, source and destination assets, recipient (or recipients), amount. The API returns the amount the user pays in, the amount each recipient receives, and the protocol fee. Useful for surfacing the cost to the user before they commit.
Order. Your backend posts the order with the same parameters plus the sender's address. The API returns an order ID and an unsigned deposit transaction (and, on EVM chains, an ERC-20 approval transaction when needed). Hinkal holds no custody at this point or any later one.
Sign. Your client passes the unsigned transactions to the user's wallet. The user signs and broadcasts from their own wallet. The user pays gas. Hinkal never touches the user's wallet key.
Track. Your backend polls the order ID. Once the deposit confirms on-chain, the API detects it and dispatches a private withdrawal to each recipient. Your backend watches the order move through pending -> in-progress -> successful, failed, or expired. Your product renders progress to the user the same way it renders any other payment.
That is the entire flow product teams have to internalize. Four operations on your backend, one wallet sign on the client, one polling surface, terminal-bound statuses to handle. The first integration is typically a week of backend work, not a quarter.
Underneath the lifecycle, the protocol does the cryptographic work. A smart contract called a shielded pool holds funds in transit. Balances and ownership inside the pool are recorded as cryptographic commitments — entries that record state without revealing it on-chain. Every state change is verified by 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 see deposits enter the pool and withdrawals exit it. You cannot link a deposit to a withdrawal, and you cannot 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.
The architecture, in one paragraph
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, building the resulting on-chain transactions - happens inside a confidential enclave. Every request the API receives 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 outside it only in encrypted form (sealed with Google Cloud KMS), and decrypted only inside the enclave for the single operation that needs it before being 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.
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 cannot 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. Every product here loses that volume the moment a competitor offers what they do not.
The moment, again
Three things are true at the same time. The market has named privacy a structural blocker for stablecoin scale. The most institution-aligned chain has shipped privacy at the wallet layer to keep institutions. The same privacy protocol is now a drop-in API any product can call, with a payments-API lifecycle product teams already understand, 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.
Be that product where serious capital flows.