Delivery and payment either both happen or neither does. There is no window in which one party has parted with value and the other has not.
Delivery-versus-payment removes the gap where counterparty risk lives.
The transfer of a tokenized asset and the movement of CBDC execute as a single settlement instruction whose only outcomes are complete or none.
Neither party surrenders value ahead of the other. The classic exposure — deliverer has paid but not received — is closed by construction, not by timing.
The tokenization engine and the CBDC engine settle against each other in the same commit, so real-world-asset delivery and sovereign payment clear together.
Atomicity is enforced by the settlement protocol, not by convention.
Each engine first validates and provisionally locks its leg. Only when all legs report ready does the coordinator issue an irreversible commit.
If any engine cannot honor its leg — insufficient balance, failed authorization, stale precondition — the whole settlement aborts and every provisional lock is released.
There is no intermediate ledger state in which one leg is final and another pending. Observers see the world before or after, never mid-settlement.
Provisional locks guarantee the value promised at prepare-time still exists at commit-time.
At prepare, the payer's CBDC and the seller's asset are reserved so they cannot be double-spent into a competing settlement while the commit is pending.
Each leg records the exact state it validated against. If that state changes before commit, the settlement fails rather than executing on stale assumptions.
A prepared-but-uncommitted settlement expires after a bounded window, releasing every lock. A failed or abandoned coordinator cannot freeze assets indefinitely.
Once committed, the transfer is irrevocable and recorded in the hash-chained ledger.
The settlement outcome is written into the hash-chained ledger, inheriting its tamper-evidence and giving both parties the same immutable record of the trade.
Each leg carries the ML-DSA-65 signature of its authorizing party, so finality rests on demonstrable consent rather than operator assertion.
After commit there is no silent reversal. Any correction is a new, separately authorized and separately recorded settlement, preserving the audit trail.
The protocol is designed so that crashes and partitions abort cleanly.
Coordinator and engine state is journaled so that after a failure each party can determine whether the settlement committed or aborted, and finish accordingly.
Replayed commit or abort messages are recognized by settlement identifier and applied once, so retries after a network fault cannot move value twice.
When the outcome cannot be confirmed, the protocol resolves to abort and release, favoring no-transfer over an uncertain or one-sided transfer.