Digital Asset started out with blockchain infrastructure. They faced a key problem in financial systems. Globally replicated ledgers don't work well for transactions where participants should not see all the data.
When two banks trade, one transfers shares while the other transfers cash. Separate registries can track each asset, and both transfers must still happen together. At the same time, the share registry doesn't need to know the price, the cash registry doesn't need to know what the payment was for, and unrelated institutions have no reason to see either side of the trade.
Public blockchains like Ethereum don't work that way. Transaction data and the system state are shared widely so independent nodes can verify them. Privacy must then be added separately to a system that defaults to broad visibility.
Canton limits visibility from the start. Who sees transaction details depends on the transaction. Each participant only sees the parts of the transaction they're allowed to see.
The three promises
If Alice owns a ticket, she can sell it to Bob, but then try to sell the same ticket to Charlie. Both sales can be correctly signed, and Alice really did own the ticket when she started. The problem is that both transactions try to spend the same piece of state.
A ledger has to provide several guarantees to handle a case like this. Two parties should not end up with conflicting versions of the same state. Accepted history should not be quietly rewritten. Someone should also be able to verify that the rules governing the asset were followed.
Public blockchains typically provide these guarantees using widely replicated state, consensus, and cryptographic verification. Canton handles these differently: shared state stays consistent without being visible to everyone, historical integrity can be checked without every participant keeping the same history, and verifying specific facts depends on who can access the relevant data.
One transaction cut into pieces
A ticket sale might involve Alice, Bob, the ticket service that tracks who owns tickets, and Bob's bank. The ticket service needs to see that ticket 123 moved from Alice to Bob, but it doesn't need to know the price. Bob's bank needs to see that $200 moved from Bob to Alice, but it doesn't need to know what Bob bought. Alice and Bob might both be allowed to see both parts.
Canton can show these parts as different views of one transaction. Each party is hosted by one or more participant nodes, and one participant node can host several parties. A participant node only stores what its parties are allowed to see, not a full copy of all application state.
No single participant node needs to store a full copy of the ledger. The separate views can still be part of one atomic transaction, so both transfers commit together or fail together.
Consistent state
To prevent Alice from selling the same ticket twice, the system must check if the state she wants to use is still active. On a public blockchain, this information is in the state, which many nodes can check independently.
If Alice first transfers the ticket to Bob, that transaction uses up the state showing Alice as the owner. A subsequent transaction trying to transfer the same ticket to Charlie will fail because that state is no longer valid. Consequently, only one transaction succeeds while the other fails. The system does not need to compare sale documents afterward, since both transactions refer to the same spendable state, which can only be used once.
Canton uses the same basic idea but keeps the contract private. The ticket is shown as a contract with a unique ID. When Alice owns it, the contract is active. When she transfers it, the old contract is archived and a new one is created for Bob.
If Alice tries to sell the ticket to both Bob and Charlie at the same time, both transactions refer to the same active contract. The nodes handling these transactions check whether that contract can still be used and whether the transaction is allowed. They share enough information to detect the conflict. Bob doesn't need to see Alice trying to sell to Charlie, and Charlie doesn't need to see her trying to sell to Bob.
The synchronizer manages this process without sharing the full transaction with everyone. The sequencer provides all relevant participants with the same order for protocol messages. These participants check the parts of the transaction they're allowed to see, and a mediator gathers their responses to decide if the transaction can proceed. Canton also tracks ongoing transactions so two transactions trying to use the same contract cannot both succeed.
This model has clear trust requirements. A party might use one participant node or multiple nodes, meaning an application doesn't always need to trust a single machine. Public blockchains rely on a wider trust model where a larger group of validators can check the same public state independently.
Integrity
Public blockchains link blocks using cryptography. Changing an old transaction changes that block and all subsequent hashes. An attacker can recalculate hashes, so hashing alone does not decide which history the network accepts. Which history becomes canonical is determined by two mechanisms: consensus and finality. Consensus is the process by which network participants agree on which chain of blocks is the valid one. Finality is the point after which that agreement can no longer be reversed.
Replacing an accepted history requires more than creating a consistent chain. The network must also accept that replacement instead of the history it already agreed on.
Canton does not send one full transaction history to every participant. Instead, the events a participant receives are linked so missing events can be detected. A participant can therefore prove, for example to an auditor, that its history has not been selectively trimmed.
Canton checks whether participants agree on the current shared state. Participants who share contracts regularly compare signed summaries of that shared state. Canton calls these summaries ACS commitments. If the summaries match, participants have proof they agree on the contracts they both know about.
This proof only covers what they've shared. A participant can check contracts it received and the state it shares with others, but it doesn't automatically know about contracts it never saw. Public blockchains usually let anyone check more of the transaction history.
Under normal operation, Canton transactions are final. Canton doesn't use blockchain-style reorganizations, where an accepted chain of blocks gets replaced by a competing chain.
Participants don't need to keep their full event history forever. Older history can be pruned after a participant saves the state needed to keep running. Pruning removes data from the participant node but doesn't delete copies kept by other participants, backups, or exported records.
Issuer trust
A distinct challenge arises when a ledger asset represents a promise from an issuer. A ticket service promises seat access, a deposit token might mean a claim on a bank, and a stablecoin might mean a claim on reserves. In every case, the issuer could create more claims than the real asset supports.
A venue with 500 seats could issue 10,000 tickets. A bank could create more claims than its backing assets or obligations cover. Preventing the same contract from being spent twice does not by itself prevent the issuer from creating several different contracts that make overlapping claims on the same asset.
A public blockchain makes on-chain token issuance easy to check because all issuance happens through public contracts. Anyone can then count the tokens shown by this public state. This doesn't say anything about real-world backing. The blockchain cannot inspect the venue, count money in a bank account, or find liabilities outside the chain, but it can show the supply on-chain.
Canton doesn't expose the unified view of the application state. Instead, participants only see the issuance data they're explicitly authorized to view. The total supply is visible only when one participant, such as a regulator, registry, or other authorized party, has enough information to put it together.
TicketCo creates one contract saying seat 14A is for Alice. Alice then transfers this ticket to Bob. TicketCo later creates a second contract saying seat 14A is for Diana. This second contract has a different ID. Since Alice and Bob are not parties to it, their systems do not receive it. Diana can later transfer her ticket to Edward.
Edward's system sees a valid active contract with the required authorizations. Bob also has a valid active contract. Both contracts claim to represent seat 14A.
Canton's spend checks operate on contract state. A conflict happens if two transactions try to use the same contract. Here, TicketCo created two separate contracts, so the system treats them as two distinct pieces of state. The ledger stays consistent even though the application created two claims on the same physical seat.
The latest Canton version lets multiple active contracts share the same contract key. A contract key is an application-defined identifier, combining a maintainer Party with business data such as a seat number, that can be used to look up a contract without knowing its contract ID. If an application needs seat 14A to exist only once, it must enforce that rule itself.
The venue can strengthen the model by creating exactly 500 authoritative seat contracts. Every valid ticket must come from one of these contracts. If issuing or transferring a ticket requires using the specific authoritative contract for that seat, Canton prevents two transactions from using the same seat state twice.
This guarantee applies to the state managed by the application. Canton ensures one authoritative contract for seat 14A cannot be used twice. However, the venue must ensure the authoritative state is correct. The system cannot verify that the venue created exactly one contract per real seat, that no fake seats were added, or that contracts match the physical venue.
A Canton application can give a registry, supervisor, or regulator visibility across the issuance process, or require that party to take part in issuance. Someone other than TicketCo can then see enough information to count outstanding claims and enforce additional rules.
This visibility happens because the application was designed to provide it. Canton keeps application data private unless the workflow shares it with other parties. Public verification therefore depends on how the application is designed and governed, not on the network itself.
Final word
Canton solves a different problem than a typical public blockchain.
When multiple institutions need to agree on shared information without showing their transactions to others, Canton's privacy model helps. Relevant parties can keep contract information consistent and enforce authorization and atomicity without sharing transactions with unrelated parties.
When outsiders need to audit the institution that issued an asset, Canton provides that visibility only if the application allows it. A regulator, registry, auditor, or supervisor can get enough issuance details to perform that audit, but holding one token does not automatically reveal the issuer's full details.
Reviewed by Michał Ostruszka and Łukasz Lenart.