Private Stablecoins for Institutional Payments

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.

Additional 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 Data

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:

  • 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:

  • 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)

Open Questions

  • Minimum viable privacy set (amounts+counterparties only vs timestamps/order flow)?
  • Regulator access model (who, what scope, revocation path, SLAs)?
  • Custody→token binding and settlement finality sensing across domains?
  • L1 anchoring cadence and metadata leakage analysis

Notes And Links

Related patterns