The four mechanism families are now on the table: CCIP as the generalised institutional default, native bridges as the chain-pair specialist, atomic swaps as the cryptographically pure but operationally unworkable reference point, intent-based routing as the maturing newer alternative. This part puts them together, walks through what that looks like for Kinexys and the JPM tokenised cash-and-collateral network (TCN) over the next twelve to twenty-four months, and surfaces the open question on how Canton fits in as it becomes more central to the institutional securities layer.

The synthesis

Use CCIP as the default. Use native bridges where they fit. Treat the rest as edge cases. The institutional cross-chain stack is a layered choice, not a single mechanism: CCIP is the generalised messaging fabric, native bridges are the optimised chain-pair specialists, and each is used for the cases it was built for.

CCIP earns the default for the reasons Part 2 set out: the two-network architecture (DON plus RMN), the regulatory engagement, the chain coverage, the production deployments at Swift, DTCC, ANZ, BNY, and JPM. For a new institutional cross-chain flow with no specific reason to choose otherwise, CCIP is the starting point. An institutional counterparty already recognises it from their own diligence reviews; an audit will accept it without an extended explanation.

Native bridges earn their place where the chain pair is a recurring high-volume route inside an issuer's own footprint. JPMD on Base interacting with Ethereum-side liquidity is a Base-bridge case. MONY extending to Base, when that integration arrives, is a Base-bridge case for issuer-controlled rebalancing. Where the issuer controls both ends, the seven-day optimistic-rollup withdrawal window is absorbable, and the cost saving over CCIP is meaningful, native bridges are the right answer.

Intent-based routing remains a watching brief. Atomic swaps remain the theoretical reference point. Neither is the right primitive for a tokenised MMF or tokenised deposit cross-chain DvP today. Both may move into the institutional default position over a longer horizon; neither is there yet.

What this looks like for TCN

The TCN cross-chain story is anchored on the OUSG transaction and extends from there. JPM's Programmable Token Transfer using CCIP for the Ondo [/use-cases/ousg] cross-chain DvP is the production reference case. The asset leg moved across chains via CCIP burn-and-mint; the cash leg settled on the destination chain via the programmable payload travelling with the transfer; the two settled together inside the destination-chain atomicity guarantee. That is the architectural template TCN extends.

Twelve to twenty-four months out, the TCN cross-chain footprint plausibly looks like this. Mainnet remains the primary settlement venue for tokenised MMF collateral, because that is where the assets sit. Base is the destination for payments-style flows interacting with JPMD. Canton is the destination for institutional securities flows where the DTCC-anchored stack settles. Cross-chain DvP between any pair is orchestrated through CCIP for the generalised case, with the Base bridge used for the specific Mainnet-Base pair where it is more efficient and the issuer controls both sides.

The economic case is straightforward: CCIP carries the diligence narrative and the cross-issuer flows, native bridges carry the high-volume issuer-controlled rebalancing, and the choice on each transaction is determined by the chain pair and the counterparty. There is no single mechanism that does all of this; trying to pick one and apply it everywhere is the wrong shape.

The open question: Canton

Whether CCIP supports Canton, and what cross-chain settlement to and from Canton actually looks like, is the live question. Canton Network runs on Daml rather than Solidity, with selective disclosure and a different consensus and party-authorisation model than the EVM chains CCIP was built around. Chainlink and Digital Asset have been working on integration, and CCIP support for Canton is plausibly imminent, but the integration is not in the same production-tested state as CCIP-Ethereum or CCIP-Base. The architectural question is whether CCIP's two-network model adapts cleanly to Canton's privacy semantics: a DON observing Canton state is a different problem from a DON observing public EVM state, because much of the relevant Canton state is not public.

The two paths are visible. One: CCIP integrates Canton successfully, the institutional cross-chain story becomes "CCIP for everything, including Canton," and the orchestration layer is unified. Two: Canton's privacy semantics resist clean CCIP integration, a Canton-native bridge mechanism emerges (likely built by Digital Asset or a Canton consortium), and the story becomes "CCIP for EVM-chain pairs, Canton-native bridge for any flow involving Canton."

Either path is workable. The strategic risk for an issuer planning a multi-year footprint is committing to the wrong assumption before the answer is settled. The right operational posture is to design the cross-chain layer as an interface (issuer-controlled, mechanism-agnostic), not as a hard-wired protocol choice, so whichever path resolves can be adopted without re-architecting upstream flows. JPM and the other issuers building on Canton are in this position now, keeping the choice between CCIP-on-Canton and a Canton-native mechanism open.

Where this leaves the chapter

Cross-chain interoperability is the connective tissue of the multi-chain architecture Chapter IV described. Without it, multi-chain is multi-silo, and the institutional case for tokenisation as a unified rail collapses into disconnected experiments. With it, the Mainnet-Base-Canton-Solana mix becomes a single addressable surface, each chain doing what it is best at and the cross-chain layer carrying value between them.

The mechanism choice is not a technical preference. It is a credit-risk and operational-risk decision dressed up as a protocol question. The history of cross-chain bridge exploits, Chainlink Labs' institutional engagement around CCIP, and the production track record at Swift, DTCC, JPM, and the other reference names all point the same way: CCIP is the right default, native bridges the right specialist, Canton integration the open question to track over the next two years. Get the default right, manage the specialists where they apply, keep optionality on the parts not yet settled. That is the institutional cross-chain answer.