Skip to main content
If you’re coming from Ethereum, Solana, or another blockchain platform, Canton will feel both familiar and fundamentally different. This section maps concepts you know to their Canton equivalents - and highlights where mental models must shift.

Core Concept Mapping

The following table maps familiar Ethereum concepts to their Canton equivalents.
Ethereum ConceptCanton EquivalentCanton Notes
BlockchainSynchronizerCoordinates consensus without storing state
Smart ContractTemplateDefines data schema and executable choices
Contract InstanceContractImmutable; state changes create new contracts
FunctionChoiceActions that archive and/or create contracts
EOA (Address)PartyCryptographic identity with explicit permissions
TransactionTransactionOnly entitled parties see their relevant views
Global StateDistributed StateNo global state; each node stores its parties’ data
NodeValidator (Participant)Stores data only for its hosted parties
GasTrafficNetwork usage fee paid in Canton Coin

The Mental Model Shift

On Ethereum: You write code that mutates global state. Everyone sees everything. Your contract sits at an address anyone can call. On Canton: You write templates that define what data exists and what actions are possible. Contracts are created and archived (never mutated). Only relevant parties see the data. Authorization is built into the model, not bolted on.

Smart Contract Paradigm: Templates vs Solidity

In Solidity, you define contracts with mutable state and functions that modify that state:
// Solidity: Mutable state
contract Token {
    mapping(address => uint256) public balances;
    
    function transfer(address to, uint256 amount) public {
        balances[msg.sender] -= amount;
        balances[to] += amount;
    }
}
In Daml (Canton’s smart contract language), you define templates with immutable contracts and choices that archive existing contracts and create new ones:
-- Daml: Immutable contracts with choices
template Token
  with
    owner : Party
    issuer : Party
    amount : Decimal
  where
    signatory issuer
    observer owner
    
    choice Transfer : ContractId Token
      with
        newOwner : Party
      controller owner
      do
        create this with owner = newOwner

Key Differences

These are the fundamental differences between Solidity and Daml programming models.
AspectSolidityDaml
State modelMutable storage variablesImmutable contracts; changes create new contracts
AuthorizationRuntime msg.sender checksCompile-time signatory/controller declarations
Default visibilityPublic by defaultPrivate by default; explicit observer declarations
Execution controlAnyone can call public functionsOnly declared controllers can exercise choices
The Transfer choice in Daml doesn’t mutate the existing contract. It archives the current contract and creates a new one with the new owner. This immutability is fundamental to Canton’s privacy and integrity guarantees.

Privacy Model Differences

Ethereum default: Everything public. Privacy requires additional layers (ZK-rollups, private channels). Canton default: Everything private. Visibility requires explicit declaration.

Reading Data: No Global RPC

On Ethereum, any node can answer queries about any state. On Canton, you must connect to the validator that hosts the party whose data you want.
There is no single, all-encompassing blockchain RPC endpoint you can call to retrieve all data. Instead, you use your validator’s Ledger API for your parties’ data, and potentially an application provider’s API for their data.
This is a direct consequence of privacy. If Charlie can’t see Alice’s data on-ledger, Charlie’s node doesn’t have Alice’s data to query.

Authorization Model

Authorization works fundamentally differently in Canton compared to Ethereum.
EthereumCanton
msg.sender determines authorizationsignatory and controller determine authorization
Anyone can call any public functionOnly specified parties can exercise choices
Authorization is runtime checkAuthorization is compile-time guarantee and a run-time double check
Canton’s authorization model uses three key roles:
  • Signatory: The party or parties that must authorize contract creation. Signatories always see the contract and can exercise choices if also declared as controller.
  • Observer: A party permitted to see the contract but cannot exercise choices unless also declared as controller.
  • Controller: The party permitted to execute a particular choice on a contract. Controllers see the contract when exercising.

Authorization Example

