B2B stablecoin payments grew 733% year over year in 2025 to roughly $226 billion annually, accounting for about 60% of all real stablecoin payment activity, according to McKinsey and Artemis Analytics research published in February 2026. 

Hinkal provides privacy infrastructure for stablecoin payments and on-chain financial operations, keeping payment, settlement, payout, and treasury data confidential on the public chains businesses already use. 

As that volume moves on-chain, finance teams hit a problem their compliance officers see immediately: a public ledger exposes counterparties, invoice amounts, and payroll to competitors, vendors, and anyone with a block explorer. 

The market has produced two structurally different answers, and they are almost always compared at the feature level rather than where the decision actually gets made. 

This article breaks down the compliance architecture behind Privacy Pools' association sets and Hinkal's selective disclosure model, so you can judge which one survives a real compliance review.

[[KEY_TAKEAWAYS]]

The Question a Compliance Review Actually Opens With

Most comparisons between privacy protocols argue about anonymity set size, gas costs, and supported tokens. A compliance officer opens with none of those. They open with four questions:

1. Can we show a regulator, auditor, or banking partner exactly what moved, when, and to whom?
2. Can a third party retroactively invalidate our position after settlement has already been cleared?
3. Are the numbers our competitors care about, invoice sizes, payroll, vendor pricing, actually hidden?
4. Does adopting this change our custody, screening, or reporting obligations?

Association sets and selective disclosure answer those questions in fundamentally different ways, because they were built to solve different problems. Privacy Pools is engineered to prove a negative to the public. Hinkal is engineered to prove a positive, on demand, to a named party.

How Privacy Pools Works: Association Sets and Proof of Innocence

Privacy Pools launched on Ethereum mainnet in March 2025, built by 0xbow and derived from a 2023 research paper co-authored by Vitalik Buterin and Chainalysis researcher Jacob Illum, among others. The Block described it as a system that uses zero-knowledge proofs and an Association Set Provider to ensure only clean funds enter the pool.

The mechanics are straightforward. A user deposits assets into the pool. The Association Set Provider, or ASP, vets that deposit and maintains a Merkle tree of pre-approved activity. The user then generates a zero-knowledge proof of membership in that approved set and withdraws to a fresh address. The on-chain link between deposit and withdrawal is broken, and no wallet history is revealed.

Two design details matter more than anything else in a compliance review:

1. Per 0xbow's own documentation, the ASP supports dynamic updates, meaning previously approved deposits can be revoked. 
2. If a deposit is later flagged, a "ragequit" or forced-exit function lets the depositor reclaim funds without contaminating the rest of the pool. 

The forced exit is a sensible safety valve. It is also an admission of the model's core dependency: privacy persists only for as long as the deposit remains inside an approved set that someone else curates.

Adoption reflects a young protocol. The Defiant reported in November 2025 that since its March 2025 launch, Privacy Pools had processed roughly $6 million from more than 1,500 users across 1,186 withdrawals, supporting ETH, wrapped Bitcoin, and major stablecoins including USDC, USDT, and DAI, live on Ethereum.

How Hinkal Works: Screening at Entry, Disclosure on Demand

Hinkal is not a mixer, not a private L1 or L2, and not a privacy rollup. It is a smart contract deployed on the public chains a business already operates on, letting users hold private balances controlled through their existing wallet keys. Nothing migrates.

The compliance architecture rests on three components:

• Chainalysis KYT screening: Wallet addresses are screened before execution, preventing high-risk funds from entering the smart contract. Screening happens at the entry point, not retroactively.
• Viewing keys: Users hold keys that decrypt their own transaction history. A viewing key can be shared full or partial, scoped to specific transactions or time ranges, and revoked, giving auditors, regulators, or counterparties exactly what they need without exposing anything on the public ledger.
• Downloadable transaction history: Exportable out of the box and ready to hand to a third party, with no protocol-side dependency and no request queue.

