Chapter IV ended on a synthesis: the institutional tokenisation stack is multi-chain by design, with each chain doing what it is best at. MONY on Ethereum mainnet for institutional gravity, JPMD on Base for predictable payments fees, Canton Network for the privacy and securities-settlement case, Solana for specific crypto-native partner flows. The unspoken assumption in that synthesis is that the chains can talk to each other. They cannot, not natively. This part sets out why interoperability is the load-bearing problem the rest of the chapter addresses, what the move from chain A to chain B actually requires, and the framing that lets the four mechanisms in Parts 2 to 5 be compared on a shared axis.
Multi-chain is the reality, not the destination
Each chain is its own state machine, deliberately walled off from every other chain. A token on Ethereum and a token on Base are not the same token even if they bear the same name. The Ethereum contract has its own balances, its own ledger, its own validator set certifying its state. The Base contract has its own. Neither contract can read or write the other's state. There is no shared memory, no implicit coordination, no protocol-level handshake that bridges them. From the perspective of either chain, the other chain does not exist.
This is the deliberate consequence of how each chain is constructed. A blockchain's security model rests on a closed validator set agreeing on a single canonical history. Opening the validator set to read external state would weaken the security guarantee. Opening it to write external state would break the guarantee entirely. The price of strong intra-chain consistency is zero native cross-chain awareness.
For a tokenised flow that has to span chains, that wall is the problem. An institutional allocator holding [/use-cases/buidl] on mainnet who wants to settle against a counterparty on Base cannot simply send the asset across. The asset on mainnet has no way to reach the destination chain on its own.
What "moving an asset between chains" actually means
No asset moves. The asset is destroyed on the source chain and recreated on the destination chain. This is the pattern every cross-chain mechanism implements, with variations in who certifies the destruction and who authorises the recreation. The two canonical shapes are lock-and-mint and burn-and-mint.
In lock-and-mint, the source-chain asset is held in a smart contract that escrows it. The escrow is the proof that the asset is not in circulation on the source chain. A wrapped representation is then minted on the destination chain, backed one-to-one by the escrowed source-chain balance. To move the asset back, the wrapped token is burned on the destination chain and the original is released from the source-chain escrow.
In burn-and-mint, the source-chain asset is destroyed outright. A new asset is minted on the destination chain. The two are the same instrument, recognised as such by the issuer. Circle's CCTP (Cross-Chain Transfer Protocol) for USDC is the canonical example: USDC on Ethereum is burned, USDC on Base is minted, the issuer treats the second as fungibly identical to the first because Circle's mint authority spans both chains. Burn-and-mint is cleaner because there is no wrapped derivative, no escrow contract to attack, no risk that the wrapper diverges in value from the underlying.
The detail that matters in both cases is the trust model. Some entity has to certify, to the destination chain, that the source-chain side of the operation has happened. The chain itself cannot verify this, by definition. The mechanisms in the rest of this chapter differ on who that certifying entity is, how decentralised they are, and what slashing or risk-management apparatus sits behind them.
Why this is the institutional question, not a crypto-native one
For a retail user moving USDC between chains for cheaper fees, cross-chain interoperability is a UX problem. A bridge that takes ten minutes and charges a few dollars is acceptable. The downside if it fails is bounded by the transfer size.
For an institutional flow, the calculus is different. The transfers are larger. The counterparties on each end are regulated entities with their own custody, compliance, and reporting frameworks. The certification that the source-chain leg has happened needs to be reliable enough that the destination-chain leg can settle against it without holding open credit risk. The mechanism needs to be auditable, the governance of the certifying entity needs to be visible, the security model needs to survive a serious diligence review.
The historical record argues for taking this seriously. The cross-chain bridge category has been the most heavily exploited surface in DeFi. Wormhole lost USD 326 million in February 2022 to a signature-validation bug. Ronin Bridge lost USD 624 million in March 2022 to a private-key compromise. Nomad Bridge lost USD 190 million in August 2022 to a faulty initialisation. The list is longer; the pattern is consistent. The trust assumption embedded in a cross-chain mechanism is its weakest point, and the historical losses traceable to bridge exploits run into the billions.
For an institutional cross-chain DvP flow involving a tokenised MMF or tokenised deposit moving between chains, choosing the wrong mechanism is not a UX issue. It is a credit-risk issue layered on top of an operational-risk issue, with the cross-chain message as the single point of failure for both.
What this chapter covers
The next four parts walk through the four mechanism families that the institutional stack actually picks between. Part 2 covers Chainlink CCIP, the institutional default and the mechanism JPM used for the Ondo [/use-cases/ousg] cross-chain DvP transaction. Part 3 covers native bridges, the cheap and fast option for specific chain pairs (Base bridge, Arbitrum bridge, Polygon bridge) where they happen to fit. Part 4 covers atomic swaps and the newer intent-based routing approach (Across, deBridge, CoW Protocol), and revisits the Wormhole exploit and its peers. Part 5 synthesises: the strategic answer for an institutional cross-chain stack, and the open question of how Canton fits in as it becomes more central.