Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.canton.network/llms.txt

Use this file to discover all available pages before exploring further.

Privacy is the most significant architectural difference between Canton and Ethereum. This page explains the differences in depth and provides guidance for adapting your thinking.

​
The Fundamental Difference

AspectEthereumCanton
Default visibilityPublicPrivate
ApproachAdd privacy on topBuild privacy in
Data locationAll nodes store all dataNodes store only relevant data
Opt-in modelOpt-in to privacy (difficult)Opt-in to visibility (explicit observers)

​
Default Visibility Comparison

​
Ethereum: Public by Default

On Ethereum, when you deploy a contract or send a transaction:
  1. Transaction data is visible in the mempool before execution
  2. State changes are recorded on every node
  3. Historical data is queryable by anyone forever
  4. Contract code is readable by anyone
  5. All interactions are visible to all observers
Even “private” variables in Solidity are not private—they’re just not exposed via the ABI. Anyone can read storage slots directly. 
// Solidity: "private" is misleading
contract NotReallyPrivate {
    uint256 private secretValue;  // Anyone can read this from storage
}

​
Canton: Private by Default

On Canton, data is visible only to entitled parties:
  1. Transaction content is encrypted during submission
  2. Views are delivered only to relevant validators
  3. State is stored only on validators hosting stakeholders
  4. Contract data is visible only to signatories and observers
  5. Third parties see nothing unless explicitly declared
-- Daml: Visibility is explicit
template TrulyPrivate
  with
    owner : Party
    secretValue : Decimal
  where
    signatory owner
    -- No observers: only owner sees this contract

​
Sub-Transaction Privacy

Canton’s key innovation is sub-transaction privacy: different parts of the same transaction are visible to different parties.

​
Example: Atomic Three-Party Transfer

Consider: Alice pays Bob with Canton Coin, and Bob simultaneously pays Charlie. On Ethereum:
  • Everyone sees: Alice paid Bob, Bob paid Charlie
  • Everyone knows: amounts, parties, timing
  • Carol (unrelated) can see all details
On Canton:

​
Why This Matters

Use CaseEthereum ProblemCanton Solution
TradingCompetitors see your tradesOnly counterparty sees trade
LendingLoan terms are publicOnly borrower/lender see terms
Supply chainAll parties see all pricesEach party sees their portion
ComplianceData visible to unauthorized partiesRegulator added as observer only

​
Comparison to Ethereum Privacy Solutions

​
Layer 2 Solutions

Approach: Move transactions off MainNet; settle on-chain.
AspectL2 SolutionsCanton
Operator visibilityL2 operator sees all transactionsSynchronizer sees nothing
Data availabilityMust be available somewhereOnly to entitled parties
SettlementRequires L1 confirmationImmediate finality
Trust modelTrust L2 operatorCryptographic privacy

​
Zero-Knowledge Solutions

Approach: Prove validity without revealing data. Canton does not use zero-knowledge proofs. Instead, privacy is achieved through selective data distribution—parties only receive the transaction views they’re entitled to see. This provides a simpler programming model without ZK circuit complexity or proof generation overhead.

​
Private Channels (Hyperledger Fabric)

Approach: Separate channels for private transactions.
AspectPrivate ChannelsCanton
GranularityChannel-levelSub-transaction level
Cross-channelComplex to implementNative atomic transactions
MembershipMust manage channel membershipDeclared in contracts
FlexibilityRigid channel structureDynamic per-transaction

​
Encryption at Rest

Approach: Encrypt data stored on-chain.
AspectEncryptionCanton
Key managementComplex key distributionNo shared keys needed
MetadataTransaction patterns visibleEncrypted entirely
Future riskMay be decrypted laterNot stored to decrypt
ComputationCan’t compute on encrypted dataFull computation on views

​
Private Ledger View

In Canton, each party has their own private ledger view—the collection of all contracts where they’re a stakeholder.

​
What This Means

Key implications:
On EthereumOn Canton
Query all tokens: getAllTokens()Query your tokens: getMyContracts()
Global state existsNo global state concept
Total supply is knownTotal supply visible only if explicitly designed for visibility
Any node answers any queryOnly your validator answers your queries

​
Querying Data

Ethereum approach: 
// Anyone can query any data
const totalSupply = await token.totalSupply();
const aliceBalance = await token.balanceOf(alice);
const bobBalance = await token.balanceOf(bob);
Canton approach: 
// You can only query your own data
const myContracts = await ledgerApi.getActiveContracts({
  templateId: "Token",
  party: myParty  // Only your party
});

// Can't query Bob's balance unless you're an observer

​
What the Synchronizer Can and Cannot See

The synchronizer (sequencer + mediator) coordinates transactions but never sees content.

​
Synchronizer Can See

  • Encrypted message blobs (must deliver them)
  • Message sizes (network routing)
  • Timestamps (ordering)
  • Confirmation results, such as committed or rejected (finality)
  • Validator identifiers (routing)
  • Party identifiers (for routing, but not end-user identity)

​
Synchronizer Cannot See

  • Transaction content (encrypted)
  • Contract data (never transmitted to synchronizer)
  • Choice being exercised (encrypted)
  • Amounts, prices, terms (encrypted)

​
Trust Implications

Canton’s trust model differs fundamentally from traditional blockchains: What you trust the synchronizer for:
  • Ordering transactions fairly (not reordering to favor certain parties)
  • Delivering messages to all entitled participants
  • Availability (being online when you need to transact)
What you don’t need to trust the synchronizer for:
  • Your data privacy—it only sees encrypted blobs
  • Transaction validation—your validator does this
  • Correct execution—the protocol enforces this cryptographically
What you trust your validator for:
  • Storing your contract data securely
  • Executing transactions correctly on your behalf
  • Not revealing your data to unauthorized parties
Your hosting validator sees all your party’s data. Choose your validator carefully—this is a trust relationship similar to choosing a bank or custodian.
EthereumCanton
Trust all validators not to censorTrust synchronizer not to censor
All validators see everythingSynchronizer sees only encrypted views
MEV is possible (validators see pending txs)MEV is significantly harder (transactions encrypted)
Front-running is structuralFront-running is much harder
Trust any node for queriesTrust only your validator for your data

​
Design Implications for Developers

​
Rethinking State Queries

Ethereum mindset: “How do I query global state?” Canton mindset: “What can my party see, and who else needs visibility?”

​
Observer Pattern

When designing contracts, explicitly consider:
  1. Who are signatories? They must authorize and always see.
  2. Who are observers? They can see but not act.
  3. Who can exercise choices? Controllers for each choice.
  4. What gets divulged? Fetching contracts in transactions reveals them.
template DesignedForPrivacy
  with
    primaryParty : Party
    counterparty : Party
    auditor : Party  -- Only if audit is required
    details : SensitiveData
  where
    signatory primaryParty
    observer counterparty  -- Needs to see, but not auditor

    -- Add auditor only when they need to see
    choice AddAuditObserver : ContractId DesignedForPrivacy
      with newAuditor : Party
      controller primaryParty
      do create this with auditor = newAuditor

​
Privacy Checklist

When designing Canton applications:
QuestionDesign Impact
Who needs to see this contract?Signatory + observer declarations
Who can act on this contract?Controller declarations per choice
What happens when contracts are fetched?Divulgence considerations
Do third parties need visibility?Add observers explicitly
Should validators see everything?Consider party hosting choices

​
Next Steps

Smart Contract Paradigm

Understand Daml’s immutable contract model vs. Solidity.

Privacy Model Deep Dive

Technical details of sub-transaction privacy.