Universal Burn
One network, one economy: every production synchronizer on Canton Mainnet pays to use the network the same way.
Establish a single economic model across Canton: all production synchronizers pay network traffic fees by burning Canton Coin (CC), while apps and validators can earn rewards for eligible activity regardless of which synchronizer carries it.
Yiannis Varelas · 5North · Shaul Kfir · Digital Asset · Draft Canton Improvement Proposal (CIP), for discussion · October 2026
→ next ← back Esc all slides
Technically one network, but economically two
Most validators share the Global Synchronizer, run by the Super Validators. Others run on dedicated synchronizers, which used to be called private synchronizers or subnets.
Canton Mainnet comprises interconnected validators and synchronizers. Activity through the Global Synchronizer already produces CC burn. Traffic on dedicated synchronizers historically operated under commercial software licenses, with payments to Digital Asset. Those fees will be phased out as Digital Asset open-sources the core network. Universal burn brings all production traffic into one network economy, further aligning value capture and economic incentives across the network.
Fees are burned, and rewards are minted back
Every transaction pays for its traffic, the data it sends, at $60/MB in Canton Coin (CC): about $1 for a typical transaction. That CC is burned. The network also mints new CC as rewards to app and validator operators. Those rewards can generally be expected, though not guaranteed, to redistribute at least 90% of what's burned.
Universal burn: all production traffic pays
- 1All production synchronizers, including dedicated synchronizers, will carry network traffic fees denominated in USD and burned as CC on-chain.
- 2Deploying and operating dedicated synchronizers will be permissionless, without a separate platform license or bilateral pricing negotiation.
- 3Eligible validator and application rewards will extend to activity on dedicated synchronizers.
- =The Global Synchronizer price stays at $60/MB.
- =Test environments stay free to use.
- =Applications may sponsor fees and paymasters may provide fiat-denominated user pricing.
- =Private configurations: enterprises may retain fully controlled configurations, but their production traffic will still burn CC.
- =Rewards split: Universal burn does not alter the allocation of minted rewards among the existing reward pools.
The price per MB falls as volume grows
A common list price applies across all dedicated synchronizers. According to the proposed CIP, dedicated synchronizers will additionally qualify for an automated throughput-related reduction to the price per MB.
The framework is designed to support high-volume, low-value financial workflows while encouraging operators to add synchronizer capacity.
The detailed curve, measurement windows, and numerical thresholds will be specified in a second CIP. A preview for this second CIP is provided in the Appendix of this slide deck.
Commit to a throughput for a year or more, and three discounts stack on the volume price. It works like a cloud provider's enterprise discount program: commit to a level of spend for a year, and you pay less.
Backed by collateral worth 20% of a year's committed spend, which you get back when you leave.
Post more, up to a full year's committed spend.
15% more for each year the commitment stays in place.
Illustrative numbers.
Commitment discounts, on top of the curve
Dedicated synchronizers may elect to make longer-term usage commitments to obtain an additional discount, secured by CC collateral.
Additional collateral and the age of a continuing commitment qualify for further reductions.
Commitments will be self-service, on-chain rules-based, and optional.
Exact collateral ratios, discount factors, and enforcement mechanics will be presented in the follow-on CIP and will be subject to ongoing SV governance processes.
Illustrative numbers.
Approve the framework. Govern the parameters.
This CIP approves the network-wide framework and establishes a mechanism for evolving pricing through Super Validator governance.
This CIP
- Approves the framework.
- Universal burn goes live.
- Until the pricing curve is approved in a subsequent CIP, the Super Validators can vote discounts for specific synchronizers, case by case.
A second CIP
- Proposes the implementation details of the pricing curve, and the actual numbers.
- The pricing curve and discounts go live.
The appendix to this deck previews our current thinking.
Feedback is welcome on the CIP-discuss mailing list: lists.sync.global/g/cip-discuss
One economic model that can scale with Canton
Digital Asset is open-sourcing the core network, so the license fees on dedicated synchronizers are going away. Universal burn replaces them with one network economy.
Every production workload contributes to Canton.
High-throughput workloads stay economically viable as Canton's activity grows.
Dedicated synchronizers add capacity without fragmenting the network's economics.
Pricing can evolve as Canton evolves, without redesigning the architecture.
The change aligns the economics of dedicated and shared infrastructure, brings production activity into the same CC economy, broadens reward eligibility, and allows the network to add throughput without splintering its token economics.
The framework separates the durable policy principle from adjustable pricing parameters.
How we're thinking about the implementation
This appendix previews the details that a second CIP will propose. None of it is up for approval in this CIP, and the numbers are illustrative. We intend to publish the second CIP proposal shortly, and we're looking for industry feedback on these details as presented here.
- ABackgroundCanton Mainnet, dedicated synchronizers and open-sourcing
- BPricing in detailThe pricing curve and the discounts, one rule at a time
- CCommitments in detailCollateral, shortfalls and safeguards
- DDesign choicesThe reasoning behind each rule
- EEconomicsWhere the burn goes, and what it does for the network
- FReferenceGlossary, worked examples, parameters and formulas
This appendix shows prices per transaction, gross, with the net figure next to them. Every number will be a governance parameter that a 2/3 supermajority vote of Super Validators can change.
Canton is a public network built for finance
Institutions issue and move real assets on it, with privacy built in.
tokenized real-world assets
daily U.S. Treasury repo trades
connected firms, from financial institutions to crypto leaders
Source: canton.network/why-canton, October 2026
Canton Mainnet is more than the Global Synchronizer
Many people picture the Global Synchronizer as the public network, and everything else as private networks. We see it the other way around: validators connect to as many synchronizers as they need, and every interconnected validator and synchronizer is Mainnet. Most share the Global Synchronizer, run by the Super Validators.
What are validators and synchronizers?
Validators are the network's nodes: they hold users' data and validate their transactions.
Synchronizers are the infrastructure that connects validators. The Global Synchronizer is the network's de facto central post office: most validators connect to it, though not necessarily all.
Call them dedicated synchronizers
"Private synchronizer" or "subnet"
It's the same thing under a new name. "Private" suggests a separate blockchain, and it isn't one: it carries the same assets on the same Mainnet, and its apps can transact with apps on other synchronizers.
Dedicated capacity on Mainnet
Like a dedicated host in a public cloud: reserved for your workload, on the same network, and adding capacity for everyone.
New lanes on the same highway, with one reserved for your traffic.
Even a fully private deployment is one command from the rest of Mainnet
A bank runs its tokenized deposits fully in-house, on its own dedicated synchronizer. Its validators connect only to that synchronizer, so the rest of Mainnet can't reach the deposits.
Then a client wants to use those deposits in a composed workflow, such as swapping them for a tokenized bond issued elsewhere on Mainnet. That needs the rest of Mainnet.
That's the option value: start with a private deployment, then expand your app's reach and utility when you're ready, with no migration and no new network. It's live from day one, which is why even fully private deployments take part in the one economy.
Open-sourcing makes one economy possible
Digital Asset has been open-sourcing its core network IP, and soon all core network components will be fully open source. As core platform license fees phase out, burn replaces them, and all of the network's revenue flows through one path.
Open and permissionless
Today you join through the Global Synchronizer, or license Digital Asset's software to run your own. Next, anyone can run on any synchronizer, with pricing that's on-chain and self-serve.
For all token holders
Today, license fees go to Digital Asset. Next, every synchronizer burns CC for traffic, so the network's revenue flows through one economy.
Everyone who benefits contributes
All value-generating use of Canton feeds the network that makes it possible. As that value grows, so does the funding for those who build, run and secure it.
One network deserves one economy
The design challenge: one pricing curve for very different users
Universal burn is half of the proposal. The other half is a pricing curve that works for Canton's very diverse users, with a price a finance team can grasp in one sentence.
High-volume, low-value traffic has to be viable.
Many start with every node in-house, where today's default is a private chain like Besu or Fabric. Starting that way on Canton shouldn't cost more.
Canton scales horizontally: spinning up new synchronizers adds network capacity. Pricing should encourage it.
Some need their own synchronizer for regulatory or security reasons, such as hedging "harvest now, decrypt later" risk. That shouldn't carry a premium.
The user can pay, the app can pay for its users, or a paymaster can pay and charge a fixed fiat price, so users never touch CC.
Committed spend and accurate forecasts of usage help the whole ecosystem, and deserve a discount.
Every rule that follows answers one of these.
Meet a tokenized deposit app: $1.00 a transaction
Traffic is priced per MB, so a bigger transaction costs proportionally more. The per-MB price is calibrated so the median transaction on the network costs $1. If a performance change makes transactions bigger or smaller, the per-MB price is recalibrated to keep the median at $1, so finance teams can plan on it.
Usually the user submitting a transaction pays for it. The app can choose to cover it.
TPS and MB
TPS is transactions per second: 10 TPS is about 315 million a year.
The exact recalibration mechanism, which keeps the median transaction at $1, will be set out in the implementation CIP.
The same list price on every synchronizer
ProblemThe app moves to a dedicated synchronizer of its own, for control. What should that cost?
To keep it simple. Teams can pick the right infrastructure for their app and users without involving the finance team.
For most apps, the Global Synchronizer: the least complex way to get started, with most validators and wallets in reach. Optimize for simplicity and time to market, then move to a dedicated synchronizer if you need to.
The price never pushes you off the Global Synchronizer, and never penalizes you for leaving it. Scale and control are the reasons to move.
Why not charge more for your own synchronizer?
Some feedback argued that a dedicated synchronizer is a premium offering and should cost more. We chose one list price so the choice of infrastructure stays seamless.
Dedicated synchronizers can then earn discounts for volume and for commitment. Those come next.
Volume halves the price every 10×
The app's 10 TPS now runs on its dedicated synchronizer, where discounts start above 1 TPS.
Below 1 TPS, you pay the list price, $1.00: low volume is never penalized. Throughput is your highest 7-, 30- or 90-day average, so a busy week or a quarter-end peak still lowers your price.
Why a volume discount?
To make Canton the obvious home for high-volume, low-value use cases, to encourage new infrastructure and ease load on the Global Synchronizer, and to keep working as the network matures.
A hypothetical at maturity: a payments network at 10,000 TPS pays 6.25¢ a transaction. Once the network is no longer inflationary, about 90% of the burn comes back as rewards to app and validator operators, so roughly 0.6¢ net.
Dashed: the net cost after rewards, on the deck's net assumptions: 9.75% of gross. Click any net figure to change them.
Spiky traffic still counts
ProblemThe volume discount depends on your throughput, but traffic varies. Some apps spike weekly, others at month-end or quarter-end.
Looking at several periods makes it work for any type of app, and you always get the best of the three.
The discount changes smoothly, without steps: at 193 TPS the price is 20.5¢, between 25¢ at 100 TPS and 12.5¢ at 1,000 TPS.
An optional commitment halves it again
ProblemThe app wants a lower, predictable price for its users. It can offer a guarantee: commit to 10 TPS for at least a year, backed by collateral.
The commitment discount stacks on the volume discount, so the committed line sits at half the volume line, at every throughput.
For the app at 10 TPS, that takes $15.8m of collateral: 20% of a year's committed spend.
What a commitment involves
Like a cloud provider's Enterprise Discount Program (EDP): you commit, and the price drops. Here the commitment is backed by collateral posted on-chain, and more collateral earns a steeper discount. Unlike an EDP, there's nothing to negotiate: it's self-serve and permissionless.
Only if you want it
The volume discount is automatic. This one is your choice: if you don't commit, you post no collateral.
$15.8m, posted in CC
20% of a year's committed spend ($78.8m at 25¢). It's a deposit, and it comes back to you when you leave.
With a year's notice
You can give notice at any time. Notice takes a year, so the shortest commitment is a year.
Why collateral?
Guaranteed spend is worth more to the network than the same spend without a guarantee.
Cloud providers enforce committed-use discounts with invoices, and ultimately in court. A permissionless network can't invoice or sue, so commitments are backed by collateral instead.
More collateral gets a deeper discount
You choose how much collateral to post: from the 20% minimum up to 100% of a year's committed spend.
The cuts compound, and the price falls smoothly in between: at the 100% maximum it's 12.8¢, about half the price at 20%.
More at stake means more certainty for the network, so the committed line moves down.
Can I lower my collateral later?
The longer you stay, the lower the price
ProblemCommitments are worth more to the network the longer they last. How do we encourage staying, without a multi-year term?
As your discounts lock in, your annual spend falls. Collateral is a share of a year's spend, so the collateral you need falls too: $15.8m at the start, $6.3m after four years.
$1.00 → 50¢ → 25¢ → 10¢
All the rules together, for the app. Try your own numbers.
A payments network runs 1,000 TPS on a dedicated synchronizer
Why no discounts on the Global Synchronizer?
Volume: as throughput grows, we want new infrastructure added to the network, and less load on the Global Synchronizer.
Commitment: we're keeping the Global Synchronizer simple for now. A future CIP could take it up.
What three kinds of company would pay
Grows into the network
Day one on the Global Synchronizer, at 1 TPS: $1.00 a transaction. On its own synchronizer, committed: 50¢, with about $3.2m of collateral. At 10 TPS, two years in: 17.5¢ (), with about $11m.
Sustained high volume
1,000 TPS on its own synchronizer: 12.5¢ a transaction. Committed: 6.25¢ (), with $394m of collateral. At 10,000 TPS, committed: 3.125¢.
Most sensitive to fees
A swap touches several apps, so the rewards that offset its fees are split between them. Moving 1,000 TPS of settlements from the Global Synchronizer ($1.00) to its own committed synchronizer: 6.25¢. Its net cost is higher than an app's, because the rewards are shared with the other apps in each swap.
None of this is a step function: commitments can be raised as confidence grows, and the price improves smoothly with throughput and with time.
Collateral is a capacitor guaranteeing the burn
Like a capacitor, it holds a charge and releases it only when needed. It never pays for normal usage; it's drawn on only when usage falls short, so the network always gets the committed burn.
The app guarantees its users' usage, and that locks in a lower price for them. The users still pay for their own traffic. If usage falls short, the app covers the gap and receives that traffic.
Usage meets the commitment if any of its 7-, 30- or 90-day averages does. The test runs weekly.
In a slow quarter, shortfalls become traffic
Say usage falls to half the commitment. Each week, the shortfall is drawn from collateral and credited back to you as traffic credits.
Once collateral falls below 75% of the $15.8m required, a margin call asks you to top it back up within 7 days.
Your price holds at 25¢ through the dip: your commitment counts as throughput.
Bursty traffic passes the usage test
A settlement venue commits to 10 TPS. It runs 50 TPS for one week a month and is near-idle otherwise.
Its 30-day average: 50 TPS for 7 of every 30 days, about 11.7 TPS.
One passing average is enough: the venue is in good standing, and nothing is drawn from its collateral.
CC price moves only matter outside the band
Your collateral is posted in CC, but the requirement is in USD, so each day the collateral is valued at the CC price. Between 75% and 125% of the requirement, nothing happens. Below 75%, a margin call asks you to top up to the full requirement within 7 days. Above 125%, you can withdraw the amount above 125%.
Growing past your commitment
Traffic grows to 100 TPS. The commitment is still 10 TPS (first year, 20% collateral).
Every transaction that day pays the same blended price, 23.75¢: the weighted average of the two.
Why only the committed volume?
The commitment can't exceed your traffic here. Committing above your traffic means shortfall draws.
One commitment can span several synchronizers
The app reaches 1,000 TPS, committed with 20% collateral in its first year, across four synchronizers of 250 TPS each.
6.25¢ a transaction
One pool of collateral: $394m.
9.5¢ a transaction
Each 250 TPS synchronizer gets a smaller volume discount, and $598m of collateral in total.
With one commitment, scaling out doesn't cost you the volume discount.
Scaling down takes a year's notice
Each time you raise your commitment, the increase becomes a separate tranche with its own loyalty clock. To scale down, give a year's notice: the newest tranche goes first, last in, first out. During the notice year it keeps its discount and stops earning loyalty, and its collateral is released monthly. Notice can't be withdrawn.
Lowering your collateral percentage also takes a year's notice. The higher percentage, and its collateral, stay in place until the year ends.
Leaving, and coming back
A commitment has no end date. To leave, give a year's notice on all of it, and your discounts are kept through that year. Each month, the requirement shrinks with what you still owe, and the reduction is released to you. Margin calls still apply to what remains.
A new commitment starts with no loyalty discount.
Two promises
Your committed volume always gets your commitment discount
However much you grow.
Your collateral comes back
It's returned when you leave. Shortfall draws become traffic credits for you, and the only way to lose collateral is to miss a margin call.
What happens if…
Every node can work out the price in advance
Every node must charge the same fee, and users need to know it before they submit, so the price uses only data every node already has.
Each synchronizer's rate for the day, its price per MB after discounts, is fixed from days that have already ended.
Charged at the rate for the day the synchronizer sequences it, when its traffic is used.
Its size in MB × that day's rate.
Everyone on a synchronizer pays the same rate that day.
The whole price on one line
Every rule so far fits into one formula. The next slides explain the reasoning behind its terms.
| Term | Rule | The app: 100 TPS, 10 committed, 20%, first year |
|---|---|---|
| List price | Universal burn: $60/MB on every synchronizer | $60 |
| Throughput factor | Rules 2–3: halves with every 10× above 1 TPS, on a smooth curve, using the highest average or the commitment if higher | 0.25 |
| Committed share | The commitment ÷ the 30-day average, capped at 100% | 10% |
| Collateral factor | Rules 4–5: 0.5 at 20% collateral, × 0.75 for each doubling, about 0.26 at 100% | 0.5 |
| Loyalty factor | Rule 6: 1, minus 0.15 for each year, down to 0.4 | 1.0 |
| Rate · per transaction | $60 × 0.25 × (10% × 0.5 + 90%) | $14.25/MB · 23.75¢ |
| Net, after rewards | Optional: × the net share, 9.75% of gross by default |
Why throughput uses the highest average, and counts your commitment
Bursty users aren't penalized: a quarter-end spike keeps counting for 90 days.
A new synchronizer is priced right from day one, without traffic history. Committing high to get a lower price doesn't pay: any shortfall below the commitment is drawn from collateral.
Only a share of your traffic is committed
When traffic runs above the commitment, the committed share gets the commitment discount and the rest gets the volume price. Each day's rate blends the two. At or below the commitment, all traffic gets the commitment discount.
It uses past traffic because the rate is fixed at 00:00 UTC, before the day's traffic is known. The 30-day window, like every number here, is a governance parameter.
Collateral is a share of a year of committed spend
Say 100 TPS is committed at 20%, and traffic runs at exactly 100 TPS: 20% × 3.15bn transactions × 12.5¢ = $78.8m.
But the price depends on your traffic. Run 500 TPS and the volume discount deepens: the committed volume pays 7.7¢, so the same formula gives $48.6m.
So which price should set the requirement?
Why collateral is sized on the commitment alone
Say traffic falls from 500 TPS back to the 100 TPS commitment. You're still meeting your commitment.
$48.6m → $78.8m
The requirement jumps, and your collateral now covers only 62% of it: a margin call, from a traffic drop alone.
$78.8m, whatever your traffic
Priced as if you ran exactly your commitment, so nothing happens.
The downside is more collateral while traffic runs far above the commitment. The upside is that a drop in traffic can't raise the requirement, so it can't push you toward a margin call on its own. Only shortfall draws below the commitment, and the CC price, can do that.
Loyalty is earned in tranches, last in, first out
Each increase in your commitment is a new tranche, with its own loyalty clock. Reductions remove the newest tranche first, so your longest-standing volume keeps its loyalty. Your loyalty discount is 15% × the volume-weighted average age of your tranches; "100 @ 2y" means 100 TPS committed two years ago.
| Event | Tranches | Average age | Loyalty discount |
|---|---|---|---|
| 100 TPS committed for 2 years | 100 @ 2y | 2y | 30% |
| Add 100 TPS | 100 @ 2y + 100 @ 0y | 1y | 15% blended |
| One year later | 100 @ 3y + 100 @ 1y | 2y | 30% |
| Reduce by 100 TPS: the newest tranche goes | 100 @ 3y | 3y | 45% |
For simplicity, the last row leaves out the year's notice before a reduction takes effect.
Reporting only decides who gets the rewards
Rewards go to the parties that earned them, so the network needs to see whose traffic burned CC. Dedicated synchronizers report their own traffic, since the Super Validators can't see it.
Dedicated synchronizer operators publish their traffic on the Global Synchronizer, attributed per party: the identities that sent it.
The reports decide how rewards are split between the synchronizer's users. They can't create more rewards: the total follows the CC actually burned on the synchronizer.
Could harden enforcement, for example with a Byzantine fault-tolerant (BFT) requirement, zero-knowledge proofs or trusted execution environments. Or it could explicitly allow an override of the rewards split.
Hardening enforcement is out of scope for now.
Mechanism vs parameters
The second CIP will set the mechanism: one list price, a volume discount on dedicated synchronizers, an optional commitment backed by collateral, loyalty in tranches, a collateral band and a year's notice. Every number below will be a governance parameter: a 2/3 supermajority vote of Super Validators can change any of them. Discounts for specific use cases can come later, in their own CIPs.
A familiar analogy: how card networks move value
Calibration: merchant fees average about 2.4% of the purchase (about 3% for rewards cards). Network assessments are about 0.2% of the purchase, or about 7% of the fee. A flat 2% cashback card returns about two-thirds of the fee.
So card networks split the fee about 93 / 7. Canton's long-run split is 90.25 / 9.75, which is very close.
The other side of the equation: where the burn goes
Like a card network, where most of each fee flows back to issuers and cardholders, most of the burn flows back to the people who run and build on Canton.
At burn-mint equilibrium, when the network burns as much CC as it mints, 90.25% flows back to app and validator operators, and 9.75% to Super Validators (4.75%) and the Development Fund (5%), using the issuance split from 2034 onward. That's the deck's default net cost: 9.75% of gross. Until then, the split sends less to operators: 76% until 2029, then 85.5%. While the network mints more than it burns, as it does today, rewards can exceed the burn. Change the assumptions under .
This CIP doesn't change the reward pools; it extends who takes part to the whole network.
Cheap per transaction, but large in total
The discounts make high-volume use cases viable. Pulling them onto the network adds up to a lot of burn.
of burn a year
of burn a year
For illustration only: gross burn at the proposed parameters, with 20% collateral, in the first year.
Commitments make the network investable
Cloud providers enforce committed-use discounts with invoices, and ultimately in court. A permissionless network can't invoice or sue, so commitments are backed by collateral instead. That has benefits beyond the discount.
Predictable burn
Committed burn is visible on-chain in advance. Anyone analyzing Canton can model future burn, and see early who's falling behind on a commitment.
CC held as collateral
Collateral is posted in CC, from 20% to 100% of a year's committed spend, so adoption locks up CC for as long as commitments last.
Collateral earns the discount
For the 10 TPS app, $15.8m of collateral halves the price from 50¢ to 25¢: about $79m a year less in fees for its users.
Users get cheaper transactions, analysts can forecast burn, and more CC stays locked up for as long as commitments last.
What each group gets out of it
One network where assets and apps can work together, with one way to pay fees.
All traffic on the network burns CC, including traffic on dedicated synchronizers, and commitments lock up CC as collateral.
One price a finance team can model, which gets cheaper as you scale. You can start with an internal pilot and open up to the rest of the network later, without moving.
More usage and more users mean more rewards.
Former license revenue becomes network burn, including traffic on synchronizers they don't run. Dedicated synchronizers feed the Global Synchronizer's economy rather than compete with it.
Volume discounts reward adding synchronizers, so more demand brings more capacity. And the money that used to leave the ecosystem as license fees now stays in it.
One network, one economy, one list price
Every synchronizer is part of Mainnet, and all of its traffic burns CC.
Glossary
Worked examples
Gross price per typical transaction (16.7 KB). Net: after rewards, on the deck's net assumptions. Collateral at the 20% tier unless shown.
Parameters
Formula sheet
To rebuild this in a spreadsheet, put your inputs in B1–B9 and copy the formulas into B10–B20. Throughput is measured in MB, so B10 converts TPS into typical 16.7 KB transactions. With the inputs shown (the app at 10 TPS, fully committed at 20% collateral, first year), it reproduces the deck.