Canton Network Through a Distributed Systems Lens

Canton Network is becoming increasingly popular in the fintech space, from big, well-established financial institutions attempting to bridge the traditional finance domain with the modern digital world, to already modern crypto and blockchain companies living and breathing the decentralized finance idea (DeFi). As an engineer willing to integrate and build on the Canton Network you have to know:

• how it works, 
• what the underlying architecture is, 
• what decisions have been taken and why, 
• where it shines and what and where the tradeoffs are. 

This is exactly what this article is about, to give you a view at certain aspects of the Canton Network architecture, the ones that are important to understand how all the pieces work together to power this entire concept.

What problem Canton solves

Canton positions itself as a solution to distributed, multi-party workflows orchestration and consensus. This doesn't sound like a big deal itself, but the biggest Canton point here is the "need-to-see" privacy solution for transactions which is baked into the platform from the ground up, not as an afterthought. You’ll see how it works later.

Example of a transaction between two entities on the Canton Network

Bank A wants to exchange some assets with Bank B. Transaction execution must be atomic, relatively quick, and durable. Additionally, it usually has to happen in the presence of a third party regulatory and controlling institution.

Let's think of what options we have here:

One involved party acts as an authority with a central DB

In a business setup, we usually don’t want to trust the other party entirely, especially if it's a competitor, so we'd probably prefer not to have one of the banks to be such an authority and have full control over our transactions and all the details.

Another aspect is sharing necessary information with regulators or other interested parties. We may try having the regulator to be the authority. This shifts the trust towards the regulator (better), but leaves us with a transaction lifecycle we have to track on our side, and with reconciliation processes that we all know are complicated and painful when things go wrong. It's not a coincidence that reconciliation jobs are usually one of the trickiest and the most complex pieces in financial systems.

Public and private blockchains

These could be options to consider, or could they? They give transaction atomicity and durability, as the results are persistently baked into a network block on the chain – no spoofing, no malicious actions once it's done. They don’t require trust in any of the parties – working with a "hostile environment" assumption is a default here. The biggest drawback it brings though is that it's all publicly visible to anyone which is a no go in the competitive world of business where an insight into e.g. trading patterns of a competitor is out of the question.

This biggest flaw above could theoretically be solved with moving the operations to private blockchains. While it is true that this increases transaction privacy, it doesn't solve the fundamental issue with multiple parties being involved. Private blockchains naturally create separate, closed networks with no standard way of integrating with them if a party wants to deal with multiple other parties who are in different private networks.

The solution Canton brings

Canton is set to address most of the flaws of the options above. First, it's deliberately not fully trustless, but works in a way that you trust each party and network component selectively and with limited scope.

Canton doesn't have one global ledger that is replicated across the entire network where every single party has access to. Instead, only participants that are directly involved in a transaction store its contracts and data. Again, this is not an afterthought done by some smart filtering at the network level, it's a concept baked into the architecture from the very beginning.

It connects tightly with the next aspect: sub-transaction privacy that is a big differentiator and the “sub” is where it matters. Instead of bolting on some privacy solutions on top of publicly visible data, it's designed with the concept of transaction views from the ground up. Each transaction involving multiple parties forms a tree split by parties, together with the pieces of data each party is allowed to see. This is all based on two general principles:

1. Parties only see data and actions they have stake in or are explicitly enumerated
2. Parties who see data and their actions also see its consequences

This goes further to the concepts of signatories, controllers, and observers and the roles they play in the contract execution. Seeing the consequences relates strictly to limited trust and verification. If a party can see a payment contract, it’s involved in being exercised, it is also guaranteed to see its result. Hence, it can independently verify its correctness without trusting any third party in that area.

On the network layer, there is yet another level of privacy strengthening, but before we talk about that, let's see what the network consists of to better understand the decisions.

The network has two types of members:

• validator nodes – the ones that store Daml contracts, as well as create, validate and process transactions
• synchronizers – network components that contain sequencers and mediators which are responsible for ordering messages and orchestrating the transaction lifecycle

Validator nodes are fully owned by parties or application providers who operate contracts for other parties – think of it as every bank being a validator or an application provider offering services to other institutions being a validator too. These nodes are under full control of the operators, they manage them, keep them secure, own all the private data and deploy contracts on.

Synchronizer nodes, on the other hand, are independent network-wide components that validators connect to. They have no access to private data stored on validator nodes by design. The split between ordering consensus and data validation consensus is deliberate here.

Because all the transaction-related work happens on the validator node (including encryption and validation), transaction data, that leaves a validator, is fully encoded and is not available for the network synchronizer layer to be read and this is cryptographically ensured. Synchronizers only see envelopes, and their tasks are only to:

• sequence messages (sequencer),
• route them in correct order only to interested participants (based on a transaction view tree),
• coordinate transaction lifecycle (mediator).

All that make this selective trust really compelling in business setups:

• Only transaction sides that have a real stake in it (Bank A and Bank B) see full details as signatories. They have to, because they need to be able to sign contracts, validate transactions etc.
• Regulatory or any other parties can see the details if given observer roles. This is a special role constituted by Daml runtime that allows read only access to transaction data. Observers can see it, but cannot modify data.
• Other parties can only be explicitly given a limited subset of data through audit choices if required. If there is a need for an auditor party who is only interested in a fact that e.g. a transaction between two parties happened but isn’t allowed to see the details (terms, pricing, conditions etc) it can be given its own set of choices disclosing only a limited set of data. 
• No other parties have access to the data due to lack of global replication and the fact that the network layer only sees encoded envelopes with recipients, without actual data.

