Daml Smart Contract Guide: How to Build on Canton Network

Daml is the smart contract language that powers every application on the Canton Network. Created by Digital Asset, Daml takes a fundamentally different approach to smart contracts than Solidity or Rust. Instead of defining state transitions on a global ledger, Daml models rights and obligations between parties — making it the natural language for financial workflows where privacy, compliance, and multi-party coordination matter.

This guide introduces Daml for developers who want to build on Canton, whether you are coming from Ethereum, traditional software engineering, or starting fresh.

Why Daml? The Problem with General-Purpose Smart Contract Languages

Solidity was designed to execute arbitrary computation on a shared global state machine. It is powerful, but it was not designed for the specific requirements of multi-party business workflows:

• ◆Privacy —Solidity contracts expose all state to every node. Daml contracts are visible only to authorized parties.
• ◆Authorization —Solidity relies on msg.sender checks. Daml explicitly models which parties can exercise which choices on a contract.
• ◆Determinism —Solidity execution can vary based on gas limits and miner behavior. Daml execution is fully deterministic.
• ◆Composability —Solidity composability requires shared state. Daml composes across privacy boundaries and synchronization domains.

Daml Core Concepts

Templates

A template in Daml is analogous to a contract definition in Solidity, but richer. A template defines the data fields, the parties involved (signatories, observers, controllers), and the choices (operations) that can be exercised on the contract. Every active contract on Canton is an instance of a template.

Parties and Authorization

Daml contracts explicitly name the parties involved. Signatories must authorize contract creation. Controllers determine who can exercise specific choices. Observers can see the contract but not modify it. This authorization model is enforced by the Canton runtime, not by imperative code checks.

Choices

Choices are the operations that can be performed on a Daml contract. A transfer choice might move ownership from one party to another. An exercise choice might trigger a payment. Choices can be consuming (archiving the original contract) or non-consuming (leaving it active).

Privacy by Construction

In Daml, privacy is not an afterthought. The visibility of a contract is determined by its signatory and observer lists. Only parties named on a contract (or their delegates) can see it. When a choice is exercised, only the relevant sub-transactions are visible to each party. This maps directly to Canton's sub-transaction privacy model.

Daml vs. Solidity: A Detailed Comparison

Setting Up Your Daml Development Environment

Getting started with Daml development requires a few key tools:

• ◆Daml SDK —Install via the official installer. Includes the Daml compiler, sandbox, and CLI tools.
• ◆VS Code + Daml Extension —Provides syntax highlighting, type checking, error reporting, and scenario visualization.
• ◆Canton Quickstart —A project template that bootstraps a full Canton development environment with sample Daml contracts.
• ◆Canton Sandbox —A local Canton node for development and testing. Included in the Daml SDK.

The Canton quickstart template on GitHub is the fastest way to bootstrap a working project. It includes sample contracts, a test harness, and deployment scripts.

A Simple Daml Contract: Token Transfer

Here is the conceptual structure of a simple token contract in Daml. A token has an issuer and an owner. The owner can transfer the token to a new owner, and only the parties involved in the transfer can see the transaction.

The template defines the token with signatory (the issuer, who must authorize creation), observer (the current owner, who can see the contract), and a Transfer choice controlled by the owner that archives the current contract and creates a new one with the updated owner.

What makes this different from an ERC-20 transfer: the issuer and the new owner are the only parties who see the new contract. No other network participant — not even validators — can see the transfer details. Privacy is structural, not added via encryption or zero-knowledge proofs.

Testing Daml Contracts

Daml includes a built-in testing framework based on scripts (formerly scenarios). Scripts simulate multi-party workflows by creating contracts, exercising choices, and asserting outcomes. The Daml sandbox executes these scripts locally, providing instant feedback during development.

Key testing capabilities:

• ◆Multi-party simulation —Test workflows involving multiple parties with different permissions
• ◆Time travel —Advance the ledger clock to test time-dependent logic (maturities, deadlines)
• ◆Authorization testing —Verify that unauthorized parties cannot exercise restricted choices
• ◆Privacy testing —Confirm that contracts are only visible to authorized parties

Deploying to Canton Network

Once your Daml contracts pass local testing, deployment follows three stages:

• ◆Canton Testnet —Deploy to Canton's testnet for integration testing with other applications and domains
• ◆Domain Selection —Choose which synchronization domain(s) your application will operate on
• ◆Mainnet Deployment —Deploy to Canton mainnet through a participant node, using CC for transaction fees

Learning Resources

Official Documentation: The Digital Asset docs provide comprehensive tutorials, API references, and example projects.

Canton Quickstart: The cn-quickstart repository on GitHub provides a ready-to-run development environment.

Background Reading: Start with our What is Canton Network guide for architectural context, and the whitepaper summaries for protocol-level understanding.