Part 1 set delivery-versus-payment (DvP) and atomicity as separate properties. Part 2 picks up where they meet operationally. Two cases. Same-ledger atomicity, where both legs sit on the same chain. Cross-ledger atomicity, where they do not, and where the engineering work and the legal work both expand sharply. The cross-ledger case is the one that determines which architectural pattern a tokenisation programme converges on, and the three solution families are not interchangeable.
Same-ledger atomicity
Same-ledger atomicity is the easy case. Both legs are tokenised on the same ledger, and the transaction updating both balances is a single ledger entry that either commits or fails as a unit. This is how Canton's DAML model handles it, how a Hyperledger Fabric channel can be configured, and how Quorum-derived stacks like Kinexys handle the asset side of intraday repo and the cash side of tokenised deposit movement.
The ledger natively supports multi-asset, multi-party transactions where the integrity guarantee covers the whole transaction. No second commit step, no race condition. This is closer in spirit to a database transaction with strong isolation than to a public-chain atomic swap, and the comparison is fair: same-ledger atomicity is the property a relational database has provided for forty years, dressed up in a tokenisation wrapper.
On a well-designed permissioned ledger (see Permissioned blockchains), atomic DvP is not a feature you bolt on. It is the baseline, assuming the ledger can natively represent both the asset and the cash. The interesting engineering work is upstream and downstream: how the balances got onto the ledger in the first place, and how post-trade events reach the systems of record at each participant. Most of the bugs and audit findings in operational reviews land in those two interfaces, not in the atomic commit itself.
Cross-ledger atomicity
Cross-ledger atomicity is the hard case. Two legs sit on two different ledgers, possibly run by different operators, possibly with different finality models. Three families of solutions, and the choice has direct consequences for who carries the residual risk.
Hash time-locked contracts (HTLCs) are the public-chain inheritance. Both legs are escrowed under a hash preimage; revealing the preimage to claim one leg also reveals it for the other; if the timeout expires before both reveals, both escrows refund. This works, but operationally it is unforgiving. Timeouts are real wall-clock deadlines, the asset must support the script primitives, the participants must run watchers. For institutional flows where a fail-to-deliver is a regulatory event, leaving atomicity in the hands of a wall-clock timer is uncomfortable. HTLCs survive in cross-chain bridge designs and in some specialist arrangements, but they are not the architecture institutional tokenisation has converged on.
The coordinator pattern, sometimes called the notary model, replaces the timer with a trusted entity that holds both legs in escrow and releases them simultaneously, or refunds both if either fails. R3 Corda uses notary nodes for exactly this purpose. The atomicity is a property of the coordinator's promise rather than of the cryptography, but the coordinator is regulated and the promise is contractually enforceable, which is what banks actually want. The trade-off is centralisation at the coordinator, which can be a single point of operational failure and a potential censorship choke point. Multiple coordinators in a sharded design mitigate this without removing it entirely.
The unified settlement layer is the third pattern, and where the BIS work converges. Project Agorá's design, the BIS Innovation Hub tiered-ledger work, and Project Ensemble all assume a shared settlement substrate, typically with central bank money at the base, that lets multiple asset ledgers commit atomically against a single cash ledger. From the participant's perspective the trade is cross-ledger; from the system's perspective the cash ledger is the operative settlement record. This is the architecture that scales beyond bilateral pairs and the one most regulator-led pilots are designing toward.
Project Mariana (2023), run by the BIS Innovation Hub with the central banks of France, Singapore, and Switzerland, used a different mechanism in the same architectural family: an automated market maker (AMM) on a shared wholesale CBDC (wCBDC) substrate to atomically exchange tokenised central bank money across three currencies. The interest is less the AMM mechanism (a trader's tool ported into wholesale settlement) and more the demonstration that cross-border, cross-currency atomic settlement is achievable in a regulated context with central bank money on each leg.
Choosing among the three
The choice is not technical, it is institutional. HTLCs ask the participant to wear timing risk and operational complexity in exchange for trust-minimisation; that trade is rarely good for a regulated bank. The coordinator pattern asks the participant to trust a known, regulated operator in exchange for cleaner failure modes; that trade matches what banks already do everywhere else. The unified settlement layer asks the central bank or a designated infrastructure to be the shared substrate; that trade asks the most of the public sector but yields the most scalable and the most regulator-recognisable architecture.
Empirically, regulator-coordinated production work has converged on the third pattern, with the coordinator pattern as the workhorse for bilateral and small-consortium arrangements. HTLCs survive mostly in the public-chain bridge ecosystem rather than in regulated tokenisation infrastructure, which is a useful tell about which trade-offs the institutional market has been willing to accept.
Part 3 picks up the cash leg, which is where same-ledger and cross-ledger atomicity both either succeed or quietly fail, and overlays the capital and operational implications that determine whether atomic DvP is worth the investment for any particular product.