Atomic DvP via ERC-7573 (cross-network)

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.

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.

Post-quantum exposure

Risk · medium
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.

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