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.

​

A

​

Active Contract Set (ACS)

The set of contracts currently active (not archived) on a participant node for its hosted parties. The ACS represents the current state from that participant’s perspective. Related: Contract, Archive, Participant Node

​

Admin API

The administrative API exposed by Canton nodes for operational tasks like party management, package uploads, and node configuration. Separate from the Ledger API used by applications. Related: Ledger API, Participant Node

​

Archive

The action of consuming/deleting a contract. Archived contracts can no longer be acted upon. In Daml, exercising a consuming choice archives the contract. Related: Contract, Choice, Active Contract Set

​

C

​

Canton

The blockchain protocol and software implementing privacy-preserving distributed ledger technology. Canton is the underlying technology; Canton Network is the public network running it. Related: Canton Network, Synchronizer, Participant Node

​

Canton Coin (CC)

The native utility token of the Global Synchronizer, used for transaction fees (traffic) and validator rewards. Formerly referred to as “Amulet” in some contexts. Related: Traffic, Global Synchronizer, Splice

​

Canton Console

Interactive command-line interface for administering Canton nodes. Provides Scala-based scripting for operational tasks like party management, package deployment, and debugging. Related: Admin API, Participant Node

​

Canton Network

The public blockchain network running on Canton protocol, coordinated by the Global Synchronizer and operated by Super Validators. Related: Canton, Global Synchronizer, Super Validator

​

Choice

An action that can be exercised on a Daml contract. Choices are controlled by specific parties and can be:

• Consuming: Archives the contract when exercised
• Non-consuming: Leaves the contract active

Related: Contract, Template, Controller

​

Confirming Participant Node (CPN)

A participant node with permission to confirm transactions on behalf of a party it hosts. Part of the transaction confirmation protocol. Related: Participant Node, Transaction

​

Contract

An instance of a template on the ledger. Contracts are immutable—changes create new contracts and archive old ones. Each contract has a unique contract ID. Related: Template, Archive, Contract ID

​

Contract ID

A unique identifier for a contract instance on the ledger. Used to reference specific contracts in choices and transactions. Related: Contract, Contract Key

​

Contract Key

A unique identifier for looking up contracts without knowing their contract ID. Keys must be unique within their template scope and have privacy implications—key structures can reveal information. Related: Contract, Contract ID, Privacy

​

Controller

A party authorized to exercise a specific choice on a contract. Declared in the template definition using the controller keyword. Related: Choice, Signatory, Observer

​

D

​

Daml

The smart contract language used on Canton. A functional programming language designed for multi-party workflows with built-in authorization and privacy. Compiles to Daml-LF. Related: Template, Choice, Daml-LF

​

Daml-LF

Daml Ledger Format—the compiled bytecode format for Daml contracts. The intermediate representation that runs on Canton participant nodes. Related: Daml, DAR

​

DAR (Daml Archive)

A compiled package of Daml code (templates, data types, etc.) ready for deployment to a participant node. Created by daml build. Related: Daml, Daml-LF, Package

​

DevNet

The development/testing environment for Canton Network. Requires VPN access and Super Validator sponsorship. Uses test Canton Coin from faucet. Related: TestNet, MainNet, LocalNet

​

Divulgence

The automatic disclosure of contract information to parties who weren’t original stakeholders but became involved through transaction composition. Happens when contracts are fetched in transactions. Related: Privacy, Observer, Sub-transaction Privacy

​

DSO (Decentralized Synchronizer Operator)

The collective of Super Validators actively operating nodes in a decentralized synchronizer. Makes governance decisions and operates infrastructure. Related: Super Validator, Global Synchronizer

​

DSO Party

A special party construct used to collect signatures for joint actions and maintain synchronization infrastructure for the DSO. Related: DSO, Party

​

E

​

External Party

A party that holds its own signing keys externally to the participant node, requiring explicit signatures for transactions. Analogous to an externally owned account (EOA) in Ethereum. Provides more control but requires external signing flow. Related: Local Party, Party

​

G

​

Global Synchronizer

The public, decentralized synchronizer operated by Super Validators, serving as the backbone of Canton Network. Governed by the Global Synchronizer Foundation. Related: Synchronizer, Super Validator, Global Synchronizer Foundation

