Documentation

Introduction Daml is a smart contract language designed to build composable applications on Canton ledgers. In this module, you will learn about the structure of a Daml ledger and how to write Daml applications that run on the Canton Network by building an asset-holding and trading application. Y

Splice nodes expose REST APIs that are separate from the Ledger API and the Admin API . These APIs are served by the Splice application layer running on top of Canton and provide access to Canton Network-specific functionality: querying network state, managing wallets, operating validators, and gove

Canton Network is a public blockchain that solves a fundamental problem: how do you get the benefits of blockchain (shared truth, automation, auditability) without exposing sensitive data to everyone? The Core Insight Traditional blockchains replicate all data to all nodes. This provides strong

Canton’s privacy model is its defining feature. This section explains how sub-transaction privacy works, what guarantees it provides, and common patterns for privacy-aware development. The Privacy Problem in Blockchain On most blockchains, achieving transaction integrity requires global visibili

Configuration errors are among the most common reasons a validator fails to start. They range from HOCON syntax mistakes to subtle environment variable conflicts. HOCON Parsing Errors Canton uses HOCON (Human-Optimized Config Notation) for its configuration files. Syntax errors prevent the valid

These gRPC status codes come from the Ledger API layer. AUTH_INVALID_TOKEN UNAUTHENTICATED: Could not verify JWT token Cause: The bearer token is missing, malformed, expired, or signed with an unrecognized key. Fix: • Verify the token has not expired (check the exp claim) • Confirm

This tutorial walks you through creating a v2 version of a Daml package. You’ll start with a simple template, add an optional field and a new choice, then verify that the upgrade compiles and that existing contracts work with the new code. Prerequisites • A working dpm installation with the Dam

Introduction To begin with, you’re going to write a very small Daml template, which represents a self-issued, non-transferable token. Because it’s a minimal template, it isn’t actually useful on its own - you’ll make it more useful later - but it’s enough that it can show you the most basic concep

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 Aspect | Ethereum | Canton | Default visibility | Public | Private | Approach | Add pri

Parties and authority Daml is designed for distributed applications involving mutually distrusting parties. In a well-constructed contract model, all parties have strong guarantees that nobody cheats or circumvents the rules laid out by templates and choices. In this section you will learn about

Multi-party workflows are where Canton’s architecture shines compared to Ethereum. This page covers the key patterns and how to think about them differently. The Core Difference On Ethereum, multi-party agreement is a pattern you implement . On Canton, it’s a protocol guarantee . Aspect | Ether

Introduction In the previous section, you saw how to change data on a contract by archiving it and re-creating it with updated data. But what if you wanted to allow another party to make specific changes? Or if you wanted to provide a convenient way to transform contract data? In this section you

Effective Canton development requires the right mental models. This page helps you build intuition that will make everything else click. The Private Database Network Think of Canton not as a blockchain, but as a network of private blockchains or databases that can synchronize. The Model Key

Canton’s defining architectural feature is sub-transaction privacy: the ability to execute a single atomic transaction where each party sees only the parts relevant to them. This page explains how it works and how to use privacy-aware patterns in your applications. Transaction Tree Decomposition

Blockchain technology promises shared truth between parties who don’t fully trust each other. But traditional blockchains achieve this trust through total public visibility—everyone sees everything. For many real-world applications, this is a dealbreaker. The Public Visibility Problem Consider w

Canton’s smart contract consensus layer determines who validates a transaction and how their confirmations produce a binding result . The mechanism is called Proof of Stakeholder : only the participant nodes hosting parties with a stake in the affected contracts participate in validation and confirm

Why reassignments exist A participant node can connect to several synchronizers. Different synchronizers may serve different purposes: regulatory compliance, performance characteristics, cost, governance models, or application-specific restrictions. Contracts created on different synchronizers nee

A Super Validator (SV) runs everything a regular validator runs, plus the Global Synchronizer infrastructure and governance tooling. SVs are operated by major institutions approved through the DSO governance process, and they form the backbone of the Global Synchronizer’s decentralized operation.

A validator is the fundamental infrastructure unit on Canton Network. It hosts parties, stores their contract data, and processes transactions on their behalf. Understanding what’s inside a validator helps with deployment planning, troubleshooting, and capacity sizing. Components of a validator

The Canton Name Service (CNS) maps human-readable names to party identifiers on Canton Network. It serves a similar function to DNS on the internet: instead of sharing a long, opaque party ID like auth0_007c675a429eaf831f0991308d85::12201abe669f..., you can share a name like alice.unverified.cns

Every transaction on Canton follows a four-step lifecycle: submit, order and distribute, validate and confirm, and commit. Understanding this flow explains why Canton can provide both privacy and integrity without requiring every validator to see every transaction. The Four Steps Step 1: Submit

Canton uses a two-layer consensus architecture that separates smart contract transaction consensus from ordering consensus . This separation is what allows Canton to achieve privacy while maintaining integrity. Why Two Layers? Traditional blockchains combine ordering and validation into a single

This page covers problems that arise when your application runs against a live network: DevNet, TestNet, or MainNet. Local development issues are covered in Development Issues . Traffic Exhaustion Every transaction on Canton Network consumes traffic, which is paid for with Canton Coin (CC). When

This page lists error codes you are most likely to encounter during Canton Network application development, grouped by where they originate. Each entry includes the error message, its typical cause, and how to resolve it. Daml Compilation Errors These errors appear when you run dpm build or co

Canton application development involves several tools that handle different parts of the workflow — from writing and compiling Daml contracts to testing locally and querying ledger state. This page summarizes each tool and when you use it. DPM (Daml Package Manager) DPM is the primary command-li

Canton applications deal with a distributed, multi-party ledger. Errors fall into distinct categories, and each category calls for a different recovery strategy. This page covers the error types you will encounter and how to handle them in your backend. Error Categories Command Rejection A com

Upgrading smart contracts in a running production environment is different from upgrading during development. Contracts are shared between parties, often across organizational boundaries, and an upgrade that works on your validator may behave differently when counterparties are running mixed version

The frontend is the user-facing layer of your Canton application. This page uses cn-quickstart as a running example. cn-quickstart is a full-stack reference application that implements a software licensing workflow on Canton Network. The cn-quickstart frontend is a React application built with TypeS

Module 4 bridges the gap between writing Daml contracts and shipping a complete application. You will learn how Canton applications are structured, which SDKs and APIs are available, and how to build both backend and frontend components that interact with the ledger. Prerequisites Before startin

Running a Canton application in production means you need visibility into what your backend and the underlying Canton nodes are doing. This page covers logging, metrics, and dashboards from an application developer’s perspective. Logging Structured Logging with Logback Canton nodes and cn-quic