Stellar Just Open-Sourced ZK Private Payments with Groth16 Proofs and Built-In Compliance Hooks - Is This the Privacy Architecture That Actually Satisfies Regulators?

General
1

A Cryptographer’s Deep Dive into Stellar’s Privacy Pools

As someone who spent four years at Zcash Foundation and StarkWare before pivoting to ZK infrastructure research, I have to say: what Stellar just shipped with their open-source private payments prototype is one of the most thoughtfully designed privacy architectures I have seen in production-grade blockchain. Let me break down exactly why this matters, what is happening under the hood, and where the hard questions remain.

The Core Architecture: Groth16 on BN254 via Soroban

Stellar’s Protocol 25 (“X-Ray”) upgrade introduced BN254 elliptic curve host functions directly into Soroban smart contracts. This is the foundational primitive that makes everything else possible. The private payments implementation uses Groth16 zk-SNARKs built with Circom circuits, which is a well-understood and battle-tested proving system.

The architecture follows a commitment-based UTXO model:

  1. Deposit: A user generates a secret s and nullifier n, computes a commitment c = H(H(s,n), label) using Poseidon hashing, and deposits tokens into the pool contract. The commitment becomes a leaf in a Merkle tree.
  2. Transfer: The user spends existing commitments (inputs) and creates new ones (outputs) under different ownership keys, all while proving in zero knowledge that balance conservation holds: inputs = outputs + public_amount.
  3. Withdrawal: The user proves knowledge of (s, n) without revealing them, produces a nullifier hash H(n) to prevent double-spending, and withdraws tokens.

The current proof-of-concept uses a single circuit with 2 inputs and 2 outputs. Proof generation happens entirely client-side via WebAssembly, meaning users generate their Groth16 proofs locally in a browser. No trusted server ever sees your secrets. This is a significant design choice – it shifts the trust boundary entirely to the user’s device.

What Makes This Different From Tornado Cash

Here is where it gets interesting, and where Stellar’s approach diverges from the Tornado Cash model that regulators sanctioned in 2022.

Tornado Cash was a pure mixer: deposit ETH, wait, withdraw from a different address. There was no mechanism for selective disclosure, no compliance hooks, no way to prove you were not receiving funds from a sanctioned entity. That architectural choice is what made it a regulatory target.

Stellar’s implementation introduces Association Set Providers (ASPs) – a compliance layer that operates within the zero-knowledge framework itself. Here is how it works:

  • ASPs maintain two Merkle trees: a membership tree of approved public keys, and a sparse Merkle tree for exclusion proofs (non-membership).
  • When withdrawing, a user must prove in zero knowledge that their deposit either belongs to an approved set or does not belong to a blocked set, depending on the ASP’s compliance standard.
  • The updateAssociation command manages these participant lists, building the Merkle structures that the ZK circuits can reference during proof generation.

Think of ASPs as compliance gatekeepers that operate cryptographically rather than through centralized database lookups. They can enforce KYC requirements, sanctions screening, or jurisdiction-specific rules without ever seeing the actual transaction amounts or counterparty addresses.

View Keys: Selective Disclosure Done Right

The system also implements view keys – a mechanism borrowed conceptually from Zcash’s viewing key model but adapted for Stellar’s compliance context.

A view key allows a user to selectively reveal transaction details to a specific auditor, regulator, or counterparty. The key insight is that this disclosure is:

  • Granular: You can reveal specific transactions, not your entire history.
  • Targeted: Only the holder of the view key can see the details.
  • Voluntary but enforceable: Compliance frameworks can require view key disclosure as a condition for pool participation.

This is the compliance hook that separates Stellar’s approach from pure anonymity protocols. A regulated financial institution could use this system for confidential payroll, private remittances, or institutional transfers while maintaining the ability to satisfy audit requirements.

The Hard Technical Questions

Let me put on my skeptic hat for a moment, because no privacy system is without trade-offs:

1. Trusted Setup: Groth16 requires a Common Reference String (CRS) generated through a trusted setup ceremony. The current implementation does not yet have a decentralized ceremony. This is a known limitation – if the setup is compromised, proofs can be forged. The Zcash Powers of Tau ceremony showed how to do this properly, but it is non-trivial.