​

Global Synchronizer Foundation (GSF)

The independent, non-profit body under Linux Foundation that governs the Global Synchronizer. Sets network policies, coordinates upgrades, and oversees Super Validator participation. Related: Global Synchronizer, Super Validator

​

gRPC

The primary protocol for the Ledger API, using Protocol Buffers for serialization. Higher performance than JSON API. Related: Ledger API, JSON Ledger API

​

H

​

Hosting

The relationship between a participant node and the parties it hosts. A participant stores data for and acts on behalf of its hosted parties. Related: Participant Node, Party

​

I

​

Interface

A Daml construct that defines a set of choices that multiple templates can implement. Enables polymorphic contract handling. Related: Template, Choice

​

J

​

JSON Ledger API

HTTP/JSON variant of the Ledger API. Simpler to use than gRPC but with some performance overhead. Often used for browser-based applications. Related: Ledger API, gRPC

​

JWT (JSON Web Token)

The authentication mechanism used by Canton APIs. Tokens encode party identity and permissions. Related: Ledger API, Admin API

​

L

​

Ledger API

The primary API exposed by participant nodes for submitting commands and reading ledger data. Available in gRPC and JSON formats. Used by applications to interact with the ledger. Related: gRPC, JSON Ledger API, Admin API

​

Local Party

A party whose keys are held by the hosting participant node, allowing the node to sign on the party’s behalf. Simpler than external parties but gives validator full control. Related: External Party, Party, Participant Node

​

LocalNet

A local development environment running Canton components on your machine. No external network required; uses simulated Canton Coin. Related: DevNet, TestNet, MainNet

​

M

​

MainNet

The production environment for Canton Network. Uses real Canton Coin with economic value. Requires full onboarding process. Related: DevNet, TestNet, LocalNet

​

Mediator

A synchronizer component that facilitates the transaction confirmation protocol by collecting confirmations from participants and declaring transaction outcomes (committed or rejected). Related: Synchronizer, Sequencer, Transaction

​

N

​

Namespace

The cryptographic scope defined by a key fingerprint. Parties and other topology entities exist within namespaces. Controls who can modify topology for entities in that namespace. Related: Party, Topology Transaction

​

O

​

Observer

A party that can see a contract but cannot exercise choices on it (unless also declared as controller). Declared explicitly in templates using the observer keyword. Related: Signatory, Controller, Privacy

​

Offset

A position in the ledger’s transaction stream. Used for pagination and resumption when reading from the Ledger API. Related: Ledger API, Transaction

​

P

​

Package

A collection of compiled Daml modules (templates, data types) deployed to participant nodes. Packaged as DAR files. Related: DAR, Template, Vetting

​

Participant Node

A node that hosts parties, stores their contract data, validates transactions, and participates in the Canton protocol. Also called “validator node” in Canton Network context. Related: Validator Node, Party, Hosting

​

Party

An on-ledger identity in Canton, analogous to an address or account. Formatted as name::fingerprint where fingerprint is derived from the party’s public key. Related: Local Party, External Party, Signatory

​

PQS (Participant Query Store)

An optional component providing SQL-based querying of ledger data for performance-intensive applications. Maintains a PostgreSQL database synchronized with ledger state. Related: Ledger API, Active Contract Set

​

Pruning

The process of removing old, no longer needed data from a participant’s storage to manage growth. Pruned data is no longer queryable but the ledger remains valid. Related: Participant Node, Active Contract Set

​

S

​

Sequencer

A synchronizer component that orders messages from participants and distributes them to recipients. Provides total ordering without seeing decrypted message content. Related: Synchronizer, Mediator

​

Signatory

A party that must authorize contract creation and is liable for contract obligations. Signatories always see the contract and any actions on it. Related: Observer, Controller, Template

​

Splice

The open-source project (under Hyperledger Labs) providing infrastructure for operating, funding, and governing decentralized Canton synchronizers. Implements Canton Coin and related applications. Related: Canton Coin, Global Synchronizer, DSO

​

Stakeholder

A party with a stake in a contract—either as signatory or observer. Stakeholders receive transaction views for contracts they have stake in. Related: Signatory, Observer, View

​

Sub-transaction Privacy

