Canton

This is the third post in our network series. We started with Bitcoin, the origin chain, and continued with Ethereum, where most onchain finance runs. This time we turn to Canton, the network built for regulated finance, and the clearest case so far of capital markets moving onchain.

If Bitcoin proved that value could move without an intermediary, and Ethereum proved that the rules around value could be written in software, Canton is proving something the first two could not. Regulated institutions can run their core markets on shared infrastructure without showing their positions to the world. For a decade, that was the gap. Public chains offered scale but exposed every transaction. Private chains offered control but never reached the critical mass that makes a market. Canton was designed to close that gap, and in the past eighteen months the largest institutions in finance have started to run on it.

Last week gave the clearest sign yet. On 28 October, The Depository Trust & Clearing Corporation (DTCC) launched the DTCC Tokenization Service, allowing DTC, the depository that holds more than $114 trillion in custody, to create tokenized versions of the securities it safeguards. Canton is one of the two networks the service runs on from day one, and DFNS is among the collaborators and partners DTCC brought together to support it.

This post walks through what Canton is and how it works, the institutional use cases already in production, every Canton capability DFNS supports today, including the CIP-112 allocations support we announced today, the cryptography and security underneath, and where we are taking the platform next.

Why Canton and why now

We started this series with Bitcoin because it is the asset most institutions hold first, and continued with Ethereum because it is where most onchain products run. Canton is the natural third, because it is where regulated capital markets are choosing to settle. Repo, collateral, tokenized Treasuries, digital bonds, tokenized deposits and funds are moving onto it in production, run by the institutions that already operate those markets offchain.

Canton is a privacy-preserving settlement network built by Digital Asset and launched in 2023 with a founding group that included Goldman Sachs, BNP Paribas, Deutsche Börse and Microsoft. Its public mainnet, the Global Synchronizer, went live in 2024. The idea behind it is different from every other network in this series. Instead of one chain that everyone shares and everyone can see, Canton is a network of networks. Each application and each institution runs its own ledger and sets its own privacy and governance rules, and all of them can still transact with one another atomically, through shared synchronization, without bridges.

A few properties matter for a financial institution.

Privacy is built in, not bolted on. On Canton, each participant sees only the parts of a transaction it is a party to. Two banks settling a repo see the trade. The rest of the network does not, and neither does the operator of the infrastructure between them. This is what Digital Asset calls sub-transaction privacy, and it is the property that allows a bank to put real positions on a shared network.
Settlement is atomic across independent ledgers. A delivery-versus-payment trade on Canton either completes in full, securities and cash together, or does not happen at all, even when the two legs live on different participants’ nodes. There is no bridge, no wrapped asset and no settlement risk between them.
The rules are written in Daml. Canton’s smart contracts are written in Daml, an open source language built for financial agreements. Daml contracts know who may see and do what, and the network enforces it. A bond, a repo or a fund share is modeled as a contract with explicit rights and obligations, which is how lawyers and operations teams already think.
Institutions run the infrastructure. The Global Synchronizer is operated by Super Validators drawn from the industry, and participants run their own validator nodes. Visa joined as a Super Validator in 2026. Since 2025, Digital Asset’s funding rounds have drawn BNY, Nasdaq, S&P Global, Tradeweb and DRW, and in June 2026 the company closed a $355 million round led by a16z crypto. The network is governed by the institutions that depend on it.

The numbers now match the design. Broadridge processes repo transactions on Canton for most of the US primary dealers, measured in trillions of dollars a month. In November 2022, Goldman Sachs settled a €100 million digital bond for the European Investment Bank same-day on GS DAP, its platform built on Canton technology, the first digital bond executed under Luxembourg law. On Saturday 26 July 2025, a working group including Bank of America, Citadel Securities, Société Générale, DTCC and Circle executed the first weekend Treasury repo on the network, trading on Tradeweb with tokenized US Treasuries financed against USDC outside market hours. Euroclear took part in the Canton collateral mobility pilot that ran 500 transactions across 27 market participants, and in 2026 joined the industry working group that has executed cross-border intraday repo on the network, including the first repo against tokenized gilts in February 2026. Franklin Templeton expanded its Benji platform onto Canton in November 2025, Kinexys by J.P. Morgan is integrating JPM Coin, HSBC is piloting tokenized deposits, and Circle has brought USDCx, a USDC-backed stablecoin minted through its xReserve, to the network, with DFNS among the day-one participants. More than 150 applications are live or emerging, and Digital Asset works with more than 700 ecosystem participants.

