Canton Network Security for Banks and Asset Managers
Quick answer. Canton's protocol gives strong structural guarantees: synchronizers order encrypted messages they cannot read or forge. Most remaining risk sits in three places you control: your validator, your Daml applications, and your node and namespace keys.
Video transcript
Canton's protocol gives institutions strong structural guarantees. But most of the remaining risk sits above the protocol, on your side of the line.
Sequencers and mediators only handle encrypted messages. They could delay messages, but cannot read or forge them. Your own validator is different. It sees all your data and could block you.
Global Synchronizer rule changes need approval from at least two thirds of Super Validator Node Operators. As of September 30, 2026, there were 13, each with one vote.
That leaves three areas to review before going live: the validator hosting your parties, the Daml applications you transact through, and how your node and namespace keys are handled.
Too many observers overshare. Divulgence can leak information. Too few observers can leave a flow depending on off-ledger disclosure.
Daml enforces who must authorize an action, not whether the logic is right. Guardian's public LayerZero reports show trusted caller input, escrow leaks, missed settlement checks and frozen governance.
Create participant keys in a KMS or HSM from the start, since migrating later is not supported. Keep the root namespace key offline, give each key one purpose, and run the topology key monitor.
Guardian's March to April 2026 review of LayerZero's full Canton production surface covered 4,833 lines of DAML and returned 71 findings.
Read the full guide for a NIST CSF mapping and a go-live checklist. Or talk to Guardian about the Digital Asset Assurance Pilot at guardian.security.
Canton Network security is now a question for bank risk committees. On October 28, 2026, DTCC said its Tokenization Service had gone live, integrated with the Canton Network and DTCC's private Besu network.
On November 3, 2026, the SEC's Division of Corporation Finance issued a no-action letter on Canton Coin. That letter is an enforcement position, not a security review.
It states that it “does not express any legal conclusion on the issues presented”. We cover it in The Canton Coin No-Action Letter.
So what does a bank actually trust on Canton? Canton moves most trust off the network and onto parties you choose, which puts most of the security work on your side of the line.
Architecture and Trust Model
Canton separates two jobs that most blockchains combine.
Validators (Canton's participant nodes) host parties, store only the contracts those parties are entitled to see, and validate the transactions they are party to.
Synchronizers order and deliver messages between validators. A synchronizer's sequencer orders encrypted messages, and its mediator declares each transaction committed or rejected.
Canton's own trust model has five trust domains:
| Party | What you trust it for | Limits, or how to rely on it less |
|---|---|---|
| Your validator | Privacy of your contracts, confirmations, internal parties' signing keys | Cannot sign for external parties. Self-host, co-host, or use a KMS or HSM |
| Counterparties | Validating shared transactions, not leaking what you share | Cannot finalize invalid transactions while your validators are honest |
| Synchronizer operators | Ordered delivery, availability, correct verdicts | Cannot read content, forge messages or approve invalid transactions |
| Application provider | Correct Daml and offchain logic, protecting logins | Audited code, external signing, your own validator to submit |
| Network governance | Upgrades that do not break your contracts, fair parameters and traffic costs | Transparent proposals; moving to another synchronizer |
One line from that model matters most: “Your validator sees all your data and could block you”.
Privacy, and Where It Leaks
Canton splits a transaction into views and encrypts each view to its recipients. Parties do not see the payload or even the metadata of parts they are not entitled to.
The Daml contract model decides who is entitled. Signatories and observers see a contract, controllers see the choices they can exercise, and anyone who sees an action sees its consequences.
So privacy depends on how each application is written. It can fail both ways.
- Too many observers. Every observer sees the contract, so list only the parties that need it.
- Divulgence. Other parties to a transaction that uses a contract can learn it.
- Off-ledger disclosure. Non-stakeholders can use contracts disclosed to them off-ledger, so that channel becomes part of your security and availability model.
- Too few observers. A party has to see a contract to act on it, or the flow depends on off-ledger disclosure (Canton OFT, M-02).
Who Runs the Global Synchronizer
The Global Synchronizer is Canton Network's public coordination layer. Canton's docs say block production needs agreement from more than two-thirds of Super Validator (SV) nodes.
Validators read from and write to several SV sequencers at once, so no single SV's sequencer must be trusted.
Digital Asset's October 30, 2026 request letter to the SEC sets out who can change the rules. As of September 30, 2026:
- There were approximately 60 Super Validators and 13 Super Validator Node Operators.
- Any change to the Global Synchronizer protocol needs approval from at least two-thirds of the node operators.
- Each node operator has one vote, however many Super Validators it hosts or Canton Coin it holds.
- Digital Asset is a Super Validator and operates two Super Validator nodes.
- The Canton Foundation's committees “do not have the power to make protocol changes”.
A private, single-operator synchronizer puts all ordering trust in one entity. On a dedicated synchronizer, you also trust the operator to keep metadata private.
Daml Application Risk
Every Daml template declares its signatories and every choice its controller, and Canton's docs say “the protocol enforces these declarations”.
Nobody can put your signature on an obligation you did not authorize. That does not make the business logic right.
Guardian's public reviews of LayerZero's Canton code show where real Daml defects sit.
- Authority the caller supplies. A choice never checked that its
issuerwas the real token issuer, so a sender could name itself (Canton OFT, C-02, Critical). - Contract IDs taken on trust. A payout path accepted a caller-supplied contract ID as a transfer factory (Canton DAML, M-12).
- Checks at initiation only. Blacklist checks ran when transfers were created, not when offers were accepted (Canton OFT, M-09).
- Escrow that leaks. Holdings locked for delivery-versus-payment could be released through the ordinary transfer rule (Canton OFT, H-04, High).
- Governance one member can freeze. Unanimous votes with no cap on proposal expiry let one member stall governance (Canton DAML, M-02).
Daml builds are deterministic, so counterparties can build from source and confirm the DAR on their validators matches.
Your Validator and Keys
Whether you self-host or use node-as-a-service, two features reduce dependence on one operator. You can host a party on several validators, or use external parties, where you hold the signing key.
A participant's owner must also explicitly vet each Daml package, through a VettedPackages topology mapping.
On keys, Canton's security guidance is blunt: “Anyone with access to these keys can submit transactions as your parties”.
- Decide on KMS before the first start. Migrating an existing participant to KMS is not supported.
- Keep the root namespace key offline, possibly air-gapped, and use intermediate keys with delegation restrictions.
- Give each key one purpose, such as namespace, sequencer authentication or protocol.
- Alert on key use. The topology key monitor warns when a tracked key signs a topology transaction.
- Lock down the APIs. Never expose the Admin API to application code.
What to Review Before Go-Live
NIST CSF 2.0 organizes outcomes into six functions and “does not prescribe how outcomes should be achieved”. The Canton evidence has to come from you.
| CSF 2.0 function | Canton evidence to have ready |
|---|---|
| Govern | Owners for validators, package vetting and synchronizer choice |
| Identify | Your parties, their validators, synchronizers, vetted packages and key fingerprints |
| Protect | KMS or HSM keys, offline root key, Admin API isolation, audited Daml |
| Detect | The topology key monitor; alerts on package vetting and party hosting changes |
| Respond | A runbook for a compromised intermediate key |
| Recover | Backups taken alongside key rotation, and a tested restore |
Before go-live, confirm in writing:
- Who operates each validator hosting your parties, and who holds their keys.
- That participant keys were created in a KMS or HSM, and where the root namespace key lives.
- Every vetted package, its reviewer, and whether the DAR was rebuilt from source.
- Which flows in each Daml application depend on off-ledger disclosure.
- That authorization checks bind caller-supplied parties and contract IDs to trusted values, and run again at settlement.
How Guardian Reviews Canton
Guardian has reviewed LayerZero's Canton code across its production surface. The first Canton OFT review returned 58 findings, including two Criticals and five Highs.
The March to April 2026 review covered 4,833 lines of DAML across OApp, governance, multisig, registry and executor, with 71 findings including a High.
The reports are public, and the LayerZero client story has the full relationship.
For banks and asset managers, the Digital Asset Assurance Pilot packages this into five self-contained modules, from an architecture assessment to offchain pentests.
Frequently Asked Questions
Is Canton Network a public or a private blockchain?
Canton's documentation describes it as a public layer 1 blockchain designed for privacy-preserving transactions. Digital Asset's letter to the SEC calls the protocol public and permissionless, with permissioning handled at the application layer.
Can Super Validators or synchronizer operators see my transactions?
Not the content. Canton's docs say the sequencer and mediator work only on encrypted messages and cannot read or forge them, though they could delay messages. Your own validator, by contrast, sees all of your data.
Who controls changes to the Canton Network?
Per Digital Asset's October 30, 2026 letter to the SEC, Global Synchronizer protocol changes need approval from at least two-thirds of the Super Validator Node Operators. There were 13 as of September 30, 2026, each with one vote.
Sources
- SEC Division of Corporation Finance: Canton Coin no-action letter (November 3, 2026)
- SEC: Incoming request letter on behalf of Digital Asset Holdings, LLC re: Canton Coin (October 30, 2026)
- DTCC: DTCC Tokenization Service Goes Live (October 28, 2026)
- Canton Network Docs: What is Canton Network?
- Canton Network Docs: Trust Model Overview
- Canton Network Docs: Privacy Model Explained
- Canton Network Docs: Two-Layer Consensus
- Canton Network Docs: Super Validator Components
- Canton Network Docs: Introduction to Node Operations
- Canton Network Docs: Topology (package vetting)
- Canton Network Docs: Daml Authorization Model
- Canton Network Docs: Explicit Contract Disclosure
- Canton Network Docs: Package Management
- Canton Network Docs: Security Best Practices
- Canton Network Docs: Validator Security
- Canton Network Docs: SV Security
- Canton Network Docs: Key Management
- Canton Network Docs: Topology Key Monitor
- NIST: The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29 (February 26, 2024)
- Guardian: LayerZero Canton OFT report (February 5, 2026)
- Guardian: LayerZero Canton DAML report (April 3, 2026)
- Guardian: LayerZero Canton VER report (May 7, 2026)
- Guardian: LayerZero OneSig on Canton report (September 4, 2026)
- Guardian: LayerZero client story
- Guardian: Digital Asset Assurance Pilot
- Guardian: The Canton Coin No-Action Letter
Review your Canton deployment with Guardian
Guardian has reviewed production Daml on Canton and can assess your validator, keys and applications before assets go live.