Canton’s core privacy feature—decomposing transactions into views where each party sees only their relevant portion. Participants see neither content nor metadata for views they’re not entitled to. Related: View, Privacy, Transaction

​

Super Validator (SV)

An entity operating nodes in the Global Synchronizer’s decentralized infrastructure. Super Validators run sequencer/mediator nodes, participate in governance, and sponsor new validators. Related: Global Synchronizer, DSO, Validator Node

​

Synchronizer

The coordination layer that orders transactions and facilitates consensus between participant nodes. Consists of sequencer(s) and mediator(s). Does not store transaction content. Related: Sequencer, Mediator, Global Synchronizer

​

T

​

Template

A Daml definition specifying contract data, signatories, observers, and choices. Contracts are instances of templates. Analogous to a class in object-oriented programming. Related: Contract, Choice, Daml

​

TestNet

The staging environment for Canton Network, used for final validation before MainNet deployment. Uses test Canton Coin from faucet. Related: DevNet, MainNet, LocalNet

​

Topology Transaction

Transactions that modify network topology—party hosting relationships, key authorizations, synchronizer connections, etc. Managed through the Admin API and Canton Console. Related: Namespace, Party, Admin API

​

Traffic

Canton Network’s term for transaction fees, paid in Canton Coin. Traffic costs depend on transaction size and complexity. Related: Canton Coin, Transaction

​

Transaction

A ledger update consisting of one or more actions (creates, archives, exercises). Transactions are atomic—all actions succeed or all fail. Related: View, Sub-transaction Privacy

​

Transaction ID

A unique identifier for a transaction on the ledger. Used for tracking and auditing. Related: Transaction, Contract ID

​

U

​

Update

A Daml monad representing ledger operations (create, exercise, fetch). The core building block of Daml transaction logic. Related: Daml, Transaction

​

User

An identity in the authentication layer (JWT) that maps to one or more parties. Users authenticate to the Ledger API and act as their associated parties. Related: Party, JWT, Ledger API

​

V

​

Validator Node

A node that hosts parties, stores their contract data, validates transactions, and participates in the Canton protocol. Used interchangeably with “participant node” in Canton Network context. Related: Participant Node, Super Validator

​

Vetting

The process of approving a package for use on a participant. Packages must be vetted before contracts from that package can be created. Provides security control over deployed code. Related: Package, DAR, Participant Node

​

View

A portion of a transaction visible to a specific party or set of parties. Sub-transaction privacy is implemented through views—each participant receives only the views they’re entitled to. Related: Sub-transaction Privacy, Transaction, Stakeholder

​

W

​

Wallet

A user-facing application for managing Canton Coin and interacting with Canton Network. The Splice project provides reference wallet implementations. Related: Canton Coin, Splice, Wallet SDK

​

Wallet SDK

SDK for integrating wallet functionality into applications. Provides APIs for balance queries, transfers, and user management. Related: Wallet, Splice, Ledger API

​

Glossary of concepts

This glossary is alphabetically sorted. Use the TOC to find the entry you are looking for.

​

Active Contract

A created contract that is not yet archived.

​

Application

Application, ledger client, and integration are all terms for an application that sits on top of the ledger. These usually read from the ledger, send commands to the ledger, or both. There’s a lot of information available about application development, starting with the /app-dev/app-arch page.

​

Archived Contract

When a contract is created on a ledger, it becomes active. But that doesn’t mean it will remain active forever: it can be archived. This can happen:

• if the signatories of the contract decide to archive it
• if a consuming choice is exercised on the contract

Once the contract is archived, it is no longer valid, and choices on the contract can no longer be exercised.

​

Assistant

Daml Assistant is a command-line tool for many tasks related to Daml. Using it, you can create Daml projects, compile Daml projects into .dar files, launch other developer tools, and download new SDK versions. See daml-assistant.

​

Authorization

The Daml runtime checks that every submitted transaction is well-authorized, according to the authorization rules of the ledger model, which guarantee the integrity of the underlying ledger. A Daml update is the composition of update actions created with one of the items in the table below. A Daml update is well-authorized when all its contained update actions are well-authorized. Each operation has an associated set of parties that need to authorize it: Updates and required authorization At runtime, the Daml execution engine computes the required authorizing parties from this mapping. It also computes which parties have given authorization to the update in question. A party gives authorization to an update in one of two ways:

