Building on Canton: The Private Blockchain That Actually Runs Production Finance

Everyone I've mentioned Canton to has the same reaction: "Isn't that the JP Morgan blockchain thing?"

Kind of. Canton Network is the production chain layer for Digital Asset's Daml smart contract platform. Deutsche Börse, SIX Digital Exchange, Broadridge, and yes, some of the biggest banks in the world run on it. Real financial settlement, running for years without a major incident.

Most people in the Ethereum/Solana world have never looked at it seriously because "enterprise blockchain" sounds like what banks do when they want to say they're doing blockchain without giving up control. Fair instinct, a lot of the time. Canton is actually different though, and the reason is worth understanding even if you never write a line of Daml.

I built OpenFluid, a regulated financial workflow product, on Canton. This is what I took away from it.

The problem public chains can't solve#

A scenario that breaks every public chain I've touched:

Fund manager A holds bond X. Counterparty B wants to buy half the position. To settle that trade:

1. A has to prove to B they own the bond
2. B has to prove to A they have the funds
3. Settlement has to be atomic, both legs or neither
4. The regulator has to be able to audit it
5. Neither A nor B wants the other one's position size, strategy, or trading history visible to the rest of the market

Step 5 kills Ethereum. Everything is public. The mempool is public. Settled transactions are permanently visible to every node. If you're trading size, you don't want validators or MEV bots reading your position before settlement.

Fine, use ZK rollups for privacy. But then step 4: the regulator needs audit access. ZK systems with selective auditor transparency are still research-stage. Not usable for actual regulated products right now.

Canton solves this with sub-transaction privacy. Each party in a transaction only sees the parts of the ledger they're a party to. The validator network processes the transaction without seeing the full details. The regulator gets explicit read access. Everyone else sees nothing.

You cannot get this on Ethereum without app-level crypto that adds latency and complexity. On Canton it's a property of the consensus protocol itself.

What Daml actually is#

Daml is Canton's smart contract language. Functional, built specifically for modeling rights and obligations in financial systems.

Honest warning: the first week is disorienting if you come from Solidity. The mental model is genuinely different.

In Solidity you think in:

• State variables stored in a contract
• Functions that read/modify state
• Events for state changes
• Mappings everywhere

In Daml you think in:

• Contracts: instances of templates, stored as active facts on the ledger
• Signatories: parties whose authority is required to create the contract
• Observers: parties who can see it but can't act on it
• Choices: actions parties can exercise, which archive the current contract and optionally create new ones

The key shift: Daml contracts aren't addresses holding state. They're facts with controlled visibility.

A simple bond in Daml:

template Bond
  with
    issuer: Party
    owner: Party
    isin: Text
    faceValue: Decimal
    maturityDate: Date
  where
    signatory issuer
    observer owner

    choice Transfer: ContractId Bond
      with newOwner: Party
      controller owner
      do
        create this with owner = newOwner

    choice Settle: ()
      controller issuer
      do
        assert (faceValue > 0.0)
        -- settlement logic
        return ()

Things to notice:

• signatory is the issuer: creating this bond needs the issuer's authority
• observer is the owner: they see it on their ledger, nobody else does
• Transfer archives the old bond and creates a new one. There's no "update state", only "archive old fact, create new fact"
• controller owner on Transfer means only the owner can invoke it

Fundamentally different from Solidity's mutation model. Took me about two weeks to stop fighting it and start thinking in facts and choices.

Where Canton shines and where it hurts#

OpenFluid handles multi-party settlement flows, the kind of thing that currently lives in a tangle of SWIFT messages, spreadsheets, and phone calls between middle-office teams.

What it's great for:

Multi-party transactions where parties shouldn't see each other's full picture. In OpenFluid a settlement involves a seller, a buyer, a custodian per party, and a central counterparty. The buyer shouldn't see the seller's position history. The custodians shouldn't see the trade economics. Canton does this natively. On Ethereum you'd be building a custom privacy layer.

Regulatory read access without touching application logic. Adding a regulator as an observer on a contract type is a one-line change in the template. They see exactly what you declare, nothing more. And it's in the contract logic itself, auditable and immutable, which is cleaner than any ACL system I've worked with.

Atomic multi-ledger settlement. A transaction can span multiple parties' ledgers and either every ledger updates or none do. That's the delivery-vs-payment guarantee settlement requires. Hard in public chains, trivial to declare in Daml.

Where it's painful:

Daml is functional, strictly typed, and unforgiving. The compiler catches most mistakes, which is good for finance. It's also slow to iterate on. A type error in a complex template with nested choices can produce error messages that take 10-15 minutes to diagnose. Coming from TypeScript where you can any your way through a prototype, it's a context switch.

The toolchain is less mature than EVM. No Etherscan for Canton. Debugging a failed transaction means reading Daml ledger logs, which are structured but verbose. No Tenderly equivalent. You test a lot, deploy carefully, diagnose slowly.

Interop with public chains is real but limited. There is an Ethereum bridge, but you're still moving wrapped assets between different trust models. Any workflow touching DeFi on Ethereum needs careful thinking about where state lives and whose finality you're trusting.

The community is small. Hit an obscure Daml issue and Stack Overflow won't save you. Digital Asset's docs are good and their Discord is active, but answer volume is a fraction of Ethereum's. You end up living in primary documentation.

When to choose it#

My honest checklist after building on it:

Use Canton if you have multiple parties who need transactional coordination but shouldn't see each other's data, if you're dealing with regulated assets where audit trails are requirements not features, if atomic settlement across parties' ledgers is a correctness requirement, or if your users are institutional and will tolerate non-consumer UX.

Don't use it if you want permissionless deployment, if your users are retail, if you need DeFi composability, or if you need to iterate fast. Daml's strictness is a feature in production and a pain in a 48-hour hackathon.

Canton is the right tool for a narrower set of problems than Ethereum. For those problems it's dramatically better. Regulated multi-party settlement is that problem. Consumer DeFi is not.

Performance#

One thing nobody talks about: Canton is genuinely fast for what it does.

Public chains measure throughput for single-party transactions (Solana ~50k TPS, Ethereum L2s ~1k-10k). Canton counts multi-party transactions, each of which would be architecturally impossible on a public chain without a privacy layer bolted on.

For OpenFluid's settlement flows I measured ~200ms end-to-end for a two-party settlement with one custodian observer. That includes the ledger write, the atomic commit across three parties' nodes, and confirmation back to the app layer.

Not HFT speed. Faster than SWIFT. For post-trade settlement, entirely fine.

The idea worth stealing#

Even if you never touch Canton, Daml's obligation-based contract model is worth internalizing.

Most smart contracts model what state exists. Daml models what rights and obligations exist and who holds them. A Bond isn't "state where balance = 100". It's "issuer owes owner on maturityDate, owner can transfer".

When the bond transfers, the old obligation is archived and a new one created. The fact that a right existed, was exercised, and was replaced stays on the ledger permanently. Auditors love this. It's a chain of custody at the contractual level, not just the transactional one.

It's a useful lens even if you're writing Solidity: who holds what rights, what choices can each party make, what gets archived when a choice is exercised. Thinking this way catches a class of bugs where state transitions are implicit and authorization logic is scattered across five functions.

OpenFluid is built on Canton Network. Daml docs are excellent and free at docs.daml.com. Developer onboarding is at canton.network.