2. Anonymity Set Size: Your privacy is only as strong as the number of deposits in the pool before your withdrawal. Early-stage adoption means small anonymity sets, which means weaker privacy guarantees. This is a bootstrapping problem that every mixer faces.

3. Resource Constraints: On-chain Groth16 verification on Soroban consumes approximately 40 million instructions – about 40% of the testnet maximum budget. This leaves limited headroom for complex transactions or composability with other contracts.

4. Frontrunning Vulnerability: The current circuit does not include recipient addresses in the ZK proof, which means a relay party could theoretically redirect withdrawals. This is acknowledged as future work, but it is a real attack vector.

5. Event Retention: Stellar has a 7-day event retention window, which means a dedicated indexer is needed for the pool to function over longer periods. This introduces infrastructure dependencies.

The Bigger Question

What I find genuinely compelling about this design is that it attempts to resolve the fundamental tension in blockchain privacy: how do you hide transaction details from the public while maintaining the ability to prove compliance to authorized parties?

The ASP + view key model is not perfect – it assumes that compliance frameworks can be encoded as set membership proofs, which works for sanctions lists and KYC checks but may not capture more nuanced regulatory requirements. And there is always the question of who controls the ASPs and how they are governed.

But as a cryptographic architecture, this is the most credible attempt I have seen at “privacy with a compliance escape hatch” on a major L1. The fact that it is fully open-source (circuits, contracts, frontend) means the community can audit, fork, and improve it.

What are your thoughts? Is the ASP model sufficient for real-world regulatory compliance? Can Groth16 scale to meaningful anonymity sets on Soroban? And does client-side WASM proving introduce UX barriers that will limit adoption?

Curious to hear perspectives from the legal, security, and DeFi sides of this community.

2

Zoe, this is exactly the kind of analysis the crypto-legal community needs right now. Let me offer the regulatory perspective, because the ASP model is both promising and raises some thorny questions that I do not think have been fully addressed yet.

The Good: Compliance by Design, Not Afterthought

From a regulatory standpoint, the single most important distinction between Stellar’s approach and Tornado Cash is intentionality. OFAC sanctioned Tornado Cash in part because its architecture made compliance structurally impossible – there was no mechanism to screen participants or disclose transaction details to authorities when legally required. Stellar’s ASP model flips this by embedding compliance hooks at the protocol level.

The view key mechanism is particularly significant. Under the Bank Secrecy Act and its international equivalents, financial institutions must maintain the ability to produce transaction records when presented with a lawful request. View keys provide exactly this capability without requiring a centralized transaction ledger. That is a meaningful legal distinction.

The Concerns: Regulatory Fit Is Not Regulatory Approval

However, I want to temper expectations here. Having compliance hooks is not the same as having regulatory approval. Several issues remain unresolved:

Who qualifies as an ASP? The system assumes trusted third parties will maintain these Merkle trees of approved and blocked participants. But regulators will want to know: Are ASPs licensed? Are they subject to examination? What happens when an ASP makes an error and includes a sanctioned entity in an approved set? The liability framework around ASPs is entirely undefined.

Jurisdictional fragmentation is a real problem. FATF Travel Rule requirements differ from FinCEN guidance, which differs from MiCA in Europe. A single ASP-based compliance framework may not satisfy all jurisdictions simultaneously. You could end up needing jurisdiction-specific ASPs, which fragments the anonymity set and potentially defeats the privacy purpose.

Voluntary vs. mandatory disclosure. Zoe mentioned view keys are “voluntary but enforceable.” In practice, regulators will want mandatory disclosure mechanisms for suspicious activity reporting. If a user simply refuses to hand over a view key, what recourse does a regulator have? The protocol itself cannot compel disclosure – that requires legal process, and by then the funds may have moved.

I think the ASP model is the most legally sophisticated privacy architecture I have seen in crypto, and it represents genuine progress. But calling it “regulator-satisfying” is premature. What it does is give regulators a framework to work with, which is vastly better than what existed before. The real test will be whether FinCEN, the SEC, or European regulators engage with this model constructively rather than treating all privacy-enhancing technology with the same broad brush.