• It is the signatory of the contract that contains the update action.
• It is an element of the controllers executing the choice containing the update action.

Only if all required parties have given their authorization to an update action, the update action is well-authorized and therefore executed. A missing authorization leads to the abortion of the update action and the failure of the containing transaction. It is noteworthy, that authorizing parties are always determined only from the local context of a choice in question, that is, its controllers and the contract’s signatories. Authorization is never inherited from earlier execution contexts.

​

Canton Ledger

A Canton ledger is a privacy-enabled Daml ledger implemented using the Canton application, nodes, and protocol.

​

Canton Protocol

The Canton protocol is the technology that synchronizes participant nodes across any Daml-enabled blockchain or database. The Canton protocol not only makes Daml applications portable between different underlying synchronization technologies, but also allows applications to transact with each other across them.

​

Choice

A choice is something that a party can exercise on a contract. You write code in the choice body that specifies what happens when the choice is exercised: for example, it could create a new contract. Choices give one a way to transform the data in a contract: while the contract itself is immutable, you can write a choice that archives the contract and creates a new version of it with updated data. A choice can only be exercised by its controller. Within the choice body, you have the authorization of all of the contract’s signatories. For full documentation on choices, see reference-choices. See also glos-consuming-choice, glos-preconsuming-choice, glos-postconsuming-choice, glos-nonconsuming-choice.

​

Choice Observer

A choice observer is a party on a choice. Choice observers are guaranteed to see the choice being exercised and all its consequences with it.

​

Command

A command is an instruction to add a transaction to the ledger.

​

Command Completion Service

Use the Command Completion Service to find out whether or not commands you have submitted have completed, and what their status was. See command-completion-service.

​

Command Service

Use the Command Service when you want to submit a command and wait for it to be executed. See command-service.

​

Command Submission Service

Use the Command Submission Service to submit commands - either create commands or exercise commands - to the ledger. See command-submission-service.

​

Commit

Stub This is a stub, documentation has yet to be written.

​

Composability

Composability is the ability of a participant to extend an existing system with new Daml applications or new topologies unilaterally without requiring cooperation from anyone except the directly involved participants who wish to be part of the new application functionality.

​

Conformance

Stub This is a stub, documentation has yet to be written.

​

Consensus

The Canton protocol does not use PBFT or any similar consensus algorithm. There is no proof of work or proof of stake involved. Instead, Canton uses a variant of a stakeholder-based two-phase commit protocol. As such, only stakeholders of a transaction are involved in it and need to process it, providing efficiency, privacy, and horizontal scalability. Canton-based ledgers are resilient to malicious participants as long as there is at least a single honest participant. A sync domain integration itself might be using the consensus mechanism of the underlying platform, but participant nodes will not be involved in that process.

​

Consistency

Stub This is a stub, documentation has yet to be written.

​

Consuming Choice

A consuming choice means that, when the choice is exercised, the contract it is on will be archived. The alternative is a nonconsuming choice. Consuming choices can be preconsuming or postconsuming. See also glos-choice.

​

Contract

Contracts are items on a ledger. They are created from blueprints called templates, and include:

• data (parameters)
• roles (signatory, observer)
• choices (and controllers)

Contracts are immutable: once they are created on the ledger, the information in the contract cannot be changed. The only thing that can happen to them is that they can be archived.

​

Contract Key

A contract key allows you to uniquely identify a contract of a particular template, similar to a primary key in a database table. A contract key requires a maintainer: a simple key would be something like a tuple of text and maintainer, like (accountId, bank). See contractkeys.

​

Controller

A controller is a party that is able to exercise a particular choice on a particular contract. Controllers must be at least an observer, otherwise they can’t see the contract to exercise it on. But they don’t have to be a signatory. this enables the propose-accept pattern.

​

Coverage

Stub This is a stub, documentation has yet to be written.

​

Create

A create is an update that creates a contract on the ledger. Contract creation requires authorization from all its signatories, or the create will fail. For how to get authorization, see the propose-accept and multi-party agreement patterns. A party submits a create command. See reference-updates.