Regulation has caught up with the technology. In Europe, MiCA has applied in full since 30 December 2024. In the United States, the GENIUS Act of July 2025 gave stablecoins a federal framework and kept tokenized deposits outside it, as bank deposits under existing banking law, and in December 2025 DTCC received a no-action letter from the SEC covering Russell 1000 stocks, major index ETFs and US Treasuries. The result is that, for the first time, banks on both sides of the Atlantic can use a shared network as part of their core infrastructure. Canton is the network built for exactly that.

What a core banking platform brings to Canton

Canton solves the hardest problem of institutional blockchains, which is sharing a network without sharing your data. It does not, on its own, solve the operational problem inside each institution. Who may sign for a party, under which approvals, within what limits, and with what evidence when the supervisor asks. Which keys sign, where they live, and how they are protected. How holdings on Canton appear in the same books as holdings on every other network. How a tokenized security delivered on Canton is received, reconciled and reported.

That is the layer DFNS provides. We are a core banking platform for digital assets, and on Canton that means the full operating layer an institution needs to run its business on the network. Accounts, transaction management, policy and approvals, compliance and audit, treasury and key security are one system, reached through one API, under one set of controls that extends across Canton and every other network the institution uses.

The institutions doing this are not running experiments. DFNS is trusted by more than 500 financial institutions and fintechs, including Standard Chartered Bank, First Abu Dhabi Bank, IBM, Broadridge, Stripe and Circle. The platform processes roughly 1% of global stablecoin volume, has run at 99.997% uptime since 2022, and has had zero breaches and zero key losses since 2020, under SOC 2 Type II and ISO 27001, 27017 and 27018 certifications.

How DFNS unlocked Canton for traditional finance

DFNS has supported Canton since 2025. We operate validators on MainNet, TestNet and DevNet, we announced Bring Your Own Validator in May 2025 so institutions could connect their own nodes, and we have built the signing, indexing and governance that let a Canton party behave like any other wallet on the platform.

Last week showed what that groundwork was for. The DTCC Tokenization Service lets DTC create tokenized representations of the securities it holds, keeping every right, protection and economic entitlement of the originals, and deliver them to the wallets eligible users choose. Twenty DTC Participants have signed on from the start, and DTS runs on the Canton Network and on DTCC’s private Besu network. Institutions on DFNS can hold, move and govern DTS tokenized securities on both. On Canton, the Daml packages that define DTS instruments are deployed on the validators DFNS operates and on client validators connected through Bring Your Own Validator, so DTS holdings are indexed, decoded and governed like any other asset on the platform.

This matters beyond DTCC. The same capability lets an institution receive a tokenized fund share from one application, post it as collateral in another and settle against cash in a third, all on Canton, all under one set of controls. That is what it means for a network to become core infrastructure rather than a pilot.

Why institutions choose DFNS for Canton

On Canton, the unit of identity is a party, and a party’s key is the whole institution’s authority on the network. Where that key lives, who can use it and under what rules decides whether an institution is in control of its Canton presence or merely connected to it. Six things make the difference.

One platform across Canton, Ethereum, Bitcoin and the rest of the 100+ networks DFNS supports. A Canton party is a DFNS wallet. It sits beside the institution’s Ethereum wallets, its Bitcoin wallets and its wallets on private networks, with the same users, organizations, policies and audit logs. An institution that settles repo on Canton and moves stablecoins on Ethereum runs both from one system.
The key never touches the node. Each Canton party is a DFNS wallet with its own key, generated and held as MPC key shares or in the institution’s own HSM. The validator node, whoever runs it, never holds the key. It asks DFNS for signatures through Canton’s external signing interface, and DFNS signs only after the Policy Engine has approved. A compromised node cannot sign on its own.
Validators your way. Use a shared validator DFNS operates on MainNet, TestNet or DevNet. Or connect your own through Bring Your Own Validator and keep the node inside your perimeter. Keys, policies and audit stay the same either way.
Governance and compliance below the API. Approval quorums, allowlists of counterparties, limits and time locks apply to Canton transfers, allocations and pre-approvals the same way they apply to a transfer on any other chain, and they cannot be bypassed with credentials alone. Every action is signed on the user’s device and recorded in an audit trail an examiner can verify.
Built for how Canton settles. DFNS supports the Canton Network Token Standard, both CIP-56 and its V2 evolution, CIP-112, for which we announced allocations support today. That means pre-approvals so incoming deliveries settle without manual acceptance, delivery-versus-payment allocations that settle the securities leg and the cash leg atomically, and committed allocations under CIP-112, which lock the Canton leg of a trade until an agreed settlement deadline so the other leg can be coordinated with certainty. Canton transactions built by DFNS stay valid for 24 hours, so a signed instruction survives a maintenance window.
Flexible deployment and predictable pricing. Run DFNS as SaaS, hybrid or fully on-premises, with the same MPC layer in every model, or keep Canton keys in your own HSM. Pricing is a subscription and licensing model with no basis points on assets and no transaction fees, so the economics do not change as volumes on Canton grow.

