Private PvP (cash to cash) Settlement via ERC-7573
Settle two stablecoin legs against each other atomically while keeping amounts and counterparties visible only to the transacting parties and their auditors. Each leg uses a shielded transfer layer for privacy; the ERC-7573 escrow pattern on both chains conditions release on verified finality of the opposite leg, so neither side settles without the other. The construction avoids the public amounts and timing leakage of plain HTLCs and avoids relying on time-locks for safety.
Settle two stablecoin legs against each other atomically while keeping amounts and counterparties visible only to the transacting parties and their auditors. Each leg uses a shielded transfer layer for privacy; the ERC-7573 escrow pattern on both chains conditions release on verified finality of the opposite leg, so neither side settles without the other. The construction avoids the public amounts and timing leakage of plain HTLCs and avoids relying on time-locks for safety.
- ERC-7573 conditional-escrow contract on each chain, parameterised with the release condition for the opposite leg.
- Shielded transfer layer on each chain that hides amounts and counterparties on the transacting side.
- Price or FX oracle feed, referenced by feed identifier, used to check the rate condition at settlement time when the legs are in different units.
- Finality-sensing component that produces an attestation (or cross-domain message) proving the paying leg finalised at or above the agreed terms.
- Optional cross-domain messaging layer when the two legs live on different L2s or app-chains.
- Attestation layer for scoped disclosure to auditors, recording which parties settled, at what rate, and when, without exposing amounts publicly.
Guarantees:
- Atomic settlement across two chains or two assets: both legs settle or both revert, without relying on time-locks for safety.
- Amount privacy: amounts are hidden on the chains themselves; only stakeholders and auditors with the viewing keys see the full trade.
- Scoped disclosure: attestations log regulator access without exposing amounts publicly.
Threat model:
- Oracle honesty and update cadence. A compromised or stale feed lets an attacker settle outside the agreed tolerance band.
- Finality-sensing correctness on the paying leg. A fake or premature finality attestation can trigger a one-sided release.
- Non-censoring cross-domain relayer. A relayer that withholds messages stalls settlement; escrows must fail safe back to the originator.
- Upgrade governance on both escrow contracts. A unilateral upgrade on one leg can freeze settled funds.
- Out of scope: correlation of settlement windows across the two chains by a global network observer.
- Oracle dependence is the main operational risk: outage, stale data, or price manipulation can each block settlement or produce an unfair release.
- Cross-L2 finality sensing and the failure-recovery path add operational overhead relative to a single-chain DvP.
- Fragmentation across issuers and L2s may require market-making facilities to source liquidity on both sides.
- Debuggability: amounts and counterparties are hidden on-chain, so post-mortems require coordinated viewing-key access with the counterparty.
Two regulated banks settle a shielded USD-stablecoin leg against a shielded EUR-stablecoin leg on separate L2s. Each bank deposits its shielded leg into an ERC-7573 escrow that references an EUR/USD price feed and the opposite escrow's finality proof. When the USD leg finalises within tolerance, a cross-domain attestation releases the EUR escrow to the USD-paying bank. Chain observers see that two escrow contracts settled but not the amounts or identities. The banks' auditors reconstruct the full trade via the shielded viewing keys and the attestation log.