​

Create (trans)action

Stub This is a stub, documentation has yet to be written.

​

DALF File

A file .dafl extension that contains daml-lf. Component of a glos-dar-file.

​

Daml

Daml is a platform for building and running sophisticated, multi-party applications. At its core, it contains a smart contract language and tooling that defines the schema, semantics, and execution of transactions between parties. Daml includes Canton, a privacy-enabled distributed ledger that is enhanced when deployed with complementary blockchains.

​

Daml Drivers

Daml drivers enable a ledger to be implemented on top of different synchronization technologies; a database or distributed ledger technology.

​

Daml Files

Daml Files are files of extension .daml that contain programs in the Daml smart contract language. smart-contract-development.

​

Daml Language

The Daml language is a purpose-built language for rapid development of composable multi-party applications. It is a modern, ergonomically designed functional language that carefully avoids many of the pitfalls that hinder multi-party application development in other languages.

​

Daml Ledger

A Daml ledger is a distributed ledger system running Daml smart contracts according to the Daml ledger model and exposes the Daml Ledger APIs. All current implementations of Daml ledgers consist of a Daml driver that utilizes an underlying Synchronization Technology to either implement the Daml ledger directly or to run the Canton protocol.

​

Daml Script

Daml Script provides a way of testing Daml code during development. You can run Daml Script inside Daml Studio. They’re useful for:

• expressing clearly the intended workflow of your contracts
• ensuring that parties can exclusively create contracts, observe contracts, and exercise choices that they are meant to
• acting as regression tests to confirm that everything keeps working correctly

In Daml Studio, Daml Script runs in an emulated ledger. You specify a linear sequence of actions that various parties take, and these are evaluated in order, according to the same consistency, authorization, and privacy rules as they would be on a Daml ledger. Daml Studio shows you the resulting transaction graph, and (if a Daml Script fails) what caused it to fail. See test-using-scripts.

​

Daml Studio

Daml Studio is a plugin for Visual Studio Code, and is the IDE for writing Daml code. See daml-studio.

​

Daml Test

Test by executing daml-script against the glos-ide-ledger.

​

Daml-LF

When you compile Daml source code into a .dar file, the underlying format is Daml-LF. Daml-LF is similar to Daml, but is stripped down to a core set of features. The relationship between the surface Daml syntax and Daml-LF is loosely similar to that between Java and JVM bytecode. As a user, you don’t need to interact with Daml-LF directly. But internally, it’s used for:

• executing Daml code on the Ledger
• sending and receiving values via the Ledger API
• generating code in other languages for interacting with Daml models (often called “codegen”)

Daml-LF, when stored as a DALF file, can be inspected using damlc’s inspect

​

Damlc

See glos-daml-compiler.

​

Damle, Daml runtime, Daml execution engine

Stub This is a stub, documentation has yet to be written.

​

DAR File

A Daml Archive file, known as a .dar file is the result of compiling Daml code using dpm which can be interpreted using a Daml interpreter. You upload .dar files to a ledger in order to be able to create contracts from the templates in that file. A .dar contains multiple .dalf files. A .dalf file is the output of a compiled Daml package or library. Its underlying format is Daml-LF.

​

Dar Upgrading

Stub This is a stub, documentation has yet to be written.

​

Data Dependencies

Stub This is a stub, documentation has yet to be written.

​

Detail Level (damlc)

Stub This is a stub, documentation has yet to be written.

​

Disjunction Choice

See glos-flexible-controllers.

​

DPM

See DPM.

​

Drivers

See glos-daml-drivers.

​

Events

Stub This is a stub, documentation has yet to be written.

​

Exercise

An exercise is an action that exercises a choice on a contract on the ledger. If the choice is consuming, the exercise will archive the contract; if it is nonconsuming, the contract will stay active. Exercising a choice requires authorization from all of the controllers of the choice. A party submits an exercise command. See reference-updates.

​

Exercise (trans)action

Stub This is a stub, documentation has yet to be written.

​

Fetch (trans)action

Stub This is a stub, documentation has yet to be written.

​

Flexible Controllers

A disjunction choice has more than one controller. If a contract uses flexible controllers, this means you don’t specify the controller of the choice at creation time of the contract, but at exercise time.

