fix(pattern): correct cross-chain atomicity claims in ERC-7573 cards

CHANGELOG.md

@@ -4,6 +4,7 @@ All notable changes to the EthSystems Map are documented here.
 
 ## [Unreleased]
 
+- fix(pattern): correct cross-chain atomicity claims. [Private PvP via ERC-7573](patterns/pattern-private-pvp-stablecoins-erc7573.md) now follows the ERC-7573 shape (one leg locked, the other paid through the decryption contract, an oracle-released key that releases or returns the locked leg) and states conditional settlement instead of "both legs settle or both revert"; the old recipe finalised one leg and then claimed both escrows revert. [Atomic DvP via ERC-7573](patterns/pattern-dvp-erc7573.md) drops the timeout reclaim that ERC-7573 does not define and names the oracle condition. [Permissioned Ledger Interoperability](patterns/pattern-permissioned-ledger-interoperability.md) states the coordinator trust assumption of two-phase commit ([#198](https://github.com/ethsystems/map/pull/198))
 - fix(ci): repair the Vale prose gate. Scope [EthSystems.Marketing](.vale/styles/EthSystems/Marketing.yml) to promotional claims instead of the bare words "only", "first" and "unique"; drop the [EthSystems.Terminology](.vale/styles/EthSystems/Terminology.yml) swap that forced "Multi-Party Computation" to lower case against GLOSSARY.md; ignore file names used as link text; pass `files` to `vale-action` as a JSON array, the one form the action parses, so the job lints the six content directories instead of the whole repository; and drop the `continue-on-error` added in [#196](https://github.com/ethsystems/map/pull/196), which kept the job green while Vale still exited 1 on 207 findings. Also clears the five real marketing terms and the remaining ERC-7573 and DA Layer terminology drift in the prose. Vale findings in the linted scope: 187 to 0 ([#197](https://github.com/ethsystems/map/pull/197))
 - feat(vendor): add [Interfold](vendors/interfold.md), plus patterns [Publicly Verifiable DKG and Threshold Decryption](patterns/pattern-verifiable-dkg-threshold-decryption.md) and [Ephemeral Committees](patterns/pattern-ephemeral-committees.md), covering single-use committees that dispose of key material after decryption ([#178](https://github.com/ethsystems/map/pull/178))
 - feat(vendor): add [The Graph](vendors/the-graph.md), decentralized indexing and query infrastructure as the audit read path ([#186](https://github.com/ethsystems/map/pull/186), landed via [#193](https://github.com/ethsystems/map/pull/193))

patterns/pattern-dvp-erc7573.md

@@ -4,7 +4,7 @@ status: ready
 maturity: concept
 type: standard
 layer: hybrid
-last_reviewed: 2026-06-18
+last_reviewed: 2026-09-11
 
 works-best-when:
   - Asset and cash legs live on different networks (L1 or L2).
@@ -63,27 +63,27 @@ In this pattern:
 
 ## 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.
+1. [user] Two institutions agree off-chain on the asset, quantity, payment token, amount, shared trade identifier `T`, and a target settlement time (ERC-7573 enforces no on-chain deadline).
 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).
+6. [operator] The decryption contract calls the oracle, which decrypts the encrypted key matching the actual outcome (success or failure) and returns it only after that outcome is final.
+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).
 
 ## 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.
+- Atomic settlement, conditional on verified key setup, correct contracts, an honest and available decryption oracle, finality on both networks, and eventual key delivery and inclusion: for each trade, both asset and cash legs settle, or the payment fails and the seller reclaims the asset. A completed payment is final; the protocol cannot reverse it.
+- Defined failure behavior: if the payment fails or is cancelled, the failure key lets the seller reclaim the asset. ERC-7573 defines no timeout. A latest-time reclaim added by a deployment is safe only if key delivery is bounded; a late key lets the seller reclaim after the buyer has paid.
 - 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.
+- Non-censoring sequencers on both networks during the settlement window. A censored payment or key-submission transaction blocks settlement or reclaim until it is included.
 - 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.
 
@@ -98,7 +98,7 @@ Threat model:
 ## 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.
+- They agree off-chain on trade identifier `T`, bond quantity, payment amount, and a target 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.

patterns/pattern-permissioned-ledger-interoperability.md

@@ -4,7 +4,7 @@ status: ready
 maturity: testnet
 type: standard
 layer: offchain
-last_reviewed: 2026-06-18
+last_reviewed: 2026-09-11
 
 works-best-when:
   - Multiple financial institutions each operate their own permissioned ledger but require atomic cross-ledger settlement.
@@ -81,16 +81,16 @@ Enable atomic transactions and data exchange across distinct permissioned ledger
 
 Guarantees:
 
-- Atomicity: cross-ledger operations settle consistently or abort.
+- Atomicity, assuming an honest coordinator: cross-ledger operations settle consistently or abort.
 - Counterparty privacy: only transacting parties see payload state; other domains observe only commitment envelopes.
 - Regulatory audit: scoped access for supervisory entities via dedicated disclosure paths.
 
 Threat model:
 
-- Honesty of the sync coordinator or relayer set. A malicious coordinator can stall commits but cannot unilaterally fabricate state.
+- Honesty of the sync coordinator or relayer set. A crashed coordinator blocks domains that have already prepared. A malicious one can send different decisions to different domains, breaking atomicity, unless a Byzantine fault tolerant commit protocol prevents conflicting decisions.
 - Each domain's local consensus. A compromised domain can produce inconsistent views to counterparties.
 - Operator control over admission. Each ledger operator retains the ability to deny access, freeze assets, or refuse to process transactions within its domain.
-- Cross-chain atomicity under partition is out of scope for simple two-phase commit; stronger protocols are needed when domains lose connectivity mid-commit.
+- Partitions. Two-phase commit keeps atomicity during a partition by blocking: prepared domains wait until they reconnect. Non-blocking commit needs stronger protocols.
 
 ## Trade-offs
 

patterns/pattern-private-pvp-stablecoins-erc7573.md

@@ -4,14 +4,15 @@ status: ready
 maturity: concept
 type: standard
 layer: hybrid
-last_reviewed: 2026-06-18
+last_reviewed: 2026-09-11
 
 works-best-when:
-  - Two permissioned or regulated stablecoins (same L2 or cross-L2) must settle atomically with amount privacy.
+  - Two permissioned or regulated stablecoins (same L2 or cross-L2) must settle against each other with amount privacy, and both parties accept an oracle as the settlement trigger.
   - Finality sensing and pricing for FX or cross-issuer settlement can be served by an oracle feed both parties accept.
 avoid-when:
   - Bilateral netting or off-chain wires already satisfy the settlement requirement.
   - HTLC timeouts with public amounts are acceptable and operational simplicity outweighs privacy.
+  - The party that pays first cannot carry exposure to oracle failure after its payment settles.
 
 context: i2i
 
@@ -25,7 +26,7 @@ crops_context:
   cr: "Censorship resistance depends on the oracle feed and the finality-relayer path. If the oracle or the cross-domain relayer censors, settlement can stall even though the escrow contracts are non-custodial."
   o: "The ERC-7573 escrow standard is open; oracle feeds and cross-chain messaging infrastructure are typically proprietary. Parties can substitute alternative oracles and relayers at deployment time."
   p: "Amounts and counterparties are hidden from the public chain, but the escrow contracts, oracle verdicts, and minimal settlement anchors remain visible. Metadata about when settlement happened and which assets are involved is not hidden."
-  s: "Rides on the correctness of the escrow contracts, oracle honesty, and finality-sensing correctness on the paying leg. Ops procedures must cover oracle outages and cross-domain message delays."
+  s: "Rides on the correctness of the escrow contracts and on the decryption oracle's honesty and liveness. Once the paying leg settles, an oracle or key-delivery failure leaves the payer exposed. Ops procedures must cover oracle outages and cross-domain message delays."
 
 post_quantum:
   risk: medium
@@ -47,53 +48,61 @@ open_source_implementations:
 
 ## Intent
 
-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 while keeping amounts and counterparties visible only to the transacting parties and their auditors. ERC-7573 makes the exchange conditional: one leg is locked and moves only on the verified outcome of the other, paying leg. A settled payment is final, so atomicity rests on the decryption oracle. Privacy comes from the shielded layers; ERC-7573 itself hides no amounts, identities, or timing. ERC-7573 defines no timeout: it replaces HTLC time-locks with trust in the oracle.
 
 ## Components
 
-- 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.
+- ERC-7573 locking contract on the receiving side's chain: holds the locked leg under a trade identifier, bound to hashes of two outcome keys (release or return).
+- ERC-7573 decryption contract on the paying side's chain: executes the payment and asks the decryption oracle (single-operator or threshold) for the key that matches the result.
+- Shielded transfer layer on each chain that hides amounts and counterparties.
+- Price or FX oracle feed, checked before the payment executes when the legs are in different units.
+- Relayer or cross-domain messaging layer that carries the outcome key to the locking contract.
+- Attestation layer for scoped disclosure to auditors, recording which parties settled, at what rate, and when.
 
 ## Protocol
 
-1. [counterparty] Agree bilaterally on notional, FX rate (if cross-currency), oracle feed identifier, and tolerance band.
-2. [counterparty] Each side deposits the shielded stablecoin into the ERC-7573 escrow on its chain, encoding the release condition that references the opposite leg and the oracle feed.
-3. [counterparty] The first leg executes: shielded payment settles and finality is reached on the originating chain.
-4. [relayer] Produce a finality attestation or cross-domain message proving the first leg finalised within the agreed terms.
-5. [contract] The second-leg escrow verifies the attestation and the oracle rate, then releases the shielded payment to the counterparty.
-6. [counterparty] On failure (missed finality window, oracle outside tolerance), both escrows revert and operational runbooks handle retry or cancel.
+1. [counterparty] Agree bilaterally on notional, FX rate (if cross-currency), oracle feed identifier, tolerance band, and trade identifier.
+2. [counterparty] The receiving side locks its shielded stablecoin in the ERC-7573 locking contract, registering hashes of two outcome keys.
+3. [counterparty] The paying side confirms the lock is final and the encrypted keys match the registered hashes for the right outcome and trade, then registers the trade terms and the encrypted keys in the ERC-7573 decryption contract on its chain.
+4. [contract] The paying side pays through the decryption contract, which checks the amount and oracle rate against the terms, then settles or rejects the payment. A settled payment is final.
+5. [operator] After the payment or cancellation outcome is final, the decryption oracle decrypts the success key if the payment settled, or the failure key if it was rejected or cancelled before payment.
+6. [relayer] Submit the key to the locking contract. The success key releases the locked leg to the paying side; the failure key returns it to its owner.
 7. [auditor] Use the attestation record and viewing keys on each leg to reconstruct the full settlement for compliance review.
 
 ## Guarantees & threat model
 
 Guarantees:
 
-- Atomic settlement across two chains or two assets: both legs settle or both revert, without relying on time-locks for safety.
+- Conditional settlement across two chains or two assets: the locked leg moves only on the key for the paying leg's actual result. Assuming verified key setup, correct contracts, an honest and available oracle, finality on both chains, and eventual key delivery and inclusion, both legs settle or the locked leg returns.
+- No cross-chain revert: if the success key is withheld after payment, the locked leg stays locked with no protocol exit, and the payer has already paid. Recovery is then bilateral or legal.
 - 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.
+- Decryption oracle honesty and liveness. A wrong key, or a withheld success key after payment, breaks atomicity against the paying side.
+- Key setup. A key that does not match its registered hash strands the locked leg after payment. A success key known to the payer, or a failure key known to the locked leg's owner, before authorized release lets that party end up with both legs.
+- Price oracle honesty and update cadence. A compromised or stale feed lets an attacker settle outside the agreed tolerance band.
+- Finality on the paying leg. A success key released before payment finality lets a reorg reverse the payment after the locked leg has moved.
+- Added deadlines. ERC-7573 has none. A reclaim deadline added by a deployment is safe only if key delivery is bounded; a late key lets the locked leg return after payment.
 - 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.
 
 ## Trade-offs
 
 - Oracle dependence is the main operational risk: outage, stale data, or price manipulation can each block settlement or produce an unfair release.
+- Asymmetric exposure: the paying side carries the risk between payment and key delivery. Choose the paying side on that basis and cover the gap contractually.
 - 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.
 
 ## Example
 
-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.
+- Two regulated banks settle a shielded USD-stablecoin leg against a shielded EUR-stablecoin leg on separate L2s.
+- The EUR-paying bank locks its leg in an ERC-7573 locking contract.
+- The USD-paying bank pays through the decryption contract on its L2.
+- Once the USD payment is final, the oracle releases the success key and a relayer submits it, releasing the EUR leg to the USD-paying bank.
+- Chain observers see that the payment completed and the locked leg was released, but not the amounts or identities. The banks' auditors reconstruct the full trade via the shielded viewing keys and the attestation log.
 
 ## See also