template Asset
  with
    owner : Party
    issuer : Party
    auditor : Party
  where
    signatory issuer        -- Must authorize creation; always sees contract
    observer owner, auditor -- Can see but cannot act unless also controller
    
    choice Transfer : ContractId Asset
      with
        newOwner : Party
      controller owner      -- Only owner can exercise this choice
      do
        create this with owner = newOwner
In this template:
  • issuer must sign to create the contract (signatory)
  • owner and auditor can see the contract (observers)
  • Only owner can exercise the Transfer choice (controller)
Note that controller declarations are per-choice. A template can have multiple choices with different controllers:
    choice Transfer : ContractId Asset
      controller owner      -- Only owner can transfer
      do
        create this with owner = newOwner

    choice Audit : AuditReport
      controller auditor    -- Only auditor can audit
      do
        return AuditReport with ...

Developer Tooling Comparison

Canton has equivalent tooling for most Ethereum development workflows.
Ethereum ToolCanton EquivalentNotes
SolidityDamlFunctional vs imperative paradigm
Hardhat / FoundryDaml SDK + dpmBuild, test, deploy toolchain
RemixVS Code + Daml ExtensionIDE with language support
MetaMaskWallet SDKUser wallet integration
Web3.js / ethers.jsLedger API (gRPC/JSON)Application integration
ERC standardsCIPsCIP-0056 (tokens), CIP-0103 (dApp standard)

Multi-Party Workflows

Canton treats multi-party coordination as a first-class concern. Where Ethereum requires manual coordination patterns, Canton builds them into the language.

Ethereum Approach: Manual Multi-Sig

// Solidity: Manual signature collection
contract MultiSig {
    mapping(address => bool) public approved;
    uint256 public approvalCount;
    
    function approve() public {
        require(!approved[msg.sender], "Already approved");
        approved[msg.sender] = true;
        approvalCount++;
    }
    
    function execute() public {
        require(approvalCount >= 2, "Need 2 approvals");
        // ... execute action
    }
}

Canton Approach: Built-in Multi-Party

-- Daml: Native multi-party agreement
template Agreement
  with
    partyA : Party
    partyB : Party
    terms : Text
  where
    signatory partyA, partyB  -- Both must agree to create
    
    choice Execute : ()
      controller partyA, partyB  -- Both must agree to execute
      do
        -- ... execute action
        return ()
The Daml version is enforced at the protocol level. There’s no way to create the contract without both signatures, and no way to exercise Execute without both parties.
Multi-party authorization in Canton requires collecting signatures from parties that may be hosted on different validators. This typically involves workflow patterns where one party proposes an action and others accept it. See the developer modules for detailed patterns on implementing multi-party workflows.

What You’ll Need to Unlearn

Coming from Ethereum, these habits will need to change.
Ethereum HabitCanton Reality
Query all state from any nodeQuery from validators hosting relevant parties
Mutate contract storageState changes create new contracts; old ones are archived
Implicit authorization via msg.senderExplicit declaration of signatories and controllers
Public by defaultPrivate by default; explicitly add observers for visibility
Interchangeable nodesValidators store their hosted parties’ state

The Four Mental Shifts

  1. No global state queries: You can’t query “all tokens” across the network
  2. Immutable contracts: State changes create new contracts; old ones are archived
  3. Explicit authorization: Every action requires explicit signatory/controller declarations
  4. Privacy by default: You must opt-in to visibility, not opt-out

Common Gotchas

These are the most common mistakes blockchain developers make when first building on Canton.
GotchaWhy It HappensHow to Avoid
Building public state lookupsExpecting Ethereum-style global queriesDesign for party-scoped queries from the start
Forgetting multi-party authorizationEthereum’s permissionless modelAlways consider: who must sign? who can act?
Trying to mutate contractsSolidity’s mutable storage modelEmbrace create/archive pattern
Designing too many partiesEthereum addresses are freeEach party creates storage overhead; design party structure deliberately

Next Steps