Atomic Settlement

Prerequisite: Executing Money Flows, Blockchain Fundamentals

Your system sells tokenized treasury bonds on Ethereum. A buyer sends USDC, your contract transfers the bond token, and both legs confirm in a single transaction. Atomic. Then a buyer wants to pay with a bank wire. The wire takes 45 minutes to settle. The bond token sits in escrow on-chain while you wait for SWIFT confirmation from a correspondent bank that operates on a different continent, a different ledger, and a different definition of “final.” The wire arrives. Or it doesn’t. Or it arrives two hours late. The escrow contract’s timeout has already triggered a refund.

Atomic settlement is not a property of a single system. It is the assertion that two legs of a trade either both complete or neither does — and maintaining that assertion across systems with incompatible finality models is the hard problem.

Delivery Versus Payment

Delivery versus Payment (DvP) is the principle that the transfer of an asset and the transfer of payment must be conditional on each other. Neither party should be exposed to the risk that they deliver their side and the counterparty defaults.

The Bank for International Settlements classifies DvP into three models:

Model Mechanism Settlement risk
DvP Model 1 Gross, simultaneous settlement of both legs Zero principal risk
DvP Model 2 Gross settlement of securities, net settlement of funds Funds leg has netting risk
DvP Model 3 Net settlement of both legs Both legs have netting risk

Model 1 is the target. Both legs settle individually, in real time, and each is conditional on the other. No netting, no deferred settlement, no counterparty exposure between trade execution and settlement.

On a single blockchain, Model 1 is trivial. A smart contract that transfers token A from Alice to Bob and token B from Bob to Alice in one transaction achieves DvP by construction — either the entire transaction succeeds or the entire transaction reverts. The EVM’s atomic execution model gives you Model 1 for free within a single chain.

The difficulty begins the moment one leg lives outside that execution model.

Why Atomicity Breaks Across Systems

Two-phase commit (2PC) is the standard distributed systems protocol for atomic operations across participants. A coordinator sends PREPARE to all participants, waits for acknowledgment, then sends COMMIT. If any participant fails to prepare, the coordinator sends ABORT.

2PC requires three properties that cross-system settlement cannot guarantee:

  1. All participants can roll back after PREPARE. A blockchain transaction that has been included in a finalized block cannot be rolled back. A bank wire that has been credited to the receiver’s account through Fedwire is final and irrevocable.
  2. The coordinator can reach all participants. A blockchain has no inbox. You cannot send a COMMIT message to Ethereum — you submit a transaction and wait for inclusion, which may take 12 seconds or 12 minutes depending on gas prices and congestion.
  3. Participants hold locks until commit. Banks do not hold funds in a locked state waiting for an external coordinator’s commit signal. Funds are either debited or they are not.

These constraints mean that cross-system settlement must use a different pattern than 2PC. The two dominant approaches are escrow-based (lock funds on each side, release conditionally) and saga-based (execute forward, compensate on failure).

See Executing Money Flows. The saga pattern for financial operations — forward actions with compensating reversals — applies directly to cross-system settlement. The difference is that on-chain legs have different reversal semantics than off-chain legs.

On-Chain Atomic Swaps

Hash Time-Locked Contracts (HTLCs) enable atomic swaps between two blockchains without a trusted intermediary. The protocol uses a cryptographic hash lock and a time lock to create conditional transfers on both chains.

The flow for an atomic swap of token A on Ethereum for token B on Solana:

1. Alice generates a random secret S, computes H = SHA-256(S)
2. Alice locks token A in an HTLC on Ethereum:
   - Recipient: Bob
   - Hash lock: H
   - Time lock: 4 hours