Execution uses UTXO-style commitments and nullifiers with zkSNARK (Groth16) proofs. Private balance reads, UTXO handling, proof generation, and transaction building run inside Hinkal's secure enclave, where raw key material is never exposed. Hinkal never holds funds or keys. The existing wallet is the credential.

Side by Side: The Compliance Model, Not the Feature List

Where the Two Models Diverge Under Review

1. Who carries the burden of proof

An association set proves your funds are not in a bad cohort. That is a statistical statement about the company you keep, and it holds only as strongly as the provider's screening list on the day the proof is checked. Selective disclosure proves the transaction itself: this party sent this amount to this counterparty on this date, cryptographically, to whoever you choose.

When a banking partner asks a business to substantiate a payment, or an auditor reconciles a payout run against the general ledger, a membership proof does not answer the question. It answers a different one. A decrypted transaction history answers the one that was asked.

2. Retroactive revocation and settlement finality

Because an ASP can revoke previously approved deposits, a business's privacy position remains contingent on a third party's continued judgment after settlement has already occurred. For a PSP settling merchant volume, or a payroll platform running a monthly cycle, contingent finality is an operational risk, not a privacy feature. It also creates an awkward disclosure: the business cannot promise a counterparty confidentiality it does not unilaterally control.

Hinkal screens before execution. Once a transaction settles, no external party can reclassify the business's position inside the contract, and no forced exit is required to protect it.

3. What actually stays hidden

This is the most commonly misread difference, and the most expensive one.

Privacy Pools breaks the link between a deposit and a withdrawal. Both events remain individually visible on-chain even when the connection between them does not. Amounts entering and leaving the pool are observable.

Hinkal's private-to-private flow removes the link and the data. Both sender and recipient operate from confidential balances and the amount is hidden. On-chain, the transaction shows no sender wallet and no recipient wallet, only the Hinkal smart contract and the relayer address. Because the relayer broadcasts the transaction, the user's own wallet never appears as its origin. No observer can determine who sent, who received, or how much.

For a business, that is the difference between concealing a relationship and concealing a price. A competitor reading a public ledger does not need to know which deposit funded which withdrawal to infer what you pay your largest supplier. They need the amount. Hinkal also supports public-to-public flows, where funds start and end in public wallets but the deposit and withdrawal are cryptographically unlinkable, so no shielded-address UX is required on either side.

4. Whether the model fits an enterprise payment flow

Privacy Pools is a deposit-and-withdraw product organized around a dedicated wallet. That is a coherent design for an individual protecting personal wallet history. It is not a settlement surface.

Hinkal is designed to sit underneath flows that already exist:

• Hinkal Pay handles confidential settlements and payouts across Solana, TRON, Ethereum, and major EVM networks without changing wallets, chains, or stablecoins.
• Hinkal Prime adds permissioned multi-user access, pending payout review, batch payouts built for payroll and vendor settlement, and compliance controls on high-value transactions with viewing-key audit access.
• Hinkal Integrations exposes the same protocol through a language-agnostic API and an SDK, so a custodian, institutional wallet, PSP, or exchange can place a private balance next to the regular balance and a private send next to the regular send, inside the product users already use. A forward-deployed Hinkal engineer supports the integration throughout.

Bessemer Venture Partners noted in April 2026 that Hinkal enables enterprises to keep stablecoin transaction amounts, counterparties, and balances confidential on all major chains through a single SDK or API integration, placing it alongside Canton in the institutional privacy category.

5. Chain coverage as a compliance constraint

Enterprise settlement rarely lives on one network. Ethereum carries large-value transfers, Solana carries speed, and TRON carries a large share of global stablecoin utility flows. A privacy model that exists on Ethereum only forces a business to run one compliance policy for shielded flows and a separate one for everything else, then reconcile the two at audit.

