Proposed traffic-payment model, November 10. Source.
A new Canton proposal sets out the first technical implementation of Universal Burn: measure traffic on a dedicated synchronizer, then have a designated paymaster burn the corresponding Canton Coin on the Global Synchronizer.
The draft, announced for discussion on November 10, builds on the CIP-0129 framework approved in October. It explains how an initial version could work before more automated, trustless enforcement is available.
The terms in plain English
- Synchronizer: infrastructure that coordinates transactions between Canton participants.
- Dedicated synchronizer: a synchronizer used for a particular set of applications or workloads, separate from the shared Global Synchronizer.
- Paymaster: the designated party responsible for paying for that synchronizer’s traffic by burning CC.
- Burn: permanently removing CC through the network’s traffic-payment mechanism.
The purpose is to connect activity on dedicated infrastructure with Canton’s existing burn-and-reward economy. Institutions could retain their dedicated setup while its traffic contributes through CC payments.
How the first version would work
- Record the traffic. The dedicated synchronizer reports the amount of data processed, grouped into ten-minute intervals.
- Calculate and pay. The operator and paymaster apply the agreed pricing and any discounts. The paymaster burns CC on the Global Synchronizer after the traffic has been consumed.
- Record reward eligibility. The burn produces validator reward coupons and activity records used for app rewards. The paymaster needs a Featured App right to receive the applicable featured rewards.
The proposed first-phase model. Source: Dedicated Synchronizer Paymaster draft.
For example, an operator might measure its traffic over an agreed period and arrange for the paymaster to spread the resulting burns over later rounds. The draft allows that kind of smoothing where the Super Validators have agreed to delayed payment. It does not give every operator an automatic right to defer payment.
What this adds to CIP-0129
CIP-0129 established the wider economic direction. This draft narrows the engineering question to a first deliverable, with several important choices:
- Payment follows use. The connection between the traffic report and payment is handled outside the ledger.
- No first-phase traffic cutoff. The dedicated synchronizer does not reject messages because a participant has run out of traffic allowance.
- Rewards go through the paymaster. The draft includes app-reward integration from the start, with more detailed attribution to other parties expected later.
- Registration requires a vote. Super Validators would register the synchronizer, its paymaster and the activity-weight limits used for rewards.
The reward point is a useful distinction from a fully developed system that allocates rewards directly across all apps on a synchronizer. The initial model concentrates the payment and reward role in the designated paymaster.
Why trust is part of the design
The first version trusts the operator and paymaster to report traffic correctly and burn the right amount. An incorrect report could understate or overstate usage. On-chain rules would still keep the resulting rewards tied to the burn that actually occurred.
That trade-off is deliberate. The draft removes a direct operational dependency on the Global Synchronizer: a dedicated synchronizer could continue working during a Global Synchronizer outage, with its payment arrangement handled separately.
Later phases are expected to reduce trust in operators and strengthen enforcement. Those later improvements should not be assumed to exist in the first implementation.
What happens next
The proposal remains a draft under discussion. It is not evidence that dedicated synchronizers have begun using this payment model, and it does not establish a final pricing curve or a deployment date.
The next steps are governance review and implementation. For readers following Canton’s economics, the concrete development is that Universal Burn now has a proposed first operating model, with its payment flow, reward treatment and trust assumptions written down.
Primary records: Paymaster draft · Discussion announcement · Approved CIP-0129 framework.
