Works best when
- The cash leg must be private in both amounts and counterparties, with selective disclosure available to auditors.
- Ethereum-native tooling on an L2 or app-chain is preferred, with composability into PvP or DvP flows.
Avoid when
- Public transparency of the cash leg is required by policy.
- Off-chain netting already satisfies the confidentiality requirement.
I2I vs I2U — context differences
Institution to institution
I2IBetween institutions the issuer and both counterparties are KYC-aligned with legal recourse. Permissioned shielded pools and ERC-3643 gating preserve unlinkability within the consortium while viewing keys cover audit. Issuer-level controls (freeze, blacklist) are negotiated contractually and bounded by governance.
Institution to end user
I2UFor end users the cash leg must not depend on an issuer who can freeze balances unilaterally or on an operator who can block withdrawals. Forced withdrawal and user-controlled viewing keys are required to make the privacy guarantee meaningful; without them, censorship resistance collapses to low.
Post-quantum exposure
Risk · high- Vector
- Pairing-based shielded pools (Groth16, PLONK/KZG) broken by CRQC. HNDL risk applies to encrypted notes and any long-lived audit log encrypted under classical asymmetric keys.
- Mitigation
- Migrate to STARK-based shielded pools with hash commitments; re-encrypt long-lived audit logs under post-quantum key encapsulation. See Post-Quantum Threats.
Visibility
| Actor | Sees |
|---|---|
| Counterparty |
|
| Chain |
|
| Regulator |
|
| Public | — |
Components
- Confidential cash token: either a native private-mode stablecoin or a wrapped form of a public ERC-20 held inside a shielded pool or under encrypted balances.
- Privacy L2 or app-chain: programmable-privacy zero-knowledge L2 (private notes plus viewing keys) or a Fully Homomorphic Encryption runtime (encrypted balances and amounts).
- Stealth-address layer (ERC-5564) to hide payer and payee identities in the Fully Homomorphic Encryption case, since encrypted balances alone do not anonymise counterparties.
- Issuer controls bound to ERC-3643 or equivalent gating: allow-listing, freeze, blacklist where mandated by policy.
- Atomic-settlement hook via ERC-7573 to compose the cash leg with an asset leg (DvP) or another cash leg (PvP).
- Audit and disclosure layer: viewing keys, selective zero-knowledge disclosure proofs, or threshold-decryption keys for regulators; on-chain attestations (EAS) log access events.
- Wallet or custody module, optionally MPC-based; issuer admin keys where policy requires.
- Optional L1 anchor of the encrypted audit log and cutoff oracles.
Protocol
- operator Optional gating: KYC issuers or custodians attest allow-listed participants via verifiable attestations and enforce ERC-3643 eligibility at mint and transfer.
- operator Mint a native private-mode stablecoin or wrap a public ERC-20 into confidential form (shielded pool or encrypted-balance token).
- user Construct a shielded transfer: generate an encrypted note or ciphertext so that only the payer, payee, and any permitted auditor can view amount and counterparty.
- contract Verify the transfer (zero-knowledge proof or homomorphic evaluation), update commitments or encrypted balances, and record any nullifiers.
- auditor Obtain a scoped view via the payee's viewing key or a selective zero-knowledge disclosure proof; access is logged via attestations.
- contract Optional atomic leg: compose with ERC-7573 to settle DvP against a tokenised asset leg or PvP against another cash leg.
- operator Optional: post commitment roots and encrypted audit log hashes to L1 and archive the append-only audit trail off-chain.
Guarantees & threat model
Guarantees:
- Hides amounts, counterparties, and memos from non-participants; reveals only to stakeholders in the transfer and any permitted auditor.
- Atomic DvP (cash against asset) or PvP (cash against cash) when composed with ERC-7573.
- Verifiable audit trail via attestations; issuer controls enforce policy without exposing transfer contents.
Threat model:
- Soundness of the underlying proof system or Fully Homomorphic Encryption scheme.
- Honesty of the L2 sequencer or prover and of any threshold decryption committee.
- Non-compromised relayer and paymaster. A colluding relayer can link user IPs to shielded activity; a colluding paymaster can selectively censor.
- Unconstrained issuer controls (freeze, blacklist without governance) break the guarantee for users; address at the policy layer.
- Network-layer metadata (timing, gas payer, IP) is out of scope and must be covered by a network-anonymity pattern.
Trade-offs
- Zero-knowledge or Fully Homomorphic Encryption proofs add per-transfer cost and latency compared with a public ERC-20 transfer.
- Developer experience varies: non-EVM privacy L2s require circuit DSLs; Fully Homomorphic Encryption stacks depend on coprocessors and oracles.
- Timing and ordering metadata can persist even when contents are hidden; mitigate with batching or delayed anchors.
- Stealth addresses alone do not provide issuer-level policy or full cash-flow privacy; they complement, rather than replace, a shielded cash token.
- Monotonic on-chain growth: commitments or ciphertexts accumulate indefinitely; prover or coprocessor costs drift up over time.
Example
- A dealer pays weekend margin in a confidential stablecoin on a privacy L2. The venue receives funds without public leakage. The regulator gets read-only access via a time-bound viewing key. The payment leg participates in an ERC-7573 PvP against another stablecoin or a DvP against tokenised collateral.