Title: Atomic DvP via ERC-7573 (cross-network) · Pattern · EthSystems

URL Source: https://original.es-internal.pages.dev/patterns/pattern-dvp-erc7573/

Markdown Content:
---
description: Enable atomic Delivery-versus-Payment across two networks so that either the asset is delivered and payment is completed, or the asset returns to the seller. The pattern targets institutions that need cross-network settlement with predictable failure behavior, auditability, and optional privacy extensions layered on top.
title: Atomic DvP via ERC-7573 (cross-network) · Pattern · EthSystems
image: https://original.es-internal.pages.dev/og.png
---

[Skip to content](#main-content) 

#### Works best when

* Asset and cash legs live on different networks (L1 or L2).

#### Avoid when

* Both legs already settle on the same network with simple on-chain transfers.
* You're searching for a production-ready solution (EIP not yet recommended).
* You're searching for a fully trustless solution.

Vector

Oracle decryption relies on standard public-key encryption; outcome key commitments inherit hash assumptions. Payment-network signatures carry host-chain PQ exposure.

Mitigation

Migrate decryption to PQ-safe KEM schemes (Kyber, ML-KEM) as ERC-7573 extensions mature. See [Post-Quantum Threats](../domains/post-quantum.md).

## Components

* Locking contract on the asset network registers the hashed outcome keys per trade identifier and gates delivery of the locked asset.
* Decryption contract on the payment network holds the encrypted outcome keys and calls the oracle after observing the payment result.
* Decryption oracle is a single or multi-operator service that decrypts the outcome key matching the actual payment result. Stateless by design.
* Off-chain trade negotiation layer assigns a shared trade identifier, creates and distributes two outcome keys per trade (success and failure), and holds them off-chain.
* Oracle proxy and callback contracts bridge the decryption contract and the oracle per the ERC-7573 interface.
* Monitoring and logging infrastructure watches both networks for event correlation and reconciles trade state.

## Protocol

1. user Two institutions agree off-chain on the asset, quantity, payment token, amount, shared trade identifier `T`, and a latest time to settle or unwind.
2. user The trade-setup system generates two outcome keys for `T` (one meaning "deliver to buyer", one meaning "return to seller") and distributes them off-chain.
3. contract The seller locks the asset in the locking contract on the asset network under `T`, registering hashed values of the two outcome keys.
4. contract The buyer registers `T` and payment details in the decryption contract on the payment network, along with encrypted forms of the same two outcome keys.
5. user The buyer executes the payment through the decryption contract. The contract checks the payment against the registered details for `T`.
6. operator The decryption contract calls the oracle, which decrypts the encrypted key matching the actual outcome (success or failure) and returns it.
7. contract An authorized party submits the outcome key to the locking contract, which verifies it against the registered hashes and either delivers the asset to the buyer (on success) or lets the seller reclaim it (on failure or timeout).

## Guarantees & threat model

Guarantees:

* Atomic settlement: for each trade, both asset and cash legs settle together, or the asset is reclaimed by the seller. One-sided settlement is not an intended state.
* Defined failure behavior: if the payment fails, is cancelled, no outcome key is released, or the latest time passes, the contracts expose a predictable reclaim path for the seller.
* Optional privacy extensions allow observers to see that a trade settled or not without seeing full terms; institutions can still disclose details off-chain when required.

Threat model:

* Soundness of the commitment scheme binding outcome key hashes.
* Non-colluding decryption oracle operators. A single operator in a centralized deployment can withhold decryption or release the wrong outcome key, breaking atomicity or liveness.
* Non-censoring sequencers on both networks during the settlement window. A censored payment or settlement transaction forces the fallback to the reclaim path.
* Honest trade-setup system that generates unique, unpredictable outcome keys and distributes them correctly. Collision or replay across trades breaks the guarantee.
* Network-layer metadata (IP, timing, gas patterns) is out of scope.

## Trade-offs

* Oracle governance is a recurring operational question. Institutions must agree on who runs the oracle, how its keys are managed, and how incidents (downtime, misconfiguration) are handled.
* Settlement latency depends on payment finality, oracle processing, and any proof generation, adding delay relative to same-network transfers.
* Integration effort is non-trivial. Internal systems must handle outcome keys, track trade identifiers, listen to events on both networks, and reconcile them with internal ledgers.
* Exceptional cases (incorrect parameters, operational errors, regulatory holds) still require documented off-chain procedures. Fully automated recovery is out of scope.
* Standard ERC-7573 provides no privacy. Confidentiality requires layering additional patterns: threshold oracles, minimal on-chain data, or private payment layers.

## Example

* An issuer issues a tokenized bond on Ethereum L1 (asset leg). A buyer holds EURC stablecoin on an L2 rollup (cash leg).
* They agree off-chain on trade identifier `T`, bond quantity, payment amount, and a latest settlement time.
* The seller locks the bond in the locking contract on L1 under `T`.
* The buyer registers `T` and executes the EURC payment via the decryption contract on the rollup; the oracle releases the success outcome key for `T`.
* That key is submitted to the L1 locking contract, which transfers the bond to the buyer. If the payment had failed or been cancelled, the failure outcome key would have been used instead and the seller would reclaim the bond.

## Privacy extensions

Standard ERC-7573 provides atomic settlement but no privacy. For institutional use cases requiring confidentiality:

* Threshold decryption oracle: Run the oracle with several independent operators and require a k-of-n quorum before an outcome key is released.
* Minimal on-chain trade data: Keep full trade terms (price, size, counterparties) in internal systems; on-chain, store only a trade identifier and a short reference that links back to those records.
* Private or proof-based payment layer: Use a network or rollup for the cash leg that hides detailed balances but can provide a clear "payment completed or not completed" result for each trade identifier.

These extensions do not change how the contracts decide outcomes: the asset contract still receives an outcome key and either delivers the asset or allows reclaim.

## See also

* [ERC-7573 specification](https://ercs.ethereum.org/ERCS/erc-7573)
* [Private Trade Settlement approach](/approaches/approach-private-trade-settlement/)

CROPS profile

Censorship-resistance: mediumOpen source: partialPrivacy: noneSecurity: medium

CRCensorship-resistancemedium

Oracle governance is typically codified in bilateral or consortium agreements, so the practical censorship risk sits below the protocol-level score. Reaches `high` if threshold decryption oracles with k-of-n quorum replace single-operator oracles, removing any single exclusion point.

OSOpen sourcepartial

Oracle and contract implementations vary by deployment. Improves to `yes` by releasing oracle implementations and outcome key services under a copyleft license.

PPrivacynone

Standard ERC-7573 provides atomic settlement but no privacy: trade identifier, amounts, and counterparties may be observable on-chain. Reaches `partial` or `full` by layering threshold-encrypted mempools, minimal on-chain trade data, and private or proof-based payment layers.

SSecuritymedium

Rides on the decryption oracle operator's honesty for liveness. Improves to `high` by replacing operational trust with verifiable proofs of outcome key validity and threshold quorum.

Standards 2 
* `ERC-7573`
* `ERC-20`

#### Referenced by

approaches4
* [Atomic DvP Settlement](/approaches/approach-dvp-atomic-settlement/)
* [Private Smart Derivatives](/approaches/approach-private-derivatives/)
* [Private Trade Settlement](/approaches/approach-private-trade-settlement/)
* [White-Label Infrastructure Deployment](/approaches/approach-white-label-deployment/)
use cases1
* [Private Stablecoins for Institutional Payments](/use-cases/private-stablecoins/)
building blocks18
* [Commit-and-Prove Cross-Chain Settlement](/patterns/pattern-commit-and-prove/)
* [Hybrid Public-Private Modes](/patterns/pattern-hybrid-public-private-modes/)
* [Hybrid TEE + ZK settlement](/patterns/pattern-tee-zk-settlement/)
* [Low-cost L2 + Off-chain Encrypted Audit Log](/patterns/pattern-l2-encrypted-offchain-audit/)
* [Modular Privacy Stack](/patterns/pattern-modular-privacy-stack/)
* [MPC Custody and Transaction Control](/patterns/pattern-mpc-custody/)
* [Permissioned Ledger Interoperability](/patterns/pattern-permissioned-ledger-interoperability/)
* [Pre-trade Privacy (Encrypted Order Flow)](/patterns/pattern-pretrade-privacy-encryption/)
* [Privacy L2s](/patterns/pattern-privacy-l2s/)
* [Private Intent-Based Vaults](/patterns/pattern-private-vaults/)
* [Private ISO 20022 Messaging & Settlement](/patterns/pattern-private-iso20022/)
* [Private PvP (cash to cash) Settlement via ERC-7573](/patterns/pattern-private-pvp-stablecoins-erc7573/)
* [Private Set Intersection (Circuit-based)](/patterns/pattern-private-set-intersection-circuit/)
* [Private Set Intersection (DH-based)](/patterns/pattern-private-set-intersection-dh/)
* [Private Set Intersection (FHE-based)](/patterns/pattern-private-set-intersection-fhe/)
* [Private Set Intersection (OPRF-based)](/patterns/pattern-private-set-intersection-oprf/)
* [Private Stablecoin Shielded Payments](/patterns/pattern-private-stablecoin-shielded-payments/)
* [zk-TLS](/patterns/pattern-zk-tls/)
vendors5
* [Chainlink ACE](/vendors/chainlink-ace/)
* [Fireblocks](/vendors/fireblocks/)
* [Paladin](/vendors/paladin/)
* [Soda Labs](/vendors/soda-labs/)
* [Space and Time](/vendors/space-and-time/)
RFPs2
* [Living Benchmark Dashboard](/rfps/rfp-benchmark-dashboard/)
* [zk-SPV for Private Cross-Chain DvP](/rfps/rfp-zk-spv-dvp/)

×

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://ethsystems.org/#organization","name":"EthSystems","url":"https://ethsystems.org/","logo":"https://ethsystems.org/icon-maskable.png","sameAs":["https://x.com/eth_systems","https://www.linkedin.com/company/ethsystems/","https://github.com/ethsystems"]},{"@type":"WebSite","@id":"https://ethsystems.org/#website","url":"https://ethsystems.org/","name":"EthSystems","publisher":{"@id":"https://ethsystems.org/#organization"}}]}
```