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.

Canton Coin (CC) is the native utility token of the Global Synchronizer. It is implemented through the Splice open-source infrastructure, where it is referred to as “Amulet” at the Daml contract level. CC serves three functions: paying for network usage (traffic), rewarding infrastructure operators and application providers, and governing the network through Super Validator participation. For background on CC’s role in the network and how to obtain it, see Canton Coin and the Global Synchronizer. The Canton Coin white paper provides the full formal specification.

​
Fee Structure

CC has three fee types. Following CIP-0078, transfer fees and lock fees were eliminated, leaving traffic fees and holding fees as the two active mechanisms.

​
Traffic Fees

Traffic credits are non-transferable. Once CC is converted to traffic, it can only pay for transaction submissions. If a validator’s traffic budget is exhausted, transactions will fail. Auto-top-up automation is available and recommended.
Traffic credits are consumed even if a confirmation request fails due to contention on consuming contracts — for example, when two transfers attempt to consume the same coin contract.

​
Holding Fees

This section was copied from existing reviewed documentation. Source: docs/src/background/tokenomics/overview_tokenomics.rst Reviewers: Skip this section. Remove markers after final approval.
holding fee remains but its behavior changed so that no holding fees are charged when using a coin as an input to a transfer. The holding fees is a fixed fee, per separate coin contract (UTXO) per unit of time, that is independent of the coin amount. It promotes merging of CC to reduce network storage use by incentivizing merging or removal of dust coins. Holding fees are not charged when transferring coins but only explicitly on expired coin contracts via the Amulet_Expire choice. A coin contract (UTXO) may be expired by the Super Validators once its accrued holding fees are greater than its coin value. This makes accounting for holding fees simple as the value of the coin contract is constant and independent of the holding fee. Because the holding fee is per-UTXO rather than per-CC-amount, small “dust” coins accrue fees faster relative to their value. Once the accrued holding fee exceeds the coin’s value, Super Validators can expire the contract, removing it from the ledger. This makes accounting straightforward: the face value of a coin contract stays constant and does not decrease with accumulated fees.

​
Transfer and Lock Fees (Post CIP-0078)

CIP-0078 eliminated almost all fees for CC transfers and locks. Neither legacy Amulet transfers, CN Token Standard two-step transfers, nor one-step TransferPreapproval transfers charge fees. The only exception is that featured one-step transfers still generate an AppRewardCoupon for the provider party who maintains the TransferPreapproval contract.

​
Burn-Mint Equilibrium

The supply of CC is therefore dynamic rather than fixed. The maximum minting curve constrains how fast new coins can enter circulation, while burn events from traffic purchases remove coins. Minting rewards are distributed across four categories of contributors:
  • Super Validators earn minting rights by operating synchronizer nodes (sequencers, mediators, and governance infrastructure).
  • Application providers earn rewards when they facilitate transactions through featured applications.
  • Validators earn minting rights proportional to the fees they burn, which the network treats as a proxy for the activity generated by that node.
  • Liveness incentives reward validators for uptime and readiness. If a validator does not use all its minting allowance via direct activity, a portion is allocated as a liveness bonus.

​
Minting Rounds

Three Daml templates drive the round lifecycle:
  • AmuletRules stores the fee schedules
  • OpenMiningRound stores the price and fees as of the round’s opening
  • IssuingMiningRound stores the computed CC-issuance-per-activity-weight

​
Minting for External Parties

For local parties, the validator application runs background automation that mints all activity records automatically. External parties sign transactions with keys they control, so the validator automation cannot mint on their behalf directly. External parties have two options:
  • Minting delegation — Delegate reward collection to a validator, avoiding custom automation.
  • Custom automation — Call AmuletRules_Transfer at least once per round with all activity records as inputs.
CIP-0073 (Weighted Validator Liveness Rewards for SV-Determined Parties) describes additional support for this workflow.

​
Activity Records

Activity record attribution can be shared among multiple beneficiaries. Each beneficiary receives a weight (summing to 1.0), and the system creates a separate contract per beneficiary/weight pair during minting. An application’s reward depends on whether it is designated as featured or unfeatured (the default). After CIP-0078, only featured applications receive a reward. A featured application gets a minting weight with a total equivalent value of approximately $1 USD per qualifying activity (the Super Validators may adjust this amount). The FeaturedAppActivityMarker is the preferred mechanism for generating application activity records. Featured one-step transfers via TransferPreapproval also generate an AppRewardCoupon for the provider party. To become a featured application, submit a request through the GSF featured app request form. The tokenomics committee reviews submissions; progress is tracked on the tokenomics committee topics page. On DevNet, you can self-feature your application for testing purposes.

​
UTXO Model and Dust Expiry

CC holdings use a UTXO (unspent transaction output) model. Each coin is represented as an individual Amulet contract on the ledger with a specific face value. Transfers consume input UTXOs and create new output UTXOs, similar to Bitcoin’s transaction model but with privacy — balances are visible only to entitled parties, and there is no public ledger of all holdings. When a transfer produces change (the input exceeds the amount being sent), a new UTXO is created for the remainder. Over time, this can result in a wallet holding many small-value UTXOs.

​
Dust Expiry

The per-UTXO holding fee creates a natural cleanup mechanism for dust. Because the fee is fixed per contract regardless of the coin’s face value, a 0.001 CC coin and a 1000 CC coin accrue the same holding fee per unit of time. Small coins therefore become uneconomical faster. Once the accrued holding fee on a UTXO exceeds its face value, Super Validators can expire the contract by exercising the Amulet_Expire choice. This removes the contract from the ledger entirely. Users are incentivized to merge small coins into larger ones to minimize the number of UTXOs and reduce holding fee exposure. The Splice wallet automation handles this merging automatically when possible.

​
CN Token Standard (CIP-0056)

CIP-0056 defines the Canton Network Token Standard, a set of Daml interfaces for token operations including transfers, locks, and metadata queries. The Splice wallet implements CIP-0056 for CC, and applications that handle CC programmatically interact through these standard interfaces. CIP-0056-based two-step transfers work as follows:
  1. The sender locks the desired CC amount, creating a transfer offer.
  2. The receiver accepts the offer, which unlocks the CC and completes the transfer.
This two-step flow does not rely on sender-side automation and works well for external parties. Since CIP-0078, these operations incur no fees and generate no activity records. For API details, see the CIP-0056 text and the token standard source code.