Skip to main content
Canton’s architecture enables use cases that are fundamentally impossible on transparent blockchains. This page explores key patterns and concrete examples.

​
Delivery vs. Payment (DvP)

The canonical example of Canton’s capabilities is atomic delivery vs. payment across different assets and parties.

​
The Scenario

Alice wants to buy a tokenized asset from Bob. She’ll pay with Canton Coin, which she obtained from Carol. The settlement should be:
  • Atomic: Either both legs complete, or neither does
  • Private: Carol shouldn’t know about Alice’s purchase; observers shouldn’t see the price

​
On Traditional Blockchains

This is problematic:
  • If done in two transactions: risk of one completing without the other
  • If done atomically: all parties (and observers) see all legs of the trade
  • Carol learns Alice bought something from Bob
  • Anyone watching can see the price and terms

​
On Canton

The entire exchange happens in a single atomic transaction with sub-transaction privacy:
PartySeesDoesn’t See
CarolCC transfer to AliceBob’s involvement, the asset, the price
AliceAll three legsN/A (she’s the central party)
BobCC receipt, asset transferCarol’s involvement, source of funds
Third partyNothingEverything

​
Why This Matters

  • Regulatory compliance: Each party sees only their entitled information
  • Atomic settlement: No settlement risk—both legs or neither
  • Privacy: Trading relationships and prices protected
  • Audit trail: Entitled auditors can be added as observers

​
Tokenized Securities

Issue and trade securities with regulatory compliance built in.

​
Requirements

  • Issuer controls who can hold the security
  • Regulator has audit visibility
  • Trades are private between buyer and seller
  • Corporate actions affect all holders (but holdings remain private)

​
Canton Design

template Security
  with
    issuer : Party
    holder : Party
    regulator : Party
    cusip : Text
    quantity : Decimal
    approvedHolders : [Party]  -- Issuer maintains list of eligible holders
  where
    signatory issuer
    observer holder, regulator  -- Regulator sees all holdings

    choice Transfer : ContractId Security
      with
        newHolder : Party
      controller holder, issuer  -- Issuer approval required for compliance
      do
        assert (newHolder `elem` approvedHolders)
        create this with holder = newHolder
The regulator observes all holdings (for compliance) without that data being public. The issuer must approve all transfers, ensuring only eligible parties can hold the security. Trades remain private between counterparties while still being auditable.

​
Cross-Border Payments

Move value across jurisdictions while respecting data sovereignty requirements.

​
The Challenge

  • Sender’s bank is in Country A with data localization requirements
  • Receiver’s bank is in Country B with different requirements
  • Correspondent banking requires coordination
  • Neither country’s regulator should see the other’s customer data

​
Canton Solution

Each jurisdiction’s data stays with validators in that jurisdiction:
  • Sender’s details stay in Country A
  • Receiver’s details stay in Country B
  • Settlement is atomic across the synchronizer
  • Each regulator sees only their jurisdiction’s data

​
Syndicated Loan Management

Multiple banks participate in a loan without seeing each other’s positions or terms.

​
The Scenario

In syndicated loans:
  • Multiple banks hold portions of the same loan
  • Each bank’s position is confidential
  • The agent bank coordinates payments
  • Borrower interacts with the group as a whole
On transparent systems, all participants would see all positions, defeating confidentiality.

​
Canton Solution

Each bank sees:
  • Their own position and terms
  • Payments flowing to/from them
  • Agent coordination for their portion
Each bank doesn’t see:
  • Other banks’ positions
  • Other banks’ terms
  • Total syndicate size (unless explicitly shared)

​
Supply Chain Finance

Track goods and payments across multiple parties without exposing commercial relationships.

​
The Scenario

A manufacturer ships to a distributor, who ships to a retailer. Financing is provided at each step.

​
Privacy Requirements

  • Manufacturer shouldn’t see retailer’s purchase price
  • Retailer shouldn’t see manufacturing cost
  • Each financier sees only their debtor’s portion
  • Logistics providers see shipping info, not financial terms

​
Canton Approach

Canton’s privacy works at the contract level—observers see entire contracts, not individual fields. To give different parties access to different information, you design separate contracts for each audience: 
-- Shipping details: visible to logistics provider
template ShipmentTracking
  with
    shipper : Party
    receiver : Party
    logisticsProvider : Party
    goods : GoodsDescription
    trackingId : Text
  where
    signatory shipper, receiver
    observer logisticsProvider
    -- Logistics provider sees goods and routing, not financial terms

-- Financing terms: visible to financier
template ShipmentFinancing
  with
    shipper : Party
    receiver : Party
    financier : Party
    terms : FinancingTerms
    shipmentRef : Text  -- Reference to link related contracts
  where
    signatory shipper, receiver
    observer financier
    -- Financier sees payment terms, not goods details or other legs' pricing
A single atomic transaction can create both contracts. The logistics provider and financier each see only their relevant contract, while the shipper and receiver (as signatories on both) see everything. Downstream participants in the supply chain never see upstream pricing, because those contracts have different stakeholders. This pattern—separating data by audience into distinct contracts—is how Canton achieves fine-grained privacy while maintaining atomicity.

​
When Canton Fits

Canton is ideal when you need:
RequirementCanton Provides
Multi-party coordinationNative multi-party contracts with explicit authorization
Confidential executionSub-transaction privacy by design
Regulatory complianceSelective disclosure to authorized parties
Atomic settlementAll-or-nothing execution across parties
Audit trailsObserver roles for entitled auditors

​
When Canton May Not Fit

Consider alternatives if you need:
RequirementConsideration
Fully public applicationsTransparency is a feature, not a limitation (e.g., public governance, open auctions)
EVM compatibilityCanton does not natively interoperate with Ethereum smart contracts
Anonymous participationCanton parties have identity; truly anonymous systems need different approaches
Simple single-party appsBlockchain overhead may not be justified

​
Next Steps

Core Concepts

Understand parties, validators, and synchronizers.

Start Building

Begin your development journey.