How Do You Settle DvP When Cash Is on Another Chain?
Cross-chain delivery-versus-payment (DvP) is an atomic settlement design that exchanges a security on one blockchain for cash on another. A lock-and-release escrow can keep both assets on their home networks, but the cross-chain message becomes part of the settlement system and must be governed like market infrastructure.
TL;DR — Key Takeaways
- ✓The demonstration: Fasanara securities on Polygon settled against ABN AMRO cash tokens on Base.
- ✓The mechanism: The seller locks securities, the buyer pays, and a cross-chain confirmation releases the assets.
- ✓The benefit: Neither institution has to bridge its asset or surrender its preferred network.
- ✓The new dependency: Atomicity depends on the messaging and verifier configuration between the chains.
- ✓The missing detail: The public design does not specify how investor eligibility is synchronized across networks.
Cross-Chain DvP Keeps Both Assets on Their Home Networks
The May 2025 ERC3643 Association demonstration used escrow rather than a token bridge. Fasanara's security stayed on Polygon, ABN AMRO's cash token stayed on Base, and LayerZero carried the messages that coordinated release.
That architecture solves a practical institutional constraint. An asset manager may issue on a public chain with permissioned-token controls while a bank issues cash on a separate network chosen for privacy, governance, or balance-sheet policy. Forcing either party to bridge its asset would create a second supply representation and a new issuer or custodian dependency.
The design settles across two blockchains “without requiring counterparties to bridge assets across chains.”
— ERC3643 Association
This extends the single-chain model described in our guide to atomic DvP for tokenized securities. The difference is that finality now depends on two ledgers and the message connecting them.
The Settlement Sequence Has Five States
The public demonstration moves through agreement, lock, notification, payment, and release. The securities leg cannot complete until the destination chain confirms that the buyer paid the specified cash token.
| State | Polygon security leg | Base cash leg |
|---|---|---|
| 1. Agreement | Seller names token, amount, and buyer | Required payment is fixed |
| 2. Lock | Securities enter escrow | No movement |
| 3. Notify | Lock event is attested | Buyer receives settlement instruction |
| 4. Pay | Securities remain locked | Buyer transfers cash token |
| 5. Release | Escrow releases securities to eligible buyer | Payment completion is recorded |
A production design also needs failure states that the demonstration summary does not describe: expiry before payment, payment after expiry, duplicate delivery, message delay, chain reorganization, and manual recovery.
Escrow Avoids a Phantom Security Supply
A lock-and-release trade moves ownership of the original security token. A lock-and-mint bridge instead creates a destination-chain representation whose supply must remain synchronized with collateral elsewhere.
Chainlink's cross-chain token documentation lists burn-and-mint, lock-and-mint, burn-and-unlock, and lock-and-unlock configurations. Those mechanics are useful for portable fungible assets, but a regulated security adds a shareholder register, transfer restrictions, corporate actions, and legal control. A false mint is not only an unbacked token; it can become a phantom shareholder entry.
| Design | Security supply | Primary failure |
|---|---|---|
| Escrow DvP | Original token stays on home chain | False payment or release message |
| Lock and mint | Representation is minted elsewhere | Unbacked destination supply |
| Burn and mint | Supply moves between contracts | Irrecoverable burn or false mint |
Atomicity Moves Trust Into the Messaging Layer
Buyer and seller principal risk can fall to zero while infrastructure risk rises. The escrow contract releases securities because a verifier says payment occurred, so the verifier policy becomes part of the asset's control framework.
The April 2026 rsETH incident shows the consequence of a false cross-chain attestation. Compromised infrastructure caused a verifier to accept a message claiming that 116,500 rsETH had been locked on a source chain when no transaction existed. The destination contract then released roughly $292 million from escrow.
“No smart contract was broken; every contract involved operated exactly as designed.”
— OpenZeppelin analysis, April 2026
The incident did not involve a permissioned RWA token, but it demonstrates the same message-authenticity failure mode. The detailed control lesson is covered in our analysis of the KelpDAO configuration and audit gap.
Identity Must Be Valid at the Moment of Release
A permissioned security cannot release to a buyer based on payment alone. The receiving wallet must satisfy the issuer's identity and compliance rules when escrow transfers the token.
The ERC3643 Association says the demonstration combines identity, compliance, and atomic settlement, but its public description does not specify how ONCHAINID claims are synchronized or evaluated across Polygon and Base. That omission should be treated as an undisclosed implementation detail, not proof that no mechanism exists.
A production design needs to state where claims live, which chain performs the final eligibility check, what happens if a claim expires while assets are locked, and whether cash automatically returns when the securities leg rejects the buyer. Those controls belong in the wider smart-contract compliance architecture, not only in the settlement dApp.
Production DvP Needs a Failure-State Contract
The operating agreement must define outcomes for every partial state, not only the successful atomic path. A trade is safe when the parties can prove who controls each asset after a delayed, duplicated, disputed, or rejected message.
- Use multiple independent verifiers and document the acceptance threshold.
- Apply replay protection and unique trade identifiers on both chains.
- Set timeouts for lock, payment, confirmation, and recovery states.
- Recheck buyer eligibility immediately before releasing securities.
- Define whether failed settlement returns cash, unlocks securities, or enters manual review.
- Reconcile escrow balances, cash receipts, and the legal holder register after every batch.
Cross-chain DvP is therefore not a bridge with a payment feature. It is a two-ledger settlement system whose legal finality, identity controls, verifier governance, and recovery process must agree before institutions can treat it as atomic.
Frequently Asked Questions
What is cross-chain delivery-versus-payment?
Cross-chain DvP is a settlement process in which a security on one blockchain is delivered only if payment is completed on another blockchain. A messaging layer coordinates the two legs so neither party should perform without the other.
How did the ERC-3643 cross-chain DvP demonstration work?
Fasanara's ERC-3643 security tokens were locked on Polygon, ABN AMRO cash tokens were paid on Base, and a LayerZero message triggered release of the locked securities to the buyer.
Why use escrow instead of bridging the security token?
Escrow keeps the regulated security on its home chain and avoids minting a representation elsewhere. This reduces supply-reconciliation risk and keeps the issuer's register and compliance controls in one place.
Is cross-chain DvP free of counterparty risk?
Atomic design can remove principal risk between buyer and seller, but it replaces that exposure with messaging, verifier, smart-contract, identity, and operational risks. Those dependencies must be governed as settlement infrastructure.
Where is investor eligibility checked in cross-chain DvP?
The securities contract must evaluate whether the buyer's receiving address is eligible before release. The public demonstration says identity and compliance are included, but it does not publish the cross-chain identity synchronization mechanism.
What happens if payment succeeds but the release message fails?
The design needs an explicit pending state, timeout, replay protection, manual recovery path, and evidence showing whether cash can be returned or securities can be released safely after delayed confirmation.
Related Articles
Who Controls an ERC-3643 Token's Agent Keys?
The privileged roles that can freeze or force-transfer securities.
When Is a Tokenized Asset Settlement Final?
Technical finality and legal finality are separate tests.
Can Tokenized Collateral Meet Derivatives Margin Rules?
Control, segregation, and mobility in regulated collateral.
How Does Decentralized Identity Support RWA Issuance?
The identity layer behind permissioned token transfers.