Understanding Canton #1: Canton Coin, economics, burn-mint equilibrium
June 04, 2026
This article is the first in our series aimed at making Canton easier to understand by unpacking its core building blocks one at a time. We start with Canton Coin and explain why it exists, how it is minted and burned, how rewards flow, and how the network’s tokenomics connect supply dynamics to real usage.
Canton’s native token: Canton Coin
Canton Coin (CC) is the native utility token of the Global Synchronizer. It was introduced without an initial coin offering, pre-mined supply, or preferential allocations to founders, employees, or venture investors. Its issuance began only after the Global Synchronizer became operational. With Canton MainNet live since mid-2024, Canton Coin is minted as a function of ongoing network participation rather than as a one-time distribution event.
The guiding philosophy is to reward network utility rather than early capital allocation. Canton Coin is earned through active participation in the live network: operating Super Validator infrastructure, running validator nodes that process user activity, or building applications that generate measurable network usage. More recent governance changes have added long-term alignment mechanisms, such as Super Validator reward locking under CIP-0105, that sit on top of the original fair-launch design.
Burn-mint equilibrium
Canton Coin’s tokenomics are built around the burn-mint equilibrium model, which aims to keep token supply aligned with real network usage.
On the burn side, transactions submitted through the Global Synchronizer consume network traffic. Paid traffic is denominated in USD per megabyte and funded by burning the corresponding amount of $CC at the current on-chain USD/CC conversion rate. Individual transactions then draw down the submitting validator’s traffic balance over time. In other words, every transaction triggers $CC burn, but the burn happens when paid traffic is purchased or topped up by applications or validators, not necessarily at the exact moment each transaction is submitted. Since in most cases the cost of consumed traffic is passed on to users in the form of transaction fees, there is still a direct correlation between user activity and traffic purchases/$CC burn.
Traffic is the main burn driver for ordinary application activity. Some other burn elements still exist, such as the holding fees, but this makes up a negligible portion of the overall $CC burned. This means the current high-level economic model is best understood through traffic rather than through a generic per-transaction fee burn model, even though user activity and $CC burn are tightly correlated:
User activity and transaction submission consumes the traffic balance of validators,
The traffic purchases for validators trigger burn $CC,
The cost of consumed traffic can be passed on to users in the form of transaction fees through the applications.
On the mint side, infrastructure providers, validators, and application providers are allowed to mint new Canton Coin as a reward for providing utility to the network as per their functions, with minting rights allocated according to measurable activity.
In the long run, Canton’s tokenomics target a state in which approx. 2.5B Canton Coin is minted per year, with net supply expansion or contraction determined by how much $CC is burned through real network activity. If usage rises and burns exceed minting, supply contracts. If usage falls and burns are lower than minting, supply expands. This feedback loop anchors $CC issuance to the real operational value of Canton Network, ensuring that token supply evolves with actual economic activity.
Burning $CC via traffic consumption
For ordinary application activity on the Global Synchronizer, the main protocol-level burn mechanism is traffic consumption.
Every transaction submitted to the Global Synchronizer consumes data traffic. As mentioned above, in order to process a transaction and submit it to the network, a validator node needs traffic credits, measured in megabytes and priced in USD. At the time of writing, the extra traffic price is commonly referenced as $60 per MB, although the live value is governance-configurable and should always be checked against current network data. Paid traffic credits are purchased by burning $CC at the current on-chain USD/CC conversion rate. The burned $CC is permanently removed from circulation.
A key detail is that the $CC is burned when traffic is purchased or topped up, not each time a transaction is processed and the already-purchased traffic balance is drawn down. Anyone can burn $CC to top up a validator’s traffic balance, the validator operator, an application provider, or a third-party service, but the traffic credits accrue to the target validator node.
After CIP-0104 (currently being implemented), only the submitting validator is charged for transaction submission. For confirming validators, i.e. those who validate a transaction but did not submit it, making confirmations is effectively free. This means validators bear traffic costs for transactions the users of their hosted applications actually submit, which can be subsidized, or alternatively passed entirely to users in the form of transaction fees.
Who pays for traffic?
It is not like Ethereum gas, where the end user directly pays a protocol fee at transaction submission. On Canton, the protocol charges the submitting validator’s traffic balance. How that cost is ultimately borne is a business decision between the parties involved: the application provider can absorb it, the application can pass it through to end users as part of its pricing, or a third party can sponsor the traffic on behalf of the validator.
The cleaner way to think about the current model is this: a transaction consumes traffic, and paid traffic was funded by burning $CC. An application may separately decide to charge users in $CC, fiat, stablecoins, or another asset to recover that cost, using it to purchase traffic for the hosting validator.
Any application on Canton faces this design choice. A tokenized securities platform could bake fees into its settlement workflow. A trading venue could charge users per trade. A stablecoin provider could absorb traffic as infrastructure overhead. The underlying economics are the same in every case: the transaction consumes traffic, traffic is funded through $CC burn when paid traffic is purchased, and the application decides how to allocate that cost commercially.
This creates a closed economic loop: network activity consumes traffic, paid traffic is purchased by burning $CC, and minting rights are allocated in proportion to measurable utility, ensuring that Canton Coin issuance is driven by real network activity.
Minting $CC as part of the reward mechanics
Canton Coin minting is distributed across three categories of network participants, each receiving a share of each round’s minting budget as determined by the minting curve. Minting happens in discrete rounds occurring approximately every ten minutes.
In the current phase of the original minting curve, 1.5–5 years after launch, the gross split is: application providers receive 62%, validators 18%, and Super Validators 20%. A 5% Development Fund established under CIP-0082 is taken pro-rata from future mint emissions across the reward categories to fund ecosystem grants, security audits, and tooling.
Within each round, participants earn reward coupons or activity records, which are minting rights rather than automatic payments. These rights must be actively claimed within the applicable minting or coupon-validity window.
Application providers
Application providers earn the largest share of minting, and this share is designed to grow over time. Under the traffic-based model approved in CIP-0104 and expected to be rolled out through Splice in July, application rewards move away from manually submitted activity markers and toward automatic measurement of app-related traffic from sequencer and mediator data.
Under this model, application rewards are calculated from the traffic cost of successful app-related activity on the Global Synchronizer. Each application’s share of the app reward pool is proportional to the traffic its transactions generate relative to total featured app traffic in that round, subject to the applicable per-transaction caps, including the $1.50 per-transaction cap introduced by CIP-0098.
This creates tighter alignment between what applications actually do on the network and what they earn. A deeper dive into app reward mechanics, including the distinction between featured and unfeatured applications, will follow in the next article in this series.
Validator rewards
Validators earn rewards through traffic-related activity. When a validator’s traffic balance is topped up by burning $CC, a ValidatorRewardCoupon is created. The coupon amount corresponds to the $CC burned, and the validator operator can claim a proportional share of the validator reward pool for that round, subject to a per-coupon cap.
Previously, validators could also earn liveness rewards simply for being online. CIP-0096 phased these out entirely as of April 30, 2026. Today, validators that process no transactions earn no $CC through passive liveness. This shift ties validator economics directly to active transaction flow rather than passive availability.
In practice, the most economically efficient model for validators is to host applications that generate real user activity. An application provider that also operates its own validator can capture both the app rewards from the app pool and the validator rewards from the validator pool on the same transaction flow.
Super Validator rewards
Super Validators earn rewards for operating the Global Synchronizer’s consensus infrastructure. Their share of minting has decreased significantly from the initial 80% during the bootstrap phase to 20% in the current period, and is scheduled to decline further to 5% after year ten.
Minting curve and reward split
The minting schedule is designed to shift rewards from infrastructure bootstrap toward application-driven growth over time:
Decreasing liquid $CC supply
Beyond the burn-mint equilibrium, a separate mechanism addresses the liquid supply of Canton Coin. CIP-0105 introduces a locking framework for Super Validators that directly reduces circulating supply.
Super Validators may elect to lock a portion of their aggregate lifetime earned rewards. Their reward weight, or SV weight, is tied directly to the percentage of lifetime earnings that are actively locked: to earn 100% of their entitled SV weight, a Super Validator must lock 70% of aggregate lifetime earnings at activation, declining to 65% after one year, 60% after two years, and 55% after three years. SVs that lock a smaller percentage earn proportionally reduced weight. SVs whose locked reward portion decreases below the lowest mandatory threshold of the tiered model, do not earn SV rewards.
Unlocking follows a mandatory vesting process: once initiated, 1/365.25 of the requested unlock amount vests and becomes liquid each day. Only the fully locked, non-vesting portion counts toward maintaining SV Weight. This prevents opportunistic behavior: Super Validators cannot quickly unlock in response to market conditions without immediately losing governance influence.
The mechanism applies uniformly to all Super Validators with no exemptions, covering both historical rewards earned before CIP-0105 activation and all future rewards. The practical effect is a significant reduction in liquid Canton Coin supply from the network’s largest reward recipients. This works alongside the burn-mint equilibrium: burns reduce total supply, locking reduces the liquid portion, and both are tied to real network participation.
A similar locking framework for featured application providers has been approved recently, under CIP-0116.
How Zenith contributes to Canton’s burn-mint equilibrium
Zenith’s architecture ensures that EVM activity contributes directly to Canton’s burn-mint equilibrium. Every EVM transaction on Zenith is represented as Canton activity and routes through the Canton protocol. This means Zenith activity consumes Global Synchronizer traffic, and paid traffic is funded through Canton’s normal traffic model by burning $CC.
Unlike traditional Layer 2 designs where sequencer fees may be captured outside the base layer’s economic model, Zenith keeps fee value within Canton’s economic loop. No value is diverted to a sequencer operating outside Canton’s tokenomics. As Zenith scales and more developers deploy applications through Zenith EVM and Zenith Stack, the volume of EVM-generated Canton activity increases, creating additional demand for Global Synchronizer traffic and therefore additional $CC burn pressure.
Zenith therefore extends Canton’s burn-mint equilibrium to EVM activity without requiring changes to the underlying mechanism. EVM growth on Zenith is, by design, additional usage-driven demand for Canton traffic and an additional contributor to Canton Coin’s burn-mint dynamics.
