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 economic engine of the Global Synchronizer. Validators, Super Validators, and application providers earn CC by contributing infrastructure and activity to the network. Users spend CC (by burning it) to purchase synchronizer traffic. The resulting burn-mint equilibrium ties the token’s value to actual network utility.

​
Burn-Mint Equilibrium

The Canton Coin application employs a burn-mint equilibrium mechanism, aiming to stabilize the conversion rate of Canton Coin around the intrinsic value it provides to network users:
  • Fee burning — Users pay fees (denominated in USD but paid by burning Canton Coin) when they purchase synchronizer traffic. The burned coins are permanently removed from circulation.
  • Minting rewards — Validators, Super Validators, and application providers mint new CC in return for their contributions to the network (infrastructure operation, application services, usage, and liveness).
  • Dynamic equilibrium — Over the long term, the total CC burned (reflecting actual network utility) roughly balances the CC minted (subject to a predetermined maximum minting curve). When usage is high, more coins are burned, which tends to increase the token’s conversion rate; when usage is lower, supply increases until balance is restored.

​
Traffic Economics

Every message submitted to the Global Synchronizer consumes traffic. The sending validator is charged; recipients are not.

​
Base-Rate Allocation (Free Tier)

Each validator receives a free, regenerating traffic allowance defined by two parameters on the AmuletRules contract:
  • burstAmount — the maximum number of bytes a validator can use within one burst window without incurring fees.
  • burstWindow — the time window over which the burst amount regenerates. After a full window of inactivity, the free balance is fully restored.
Base-rate traffic is always consumed first. Only when it is exhausted does extra (paid) traffic get drawn down.

​
Extra Traffic (Purchased by Burning CC)

A validator increases its traffic credit balance by burning CC at the current USD-to-CC conversion rate (a USD/MB price). When needed, the operator of a validator (or a third-party service provider) burns CC in exchange for traffic credits. The CC burned creates a ValidatorRewardCoupon recording the amount of CC burnt, where the user is the validator operator hosting the purchasing party. No AppRewardCoupon is created for traffic purchases. Automatic top-up automation is available so validators do not run out of traffic unexpectedly. A minTopupAmount parameter ensures each purchase is large enough to amortize the processing cost for Super Validators. Traffic accounting is per-validator — all parties hosted on the same validator share one traffic balance. When a validator hosts external parties, it purchases traffic on their behalf. The Scan API provides traffic pricing parameters that validators can use to estimate costs for transactions submitted by external parties.

​
Cost Factors

The actual traffic drawn from a validator’s balance for a given message depends on:
  • Payload size — the byte size of the sequenced message.
  • Number of recipients — each recipient adds a delivery surcharge controlled by readVsWriteScalingFactor (specified in basis points). For example, at a factor of 4, a 1 MB message with 10 recipients costs 1,000,000 * (1 + 10 * 0.004) = 1,040,000 bytes.
  • Extra traffic price — the extraTrafficPrice in USD per MB, charged in CC at the prevailing conversion rate.
All of these parameters live on the AmuletRules contract and can be queried through the Scan API.

​
Reward Distribution

Network activity is tracked through activity records, each carrying a weight that determines the party’s share of CC minting for a given round. Five key contract templates drive the accounting:
  • SvRewardCoupon — one per Super Validator per round. SV minting rights are granted by the tokenomics committee through the CIP process in exchange for operating SV infrastructure or contributing key resources.
  • ValidatorRewardCoupon — created whenever CC is burned (traffic purchase) or an AmuletRules_Transfer executes. The coupon’s weight reflects the amount of CC the validator burned.
  • ValidatorLivenessActivityRecord — one per live validator per round. Rewards a validator for being available to validate and confirm transactions and provides initial funds for purchasing extra traffic after onboarding.
  • AppRewardCoupon — created when a featured application’s transaction succeeds or when a FeaturedAppActivityMarker is converted by SV automation. Only featured applications receive rewards (per CIP-0078).
  • FeaturedAppActivityMarker — created in the business transaction for economically meaningful events (asset transfers, token mints/burns). SV automation converts these into AppRewardCoupon contracts.

​
Issuance Curve and Minting Schedule

The IssuanceConfig on the AmuletRules contract defines the maximum CC that can be minted. Its key fields are:
  • amuletToIssuePerYear — the annual ceiling on new CC issuance. Per-round issuance is derived by dividing this number by the number of rounds per year (rounds start every 10 minutes by default, so roughly 52,560 rounds per year).
  • validatorRewardPercentage — the fraction of per-round issuance allocated to validator activity rewards (burn-proportional coupons and liveness faucets).
  • appRewardPercentage — the fraction allocated to application rewards.
  • The remainder after validator and app tranches goes to Super Validator rewards, distributed proportionally to each SV’s weight.
Within each tranche, per-coupon issuance is capped (validatorRewardCap, featuredAppRewardCap, unfeaturedAppRewardCap, validatorFaucetCap). If total coupon demand in a tranche is below the cap, the surplus flows to the next tranche — for example, unclaimed validator activity rewards flow to the validator liveness faucet, and unclaimed unfeatured app rewards flow to featured app rewards. Unclaimed rewards beyond all tranches go to SV rewards. A developmentFundPercentage (default 5%) is set aside from each round’s issuance for the development fund under CIP-0082, before the remainder is split across the tranches above.

​
Fee Schedules and Round Snapshots

Fee parameters are stored on the AmuletRules contract, which the DSO governs through on-ledger voting. When a new mining round opens, the current fee values and conversion rate are snapshotted into an OpenMiningRound contract so that all transactions within that round use consistent pricing. As the round progresses through its phases, an IssuingMiningRound contract records the computed amount-to-mint-per-activity-weight for each reward type. CIP-0078 eliminated nearly all fees for CC transfers and locks. The holding fee remains — a fixed fee per separate coin contract (UTXO) per unit of time, independent of coin amount. Holding fees incentivize merging small coins to reduce on-ledger storage. They are charged only on expired coin contracts via Amulet_Expire, not during transfers.

​
CC-USD Conversion Rate

Each Super Validator publishes the CC conversion rate they consider appropriate. The rate used for each mining round is the median of all published SV rates. This median-based approach prevents any single SV from unilaterally shifting the price. The resulting amuletPrice (USD per CC) is recorded on each OpenMiningRound contract and can be queried through the Scan API or Scan UI. All USD-denominated fees (traffic costs, reward caps) are converted to CC at this rate when applied.

​
How Validators Earn

Validators earn CC through two mechanisms that run every round:
  • Liveness rewards — each live validator creates a ValidatorLivenessActivityRecord, earning a share of the validator faucet tranche. The per-validator faucet cap defaults to $2.85 USD equivalent per round. Liveness rewards give new validators initial CC to fund traffic purchases.
  • Activity rewards — when a validator’s users burn CC (traffic purchases or transfers), the resulting ValidatorRewardCoupon entitles the validator to mint CC proportional to the amount burned. Validators that drive more network usage earn more.
For validators hosting external parties (parties that sign with their own keys rather than through the validator), minting can be handled either through a minting delegation to the validator or through custom automation calling AmuletRules_Transfer each round. CIP-0073 describes weighted validator liveness rewards for SV-determined parties.

​
Further Reading