Hinkal operates across Ethereum, Polygon, Arbitrum, Optimism, Base, Solana, TRON, Arc, and Tempo, with cross-chain bridging that preserves privacy. One disclosure mechanism, one screening standard, one policy across the entire footprint.

Which Model Fits Which Business

The Honest Case for Association Sets

Association sets solve a real problem elegantly. Proving dissociation from sanctioned activity is precisely what a mixer cannot do, and it changes user behavior in measurable ways. AMLBot data cited by Metaverse Post in early 2026 shows USDC accounting for 81% of Privacy Pools' volume, while Tornado Cash, which performs no screening, sees 99.4% of its volume in DAI, the stablecoin that cannot be frozen. Users bring freezable assets to protocols they trust. That is a meaningful validation of screened privacy as a category.

The ASP design is also open-source, so any protocol or jurisdiction can operate its own version, which is genuinely useful public infrastructure.

But solving dissociation is not the same as solving disclosure. A compliance review does not stop at "these funds are clean." It asks for records. It asks whether commercially sensitive amounts are exposed to competitors. It asks whether the business can produce a scoped, time-bounded history for one auditor without deanonymizing its entire ledger to everyone. 

Association sets were never designed to answer those questions. Selective disclosure was.

Conclusion

Hinkal delivers full-privacy multichain settlement where sender, recipient, and amount stay confidential, compliance stays intact, and nothing about a business's existing chains, wallets, custody, or workflows has to change. 

Association sets and selective disclosure are not competing implementations of one idea. Privacy Pools proves funds are not illicit and depends on a provider to keep saying so, on a single chain, while leaving amounts in the open. Hinkal screens with Chainalysis KYT before execution, hides the data competitors actually exploit, and hands auditors a scoped, revocable viewing key the moment they ask. 

For any business whose compliance function needs records rather than reassurances, that distinction decides the review. 

Book a demo to see how Hinkal fits into the settlement flow you already run.

Read Next:

• Best Privacy Infrastructure for Tokenized Asset Platforms
• How to Shield and Unshield Crypto Assets with Hinkal: A Step-by-Step Guide
• Best Railgun Alternatives for Private Stablecoin Treasury Management (2026)

FAQs:

1. What is the difference between association sets and selective disclosure?

The difference between association sets and selective disclosure is what each one proves. Association sets prove that funds are not linked to illicit sources by demonstrating membership in an approved deposit set. Selective disclosure proves the contents of a transaction to a chosen party using a viewing key, revealing sender, recipient, amount, and date without exposing anything on the public ledger.

2. Which privacy model is better for businesses, Hinkal or Privacy Pools?

The better privacy model for businesses is Hinkal, because business compliance reviews require producible records and amount confidentiality rather than proof of non-association. Hinkal hides sender, recipient, and amount together, screens addresses with Chainalysis KYT before execution, and provides scoped viewing keys plus downloadable transaction history for auditors, regulators, and banking partners.

3. Does Privacy Pools hide transaction amounts?

Privacy Pools does not hide transaction amounts. The model works by breaking the on-chain link between a deposit and a later withdrawal, so both events stay individually observable even though the connection between them is concealed. Hinkal's private-to-private transfers hide the sender, the recipient, and the amount simultaneously.

4. Can a compliance officer audit Hinkal transactions?

A compliance officer can audit Hinkal transactions using viewing keys, which decrypt a user's transaction history and can be shared in full or in part, scoped to specific transactions or time ranges, and revoked afterward. Hinkal also provides downloadable transaction history out of the box, ready to hand to an auditor, regulator, or counterparty.

5. Which chains does Hinkal support compared to Privacy Pools?

Hinkal supports Ethereum, Polygon, Arbitrum, Optimism, Base, Solana, TRON, Arc, and Tempo, with privacy-preserving cross-chain bridging across EVM, Solana, and TRON networks. Privacy Pools is live on Ethereum, which confines shielded settlement to a single network and forces businesses to run separate privacy and reporting policies for every other chain they settle on.