Comprehensive Canton support, end-to-end

The summary below covers what DFNS supports on Canton today.

Validators and connectivity

Validators operated by DFNS on MainNet, TestNet and DevNet
Bring Your Own Validator, connecting an institution’s own node to the platform
Canton Wallet Gateway, where DFNS is an official signing provider, so any CIP-103 compliant application on Canton can request signatures from DFNS-secured keys without a DFNS-specific integration
Controlled, audited deployment of Daml packages, so an institution can enable the applications and instruments it uses, including DTS

Parties, keys and signing

Each Canton party as a DFNS wallet, with its own Ed25519 key held as MPC shares or in an institution’s HSM
External signing, where the node prepares the transaction and DFNS signs it after policy approval, so the key never sits on the node
Party onboarding and topology changes signed through the same flow
Transactions valid for 24 hours from the moment they are built, so signing and broadcast both fit inside the window

Instruments and settlement

Canton Network Token Standard support, CIP-56 and CIP-112 (Token Standard V2)
Pre-approvals, so incoming deliveries of approved instruments settle without a manual step
Delivery-versus-payment allocations, settling securities against cash atomically
Committed allocations under CIP-112, locking the Canton leg of a trade until a settlement deadline, for DvP coordinated with another leg, onchain or off
Transfers and allocations under the Policy Engine, with quorums, allowlists and limits

Indexing, history and webhooks

Canton holdings indexed and decoded into balances and history for each party
Webhooks for deliveries, transfers and allocations, so back-office systems react in real time
DTS instruments indexed and decoded on validators where the packages are deployed

Operations

Transfers, broadcast transactions and signature requests accept an external identifier for idempotency, so retries never double-submit
The same dashboard and API as every other network, so operators do not learn a second system for Canton

Engineering deep dive: the cryptography behind it

Canton’s default signing scheme is Ed25519, and DFNS uses it for every Canton party, which changes the picture compared with Bitcoin and Ethereum.

Threshold EdDSA. DFNS produces Ed25519 signatures through a threshold protocol, so the party key exists only as shares across independent signers and is never assembled. The signature is indistinguishable from one made with a single key, which is what the Canton node and the network expect.
Throughput. EdDSA signing on DFNS runs at substantially higher throughput than ECDSA. For Canton, where a busy participant signs many small transactions, that headroom matters.
External signing as a security boundary. Canton’s external signing model separates the node that prepares a transaction from the signer that authorizes it. DFNS uses that boundary deliberately. The node sees the transaction. The signer sees the hash, the policy decision and the governed records behind it. Neither can act alone.
The no-key-assembly invariant. As on every other network, a DFNS key is never materialized in one place at any point in its life, from generation to signing to backup and authorized export.
Independent signer environments. Each signer runs in a separate, hardened environment. In our managed deployment these span Tier 3+ and Tier 4 data centers across regions. In hybrid and on-premises deployments the institution decides where each signer lives.

Security architecture beyond the cryptography

Passkeys. Every action is authorized on the user’s device with a passkey built on FIDO2 and WebAuthn. No passwords, no shared secrets, no phishing path to a Canton party.

Deployment models. Fully managed in DFNS’s certified infrastructure. Hybrid, with one or more key shares on your own infrastructure so nothing signs without you. On-premises, with the full stack inside your perimeter. And Bring Your Own HSM, with IBM, Thales, Securosys and other FIPS-certified modules holding Canton keys in your own root of trust.

Audits and certifications. SOC 2 Type II and ISO 27001, 27017 and 27018, with continuous third-party penetration testing.

Insurance. Crime, cyber and errors-and-omissions cover placed with Lloyd’s syndicates Mosaic and Markel.

Availability. 99.997% uptime since 2022, with active-active infrastructure and automatic failover. Status is published at status.dfns.co.

Disaster recovery. Independent recovery paths at every layer, including the ability for hybrid and on-premises clients to recover their Canton keys without DFNS.

Governance for Canton operations

Securing the party key is necessary. Controlling what it can do is what a supervisor will ask about. The DFNS Policy Engine runs before any Canton signature is produced. In practice, Canton operations look like this.

