Nobody Sees Everything.
Canton Network Basics, Rebuilt.

01Why Canton is the odd one out

Every other track on WEB3PWN rests on the same assumption: there is one ledger, and every validator holds all of it. Ethereum re-executes every transaction on thousands of nodes. Bitcoin nodes check every spend. Starknet proves every batch to a verifier that anyone can re-check. Transparency is the security model: you don't have to trust anyone, because you can check everything yourself.

Canton, the protocol Digital Asset built for regulated finance, throws that assumption out. Banks, exchanges and custodians can't broadcast their positions, counterparties and client flows to every competitor on the network, and often aren't legally allowed to. But keeping everything in private databases means reconciling two copies of every trade for days afterwards.

Canton's answer is to partition the ledger instead of replicating it. Each organization's node stores only the contracts its own parties are part of, and nodes only exchange data about transactions they share. The Canton documentation calls the union of those private slices the virtual global ledger: one consistent history that no single machine ever holds.

Nobody holds the whole ledger. Not even the infrastructure that orders it.

// Canton Network Basics, Stage 5

That changes what a security engineer has to ask. On Ethereum, "who can see this?" is always "everyone", and the interesting question is who can change it. On Canton, both answers live in the same place: the DAML template. Stakeholders, controllers and authority are keywords, not conventions, and the ledger enforces them to the letter.

The first version of our Canton Network Basics gave each of these ideas a sentence or two between quiz checkpoints. That was not enough to build real intuition for a system this different, so we rebuilt it. This post walks through the core ideas, with two of the new interactive models embedded right here.

02Six public-chain instincts Canton breaks

Coming from Ethereum, Solana or Bitcoin, a lot of your reasoning transfers: state machines, authorization, "what if this input is hostile?". These six reflexes don't transfer, and each one is the subject of at least one stage.

Scroll horizontally on small screens →

03Contracts, parties and who signed what

Canton doesn't track account balances like Ethereum, or unspent coins like Bitcoin. It tracks contracts: immutable agreements between named parties, created from DAML templates. A template says who has to agree, who may look, and what can happen next. Here is the Iou that the track keeps coming back to:

template Iou
  with
    issuer : Party     -- who owes the money
    owner  : Party     -- who is owed
    amount : Decimal
  where
    signatory issuer   -- must authorize creation; bound by it
    observer owner     -- may see it; bound by nothing
    ensure amount > 0.0

    choice Transfer : ContractId Iou
      with newOwner : Party
      controller owner -- the only party who may exercise this
      do create this with owner = newOwner

The Iou template from Stages 1, 2 and 6

Three rules follow from those few lines, and the rest of the track builds on all three:

• Every signatory must authorize a contract's creation. Not the submitter, not a majority: all of them. So no party can bind another without consent. A contract with two signatories only exists after a propose/accept workflow: one party creates a proposal, the other exercises Accept on it.
• Contracts are never edited. Exercising a consuming choice (the default) archives the contract, and the choice body creates its successors. The old contract ID is dead forever, and anything still holding it will fail.
• Only stakeholders ever receive a contract. Signatories and observers get it; every other node never sees the data at all.

Parties aren't key-derived addresses either. A party ID like Alice::1220f2a9… pairs a readable hint with the fingerprint of the namespace key that owns it, and the network's topology state records which participant nodes host it. In the classic setup, that node submits and confirms transactions on the party's behalf. So "who can act as Alice?" is a question about node access and hosting, not only about keys, and it's a common thing to get wrong.

04Sub-transaction privacy, live

Canton doesn't just hide whole transactions from outsiders. It hides parts of transactions from the parties inside them. A transaction is a tree: exercising a choice triggers further creates and exercises beneath it. For each action, the ledger works out its informees (roughly, the stakeholders of the contract involved, plus whoever is exercising the choice). Each party receives its own projection: the actions it's an informee of, together with everything those actions caused.

Here is a delivery-versus-payment (DvP) trade: Alice pays Bob $100 of Bank-issued cash for 10 ACME shares recorded by Registry, in a single transaction. Pick a party to see what its node actually receives.

Flip to Public chain and every party, Carol included, sees all five actions. That's the trade-off in one click. Public chains get their trustless guarantee because every node re-executes everything. Canton gives that up on purpose: each transaction is validated by the nodes of the parties it affects, which are also the only ones with anything at stake in it. Digital Asset calls this proof of stakeholder.

Private doesn't mean unverified. Every informee's node re-runs its own view through the DAML engine and checks conformance (the actions are what the templates allow), authorization (every required signatory and controller agreed) and consistency (every input contract is still active). The views are bound together in a Merkle tree, so Bank's view and Registry's view provably belong to the same transaction even though neither can read the other.

05Ordering what you can't read

If nobody sees everything, who stops the same Iou from being spent twice? On a public chain, ordering comes free with global consensus. On Canton it's the job of a synchronizer (called a "domain" in older versions), which has two main services. The sequencer gives every message a timestamp and a place in one total order, then forwards it only to its addressees. The mediator collects each involved node's approve or reject and announces a single verdict. Neither one ever sees a contract.

Now the double spend. Alice submits two transfers of the same Iou #7 at almost the same moment, one to Bob and one to Carol. The sequencer can't read either request, so it has no idea they conflict. It just stamps them in arrival order. That turns out to be enough: every involved node sees the same order, the first request consumes #7, and the second fails its activeness check on every node independently. Stage 5 lets you run this race yourself, then step through all seven protocol steps while watching what the sequencer, the mediator and an uninvolved node each know at every point.

