Recommended Free Tools
Delivery-versus-payment (DvP) ties an asset transfer to its corresponding payment so one party is not meant to complete an irreversible delivery while the other fails to pay. Hyperledger and Kaleido’s April 2024 webinar used that goal to explore settlement across ledgers and other systems. Its key lesson is architectural: a smart contract can coordinate parts of an exchange, but trust, expiry, off-chain evidence, reversibility and dispute handling still have to be designed.
What DvP settlement means
DvP is a settlement arrangement in which the asset leg is conditional on the payment leg. In a securities trade, for example, the securities transfer should occur only if the corresponding payment happens. The Linux Foundation’s Decentralized Trust event description calls this a way to mitigate settlement risk by ensuring the simultaneous exchange of securities and cash.
As an Amazon Associate I earn from qualifying purchases.
The aim is to reduce principal risk: the risk that one party irrevocably delivers value while the other does not deliver its side. DvP does not remove every risk in a transaction. Counterparty, liquidity, operational, cyber, legal and regulatory risks may remain, and tokenization alone does not make an asset or payment instrument compliant or legally effective.
What the 2024 Hyperledger and Kaleido webinar covered
The Linux Foundation event listing dates the webinar to April 24, 2024, and names Kaleido Founder Steve Cerveny and Senior Full Stack Engineer Andrew Richardson as panelists. The organizer described a session on DvP challenges and benefits, including an enterprise DvP flow. The LF Decentralized Trust listing described a toolkit powered by Hyperledger FireFly and compatible with Hyperledger Besu, Hyperledger Fabric and many public chains. These are descriptions of the event and platform, not independent validation of production performance or readiness.
#1 Best Overall
Kaleido’s April 2024 presentation organizes DvP design around the network, asset type, intermediary and settlement mechanism. That framing is useful because the right coordination method depends on where each leg lives, what is being exchanged and which parties or systems must be trusted.
How DvP designs differ
| Design | Where the legs occur | How settlement is coordinated | Key trust or recovery question |
|---|---|---|---|
| Single-ledger smart contract | Both commitments share one ledger and execution domain. | A contract records the commitments and executes them together or not at all, subject to its design assumptions. Kaleido says asset locking may be optional depending on the exchange and desired guarantees. | What is locked, when is the action irreversible, and what contract or governance failures are in scope? |
| Multiple ledgers with hash and time locks | The asset and payment legs are recorded on separate chains, whether or not they use the same protocol. | Parties use a shared hash-linked secret; revealing the secret to claim one leg enables the counterparty to claim the other. Time locks let unfulfilled claims expire. | Are expiry times ordered to leave enough time for the counterparty to act, and what happens when a claim is delayed or a chain is unavailable? |
| On-chain plus trusted off-chain action | At least one leg depends on an external system or event, such as physical delivery. | A contract can gate release on a recorded confirmation, signed evidence or supervised sign-off. | Who verifies the external event, what evidence is authoritative, and who can challenge it? |
| Supervised off-chain settlement | Settlement includes an intermediary or notary with authority over some part of the process. | An intermediary may hold escrowed assets, or a notary may attest to validity and execution; some arrangements give a trusted party power to cancel or reverse a failed settlement. | What authority does the intermediary have, how is it governed, and what happens if it is unavailable or disputes a party’s claim? |
These designs are not interchangeable. A one-chain contract can offer a comparatively simple atomicity story only when both relevant commitments really share that chain’s execution domain. Across chains, claims unfold over time and rely on timeout and recovery logic; they are not one globally atomic transaction. When a physical event or legacy system is involved, code can enforce a decision based on recorded evidence but cannot, by itself, prove that the external event happened truthfully.
How Kaleido’s cross-chain demo worked
Kaleido’s April 2024 presentation illustrates a two-chain hash-time-locked arrangement. The example uses an ERC-721 asset chain and an ERC-20 payment chain. It is a vendor demonstration of one possible pattern, not a universal protocol prescription.
- Seller escrows the NFT. The seller places the NFT in a settlement contract on the asset chain, chooses a secret and sets an expiry. The contract records a hash of the secret.
- Buyer escrows payment. The buyer deposits payment into a second contract on the payment chain using the same hash and a shorter expiry than the seller’s lock.
- Seller claims payment. The seller reveals the secret to claim the payment. That disclosure makes the secret available on-chain.
- Buyer claims the NFT. The buyer uses the revealed secret to claim the NFT from the asset-chain contract.
The shorter payment-side expiry is intended to give the seller time to claim payment before the NFT-side lock expires, while leaving the buyer a path to reclaim payment if the seller does not act. Exact timeout margins and recovery behavior depend on implementation and network conditions; a design must account for delayed transactions, chain congestion and unavailable services rather than assume every claim lands promptly.
Hash and time locks coordinate conditional claims, but they do not make the two ledgers execute as one transaction. The parties need to understand the point at which a secret is revealed, which claims remain possible, when escrow can be reclaimed, and what happens if a leg is submitted but not finalized. Those boundaries should be reflected in both the contract logic and the operational procedures.
What changes when an asset is off-chain
For physical goods, a token transfer cannot itself cause or verify delivery. A design may require a carrier record, warehouse receipt, inspection result or signed confirmation from an authorized party before the contract releases payment or the digital representation of the asset. The legal agreement must establish which evidence counts, who may provide or dispute it, and how a false, late or contradictory confirmation is handled.
Rank #4
Before implementation, define the cancellation and reversal boundary for each leg. Specify who can pause settlement, how an expired lock is reclaimed, whether an intermediary can reverse a transfer, and how a dispute is resolved across the ledger and the off-chain legal relationship. These are core settlement rules, not details that a smart contract can safely infer.
What the Hyperledger Cacti example adds
Hyperledger Cacti describes a financial-markets case in which payment on a central bank digital currency (CBDC) ledger and transfer of securities entitlements on a separate ledger must be coordinated for the intended DvP outcome. This makes the cross-network challenge concrete: both ledgers must reflect the agreed exchange, even though each may have different rules and execution conditions. It is a technical illustration, not evidence of a particular live deployment.
Best Value
A separate tokenized-bond case in the presentation
The LF-hosted presentation also describes a digital-bond platform for a Spanish regulated central securities depository (CSD). It says a native tokenized bond was denominated and settled in tokenized cash, with issuance, coupons, principal repayments and DvP included in the lifecycle. The presentation attributes the technology stack to ioBuilders and says the project was built for the Spanish CSD/CCP associated with SIX Digital Exchange Group. This case is distinct from Kaleido’s two-chain NFT-and-token payment demo; the presentation’s description should not be read as proof that the demo and the bond platform used the same architecture.
How to interpret the presentation’s settlement-time claim
Kaleido’s April 2024 presentation says traditional clearing and settlement can take up to T+2 days and that systems typically operate only during business hours. Treat “up to T+2 days” as a vendor-authored statement from that presentation, not a current or universal measure of settlement cycles: timing varies by market, asset and applicable rules. The material does not establish an independently sourced market-wide figure for speed, cost or risk reduction.
What to verify before adopting a platform or pattern
- Execution scope: Confirm whether both legs truly share a ledger and atomic execution domain, or whether interoperability and staged claims are involved.
- Asset and cash validity: Establish the legal status and transfer rules for each token, the payment asset and any off-chain asset; tokenization does not settle those questions by itself.
- Timeouts and recovery: Review expiry ordering, finality assumptions, reclaim paths, chain outages, delayed transactions and the exact point at which funds or assets can no longer be recovered.
- Evidence and disputes: Name the source of off-chain evidence, the parties authorized to submit or challenge it, and the decision-maker for unresolved disputes.
- Governance and security: Determine who can pause, cancel or reverse settlement, how keys and contract upgrades are controlled, and which legal agreements govern each domain.
- Current product details: The webinar listing and Kaleido’s product materials describe FireFly, Besu and interoperability capabilities. Those are vendor and organizer descriptions that may change; verify current versions, deployment topology, security model, governance, support and regulatory requirements for the intended implementation.
The webinar is a dated educational demonstration from 2024. It can clarify design choices, but it does not establish that a particular configuration is production-ready or suitable for a regulated transaction.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