Approval quorums. A transfer or an allocation above a threshold needs sign-off from several named approvers, with the quorum varying by amount, instrument, counterparty or time.
Allowlists. Transfers can be restricted to approved counterparties. Adding to the list is itself a governed action.
Pre-approval policy. Which instruments a party accepts automatically, and which require a human, is a rule rather than a manual habit.
Limits and time locks. Caps on value moved per window, and delays on large movements.
Screening. Where a Canton flow touches an asset or a counterparty covered by Chainalysis, Elliptic or Global Ledger, screening runs before signing.
Roles and permissions. Separation of duties mapped directly into platform roles, so the people who operate a party are not the people who approve its policies.

Because these rules live below the API, in the same layer that produces signatures, they hold even when credentials are compromised. On a network built for privacy, this is also what makes an institution’s own operations provable to the one party that needs to see them, its regulator.

Canton use cases at institutional scale

Canton is not one product. It is where several regulated markets are moving at once, and the same wallet infrastructure serves all of them.

1. Tokenized securities and the DTCC Tokenization Service

DTC-custodied securities as tokens on Canton, delivered to the wallets eligible users choose. DFNS indexes DTS instruments on the validators where the packages are deployed, holds them in governed wallets, pre-approves deliveries and settles them against cash. For a bank or broker receiving tokenized securities, this is the operational layer that turns a delivery into a position in its books.

2. Repo and collateral mobility

Broadridge’s repo platform and the collateral mobility pilots Euroclear has taken part in on Canton have shown what atomic settlement does to a market that used to run on batches. Collateral moves between counterparties in minutes, around the clock, and intraday repo becomes ordinary. DFNS brings the controls that make a bank’s participation safe. Who can pledge, who can recall, within what limits, with what approvals, and, for collateral held on EVM networks, locks on Vaults so it stays put until a term ends. With CIP-112 committed allocations, a dealer can lock the Canton leg of a repo until the settlement deadline, which is what makes delivery-versus-payment dependable when the cash or the counterparty sits somewhere else.

3. Tokenized funds

Franklin Templeton’s expansion of Benji onto Canton points to where fund administration is heading. Subscriptions, redemptions and transfers of fund shares as Canton contracts, settled against cash. DFNS provides the wallets for distributors and investors, the policies that enforce who may hold and transfer, and the audit trail the administrator needs.

4. Tokenized deposits and cash on Canton

JPM Coin through Kinexys, HSBC’s tokenized deposit pilot and Circle’s USDC-backed USDCx give Canton the cash leg that delivery-versus-payment needs. DFNS treats these balances like any other asset in treasury, with limits, approvals and reconciliation, and lets an institution settle securities against them atomically.

5. Digital bonds

The EIB’s €100 million bond with Goldman Sachs, issued, recorded and settled on GS DAP under Luxembourg law, showed what same-day settlement looks like. Issuers and dealers on DFNS can hold, allocate and settle digital bonds on Canton with the same governance they apply to any other issuance, and use the Tokenization Engine to run the lifecycle.

6. Applications built on Canton

With more than 150 applications live or emerging, many institutions will participate in Canton through someone else’s application rather than their own. Daml packages deployed on an institution’s validator let DFNS index and govern the instruments those applications issue, so a position in a third-party app appears in the same books, under the same controls, as everything else.

Roadmap: where Canton support is heading next

Canton is adding applications, instruments and participants faster than any network built for institutions before it. Our near-term focus follows that growth. Deeper support for Token Standard V2 as applications adopt CIP-112 beyond allocations, and for the instruments and workflows around the DTCC Tokenization Service as more participants go live. Broader coverage of the applications institutions join, so new Daml packages are enabled and indexed quickly. Validation Gate support for Canton signing on hybrid and on-premises deployments, so an institution’s own system can approve each signature before it happens. And the same principle as everywhere else on the platform. Whatever an institution adopts on Canton should run under the controls it already has, without re-architecting.

If Canton is on your roadmap, talk to us.

What’s next in this series

Bitcoin was the origin chain. Ethereum is where most onchain finance is built. Canton is where regulated capital markets are moving. The next post will cover Solana, the network where payments and consumer finance meet institutional scale, and where stablecoin settlement has grown fastest in the past two years. Further network deep dives will follow.

Subscribe to the DFNS newsletter if you want each post in your inbox as it goes live.

Learn more about onchain core banking: dfns.co
Explore the platform and documentation: docs.dfns.co
Start building today on DFNS: app.dfns.io/get-started
Talk to our team: dfns.co/contact