• The synchronizer can order, timestamp and deliver messages, and see metadata: who sent what to whom, when, and how large.
• It can't read contract contents, or forge or alter a transaction: views are signed by the submitting node and re-validated by every recipient.
• You still trust it for liveness and fair ordering. It can delay, drop or censor. That's why the Global Synchronizer on the public Canton Network is run by a group of independent super validators with Byzantine fault tolerant ordering, not by a single company.

06Where authority leaks

On the EVM, every function is callable by anyone, and access control is a require buried in the body. Forget it and anyone can call. DAML turns that around. Each choice declares its controllers, the ledger checks that they authorized the exercise before the body runs, and every involved node re-checks it during validation. There is no msg.sender check to forget.

That doesn't make DAML authorization easy. Inside a choice body, the transaction carries the combined authority of the contract's signatories and the choice's controllers. A choice is a delegation: the signatories pre-authorize whatever the body does, for whoever the controller turns out to be. Watch what happens when the caller gets to pick the controller:

template Vault
  with
    custodian : Party
    owner     : Party
    auditor   : Party
    amount    : Decimal
  where
    signatory custodian
    observer owner, auditor

    choice Withdraw : ContractId Payout
      with requester : Party
      controller requester     -- whoever submits names themselves
      do
        create Payout with
          custodian = custodian
          recipient = requester  -- ...and gets paid
          amount    = amount

template Vault
  with
    custodian : Party
    owner     : Party
    auditor   : Party
    amount    : Decimal
  where
    signatory custodian
    observer owner, auditor

    choice Withdraw : ContractId Payout
      controller owner         -- fixed when the vault was created
      do
        create Payout with
          custodian = custodian
          recipient = owner
          amount    = amount

Illustrative excerpt: the Payout template is omitted

In the vulnerable version, the auditor, who was only ever meant to read the vault, exercises Withdraw with requester = auditor. The ledger checks that the controller authorized the exercise, which it did by submitting. The body creates a Payout with the custodian's authority, and every node agrees the transaction is valid. Nothing was bypassed. The template said "anyone who can see this can withdraw it to themselves", and Canton enforced exactly that. On Canton, every observer is a potential controller.

The same family, all of which you'll meet in the labs:

• Signatory-only archive: every template gets an implicit Archive choice controlled by its signatories. If the issuer is the only signatory of an Iou, the issuer can erase its own debt without asking the owner.
• Wrong consumption: a nonconsuming choice that should consume can be exercised again and again; a consuming one that shouldn't breaks everyone still holding the old contract ID.
• Unchecked arguments: a Split without ensure amount > 0.0 on its template will happily create a negative Iou from a too-large split amount.

Stage 6 puts a live Iou ledger in front of you: exercise Transfer, Split and Archive as any party, then try to reuse a contract you just consumed. The Authorization and State Integrity modules turn it into exploits.

07All or nothing, across institutions

In 1974, German regulators closed Bankhaus Herstatt at the end of the German business day, after its counterparties had paid it Deutsche Marks but before it paid out the dollars it owed them in New York. The danger of a half-settled trade is still called Herstatt risk, and removing it is a big part of why modern settlement systems exist.

Canton composes the cash leg and the asset leg into one atomic transaction, even though Bank can't see the share leg and Registry can't see the cash leg. Each involved node validates only its own view, and the mediator only commits once every required approval is in. One rejection anywhere rejects the whole thing, for everyone. Break a leg below and compare the two ways of settling:

Untick the share leg. As one Canton transaction, nothing happens and both sides keep what they had. As two separate transfers, Alice pays $100 and receives nothing.

Atomicity doesn't stop at one deployment, either. A single transaction is always ordered by one synchronizer, but contracts can be reassigned: unassigned from one synchronizer and assigned to another, as long as their stakeholders' nodes are connected to both. Move the shares next to the cash, then settle atomically there. That's what makes Canton a network of networks rather than a collection of isolated private ledgers, and it's why cross-contract authority and state consistency keep coming back in the advanced modules.

08What's inside the rebuilt module

Every stage now gives you several sections of reading before each quiz checkpoint, and a model you can poke at. The quiz questions stay short. The reading around them is where the intuition comes from.

1. What Is Canton?A network of ledgers, not one public blockchain.toggle public chain vs Canton, watch who receives a trade
2. Contracts & PartiesAgreements between named parties, not balances or unspent outputs.pick a template, choose who authorizes, see if it can exist
3. Privacy by DesignNobody sees a transaction they weren't part of.view one DvP trade as five different parties
4. Participant NodesWhere an organization's own slice of the ledger actually lives.compare what each node stores with an Ethereum full node
5. SynchronizersAgreeing on sequence without reading the contents.race two spends of one Iou, then step through the protocol
6. Choices & ControllersWho's allowed to act on a contract is declared upfront, not checked at call time.transfer, split and archive on a live ledger, as anyone
7. Composability & AtomicityMulti-party workflows that succeed or fail together.break a DvP, atomic vs two separate transfers
8. Where This FitsPrivacy, authorization and interoperability: together, on purpose.tick your requirements, see which architecture survives

The rest of the track: ten modules, three tiers

Network Basics is the entry point to the full Canton & DAML skill tree. Clear a tier and the next one builds directly on it:

09Start here

Three ways in, depending on how much you want to commit right now:

Found a projection edge case, or think our Vault is too easy? Come argue with us on Discord. See you on the ledger, or at least on your slice of it.