SOVEX
CBDC Data Centers Sovereign AI Tokenization Deep Tech Architecture About Team Request access
Tokenization / Settlement / Delivery-versus-payment

Delivery-versus-payment.

The asset leg and the payment leg execute as one indivisible operation. Either both sides move, or neither does — there is no window in which one party holds both the asset and the cash.

DvP is enforced as a single ledger transaction, not a choreography of promises

Settlement risk is eliminated at the mechanism, not managed after the fact through collateral and netting.

01

One transaction, two legs

The token transfer and the payment transfer are bound into a single ledger commit. The commit is all-or-nothing: partial application is not a representable state.

02

No principal risk window

There is never a moment where the buyer has paid and awaits delivery, or the seller has delivered and awaits funds. The gap that Herstatt risk lives in does not exist on the rail.

03

Deterministic outcome

Given the same inputs and ledger state, the settlement resolves identically every time. Outcomes are a function of committed state, not of timing, ordering, or operator intervention.

04

Failure is a clean no-op

If any precondition fails — insufficient balance, wrong owner, expired quote — the entire transaction is rejected and the ledger is unchanged. There is nothing to unwind.

Both legs are validated against live ownership and balance before either is applied

Preconditions are checked atomically so that authorization and settlement cannot drift apart.

01

Precondition binding

Asset ownership, payment balance, and transfer authorization are evaluated together as the transaction's guard. All conditions hold at the instant of commit or the transaction does not commit.

02

Ownership at the key

The asset leg debits the seller only if the seller's post-quantum key authorizes the transfer. Custody moves by cryptographic control, not by a custodian's book entry.

03

Payment in native ledger money

The cash leg settles in CBDC or tokenized deposit on the same ledger as the asset, so both legs share one commit boundary rather than crossing a system seam.

04

No intermediary escrow

There is no third party holding the asset or the funds during settlement. The rail itself is the escrow, and it holds for the duration of a single atomic commit.

Trade terms are encoded as settlement conditions the ledger checks, not paperwork it trusts

The economic terms of the trade become machine-checkable predicates enforced at commit.

01

Price and quantity as guards

Agreed price and quantity are part of the transaction's precondition set. A settlement that does not match the confirmed terms is not admissible.

02

Eligibility and restrictions

Transfer restrictions — holder eligibility, lockups, jurisdictional constraints — are evaluated inside the same commit. An ineligible transfer fails atomically alongside its payment.

03

Time-bounded settlement

Trades carry validity windows. A settlement instruction that arrives after its window expires is rejected rather than settled late against stale terms.

04

Multi-party legs

Where a trade involves more than two accounts — fees, splits, agent legs — every debit and credit is bound into the one commit, so no participant is left partially settled.

Every settled DvP leaves a tamper-evident record that both legs moved together

The proof of atomic settlement is intrinsic to the ledger, available to owners and auditors without reconstruction.

01

Hash-chained record

The settled transaction is written into the tamper-evident hash-chained ledger. Altering the record of either leg breaks the chain and is detectable.

02

Self-evident linkage

The asset leg and payment leg carry the same transaction identity in the ledger, so no external reconciliation is needed to prove they belong to one settlement.

03

Owner-verifiable

Because owners hold the keys, they can independently verify that a given DvP settled as recorded, without relying on an operator's attestation.

04

Post-quantum signatures

Each authorization is signed under ML-DSA-65 (FIPS 204), so the record of who authorized which leg remains verifiable against a quantum-capable adversary.

Build it sovereign.

Talk to us about delivery-versus-payment in a sovereign deployment.