Module 0 · Lesson 1 · ~25 min read

What Canton Is (and Isn't)

Before we touch any Go, let's answer the real question: what is Canton, what does it do that existing systems don't, and where would you — a Go contributor — actually plug in?

The one-sentence version

Canton is a privacy-preserving distributed ledger where every workflow is a Daml smart contract, and any two parties to a contract can transact through a shared synchronizer without revealing anything to anyone else.

Now the unpacking.

What it actually solves

Take a scenario your old-world employer probably lived with: two banks want to settle a derivatives trade. Both sides run their own systems of record. They reconcile nightly. Breaks happen — field mismatches, out-of-sequence updates, timing windows. Someone (an ops team, usually) stays late fixing them.

The blockchain-shaped answer to this is: "put the trade on a shared ledger, problem solved." Except:

• Bitcoin / Ethereum — everyone sees everything. Two banks cannot post a trade because regulators (and common sense) forbid publishing counterparty positions to a global broadcast channel.
• Permissioned Ethereum-alikes — same problem, smaller audience. Every node still sees every transaction.
• Hyperledger Fabric private channels — closer, but privacy is per-channel, not per-contract. You end up provisioning a channel per counterparty pair, and workflows that span three parties get awkward fast.

Canton's answer: the ledger isn't a global chain. It's a virtual shared ledger, where each party sees only the contracts they're a stakeholder in. Two banks trading a derivative see the trade. Nobody else — not other banks, not the synchronizer operator, nobody — sees its contents. They see only that something happened between someone.

The moving parts

Four nouns carry most of the meaning. Memorize these — everything in Canton's docs and codebase assumes you know them.

Party

A logical identity that owns and interacts with contracts. Alice, Bank A, "the bond issuer." A party is not a node — a party is hosted on one or more participant nodes.

Participant node

A server run by an organization. It hosts one or more parties, holds the subset of the ledger those parties can see, and talks to synchronizers on their behalf. This is the component you interact with via the Ledger API (gRPC). This is where most integration code — including the Go client you'll build in the capstone — connects.

Synchronizer

Canton's name for the thing that coordinates multi-party transactions. Formerly called a "domain" (you'll still see that in older code and docs). Internally it's several services — a sequencer (orders messages), a mediator (arbitrates transaction confirmation), and topology management. A synchronizer never sees contract contents; it only orders and confirms encrypted traffic.

Daml

The language every contract is written in. A pure functional language. Contracts define the data (like a row in a DB) and the choices (the operations that advance the ledger state). We'll cover Daml properly in the next lesson.

Topology — what connects to what

The picture below is the minimum viable Canton deployment: three participants and one synchronizer. Each participant runs its own node, holds its own parties and its own subset of contracts. The synchronizer coordinates messages between them.

What a transaction actually looks like

Say Alice wants to transfer a bond to Bob.

1. Alice's client (running on participant A) submits a command over the Ledger API: "exercise the Transfer choice on bond contract #42, new owner = Bob."
2. Participant A interprets the command against the Daml model, producing a proposed transaction (a tree of commits and archives of contracts).
3. Participant A routes the transaction to the synchronizer, encrypted such that only the informees (Alice, Bob) can see their respective views. The synchronizer itself can't.
4. The synchronizer orders the message globally and forwards views to each informee participant.
5. Each informee confirms it accepts its view. The mediator aggregates confirmations.
6. On unanimous confirmation, the synchronizer emits a "commit" signal and each participant updates its local ledger.
7. Alice sees her Transaction Stream event ("bond #42 archived, new bond issued to Bob"). Bob sees the same. Carol, who wasn't involved, sees nothing. The synchronizer operator sees ordered encrypted blobs.

Canton vs the other systems you might compare it to

Property	Bitcoin / Ethereum L1	Fabric private channels	Canton
Privacy model	Everything public	Per-channel visibility	Per-contract, per-stakeholder
Consensus	Global (PoW / PoS)	Per-channel (orderer)	Per-synchronizer ordering; no global consensus needed
Contract language	Solidity, etc.	Go, Java "chaincode"	Daml — pure functional, privacy-aware
Throughput ceiling	Tens of TPS (L1)	Hundreds–thousands TPS	Scales with synchronizer tier; workflows are parallelizable per disjoint party set
Who runs it	Anyone — permissionless	Permissioned	Permissioned; parties choose their own synchronizer(s)
Regulator access	Inherent (everything is public)	Awkward — add them to every channel	Make them an observer on the contracts they need

Where Go fits in this world

Canton's core — the protocol, the synchronizer services, the participant node runtime — is Scala. Daml is its own compiler. Those aren't where you're aiming. Where Go is genuinely useful:

• CLI tools — Canton has a console (a Scala REPL), but there's a real appetite for ops-friendly CLIs that talk to the Ledger API and to operational endpoints.
• Integration services — most real-world Canton deployments sit in front of, behind, or alongside classical systems. Kafka consumers that submit commands. Postgres exporters that subscribe to the transaction stream. Webhooks, reconciliation, audit exporters. Classic glue code — Go's sweet spot.
• Operators and controllers — Kubernetes operators for deploying and upgrading participant nodes. Go owns this ecosystem.
• Bridges and custom off-ledger services — monitoring, metrics exporters, log shippers, custom indexers.

You already know how to build these categories of software. What you need is Go fluency plus knowing the Ledger API shape. That's the plan for the rest of the course.

Common misunderstandings, up front

Where to read more

• docs.digitalasset.com/build/3.5/ — official documentation. Bookmark this; we'll reference it throughout.
• github.com/digital-asset/canton — source code (Apache 2.0). We'll do a guided tour in Lesson 4.
• The Canton whitepaper (linked from the docs landing page) — worth reading once if you want the cryptographic detail.

Takeaways

Before the next lesson, make sure these four sentences feel obvious:

• A party is an identity; a participant is a node that hosts parties; a synchronizer orders messages between participants without seeing contents.
• Contracts are written in Daml. They have stakeholders, and only stakeholders see a given contract.
• The Ledger API is how external code (including Go) interacts with a participant. It's gRPC. Two fundamental motions: submit commands, stream transactions back.
• Canton is not a classical blockchain. No global chain, no global consensus, no public transactions.

Mark as complete