Use Case
Institutions want to use stablecoins as settlement cash without exposing amounts, counterparties, or workflow metadata to non-participants. The solution requires stakeholder-only visibility with selective disclosure and atomic settlement capabilities with assets.Jurisdiction Note: In jurisdictions where stablecoins are restricted, these same privacy patterns apply to authorized digital currencies (e.g., CBDCs, tokenized deposits).
Business Context
Actors: Payer/Payee (banks, dealers, buy-side) · Stablecoin Issuer/Admin · Execution Venue · Post‑trade/Market Infrastructure (custody/CSD/clearing) · Regulator/Auditor · Compliance/Monitoring · Custodians/Prime Brokers · Oracles/Reference DataAdditional confidential business context is available in the private IPTF repository.
Problems
Problem 1: Payment Privacy with Regulatory Compliance
Public-by-default ledgers leak strategy and order flow and conflict with institutional confidentiality and compliance obligations. Institutions need stakeholder-only visibility with selective disclosure and atomic settlement with assets.Problem 2: User Onboarding & Fiat Integration
Institutions need practical paths to onboard their users (corporates, funds, counterparties) onto private stablecoin infrastructure. This includes integrating with existing fiat rails, compliance workflows, and ensuring users can move between fiat and private tokens seamlessly.Requirements
Requirements
- Must hide: transfer amounts, payer/payee identities to non-participants, and memos/workflow metadata; optionally timing/ordering leakage minimised
- Public OK: existence of a transaction/anchor; contract code; allow-list membership proofs (no PII); attestation schemas
- Regulator access: scoped viewing keys and/or attestations with access logging; revocation & rotation policies
- Settlement: Atomic DvP/PvP across cash↔asset or cash↔cash using ERC‑7573 semantics; minutes‑level finality OK for pilot
- Ops: predictable L2 costs; encrypted audit log with L1 anchors; issuer controls (freeze/blacklist) where mandated; KYC holder gating (e.g., ERC‑3643)
Constraints
Constraints
- Performance: Throughput/latency/finality must be measured on chosen Ethereum stack (no reliance on vendor claims)
- Regulatory: Must not weaken KYC/AML/sanctions, reporting, or books‑and‑records per local jurisdiction requirements
- Interoperability: Avoid vendor lock‑in; standardised APIs/bridges; production migration path
Recommended Approaches
See detailed solution architecture and trade-offs in Approach: Private Payments.Jurisdiction-Specific Implementations
China
Apply these patterns to e-CNY (Digital Yuan) infrastructure through approved BSN channels
EU/US
Licensed stablecoins under MiCA/GENIUS frameworks
Hong Kong
SFC-licensed digital payment token services
Non-Solutions
- Public ledger without privacy — transaction details exposed to all observers; fails institutional confidentiality requirements
- Simple payload encryption — breaks on-chain verifiability, atomic settlement, and composability with other protocols
- HTLC-only atomicity — incentive misalignment and timeout brittleness compared to conditional settlement standards like ERC‑7573 (analysis)
- Fully private infrastructure — conflicts with regulatory transparency requirements and limits interoperability
- FHE alone for unlinkability — provides confidentiality but does not hide address linkage; requires additional privacy layer (stealth addresses or similar)
Technical Note: Privacy vs Unlinkability
FHE implementations (Fhenix, Zama fhEVM) encrypt data-in-use providing confidentiality but not unlinkability. To hide address linkage and prevent transaction graph analysis, combine with ERC-5564 Stealth Addresses or equivalent unlinkability mechanisms.
Open Questions
Minimum viable privacy set
Minimum viable privacy set
Should privacy cover amounts + counterparties only, or extend to timestamps and order flow?
Regulator access model
Regulator access model
Who gets access, to what scope, with what revocation path and SLAs?
Custody and settlement finality
Custody and settlement finality
How does custody→token binding work, and how do systems sense settlement finality across domains?
L1 anchoring cadence
L1 anchoring cadence
What’s the optimal anchoring frequency, and what metadata leakage risks exist?
Standards & References
Core Standards
- ERC-7573 - Atomic cross-domain settlement
- ERC-3643 - Permissioned token standard with compliance
- ERC-5564 - Stealth addresses for unlinkability
Privacy Infrastructure
- Aztec - Privacy-focused L2
- Zama fhEVM - Fully homomorphic encryption
- Fhenix - FHE-powered confidentiality
Regulatory Frameworks
See Jurisdictions for jurisdiction-specific compliance requirements.Related Patterns
- Stateless Plasma Privacy - Onboarding privacy via client-side proving
- TEE-Based Privacy - Issuer-side private minting
- Private Stablecoin Shielded Payments
- Private PvP Settlement - Payment-versus-payment atomicity
- DvP via ERC-7573 - Delivery-versus-payment atomicity
- L2 Encrypted Offchain Audit
Related Use Cases
- Private Payments - Broader payment rails context
- Private Bonds - Asset settlement using private stablecoins
- Private Derivatives - Margin transfers using private stablecoins