​

GHC, and GHC as foundation of the Daml Compiler

Stub This is a stub, documentation has yet to be written.

​

IDE Ledger

Stub This is a stub, documentation has yet to be written. A simulated/mocked version of the ledger, intened for unit tests.

​

Incremental Builds

Stub This is a stub, documentation has yet to be written.

​

Inspect

The inspection tool of glos-damlc (called on the command line, using glos-dpm, dpm damlc inspect), allows you to parse and inspect both .dar and .dalf files. See how-to-parse-daml-archive-files.

​

Integration (application)

Application, ledger client, and integration are all terms for an application that sits on top of the ledger. See glos-application.

​

Java Bindings

An idiomatic Java library for writing ledger applications. See component-howtos-application-development-java-client-libraries.

​

Language

See glos-daml-language.

​

Ledger

See glos-canton-ledger or glos-daml-ledger.

​

Ledger API

The Ledger API is an API that’s exposed by any ledger on a participant node. Users access and manipulate the ledger state through the Ledger API. There are two protocols available for the Ledger API: gRPC and JSON. See the Ledger API reference.

​

Ledger Client (application)

Application, ledger client, and integration are all terms for an application that sits on top of the ledger. See glos-application.

​

Library

Stub This is a stub, documentation has yet to be written.

​

Log Level (damlc)

Stub This is a stub, documentation has yet to be written.

​

Maintainer

The maintainer is a party that is part of a contract key. They must always be a signatory on the contract that they maintain the key for. It’s not possible for keys to be globally unique, because there is no party that will necessarily know about every contract. However, by including a party as part of the key, this ensures that the maintainer will know about all of the contracts, and so can guarantee the uniqueness of the keys that they know about. For documentation on contract keys, see contractkeys.

​

Mediator

The mediator is a service provided by the sync domain and used by the Canton protocol. The mediator acts as commit coordinator, collecting individual transaction verdicts issued by validating participants and aggregating them into a single result. The mediator does not learn about the content of the transaction, they only learn about the involved participants.

​

Module

Stub This is a stub, documentation has yet to be written.

​

Multi-package

Stub This is a stub, documentation has yet to be written.

​

Nonconsuming Choice

A nonconsuming choice does NOT archive the contract it is on when exercised. This means the choice can be exercised more than once on the same contract. See also glos-choice.

​

Observer

An observer is a party on a contract. Being an observer allows them to see that instance and all the information about it. They do NOT have to consent to the creation. For documentation on observers, see reference-templates.

​

Package

Stub This is a stub, documentation has yet to be written.

​

Package Database

Stub This is a stub, documentation has yet to be written.

​

Package Service

Use the Package Service to obtain information about Daml packages available on the ledger. See package-service.

​

Participant Node

The participant node is a server that provides users with consistent programmatic access to a ledger through the Ledger API. The participant nodes handle transaction signing and validation, such that users don’t have to deal with cryptographic primitives but can trust the participant node that the data they are observing has been properly verified to be correct.

​

Party

A party represents a person or legal entity. Parties can create contracts and exercise choices. Signatories, observers, controllers, and maintainers all must be parties, represented by the Party data type in Daml and determine who may see contract data. Parties are hosted on participant nodes and a participant node can host more than one party. A party can be hosted on several participant nodes simultaneously.

​

Postconsuming Choice

A choice marked postconsuming will not be archived until the end of the exercise choice body. See also glos-choice.

​

Preconsuming Choice

A choice marked preconsuming will be archived at the start of that exercise. See also glos-choice.

​

Privacy, visibility

Stub This is a stub, documentation has yet to be written.

​

Private Contract Store

Every participant node manages its own private contract store (PCS) which contains only contracts the participant is privy to. There is no global state or global contract store.

​

Protocol

See glos-canton-protocol.

​

Reading From the Ledger

Applications get information about the ledger by reading from it. You can’t query the ledger, but you can subscribe to the update stream to get the events, or the more sophisticated State Service.

​

Sandbox

Sandbox is a lightweight ledger implementation. In its normal mode, you can use it for testing. You can also run the Sandbox connected to a PostgreSQL back end, which gives you persistence and a more production-like experience. See sandbox-manual.