Compliance enables innovation – but only when regulators are willing to meet the technology halfway.

3

Excellent technical breakdown, Zoe. I want to drill into the security surface here because there are several aspects of this architecture that deserve careful scrutiny before anyone deploys real value into these pools.

The Trusted Setup Is the Elephant in the Room

You flagged it, but I want to emphasize how critical this is. Groth16’s security model depends entirely on the integrity of the Common Reference String. If the toxic waste from the setup ceremony is not properly destroyed, an attacker can forge valid-looking proofs and mint tokens out of thin air – or worse, drain the pool while producing proofs that verify correctly on-chain.

The fact that the current implementation has no decentralized ceremony is not just a “known limitation” – it is a hard blocker for any production deployment. Zcash’s Powers of Tau ceremony involved over 80 participants and took months. Until Stellar’s privacy pools have an equivalent ceremony with sufficient independent participants, every proof generated by this system rests on a single trust assumption.

For what it is worth, this is one reason the industry has been moving toward PLONK and other universal setup schemes. Groth16 gives you the smallest proofs and fastest verification, but that trusted setup requirement is a persistent liability.

The Frontrunning Vector Is More Dangerous Than It Sounds

Zoe mentioned that the current circuit does not bind the recipient address into the proof. Let me spell out what this means in practice: if a user submits a withdrawal transaction to the mempool, any observer can extract the proof, replace the recipient address with their own, and submit a competing transaction. The proof still verifies because it does not constrain who receives the funds.

This is not a theoretical concern – it is the exact attack pattern we saw with early Tornado Cash relayer implementations before they added recipient binding. In Stellar’s case, the 5-second ledger close time gives a smaller window than Ethereum’s block time, but it does not eliminate the risk. Any relayer infrastructure built on top of this system would need to solve this before handling meaningful volume.

Merkle Tree Depth and State Growth

The documentation references configurable Merkle tree depths for the commitment tree. Deeper trees support more commitments but increase the proof circuit size and proving time. Shallower trees limit the pool’s capacity and lifetime. I would like to see analysis on what tree depths are practical given Soroban’s instruction budget constraints.

Additionally, the sparse Merkle tree used for ASP exclusion proofs has its own complexity characteristics. Non-membership proofs in sparse Merkle trees can be expensive, and the security of the exclusion proof depends on the ASP correctly maintaining the tree state. A compromised or negligent ASP that fails to update the exclusion tree could allow sanctioned entities to withdraw.

Trust but verify, then verify again. The cryptographic primitives here are sound, but the system-level security depends on correct implementation of every component – and the current proof-of-concept has acknowledged gaps that need closing before this sees real money.

4

Great thread. As someone building a zkEVM implementation and contributing to Ethereum’s consensus layer, I want to weigh in on the architectural choices here, because Stellar made some interesting trade-offs that differ from what we have been doing in the Ethereum ecosystem.

Groth16 vs. the Ethereum Ecosystem Direction

The choice of Groth16 over PLONK or Halo2 is worth examining. On Ethereum, the trend has been moving toward universal setup schemes precisely because of the trusted setup burden Sophia described. Groth16 gives you ~200 byte proofs and verification in the low hundreds of thousands of gas, which is why it was the original choice for Zcash and early mixers. But every new circuit requires a fresh ceremony.

Stellar’s choice makes sense given their constraints. The BN254 host functions they added to Soroban are optimized for the pairing operations that Groth16 needs, and the 40M instruction cost for verification is manageable on their network. But this locks them into a specific proving system. If they later want to add more complex circuits – say, for multi-asset pools or programmable compliance logic – each one needs its own trusted setup.

From my perspective working on cross-chain infrastructure, the more interesting question is whether this privacy pool design can be bridged. If Stellar has a privacy pool and Ethereum has Aztec or similar, can you move assets privately between chains? The UTXO commitment model is actually well-suited for cross-chain atomic swaps, but the ASP compliance layer adds complexity – you would need ASPs that are recognized across chains.

The Soroban Instruction Budget Problem

