The four chains in Parts 1 to 4 are not competing for a single slot in an institutional issuer's stack. They are optimising for different properties that no single chain can deliver simultaneously. Mainnet maximises brand and composability and pays for it in fees. Base maximises predictable cost and inherits Ethereum's security but gives up some crypto-native composability. Canton maximises privacy and institutional-securities fit but sits outside the EVM ecosystem entirely. Solana maximises throughput and fits a specific crypto-native counterparty base but is not the institutional default. The conclusion of the chapter is that the right architecture is multi-chain by design, with each chain doing what it is best at and a deliberate orchestration layer connecting them. This part covers the synthesis, where the Kinexys strategy is heading, and how cross-chain orchestration fits in as the primitive that makes multi-chain operationally tractable.
Why "pick the best chain" is the wrong frame
The trade-off space does not collapse to a single optimum. An institutional MMF needs maximum composability with the existing tokenised-asset universe (mainnet wins). A payments token needs predictable sub-cent fees and high throughput (Base wins). A securities settlement layer needs sub-transaction privacy and party-based authorisation (Canton wins). A crypto-native commercial paper instrument needs Solana's throughput and counterparty base. No chain wins on all four axes, and the trade-offs are structural, not transient. The design choices that produce each chain's strengths are the same choices that produce its weaknesses.
For the institutional tokenisation stack, there will not be one winner. There will be a small number of chains each occupying a structural slot, and the orchestration layer between them will become as important as any single chain.
Where the Kinexys strategy is going
JPMD on Canton and JPMD on Base coexist. The 2026 Canton integration is not a migration off Base. It is an additional deployment serving a different counterparty base. JPMD on Base serves the Coinbase-distributed institutional segment and corporate treasury use cases where predictable cost and EVM-native composability dominate. JPMD on Canton serves Asian institutional clients with explicit privacy mandates and the DTCC tokenisation flow where sub-transaction privacy is a precondition for participating at all. The two deployments are the same product (a JPM-issued tokenised deposit) on two different rails, with cross-chain orchestration handling the cases where value needs to move between them.
MONY likely extends to Canton in 2026 to 2027. If Canton becomes the de facto institutional securities layer in the US (the central strategic question raised in Part 3), then MONY needs to be reachable from that layer. The use case is institutional MMF holdings being usable as collateral inside DTCC-routed securities settlement, which requires MONY to be present on the Canton side of that flow. The exact timing depends on Canton ecosystem maturity and DTCC tokenisation service rollout. The strategic direction is settled even if the schedule is not.
Solana surfaces transactionally, not foundationally. Galaxy USCP is the template: when a specific high-value counterparty's natural rail is Solana, JPM acts as Arranger and the deal lands on Solana. The same pattern would apply to a future tokenised commercial paper for a different crypto-native sponsor, or a tokenised structured product targeting the Solana-native institutional base. JPMD itself is unlikely to deploy on Solana unless a specific counterparty trigger emerges, because the marginal counterparty reach is too thin to justify the operational cost of another foundational chain.
How cross-chain orchestration makes multi-chain tractable
A multi-chain strategy is operationally cheap in theory and expensive in practice. The cost shows up in the cross-chain interactions: moving a holder's position from JPMD on Base to JPMD on Canton, settling a trade where the asset leg is on one chain and the cash leg on another, providing a single account view to a client whose holdings span four chains. Without a clean orchestration layer, every additional chain compounds operational complexity rather than adding linearly to the addressable counterparty base.
The current institutional answer is Chainlink CCIP (Cross-Chain Interoperability Protocol). CCIP runs a decentralised oracle network plus a separate Risk Management Network that independently verifies cross-chain messages. Tokens lock on the source chain, oracles attest, the Risk Management Network verifies, and the destination chain mints. The two-layer architecture exists specifically because institutional risk diligence is allergic to single-source attestation.
CCIP is the primitive JPM used for the Ondo Finance OUSG cross-chain DvP transaction. It is also in production with Swift, DTCC, ANZ, and BNY. The trade-off is latency (ten minutes to multiple hours for high-value transfers, due to source-chain finality requirements) and per-message LINK fees, both acceptable for institutional settlement.
The open question for the next twelve to twenty-four months is whether CCIP supports Canton at institutional grade or whether Canton-specific bridging primitives are needed for the EVM-to-non-EVM gap. Chapter V picks this thread up in detail.
The chapter-level conclusion
Multi-chain is not a transitional state. It is the destination. The institutional tokenisation stack is converging on a small set of chains, each occupying a structural slot driven by the counterparty base it serves. Mainnet for institutional MMF gravity. Base for the predictable-cost payments and corporate treasury layer. Canton for institutional securities and the privacy-mandated Asian segment. Solana for specific crypto-native partner deployments. Other chains (Polygon, Arbitrum, Optimism) for specific partner-driven cases.
The strategic question is not which chain wins. It is which slot each chain ends up occupying, how the orchestration layer matures, and how the product strategy maps onto the resulting topology. The chain choice for any institutional tokenised product is downstream of which counterparty base it serves; the right architecture is to deploy on as many chains as the counterparty base requires while keeping the orchestration layer disciplined enough that operational cost stays linear.