Hinkal WaaS - Programmable Privacy for Institutions

More institutional payment volume is moving to stablecoin rails every quarter - payroll, vendor payments, B2B settlement, treasury rebalancing. That volume runs on public ledgers, meaning balances, counterparties, and cash flow patterns are visible by default. For most institutions, that exposure is incompatible with how their finance operations actually run.

Bessemer Venture Partners named privacy as one of five structural blockers preventing stablecoins from scaling into global financial infrastructure - and named Hinkal as one of two solutions. Polygon validated that read by integrating Hinkal as the privacy layer inside its institutional wallet. The question now is which teams get access to that same infrastructure - and on what terms.

Hinkal WaaS is built for institutions that need to provision and operate stablecoin wallets for their own users - creating them, assigning them, executing transactions on behalf of users, and enforcing org-level policies - without building the tech infrastructure to do it. The wallets belong to the institution's org structure. The privacy protocol runs underneath, managed by Hinkal's enclave.

[[KEY_TAKEAWAYS]]

How WaaS Works

A company administrator creates an organization and has full control over it. The administrator provisions users inside that organization, assigns wallets to each, and defines the policies that govern what each user is permitted to do - spend limits, allowlists, action restrictions. The administrator can also act on behalf of users directly, executing transactions or managing wallets from the same backend.

Org → User → Wallet → Policy - not as a diagram, but as the actual call sequence. The institution owns the org structure. It owns the wallets. Hinkal provides the enclave, the protocol, and the compliance layer underneath.

For teams outside TypeScript who cannot integrate the Hinkal SDK directly, WaaS delivers the same infrastructure through a standard REST interface -  Python, Go, Java, .NET, Rust.

The Five Transaction Modes

Privacy is opt-in per transaction. Each API call chooses its own mode.

Private → Private. Both sender and recipient are inside the shielded pool. Nothing is revealed on-chain. 

Private → Public. A shielded balance pays out to a public address. The link back to the original deposit or the sender stays hidden. 

Public → Private. Public funds enter the shielded pool and become a private commitment.

Public → Public via Hinkal. Both addresses are public, but the relationship between them is broken by routing through the pool.

Plain public. A normal transfer with no privacy applied. 

Real operations are mixed. An internal payroll run is private → private. A vendor invoice to an exchange wallet is private → public. A tax payment is plain public. WaaS handles all five from one API.

Security: How the Enclave Works

Every security-critical operation runs inside a hardware-sealed enclave - a GCP Confidential VM powered by AMD SEV, which encrypts the VM's memory at the chip level. The host, the cloud provider, and Hinkal engineers cannot read what is inside.

Private keys are generated inside the enclave, encrypted before they are stored, and decrypted only at signing time - inside the enclave. The API server and database never see raw key material. Only the signature comes out. Every API request is signed with the customer's own Ed25519 keypair; there are no passwords or shared tokens. The enclave re-validates each request independently before acting, so a compromised API layer cannot forge a signing request. Every record the enclave writes - wallets, policies, encrypted keys - is signed by the enclave before storage. A tampered record fails verification on the next read.

The customer does not have to trust Hinkal's infrastructure. The architecture verifies itself.

Compliance, Built In

Chainalysis KYT screening runs on every private transaction before it executes - a flagged address never enters the shielded pool. Viewing keys give an organization selective, scoped, revocable read-access for auditors, regulators, or internal compliance teams, without making the full history public. Policy enforcement runs inside the hardware enclave before any signing happens, not at the application layer where it could be bypassed.

Private to the public. Provable to the parties who have standing to verify it.

Where This Fits

WaaS is the right surface when the institution needs to own the wallets, not just use them.

Enterprises running stablecoin payroll or contractor payments where the company is the administrator and needs org-level policies enforced on every disbursement.

Banks and corporate treasuries provision wallets for employees or vendors and execute payment flows programmatically from their own backend.

OTC desks and crypto-native institutions managing client wallets and running private settlements without building a custody stack or an HSM project.

If your users hold their own wallets and sign their own transactions, Hinkal's API is the simpler fit. If your institution needs to provision and operate the wallets - WaaS is where that starts.

Read the WaaS documentation:

‍