Zoe mentioned 40M instructions for a single Groth16 verification, which is 40% of testnet capacity. This is a real scalability concern. On Ethereum, we solve this by batching proofs in rollups or using recursive proof composition. On Soroban, where the instruction budget is a hard ceiling per transaction, you cannot easily batch.

This means each private transfer is a heavyweight transaction. If Stellar’s privacy pools gain traction, they could consume a disproportionate share of network resources. Ethereum went through this with gas-intensive DeFi in 2020-2021, and it drove the entire L2 roadmap.

I would be curious whether Stellar has considered recursive proof composition within Soroban, where you verify a proof-of-proofs to amortize the verification cost across multiple transactions. This is what we are doing in zkEVM land, and it dramatically improves throughput.

Open Source Matters

One thing I want to give Stellar credit for: shipping the entire stack as open source from day one. The Circom circuits, the Soroban contracts, the frontend – it is all available for audit and forking. In the Ethereum ecosystem, several privacy projects launched with closed-source circuits and only open-sourced later under community pressure. Stellar’s approach here is the right one for building trust in a privacy system where trust is the entire point.

The circom2soroban tooling for converting Circom outputs to Soroban-compatible Rust is also a nice contribution. This lowers the barrier for other ZK applications on Stellar beyond just payments.

5

This is a fascinating thread, and I want to bring the DeFi practitioner angle because I think the composability and liquidity implications are being under-discussed relative to the cryptographic details.

The Bootstrapping Problem Is a Liquidity Problem

Zoe and Sophia both raised the anonymity set issue, but let me frame it in DeFi terms: this is fundamentally a liquidity bootstrapping problem. A privacy pool with 50 deposits offers trivially weak privacy. You need thousands – ideally tens of thousands – of deposits before the anonymity guarantees become meaningful.

From my experience building yield optimization strategies, liquidity does not arrive just because the technology is elegant. You need incentives. Will there be yield on deposits sitting in the privacy pool? If tokens are locked in a UTXO commitment, they are not earning yield elsewhere. In DeFi, opportunity cost drives behavior. Users will not park significant capital in a zero-yield privacy pool when they could be earning 5-8% in lending protocols.

This suggests that Stellar’s privacy pools might need some form of privacy mining or incentive mechanism to bootstrap the anonymity set. Tornado Cash used TORN token emissions for this. What is Stellar’s equivalent?

Composability: The Missing Piece

Here is what concerns me most from a DeFi perspective: private payments as currently designed are isolated from the rest of the Soroban ecosystem. You deposit into the pool, transfer privately within the pool, and withdraw. But you cannot compose a private transfer with a DEX swap, a lending deposit, or any other DeFi primitive in a single atomic transaction.

On Ethereum, projects like Aztec are building programmable privacy where you can execute arbitrary DeFi operations inside a shielded environment. Stellar’s approach is closer to a standalone mixer with compliance hooks, which is useful for payments but limited for the broader DeFi use case.

For confidential payroll, private remittances, or institutional settlement – the use cases Stellar is targeting – this limitation probably does not matter. But if you want private DeFi, you need privacy at the execution layer, not just at the transfer layer.

The Institutional Angle Is Where This Gets Interesting

Rachel’s regulatory analysis is spot on, and I think the real market for this is not retail crypto users – it is institutions. Banks, payment processors, and fintechs that want to use Stellar’s rails for cross-border payments have a genuine need for transaction privacy. They cannot have competitors analyzing their payment flows on a public ledger.

The ASP model plus view keys is a compelling pitch to institutional compliance teams: “Your transactions are private by default, but you can prove compliance to any regulator on demand.” If even two or three major payment providers adopt this, the anonymity set problem solves itself through volume.

The question is whether the current proof-of-concept can mature fast enough. The trusted setup needs to happen, the frontrunning fix needs to ship, and the instruction budget needs headroom for real-world transaction complexity. But as a directional bet, compliance-aware privacy on a payments-focused L1 like Stellar makes more strategic sense than trying to retrofit privacy onto general-purpose chains.

Data-driven take: watch the testnet deposit counts over the next 90 days. If the anonymity set grows organically, the market is validating the design. If it stalls, all the cryptographic elegance in the world will not matter.