The chains in Parts 1 and 2 share an architectural assumption inherited from Bitcoin and entrenched by Ethereum: every transaction on the ledger is publicly visible. For payments and for tokenised funds with disclosed institutional holders, this is a tolerable property. For institutional securities settlement at the volumes DTCC processes, it is not. Canton Network exists because a meaningful slice of institutional finance refuses to operate on rails where strategic position information is leaked by default. This part covers what Canton actually is, what it solves that EVM chains structurally cannot, and why JPM is integrating JPMD with Canton in 2026.
What Canton actually is
A privacy-by-default network built by Digital Asset. Canton is not a single chain in the EVM sense. It is a network of independently operated nodes that share a common protocol, where each node holds only the data its operator's parties are entitled to see. There is no global ledger that any participant can read in full. The protocol guarantees consistency across the parties to a transaction without requiring those parties to disclose the transaction to anyone else.
Daml is the contract language. Daml (Digital Asset Modeling Language) is purpose-built for financial workflows. The unit of authorisation is the party (an identity within the network), not the address. Contracts are written as templates with explicit signatories, observers, and choices, and the runtime enforces that only authorised parties can exercise choices on a contract. The mental model is closer to a typed multi-party workflow than to a Solidity smart contract executing in a public VM.
Sub-transaction privacy. The load-bearing property and the one that distinguishes Canton from every public chain. In a single transaction touching multiple parties, each party sees only the parts relevant to them. A buyer sees the purchase. A seller sees the sale. A custodian sees the custody movement. A regulator (if specified as an observer) sees what the mandate requires. No participant sees the full graph unless they are entitled to. Selective disclosure built into the protocol, not bolted on.
Smaller, more institutional ecosystem. Canton's ecosystem is substantially smaller than Ethereum's. There are no DeFi protocols on Canton in the EVM sense and no broad retail user base. The integrations that matter are with regulated financial institutions: DTCC, the major sell-side banks, asset managers building institutional rails, and central banks evaluating Canton for wholesale settlement. A feature for the use cases Canton targets, a structural ceiling for the ones it does not.
Why JPM is integrating JPMD with Canton
Two distinct customer segments drive this.
Asian institutional clients with explicit privacy mandates. Japanese keiretsu and certain Korean institutional pools (insurance, pension, megabank treasury) hold mandates that prohibit operating on rails where positions are disclosed by default. The mandate language varies but the substance is the same: strategic positioning information is itself a regulated asset, and depositing it onto a public chain is non-compliant regardless of the operational benefits. For these clients, JPMD on Base is unusable. JPMD on Canton is.
The 2026 launch timing for JPMD on Canton aligns with several of these clients moving from internal pilots to production tokenised-deposit usage. The integration is not speculative; it is responding to specific demand from named institutional partners who have indicated that Canton-native availability is a precondition.
DTCC's tokenisation service. DTCC processes roughly $99 trillion in securities across its core depository services. Operating that flow on a public chain is structurally non-viable; the strategic information leakage from real-time visibility into who is settling what against whom would reshape market dynamics in ways no participant has consented to. DTCC's choice of Canton for its tokenisation service is the most consequential institutional chain selection of the past two years. Once DTCC's tokenisation service runs on Canton at scale, every issuer wanting their tokenised asset to settle through DTCC's infrastructure has to be reachable from Canton. JPMD's integration with Canton positions it as one of the cash legs available for that DTCC-hosted settlement.
The strategic question Canton raises
The substantive question is whether Canton becomes the de facto institutional securities tokenisation layer in the US, with DTCC, JPMD, BlackRock, Goldman, and the rest of the bulge bracket converging there for the institutional-securities slice while keeping payment and crypto-native flows on EVM chains.
The argument for: DTCC's choice creates gravitational pull. Once a meaningful share of US securities tokenisation routes through DTCC's Canton-based service, every counterparty that wants to be reachable for that flow has to integrate with Canton. Standard settlement network effect.
The argument against: Canton's ecosystem is small enough today that betting it becomes the institutional default is not a foregone conclusion. The major Asian institutional adoption stories (Project Guardian flows, Hong Kong Project Ensemble, Japan's Progmat stack) are running on permissioned EVM variants and consortium chains, not on Canton. If Canton fails to attract those flows, it remains a US-centric institutional rail rather than a global one.
The honest read: Canton is the most credible candidate today, but the outcome depends on whether DTCC's gravity overcomes EVM ecosystem momentum. JPM's choice to integrate JPMD with Canton in parallel with Base is a hedge.
What Canton means for the rest of the architecture
Canton sits at the opposite end of the design space from mainnet and Base. Mainnet maximises composability and brand at the cost of throughput; Base maximises throughput and predictable cost at some loss of crypto-native composability; Canton maximises privacy and institutional-securities fit at the cost of crypto-native ecosystem entirely. No chain dominates on all three axes, so the right architecture is to deploy on the chains your counterparty base requires. Part 4 covers Solana for crypto-native partner use cases. Part 5 ties it together as the multi-chain-by-design synthesis.