3. Bob sees Alice's HTLC, locks token B in an HTLC on Solana:
   - Recipient: Alice
   - Hash lock: H (same hash)
   - Time lock: 2 hours (must be shorter than Alice's)
4. Alice claims token B on Solana by revealing S
5. Bob reads S from Alice's claim transaction, claims token A on Ethereum

The time lock asymmetry is critical. Bob’s lock expires before Alice’s. If Alice reveals the secret to claim on Solana, Bob has time to use that secret on Ethereum before Alice’s lock expires. If Alice never reveals the secret, both locks expire and both parties recover their funds.

Outcome Alice Bob
Alice reveals S, Bob claims Gets token B Gets token A
Alice never reveals S Gets token A back (after 4h) Gets token B back (after 2h)
Alice reveals S, Bob misses window Gets token B Gets token A back (after 4h) — but this means Bob failed operationally

The failure mode is the third row. If Bob’s infrastructure is down when Alice reveals the secret, Bob’s HTLC on Ethereum expires and Alice recovers token A — while also having claimed token B on Solana. Alice gets both assets. This is not a protocol bug; it is an operational risk. Bob must monitor Alice’s claim transaction and react within the time window.

HTLCs work for two-chain atomic swaps where both chains support hash locks and time locks. They do not extend to fiat — a bank cannot lock funds behind a SHA-256 hash and release them when a preimage appears on a blockchain.

Cross-System Atomicity: On-Chain Meets Fiat

When one leg is on-chain and the other is a fiat payment, no cryptographic protocol can make both legs atomic. The fiat banking system does not support conditional execution based on blockchain events. The solution is an escrow intermediary — a party trusted by both sides to hold one leg until the other confirms.

         ┌──────────────┐
         │   Escrow     │
         │  (trusted)   │
         └──┬───────┬───┘
            │       │
   Token leg│       │Fiat leg
            │       │
    ┌───────▼──┐ ┌──▼────────┐
    │Blockchain│ │   Bank    │
    │ (smart   │ │ (wire /   │
    │ contract)│ │  ACH)     │
    └──────────┘ └───────────┘

The sequence for a tokenized bond purchase with fiat payment:

  1. Buyer initiates a bank wire for $100,000
  2. Seller locks the bond token in an escrow smart contract with a 24-hour timeout
  3. Escrow service monitors both systems:
    • Watches for wire confirmation from the banking partner (webhook or API polling)
    • Watches the escrow contract’s state on-chain
  4. Wire confirms → escrow service calls release() on the smart contract → bond token transfers to buyer
  5. If wire does not confirm within 24 hours → escrow contract’s timeout triggers → bond token returns to seller

The escrow service is the single point of trust. It sees both legs and decides when to release. If the escrow service fails, the timeout protects the seller (tokens return) but the buyer’s wire may have already settled — requiring manual reconciliation and a fiat refund.

The timeout window is a design decision with real cost. Too short: legitimate wires that take longer than expected trigger unnecessary refunds and re-attempts. Too long: the seller’s asset is locked and unavailable. For domestic wires (Fedwire, same-day settlement), 2–4 hours is typical. For international wires (SWIFT, correspondent banking), 24–48 hours accommodates timezone and intermediary delays.

The escrow intermediary introduces counterparty risk that the pure on-chain atomic swap eliminated. You are trusting the escrow service to honestly report the fiat leg’s status. If the escrow service is compromised or reports a false confirmation, the on-chain leg releases without actual payment. This is why regulated settlement systems require the escrow function to be operated by a licensed, audited entity — not an anonymous smart contract.

Three-System Settlement: The Saga

Real-world settlement often involves three systems: your internal ledger, a blockchain, and a banking partner. A customer deposits fiat, you mint stablecoins, and the customer receives tokens. Three legs, three systems, three definitions of “done.”

The saga pattern decomposes this into a sequence of local transactions, each with a defined compensating action:

Step Action Compensating action System
1 Record deposit intent in ledger Cancel deposit record Internal ledger
2 Confirm fiat receipt from bank Initiate fiat refund Banking partner
3 Mint tokens to customer address Burn tokens from customer address Blockchain
4 Update ledger: deposit complete Revert ledger to pre-deposit state Internal ledger

If step 3 fails (mint transaction reverts), the compensating actions fire in reverse: refund the fiat (step 2 compensation), cancel the deposit record (step 1 compensation). The customer’s fiat returns and no tokens were created. The system is consistent.

The complication is that compensating actions are not free. A fiat refund takes 1–3 business days. The customer sees money leave their bank account on Monday, the mint fails, and the refund arrives on Wednesday. During those two days, the customer’s funds are in limbo. Your support team fields the call.

Saga orchestration for settlement requires an orchestrator service that:

  • Persists the saga state to a durable store (Postgres, not an in-memory queue)
  • Retries failed steps with exponential backoff before triggering compensation
  • Handles partial failure in compensation itself (what if the refund fails?)
  • Emits events for monitoring and alerting at each state transition
  • Maintains an audit trail that regulators can follow

The orchestrator’s state machine has more states than the happy path suggests:

INITIATED → FIAT_PENDING → FIAT_CONFIRMED → MINT_PENDING → MINT_CONFIRMED → COMPLETE
                 │                │                │
                 ▼                ▼                ▼
           FIAT_TIMEOUT    FIAT_FAILED      MINT_FAILED
                 │                │                │
                 ▼                ▼                ▼
              CANCELLED    REFUND_PENDING    REFUND_PENDING → BURN_PENDING
                                  │                               │
                                  ▼                               ▼
                           REFUND_CONFIRMED                REFUND_CONFIRMED
                                  │                               │
                                  ▼                               ▼
                              CANCELLED                       CANCELLED

Every edge in this state machine is a real code path that must be tested. The happy path is one path through approximately twelve possible terminal states.

Programmable Settlement: Kinexys and Tokenized Deposits

J.P. Morgan’s Kinexys (formerly Onyx) platform brings DvP guarantees to institutional settlement by putting both legs on a permissioned blockchain. Dollar deposits are tokenized as JPM Coin (now Kinexys Digital Payments), and settlement occurs as an atomic on-chain swap between tokenized deposits and tokenized assets.

Kinexys processes over $2 billion in daily transaction volume. The architecture avoids the cross-system atomicity problem by tokenizing the fiat leg — once dollars are represented as on-chain tokens, both legs of a DvP trade execute in a single atomic transaction on the same ledger.

The tradeoff is that participants must hold tokenized deposits on the Kinexys network. This requires a banking relationship with J.P. Morgan and onboarding to their permissioned chain. The settlement is atomic, but the ecosystem is closed.

Broadridge’s Distributed Ledger Repo (DLR) platform uses a similar approach for repurchase agreement settlement, processing $1 trillion per month in repo transactions. Both the security leg and the cash leg are tokenized, and settlement executes atomically on-chain with intraday finality.

Central Bank Experiments

The Bank for International Settlements has run multiple projects exploring atomic cross-border settlement:

Project mBridge connects the central banks of China, Hong Kong, Thailand, and the UAE on a shared platform using a custom blockchain (built on Ethereum technology). Participating central banks issue CBDCs on the shared ledger, and cross-border payments settle atomically as on-chain swaps between different CBDCs. The platform completed a pilot processing $22 million in real-value transactions in 2022, with settlement times under 5 seconds compared to 2–5 days through correspondent banking.

Project Mariana tested automated market maker (AMM) protocols for cross-border FX settlement between the Swiss National Bank, Banque de France, and the Monetary Authority of Singapore. Hypothetical euro, Swiss franc, and Singapore dollar CBDCs traded through a Curve-style AMM, with settlement atomic by construction — the AMM’s invariant function guarantees that both legs of the FX trade execute or neither does.

Project Participants Settlement time Mechanism
mBridge 4 central banks < 5 seconds CBDC swap on shared ledger
Mariana 3 central banks Seconds AMM with CBDC pools
Correspondent banking N banks 2–5 days Sequential SWIFT messages

These experiments demonstrate that atomic cross-border settlement is technically feasible. The barrier is not engineering — it is governance. Which jurisdiction’s law governs a dispute? Which central bank’s money is the settlement asset? Who operates the shared infrastructure? The technical protocol is the smallest part of the problem.

Settlement Finality

Atomicity guarantees that both legs complete or neither does. Finality guarantees that once complete, the settlement cannot be reversed. These are separate properties, and conflating them creates real exposure.

On Ethereum, a transaction included in a block is not final until the block is finalized — approximately 12–15 minutes after inclusion under proof-of-stake. A transaction confirmed in one block can be excluded by a chain reorganization. If you release the fiat leg upon transaction confirmation (1 block) rather than finalization (~64 blocks), a reorg can remove the on-chain leg while the fiat leg has already settled irrevocably.

Chain Confirmation Finality Risk window
Ethereum (PoS) ~12 seconds (1 slot) ~15 minutes (2 epochs) Reorg removes confirmed tx
Solana ~400ms (1 slot) ~12 seconds (32 slots) Optimistic confirmation can be rolled back
Bitcoin ~10 minutes (1 block) ~60 minutes (6 blocks, probabilistic) Deep reorg theoretically possible
Fedwire Immediate Immediate and irrevocable None — finality on receipt

For fiat rails, finality varies by system. Fedwire is final on receipt — once the receiving bank is credited, the payment cannot be reversed by the sender. ACH is not final for 2 business days (the return window). Card payments are not final for up to 120 days (the chargeback window). SEPA Instant is final within 10 seconds of acceptance.

The design implication: your settlement system must match the finality guarantee of the faster-settling leg to the finality guarantee of the slower-settling leg. If one leg is Fedwire (instant finality) and the other is Ethereum (15-minute finality), you wait for Ethereum finality before considering the settlement complete — even though the fiat leg settled 14 minutes ago. The alternative is accepting the reorg risk for those 14 minutes, which means accepting that a reorganization could leave you with an irrevocable fiat payment and no corresponding on-chain asset.

Choosing when to treat settlement as final is not a technical decision. It is a risk decision — how much exposure are you willing to carry in the window between confirmation and finality, denominated in the value of the assets being settled.