​

Script

See daml-script.

​

Sequencer

The sequencer is a service provided by the sync domain, used by the Canton protocol. The sequencer forwards encrypted addressed messages from participants and ensures that every member receives the messages in the same order. Think about registered and sealed mail delivered according to the postal datestamp.

​

Shake

Stub This is a stub, documentation has yet to be written.

​

Shake Profiling Reports

Stub This is a stub, documentation has yet to be written. See glos-shake.

​

Signatory

A signatory is a party on a contract. The signatories MUST consent to the creation of the contract by authorizing it: if they don’t, contract creation will fail. Once the contract is created, signatories can see the contracts and all exercises of that contract. For documentation on signatories, see reference-templates.

​

Signing

See glos-authorization.

​

Stakeholder

Stakeholder is not a term used within the Daml language, but the concept refers to the signatories and observers collectively. That is, it means all of the parties that are interested in a contract.

​

Standard Library

The Daml standard library is a set of Daml functions, classes and more that make developing with Daml easier. For documentation, see stdlib-reference-base.

​

State Service

Use the State Service to obtain a party-specific view of all contracts currently active on the ledger. See state-service.

​

Studio

See glos-daml-studio.

​

Sub-transaction Privacy

Sub-transaction privacy means that participants in a transaction only learn about the subset of the transaction they are directly involved in, but not about any other part of the transaction. This applies to both the content of the transaction as well as other involved participants.

​

Submitting Commands

Applications make changes to the ledger by submitting commands. You can’t change it directly: an application submits a command of transactions. The command gets evaluated by the runtime, and will only be accepted if it’s valid. For example, a command might get rejected because the transactions aren’t well-authorized; because the contract isn’t active (perhaps someone else archived it); or for other reasons. This is echoed in Daml script, where you can mock an application by having parties submit transactions/updates to the ledger. You can use submit or submitMustFail to express what should succeed and what shouldn’t.

​

Synchronization Domain

The sync domain provides total ordered, guaranteed delivery multi-cast to the participants. This means that participant nodes communicate with each other by sending end-to-end encrypted messages through the sync domain. The sequencer service of the sync domain orders these messages without knowing about the content and ensures that every participant receives the messages in the same order. The other services of the sync domain are the mediator and the sync domain identity manager.

​

Synchronization Domain Identity Manager

The sync domain identity manager is a service provided by the sync domain, used by the Canton protocol. Participants join a new sync domain by registering with the sync domain identity manager. The sync domain identity manager establishes a consistent identity state among all participants. The sync domain identity manager only forwards identity updates. It can not invent them.

​

Synchronization Technology

The synchronization technology is the database or blockchain that Daml uses for synchronization, messaging, and topology. Daml runs on a range of synchronization technologies, from centralized databases to fully distributed deployments, and users can employ the technology that best suits their technical and operational needs.

​

Template

A template is a blueprint for creating a contract. This is the Daml code you write. For full documentation on what can be in a template, see reference-templates.

​

The Daml Compiler

The Daml Compiler damlc compiles glos-daml-source-files into Daml archives, and can run tests wriiten in daml-script. It is recommended to use damlc trough glos-dpm. See howto-daml-compiler.

​

Transaction

Stub This is a stub, documentation has yet to be written.

​

Trust Domain

A trust domain encompasses a part of the system (in particular, a Daml ledger) operated by a single real-world entity. This subsystem may consist of one or more physical nodes. A single physical machine is always assumed to be controlled by exactly one real-world entity.

​

Update Service

Use the Update Service to listen to changes in the ledger, reported as a stream of transactions. See update-service.

​

Virtual Global Ledger

While every participant has their own private contract store (PCS), the Canton protocol guarantees that the contracts which are stored in the PCS are well-authorized and that any change to the store is justified, authorized, and valid. The result is that every participant only possesses a small part of the virtual global ledger. All the local stores together make up that virtual global ledger and they are thus synchronized. The Canton protocol guarantees that the virtual ledger provides integrity, privacy, transparency, and auditability. The ledger is logically global, even though physically, it runs on segregated and isolated sync domains that are not aware of each other.

​

Writing To the Ledger

See glos-submitting-commands.