So far, we've mostly talked about who sees what and the segregated-privacy aspect, which is Canton’s flagship and selling point. But if you've built distributed systems for a while, there is a question in the air: if there's no single database holding everything, who decides the order in which things happened? How do the parties actually agree that a transaction went through? And what happens when one of them goes offline right in the middle?

Who decides the order

Let's start with ordering. When Bank A and Bank B both touch the same contracts attempting to exercise them, the "who went first" call belongs to the sequencer (part of the Synchronizer node).

Contrary to traditional blockchains, there is no single, global order. The sequencer orders messages per synchronizer, and different synchronizers do their own ordering independently, in parallel, with no shared clock between them. And what gets ordered isn't really "transactions on a chain", it's a stream of encrypted messages, each one stamped with an ever-increasing counter and handed out in that order. If that smells like Kafka offset – good, that's more or less the right intuition: monotonic, replayable from a given point, and gap-aware, so if a participant sees counter 41 and then 43 it knows it missed something and re-fetches. So, the mental model to keep isn't one giant global log, it's many smaller logs, one per synchronizer, each maintaining its own order. 

Isn’t the synchronizer a bottleneck then? Well, in practice, most of the traffic today goes through the single Global Synchronizer; it's the default place new contracts land, it holds most of them, and the docs even treat its sequencer as a metered, rate-limited resource you can top up. There are constant efforts to make the most out of it - e.g. see recent performance achievements here. 

But the ceiling is way higher than the one on a traditional blockchain node in terms of capacity: it doesn't execute anything, as it just orders and routes encrypted messages (without looking at their content). All the actual work – running the contract logic, validating it, signing, and encoding – stays on the participant nodes. On top of that, the Global Synchronizer isn't just a single box. It's a BFT (Byzantine Fault Tolerant) set of replicated operators working under strict guarantees. In case you’re not familiar with BFT, read more on it on the ledger academy. 

Moreover, nothing actually forces parties to use the default one. The network topology of Canton allows parties to connect to any synchronizer they need, so some workflows spanning known parties can run on their own “subnet” with their own synchronizer if needed. You may think that this is giving up privacy and full control back to a single party, but as discussed before - synchronizer nodes don’t see the actual data flowing, so the only thing you have to trust in is that they are available to do its job.

Agreeing on what actually happened

Ordering tells everyone the sequence of messages, but it doesn't say which transaction is actually committed. Canton solves this with a good old two-phase commit. Yes, that two-phase commit, the one most of us were told to better stay away from because of its blocking coordinator and messy "in-doubt" state.

Why does it work here, then? The commit has a timeout, so a missing confirmation just aborts cleanly instead of hanging around forever. The mediator, playing the coordinator role, only counts signed confirmations, and the set of participants for a given transaction is small and known upfront (only signatories are counted). So in practice the mediator gathers confirmations from a few parties, commits if they all agree before the timeout, and aborts otherwise. It doesn’t hold any transaction state, and it communicates entirely through a sequencer, so it's the sequencer that records the decision, not the mediator.

And when something breaks, you only lose progress, never correctness. A validator that drops offline simply replays from its last offset once it's back. If the synchronizer goes down, nothing moves until it's back up, but nothing wrong slips through either. A timeout or a rejection aborts the whole thing with no half-finished states.

Why a contract can only be used once

That "no half-finished state" guarantee leans on one more decision: contracts in Canton are immutable. You never update a contract in place. Exercising a choice on it archives the old one and creates a new one. Think of it as an append-only log – if you've done Kafka or event sourcing this should feel familiar: never mutate state, act on the existing one, and produce a new one.

This is also what allows taking care of double spending. If you try to use a contract that's already been archived, the attempt fails. A contract gets consumed exactly once, and the protocol makes sure of it with the help of deterministic ordering. There is no dedicated "double-spend check" anywhere, it’s just baked into the design.

Where is the ledger, really?

There is a “ledger” word showing up often when talking about blockchains, Canton, etc. But there isn't one really – at least not in any single spot. There is no globally replicated chain of blocks that would constitute a ledger. Instead, each validator keeps only the contracts its parties care about, and the synchronizer keeps only the ordering, no data at all. What we casually call "the ledger" (or “virtual global ledger” as the team calls it) is the shared picture of all the parties' states, living in the overlap rather than in some master database somewhere.

All the bits and pieces are familiar: durable append-only logs, selective views on the network, decoupling of ordering and validation, all combined with a lightweight two-phase commit and stretched across multiple parties, with cryptography deciding who gets to see what. None of these ideas is new on its own. What's interesting is what you get when you put them together and treat privacy as a first-class concern from day one. The whole protocol is based on the properties and structure of Daml, which in turn is designed to express the properties of rights and obligations, and this is what we’ll look at next. We’ll see how Daml (the language these contracts are written in) works and why the model it builds on feels surprisingly natural if you've spent some time with functional programming and/or actors.

The Bottom Line: If your organization is planning to connect to the Canton Network or deploy enterprise-grade Daml applications, partnering with an engineering team that helps build the core network infrastructure is the most critical step you can take to de-risk your deployment. Contact VirtusLab today – it might be the best business decision you make this year.