Canton Network Development: Daml Apps, Validator Nodes and EVM Links
The Canton Network is a public layer 1 blockchain for privacy-preserving financial transactions, created by Digital Asset; Canton Network development is the work of putting an institution's workflow on it. Canton does not run EVM contracts natively, so Solidity stays on the EVM chain, linked to Canton through LayerZero or Chainlink CCIP. Protofire builds and operates each part: contracts in Daml, Canton's smart contract language, the Ledger API integration, the validator node and the EVM end of each route. A MainNet validator needs the Canton Foundation's approval, should take weekly upgrades and, since 30 April 2026, earns nothing for uptime alone. The first decision is whether Protofire runs your own validator in your cloud account, or you rent a node from an approved operator.

Reviewed by Luis Medeiros, Field CTO at ProtofireLast reviewed: October 2026
Protofire builds the Daml application and its integrations, connects it to EVM chains over the routes that are live, and runs the nodes on DevNet, TestNet and MainNet through Canton's weekly upgrades, 24/7.
The institution or app provider files its own applications for network approval, from the Canton Foundation's validator approval to Featured App status, which makes an app eligible for app rewards. Its parties (Canton's on-ledger identities, much like accounts) sign with keys in its own KMS or external signer.
Canton's validator software gets a backward-compatible upgrade every Monday; the rules, counts and listings on this page are given as of 18 October 2026.
The parts of a Canton deployment, from your systems to the network
Your systems and the Daml application sit on top, the node with its keys and traffic is what gets operated, and the synchronizer and EVM routes are shared.
Your systems
Integration service
Daml application
Participant and validator node
Keys and traffic
Global Synchronizer
EVM routes
Which pieces make up Canton Network development, from Daml contracts to EVM links?
Each part can be taken on its own: a team with Daml developers can hand us only the nodes, and a team that rents its node only the application.
We write the Daml model of your workflow: templates, the choices that move it forward, and the signatories and observers that decide who must authorize each step and who sees it. Daml is, in Canton's words, "a functional smart contract language with a strong type system, built-in authorization model, and privacy controls". The model decides what each counterparty's node receives, because Canton distributes state and transactions only to the nodes the contracts specify.
How that need-to-know model compares with private validiums, FHE tokens and shielded pools, and who can grant an auditor access in each, is covered in our onchain privacy for institutions guide.
Every template ships with tests in Daml Script, "the primary testing tool for Daml contracts", which runs each scenario on a fresh ledger. Where it fits, we start from Digital Asset's cn-quickstart reference application, with its Java backend and React frontend.
Later changes to your packages go through Smart Contract Upgrade, the Canton 3 upgrade model. Existing Daml 2 code is ported first, because a Canton 3 node does not run Daml 2 packages.
We connect the Daml application to the systems your business already runs through the participant node's Ledger API. The Ledger API comes in gRPC and JSON-over-HTTP forms, both at version 2 in Canton 3, with JWT authentication through your OIDC identity provider; in Canton 3 the JSON API is built into the participant node. We build on the officially supported Java and TypeScript bindings, since community libraries for Python, Rust, Go or C# "are not maintained or supported by Canton Network".
The integration service maps your users and accounts to Canton parties, submits commands and follows each one until it completes, and feeds reporting and reconciliation from PQS, which projects contract state into PostgreSQL for SQL queries. New Daml packages reach the participant as DAR (Daml Archive) files, and because a release may need the same packages on counterparties' nodes, we coordinate each DAR deployment with them.
We build assets to CIP-56, the Canton Network Token Standard, so wallets, custodians and other applications can hold and settle them. CIP-56 defines Daml interfaces for holdings, transfer instructions and allocations, and an allocation locks assets so that a multi-leg delivery-versus-payment settlement executes atomically. Token Standard V2 (CIP-0112) was approved in June 2026, and the docs still say "CIP-0056 remains the current deployed standard". We build to CIP-56 and track V2.
Wallet connectivity follows the CIP-103 dApp standard, with Canton's Wallet SDK, dApp SDK and Wallet Gateway. On the custody side, BitGo, Fireblocks, Ledger and Ripple Custody support Canton Coin. Fireblocks also supports CIP-56 tokens, and Ripple Custody supports the CIP-56 tokens issued through the Digital Asset Registry, working with a validator that you or your node provider operate.
Where a party signs with its own keys, held with a custodian or in an HSM, the integration prepares each transaction for external signing through the Ledger API's interactive submission service. When the same asset also needs an EVM representation, our tokenization infrastructure work covers the ERC-3643 side.
We deploy and run the validator that hosts your parties, on Kubernetes in your cloud account, on DevNet, TestNet and MainNet. Canton recommends Kubernetes for TestNet and MainNet: version 1.27 or newer with Helm, an ingress controller, an external PostgreSQL database in the same zone as the cluster, and a static egress IP.
Canton's reference sizing for an app provider with moderate activity is 2 CPUs, 16 GB of memory and a 100 GB database. The docs call these "reference values"; we size from your expected traffic and load-test before MainNet.
For each network, the Super Validators add a distinct egress IP to their allowlists, which "usually takes between 2-7 days", and on TestNet and MainNet the Super Validator sponsoring you issues a one-time onboarding secret, valid for 48 hours. The cloud, database and monitoring layers come from our node infrastructure practice.
We keep each node on Canton's release cadence, its keys in a KMS and its traffic balance funded, and we watch all of it around the clock. Splice, the application layer each validator runs for Canton Coin, the wallet and network automation, gets backward-compatible upgrades "on Mondays, every week". Daml model changes come every few months after a CIP and an onchain vote, and protocol upgrades every three to four months, for which "Canton requires all nodes to migrate together". At a Daml model cutoff, only validators on the latest Splice version can take part in transactions that use the new models.
Asked on Episode 5 of The Protocol Roundtable what institutions did not plan for, Protofire's Lead Product Manager, Rado Patus, spoke about chain upgrades in general and pictured one at 3 a.m.: "What's the bank supposed to do with it? So there needs to be someone who needs to upgrade the chain, or basically all of their systems, to adapt to that, or they will fail eventually in six hours, in the morning."
DevNet always takes a new release before TestNet and MainNet, so we run your application on all three networks and take every upgrade on DevNet first. A version upgrade is a helm upgrade, and the rules forbid deleting a Postgres database or changing migration IDs or secrets along the way.
By default Canton generates node keys and keeps them in the node's primary storage. We put them under AWS KMS, Google Cloud KMS or, through Canton's KMS driver API, your own KMS, either encrypted at rest with a KMS key or generated and kept entirely inside the KMS.
Monitoring covers the node's connection to the synchronizer, failed commands, the traffic balance with automatic top-up, package versions against your counterparties, and each cross-chain route. The alerting and on-call tooling come from our managed onchain operations work, and your operations team signs off on the incident procedures.
We connect Canton to EVM chains over the routes that are live, and we build the EVM end of each route as well. LayerZero announced its Canton integration on 26 March 2026, and its deployment registry lists a Canton mainnet endpoint as active, with LayerZero Labs and Nethermind as verifier networks. Chainlink's CCIP directory lists Canton lanes to Ethereum and Base carrying the USD1 and RIZE tokens, with Canton Coin as the fee token. Chainlink's Data Streams, NAV and proof-of-reserve feeds were announced as live on Canton in late February 2026.
Circle's USDCx, live since 4 December 2025, is a USDC-backed token: "When a user deposits USDC into xReserve on Ethereum, a mint of USDCx is initiated on Canton through the protocol." Wallets need their own integration for those deposits and withdrawals. Neither Zenith nor Wormhole offered a live route: Zenith's EVM execution layer for Canton was on testnet, and Wormhole, a Super Validator, had no Canton entry in its chain registry.
On the EVM side we write and test the contracts each route needs, set rate limits and verifier configuration, and follow every message on both ends. Our cross-chain integration and CCIP integration work covers those protocols on EVM chains, and oracle integration the feeds.
DTCC's fact sheet names Canton (CIP-56 tokens) and Besu, its private network (ERC-20 tokens), for the launch of its Tokenization Service, so an issuer may need the same asset in both forms.
Should you run your own validator or rent one from a node operator?
Both routes reach MainNet, and we build for either. The Canton Foundation calls a white-label node from an approved Node-as-a-Service operator "the fastest way to participate", while your own validator keeps your parties' contract data on infrastructure you control.
Which institutions are on Canton, and at what stage?
This is a selection from the public record of Canton use on 18 October 2026, taken from company and Canton releases and, where named, press reports. Many of the largest names hold governance roles, as Foundation members or Super Validators, so live use and membership are listed separately.
Which institutions run Canton in production?
Broadridge's Distributed Ledger Repo processed $7.5 trillion of repo in September 2026. Broadridge's product page says DLR is "Built on Canton Technology", without saying whether it settles on the public Global Synchronizer. Circle's USDCx has been live since December 2025, and World Liberty Financial's USD1 launched natively on Canton on 25 August 2026, as Cointelegraph reported. Hashnote, now part of Circle, brought its USYC fund to Canton in October 2024, and Franklin Templeton expanded its Benji platform there in November 2025.
Which institutions have run first trades or limited production?
DTCC ran production trades of DTC-tokenized assets on Canton and Besu on 15 July 2026, with more than 30 firms taking part, and plans to launch its Tokenization Service in October 2026. We found no launch announcement by 18 October. On 1 July 2026 Tradeweb announced that Franklin Templeton had transferred a tokenized US Treasury security to Virtu Financial for USDCx on its platform. On 13 October 2026 Derivnex announced what it calls the first OTC swap on Canton, a total return swap with DRW as counterparty and Marex as swap provider.
Which institutions have only announced Canton plans?
Digital Asset and Kinexys by J.P. Morgan announced plans on 7 January 2026 to issue JPM Coin (JPMD) natively on Canton in phases through 2026, and we found no confirmation of live issuance. Société Générale-FORGE said in May 2026 that it will bring its EURCV and USDCV stablecoins to Canton for non-US persons. Visa said in March 2026 that it would work with institutions to bring Canton into production, and on 29 April 2026 it added Canton to its stablecoin settlement pilot, which now supports nine blockchains.
Which institutions hold governance roles or membership?
The Canton Foundation lists 56 Super Validators, among them DTCC, Nasdaq, Visa, Franklin Templeton and Circle, and Société Générale and LSEG were approved as Super Validators in 2026. Most Super Validators earn reward weight through another operator's node. The Foundation's Premier members include BNP Paribas, BNY, DTCC, Euroclear, Goldman Sachs DAP and HSBC.
Is Canton the right network for this product?
Canton's documentation points to Canton where counterparties should not see each other's positions, as in syndicated loans or trade finance, and for tokenized regulated assets such as securities. It points away from Canton where a product must be fully public, anonymous or EVM-interoperable.
Our guide to institutional blockchains compares Canton with the other networks institutions choose. A bank weighing a deposit token can build it on Canton or an EVM chain through our tokenized deposits work; JPMD's announced Canton issuance sits beside the other bank programs in the tokenized deposits vs stablecoins guide.
An asset manager deciding who should tokenize a fund, and on which network, can compare the platforms in our fund tokenization providers guide. Permissioned tokens on public EVM chains, with ERC-3643 identity checks, are on enterprise blockchain development, and a bank's wider digital-asset program starts from banks and credit institutions.
How does a Canton application reach MainNet?
How do you model a Canton application on LocalNet?
How do you test it with counterparties on DevNet?
How do you get validator approval and reach TestNet?
How do you go live on Canton MainNet?
How do you run the deployment and hand it over?
Which Protofire work does a Canton deployment draw on?
The node work draws on infrastructure we already run: the Glif public RPC endpoint and the Filecoin nodes behind it, which we built and operate. We have also operated validators and other node types on networks including Avalanche, Secret Network and Lava Network.
The EVM end of a Canton route builds on our Chainlink node and External Adapter work, and the Solidity we deploy there is checked with Solhint, the open-source linter we maintain.
“DevNet always takes a new release before TestNet and MainNet, so we run your application on all three networks and take every upgrade on DevNet first.”
For the node layer: Protofire operates the public and dedicated Filecoin nodes that serve the Glif endpoint and the proxy in front of them, and owns their monitoring. A Canton validator gets the same model: an owner for every incident and upgrades taken on schedule.
For the EVM end: under Chainlink Community Grants, Protofire built node deployment repositories for five chains (Gnosis Chain, Avalanche, Harmony, Plasm and Celo) and dozens of External Adapters, and ran integration tests across 9 EVM networks.
FAQ
What is Canton Network development?
What is Daml?
Can Canton run Solidity or EVM contracts?
How do you connect Canton to Ethereum or other EVM chains?
What is CIP-56?
What is Canton Coin?
How do transaction fees work on Canton?
What does it take to run a Canton validator node?
How long does it take to join Canton MainNet?
Do Canton validators earn rewards?
Which institutions use Canton today?
Is Canton a public or a permissioned network, and who governs it?
What does an institution's own team need to run Canton without a partner?
Get a proposal
Tell us what you are building. An engineer reads it, we have a short call, and the written proposal follows within one business day.
Budget
An NDA is available from the first message and can cover anything you share. How it works


