CCPEDIAby Unity Nodes
Mailing Lists/CIP-TBD: Universal Burn and Synchronizer PricingSource on lists.sync.global ↗

CIP-TBD: Universal Burn and Synchronizer Pricing

cip-discuss0 messages
Also mentions:CIP-0042CIP-0082CIP-0084CIP-0100CIP-0116
  1. #1Yiannis Varelas09-10-2026source ↗

     

    Hi all,

    Shaul and I are sharing a draft CIP for discussion: Universal Burn and Synchronizer Pricing.

    Today, traffic on the Global Synchronizer burns CC and earns rewards for the apps and validators that generate it, while traffic on dedicated synchronizers has been paid for through license fees that sit outside the network’s economy. This CIP proposes that every synchronizer running production workloads burns CC at the Global Synchronizer’s list price, that apps and validators earn rewards on that traffic wherever it runs, and that running a dedicated synchronizer becomes fully permissionless. To make Canton viable for high-throughput, low-value use cases like payments and trading, it also introduces volume pricing for dedicated synchronizers and further discounts for operators who commit to throughput and back that commitment with staked CC. We’re excited about this because it turns MainNet into one economy: value that used to leave the ecosystem becomes burn, more activity feeds the same reward pools, and Canton becomes competitive for the kinds of workloads that can drive real volume. This CIP asks the SVs to approve the framework; the specific numbers will follow in a second CIP.

    A supporting presentation with our current thinking and illustrative pricing is available at the universal burn deck.

    We'd love your feedback on this, as we consider it a critical step for the growth of the network.
    Y.

    CIP-TBD: Universal Burn and Synchronizer Pricing

    Number: CIP-XXXX
    Title: Universal Burn and Synchronizer Pricing
    Author(s): Yiannis Varelas, Shaul Kfir
    Type: Tokenomics
    Status: Draft
    Created: 2026-10-07
    License: CC0-1.0

    Abstract

    Traffic on Canton MainNet is paid for in two different ways. On the Global Synchronizer, users burn Canton Coin (CC) for traffic, and apps and validators earn rewards based on that traffic. Traffic on dedicated synchronizers doesn't burn anything. Historically, it has been paid for through license fees to Digital Asset.

     

    This CIP proposes universal burn: every synchronizer running production workloads burns CC for its traffic at the Global Synchronizer's list price, and apps and validators earn rewards for that traffic just as they would on the Global Synchronizer. To incentivize high-volume use cases to run on Canton, dedicated synchronizers will also get a volume-based pricing curve, plus further discounts for operators who commit to a level of throughput, back it with collateral, and maintain the commitment over time.

     

    We are asking the Super Validators (SVs) to approve this framework. Once it is approved, universal burn can be implemented. A second CIP will propose the implementation details of the pricing curve and the discounts, along with initial parameters.

    Motivation

    Validators can connect to as many synchronizers as they need. Most use the Global Synchronizer, which the SVs run. Some workloads run on dedicated synchronizers instead (historically referred to as private synchronizers or subnets). These are part of the same MainNet: they carry the same assets, and apps on them can transact with apps on other synchronizers.

     

    Economically, though, they currently sit apart. Traffic on the Global Synchronizer burns CC, and app and validator operators earn rewards for it. Dedicated synchronizers and the apps and validators connected to them do not.

     

    We'd propose that MainNet should work as one economy. Anyone should be able to run a synchronizer without a license, and all production traffic should pay into the same system that rewards the apps and validators generating it.

     

    A single flat price doesn't get us all the way there. Some of the most promising use cases for dedicated synchronizers on Canton, such as payments and trading, run at high throughput with a low value per transaction. At the current pricing of $60/Mb before rewards (about $1 per transaction), the barrier to use Canton is too high. Cloud providers entice high-volume customers with volume pricing and committed-use discounts, and this CIP proposes a similar structure.

    Specification

    1. Universal burn

    1. Every synchronizer running production workloads on MainNet burns CC for its traffic, at the same list price. This covers the Global Synchronizer and every dedicated synchronizer.

    2. The list price is the Global Synchronizer's price per MB, as set by the SVs through the process in CIP-0084. It is currently $60/MB, about $1 for a typical transaction before rewards.

    3. Running a dedicated synchronizer is permissionless. Anyone can deploy one and connect validators to it, with no license and nothing to negotiate. Its traffic is paid for on-chain, by burning CC, in the same way as traffic on the Global Synchronizer.

    2. Rewards

    1. Apps and validators earn rewards for all of their traffic, including traffic on dedicated synchronizers. The same reward rules apply wherever the traffic runs.

    2. The SVs cannot see traffic on synchronizers they do not operate. The operator of each dedicated synchronizer will therefore publish aggregate reports of its traffic on the Global Synchronizer, attributed per party as the reward rules require.

    3. At launch, these reports rely on the operator being honest. A maliciously constructed report can misdirect rewards between participants of the dedicated synchronizer, but it cannot earn rewards on more traffic than the synchronizer or its users paid for. A future CIP may tighten enforcement.

    4. Rewards on dedicated-synchronizer traffic are weighted by the CC actually burned, after discounts (described below).

    3. Volume pricing on dedicated synchronizers

    1. The Global Synchronizer keeps a single price at every volume.

    2. For dedicated synchronizers, the price per MB decreases as sustained throughput on each synchronizer increases, following a published curve applicable to all dedicated synchronizers.

    4. Commitment discounts

    1. On a dedicated synchronizer, an operator can commit to a level of throughput for a year or more and back the commitment with collateral posted in CC. Committed volume gets a lower price.

    2. There are three discounts, applied on top of the volume-based discount:

      • Commitment: for committing, with a minimum collateral requirement.

      • Collateral: a larger discount for posting more collateral, up to a maximum.

      • Loyalty: a further discount for each year the commitment and staked collateral stay in place, up to a maximum.

    3. Committing is optional. Once implemented, it is self-serve and permissionless: it happens on-chain, without negotiating with the Canton Foundation, the SVs, or anyone else.

    4. A commitment is binding. Shortfalls against it are paid from the collateral and credited back as traffic. Collateral that is not topped up when required can be forfeited. The rest is returned when the commitment ends.

    5. Governance

    Every number in this framework will be an on-chain governance parameter, including the list price, the volume curve, the size of each discount, and the collateral levels. The SVs can change any of them with a 2/3 vote. Future discounts may be added to this framework via CIP and 2/3 vote.

    6. Until the pricing curve is approved

    1. Approving this CIP allows universal burn to be implemented without waiting for the second CIP.

    2. Until the pricing curve is approved in a subsequent CIP, the operator of a dedicated synchronizer can ask the SVs for a discount, and the SVs decide on a case-by-case basis by vote.

    3. These interim discounts end when the pricing curve and the commitment discounts go live.

    7. What does not change

    • The Global Synchronizer's price.

    • The split of rewards between SVs, validators, apps, and the Development Fund (CIP-0082).

    • Paymasters can still offer users a fixed fiat price for traffic.

    • Private configurations remain possible: an organization can still run everything in-house, much as it would a private blockchain. Its production traffic burns CC like any other.

    • Test and development environments do not burn real CC.

    8. Rollout

    Phase

    Estimated timing

    What goes live

    1

    Q1 2027

    Universal burn, with interim discounts voted by the SVs case by case.

    2

    Q3 2027

    Volume pricing and commitment discounts, once a second CIP is approved. They replace the interim discounts.

     

    These dates are our ambitious estimates of when each phase could be ready. They are not deadlines.

    9. Left to the second CIP

    The second CIP will propose the implementation details, including:

     

    • the volume curve, and how sustained throughput is measured

    • the size of each discount, and the collateral levels

    • how collateral is valued, and the rules for notice, shortfalls and margin calls

    • whether and how parameter changes apply to existing commitments

    • commitments that cover more than one synchronizer

    • how the discounted price is computed and applied

     

    The appendix of the accompanying Universal Burn deck sets out our current thinking on each of these, with illustrative numbers. It is there to inform the discussion and is not part of what this CIP asks the SVs to approve.

    Rationale

    Why the same list price everywhere? Starting every synchronizer at the Global Synchronizer's price gives the whole network one reference price, and the Global Synchronizer's price doesn't change. There's no setup fee and no premium for running a dedicated synchronizer.

     

    Why volume pricing only on dedicated synchronizers? When a workload grows, we'd rather it bring new capacity to the network than put more load on the Global Synchronizer. A single price also keeps the Global Synchronizer simple.

     

    Why collateral behind commitments? Cloud providers enforce committed-use discounts through invoices and contracts. A permissionless network can't, so commitments are backed by collateral instead. Collateral also makes committed burn visible on-chain in advance, so future burn is easier to forecast, and it keeps CC locked for as long as the commitment lasts.

     

    Why approve the framework before the numbers? The structure is what operators need to plan around, and we think it's the decision the SVs should make first. The numbers need more modeling and more feedback from the community and from operators. Splitting the two lets universal burn start sooner, and the interim discounts give the SVs a way to handle specific cases in the meantime. CIP-0082 took the same approach: it established the Development Fund and left the mechanics to a later CIP (CIP-0100).

    Alternatives considered

    • Keep license fees for dedicated synchronizers. That's the status quo. License payments leave the network's economy, and the approach doesn't fit a permissionless network built on open-source software.

    • One flat price, with no discounts. Simpler, but it would price high-volume, low-monetary-value use cases out of Canton.

    • Negotiated pricing, permanently. Case-by-case deals would have the SVs negotiating with every operator, and the outcome would be neither predictable nor permissionless. We propose it only as a stopgap until the pricing curve is approved.

    • Exempting deployments that serve a single organization. A fully private deployment is one admin command away from the rest of MainNet, and an exemption like this would be hard to define and hard to police. A future CIP could introduce a further discount for such use cases.

    Economic impact

    • License revenue that used to leave the ecosystem becomes burn on the network.

    • Apps and validators on dedicated synchronizers participate in the same reward pools, so rewards are shared across more activity, and that activity brings more burn.

    • Volume pricing makes high-throughput use cases viable. We expect that to mean more total burn, even at lower prices per transaction.

    • Commitments lock CC up as collateral and make future burn more predictable.

    • Issuance and the reward split don't change.

    Backwards compatibility

    The Global Synchronizer's price and mechanics don't change.

     

    Existing dedicated synchronizers move from license fees to burn as the license fees phase out. Digital Asset will handle that transition with each existing customer, and the interim discounts are available in the meantime.

    Reference implementation

    None yet. If this CIP is approved, the next steps are:

     

    1. Implement universal burn, including traffic reporting for dedicated synchronizers, and deploy it by SV vote.

    2. Request a grant to design the pricing curve and the discounts, run proofs of concept, and continue discussions with operators.

    3. Submit the second CIP with the implementation spec.

    4. Request a grant to implement it on MainNet.

    Copyright

    This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.

    Changelog

    • 2026-10-07: Initial draft.

     

     

    Appendix: Preview of the proposed initial pricing

    This appendix is not part of the CIP and is not up for approval. It gives a high-level preview of the initial pricing we expect to propose in the second CIP. The numbers are illustrative. The appendix of the Universal Burn deck has the details.

    All prices here are gross, per typical transaction (16.67kb), on a dedicated synchronizer. The Global Synchronizer stays at the list price, about $1 a transaction, at any volume. All parameters suggested here will be configurable on-chain by vote of 2/3 of SVs.

    • Volume. Up to 1 TPS of sustained throughput, the price is the list price. Above that, it halves with every 10x of throughput: 50¢ at 10 TPS, 25¢ at 100 TPS and 12.5¢ at 1,000 TPS.

    • Commitment. An operator who commits to a level of throughput for a year or more, and posts collateral worth 20% of that year's fees, gets 50% off the volume price on the committed volume.

    • More collateral. Each doubling of the collateral takes another 25% off, up to collateral worth 100% of a year's fees, which guarantees the full year's spend. Going from 20% to 100% is a little over two doublings, so 100% collateral comes to about 74% off the volume price.

    • Loyalty. Each year the commitment stays in place takes another 15% off the committed price: 30% after two years, and 60% after four, which is the maximum.

    With all three at their maximum, committed volume costs about a tenth of the volume price. An app at 10 TPS would pay a gross fee of about 5¢ a transaction instead of 50¢.

    Most of what's burned is minted back as rewards to app and validator operators, so the net cost is much lower than these gross prices. The deck shows both.







  2. #2ds13-10-2026source ↗

    Thank you, Yiannis and Shaul, for setting this out so clearly. We support the central aim: dedicated synchronizers should sit inside the CC economy. While they pay no burn, the Global Synchronizer has no pricing power over them, and value that should accrue to the network leaves it.

    The questions below concern how that is achieved. Several of them were also raised from an operator's perspective in #886, and we think they share a common root: the price of capacity is administered rather than discovered.

    Questions for the authors

    1. Have you considered the direction of the feedback between traffic and CC demand? The list price is fixed in USD, so the CC burned per transaction is the USD price divided by the CC price. As CC appreciates, each transaction burns fewer CC, and demand for CC from traffic falls as its price rises. On Ethereum the relationship runs the other way: congestion raises the fee in ETH, and with it the demand for ETH. A USD peg caps the upside of CC unless the policy is continually revised; deriving traffic fees backwards from the CC price inverts the relationship a market would set.
    2. Is $60/MB intended as a policy price or as the cost of a resource? Ethereum administers its gas schedule, the relative cost of each operation, but leaves the price of gas to a demand-responsive base fee and priority tips. Bitcoin clears block space by fee auction. Canton would be the only one of the three to administer the price per unit itself.
    3. What does the burn on a dedicated synchronizer pay for? The operator provisions and pays for its own infrastructure, so the burn recovers no network cost. A volume discount is a cost argument, economies of scale over fixed cost, applied to a charge with no cost behind it. It also lowers burn per transaction precisely where throughput is highest, which compounds the effect in point 1.
    4. Have you considered pricing the cost of capital rather than fixing it? The commitment discount moves towards pricing locked CC, but it states the cost of capital explicitly in a schedule. A committed operator pays for committed traffic whether or not it is used, and is compensated by a discount set in advance rather than by a rate the market sets for locking CC over the term.
    5. Have you considered how the network prices the option it is writing? Posting 20% collateral gives the committing operator what is in effect a call option on traffic at half the volume price. If the traffic materialises, it is bought at the strike; if not, the loss is capped at the collateral, which is returned if the commitment is met. Whether committed prices are protected from later parameter changes, left open in section 9, decides whether the holder is also long any vote that raises the list price. Any fixed set of curves, tiers and time constraints creates boundaries of this kind, and they will be arbitraged. A single schedule also cannot reflect utility that differs widely between synchronizers.
    6. Where will traffic route? Paymasters can offer a fixed fiat price, and a staked operator of a dedicated synchronizer can resell committed capacity. Both draw traffic to the cheapest route to deliver, priced down to the committed operator's risk-adjusted cost of capital. If most traffic flows that way, burn is collected near the maximum discount, about a tenth of the volume price, and the spread accrues to intermediaries rather than to the network.
    7. Could metering be avoided rather than verified? The questions already raised on measurement suggest that equitable reporting is a larger task than the framework implies. If the price of capacity were implied by committed CC, metering for reward attribution would not be required. Enforcement would become a local admission check within the synchronizer, with nothing published about participants or counterparties, which would also meet the confidentiality concern in #886.
    8. Have you considered SV authorisation rather than permissionless operation? Canton admits participants through SV sponsorship today, and permissionless synchronizers would depart from that model. Authorisation need not touch privacy: what the SVs would authorise is the capacity a synchronizer offers, not visibility into its traffic.
    9. Who will monitor the honesty of traffic reports? The draft leaves enforcement to a future CIP. If the burden falls to the Foundation, as the good-standing judgement does for featured apps under CIP-0116, it adds to an existing monitoring load and centralises control.
    10. Two definitions would help the second CIP. The appendix compounds the collateral discount multiplicatively (74% at 100% collateral) but the loyalty discount additively (60% at four years). It would also help to confirm that the collateral percentage is measured against the discounted spend, as the description of the 100% case implies.

    A market mechanism for the committed tier

    We have shared a draft CIP on this list, Holdings-Denominated Capacity Rights (draft; scripts reproducing every figure at dark-sole/canton-capacity-rights). It addresses these questions by discovering the price of committed capacity rather than setting it, and we offer it for consideration as the mechanism for the commitments in section 4 and for the second CIP.

    In brief:

    • Capacity is issued by auction. Each synchronizer offers capacity below a conservative floor it undertakes to deliver. Participants bid CC to be locked, and the auction clears to a rate in bytes per epoch per locked CC. Governance sets the headroom and the maturity ladder, not the price.
    • Entitlement is absolute and fixed for the term. A party receives a stated number of bytes per epoch until maturity, enforced at admission. It does not move with other parties' locking or with later changes in capacity, so it can be budgeted on the day it is acquired.
    • Capacity and capital are separable. Locking mints a utility strip (TU), carrying the entitlement and expiring at maturity, and a capital strip (TC), redeeming to CC. A participant that needs only throughput buys TU and takes no CC price exposure; a holder retains TC and sells capacity it would not use.
    • The market reports what the schedule would have to guess. The TU forward curve across maturities signals scarcity ahead of time for provisioning, and the discount at which TC trades to spot CC is the market's cost of capital for locked CC over the term.

    This is compatible with universal burn. Committed capacity would be the senior tier, and uncommitted residual capacity would remain available at spot, for which the universal burn price is a natural reference. The CIP goes further in places, proposing to replace parts of the reward-offset construction, but the committed tier stands on its own.

    How the two approaches compare

    Each row sets a question above against how the draft and the capacity-rights CIP treat it.

    Question Universal Burn draft Capacity-rights CIP
    Price of capacity (1, 2) Fixed in USD by governance; CC burned per transaction falls as CC rises Cleared at auction in CC; the price is discovered
    Volume pricing (3) Discount curve on sustained throughput, with no cost basis Not required; every participant bids at one clearing rate
    Cost of capital (4, 5) Fixed by the discount schedule; the option a commitment confers is unpriced Implied by the TC discount to spot CC
    Arbitrage and routing (5, 6) Tier boundaries and resale through paymasters and staked operators One rate per maturity; TU is fungible and traded openly
    Nature of the commitment (4) Take-or-pay obligation to spend, backed by collateral Right to a stated throughput, senior to spot
    CC price exposure Carried by the committing operator through its collateral Separable: TU carries none, TC carries all
    Reward attribution (7, 9) Operator self-reports per party; enforcement left to a future CIP Admission check against an epoch snapshot; nothing reported
    Confidentiality (#886) Per-party attribution published on the Global Synchronizer Traffic and counterparties stay within the synchronizer
    Synchronizer admission (8) Permissionless Not specified; SV authorisation would attach to the governed capacity floor each synchronizer offers
    Provisioning signal None specified TU forward curve across maturities
    Interim pricing Case-by-case SV votes on discounts Auction from the first issuance

     

    We would welcome the authors' views on whether a market-cleared committed tier could serve as the basis for section 4 and the second CIP, and we would be glad to contribute to that work.

    Daryn

  3. #3Abdulkadir CANPOLAT13-10-2026source ↗

    Proposal: Protocol-Level CC Burn Before Reward Distribution

    Sustainable Economic Value and Supply Management for Canton Coin

    Purpose of the Proposal

    The long-term economic sustainability of Canton Network should not depend solely on CC burns generated by transaction traffic. While traffic-based burning is an important mechanism, I believe a stronger and more direct economic balance should be established between network growth, reward issuance, and the supply of newly minted Canton Coin (CC).

    For this reason, I propose introducing a second burn channel that complements the existing Universal Burn approach.

    The primary objective is to permanently burn a defined percentage of newly minted Canton Coin rewards at the protocol level, before those coins enter circulation.

    This mechanism should operate independently of CC's USD market price and directly connect the network's reward issuance to disciplined supply management.

    1. A Dual-Channel Burn Model

    Canton Network's burn economy could consist of two complementary mechanisms.

    Channel One — Traffic-Based Burn

    The existing traffic burn mechanism would remain in place. Transactions and data usage across the network would continue generating CC burns under the applicable traffic pricing rules.

    Channel Two — Protocol-Level Reward Burn

    A defined percentage of CC rewards allocated to Validators, Super Validators, and Featured App operators would be automatically burned before distribution.

    This deduction would:

    • Be independent of CC's market price.

    • Be calculated directly in CC.

    • Be enforced automatically at the protocol level before rewards are distributed.

    • Require no voluntary action from operators.

    • Prevent the burned portion of newly minted CC from entering circulation.

    • Be recorded and verifiable across the network.

    2. Proposed Mechanism

    For illustration, assume that the network generates 1,000,000 CC in gross daily rewards and that a 3% burn rate is applied.

    Description CC Amount
    Gross daily rewards 1,000,000
    Protocol-level burn (3%) 30,000
    Net rewards distributed 970,000

    Under this model, 30,000 CC would be permanently burned before reaching the accounts of reward recipients.

    Assuming the same daily issuance throughout the year, this would prevent 10,950,000 CC from entering circulation annually.

    The 3% rate is illustrative only. The actual percentage should be determined through economic analysis and network governance.

    3. Economic Objectives

    The objective of this proposal is not simply to increase the amount of CC burned.

    The broader goal is to support the long-term economic value of Canton Coin, moderate the market impact of newly issued supply, and establish a sustainable relationship between network growth and token economics.

    The proposed mechanism aims to achieve the following:

    1. New Supply Management: A defined percentage of newly minted reward allocations would be permanently removed before entering circulation.

    2. Support for Economic Value: All else being equal, reducing the amount of newly issued CC entering the market may help moderate supply pressure and support the long-term economic value of Canton Coin.

    3. Price-Independent Operation: The burn percentage would remain consistent regardless of CC's USD market price.

    4. Burns Linked to Network Growth: As reward issuance increases, the amount of CC burned through this mechanism would increase proportionally.

    5. Shared Economic Responsibility: All participants benefiting from the network's reward economy would contribute to the burn mechanism under transparent and consistently applied rules.

    6. Predictability: A predefined burn rate would make the mechanism's effect on reward distributions and new circulating supply measurable and predictable.

    4. Transparency and Network-Wide Reporting

    The proposed burn mechanism should not only operate at the technical level but also become an integral part of Canton Network's economic transparency.

    For this purpose, I propose introducing a publicly available Canton Network Burn Report, published daily.

    The report should separately disclose:

    • Total daily traffic-based CC burns.

    • Total CC burned before reward distribution.

    • Burn contributions attributable to Validators, Super Validators, and Featured Apps.

    • Total newly minted CC.

    • Net newly issued CC entering circulation.

    • Cumulative CC burned.

    All burn transactions should be verifiable on-chain, with daily aggregate figures published through an official network-wide reporting mechanism.

    Importantly, implementation should rely on a protocol-recognized, irreversible burn operation that genuinely reduces CC supply, rather than merely transferring tokens to an inaccessible address.

    5. Relationship to the Universal Burn Proposal

    The Universal Burn proposal seeks to integrate traffic activity across different synchronizers into a unified CC burn economy.

    I support this objective.

    However, traffic-based burning and the management of newly issued reward supply address two different economic challenges.

    Traffic-based burning is driven by network usage.

    The proposed protocol-level reward burn would instead be directly linked to newly minted CC rewards.

    Allowing these two mechanisms to operate together could provide Canton Network with a more balanced and comprehensive economic framework.

    Conclusion

    Canton Network's long-term success should not depend solely on transaction counts, traffic volumes, or the quantity of rewards distributed.

    As the network grows, it should also have predictable and automated mechanisms designed to preserve and support the economic value of Canton Coin.

    My proposal is to permanently burn a defined percentage of newly minted CC rewards before they enter circulation, establishing an independent, protocol-enforced burn channel alongside the existing traffic-based burn mechanism.

    This would allow Canton to move beyond a model in which burning is driven exclusively by network usage, making reward issuance itself part of the network's supply management strategy.

    Such a mechanism would not, by itself, guarantee an increase in CC's market price. However, it could establish a transparent, measurable, and sustainable framework for moderating new supply and strengthening Canton Coin's long-term economic foundations.

    Core Principle

    “Canton Network should not rely solely on burning CC through network usage. A portion of newly minted rewards should be permanently burned before entering circulation, ensuring that network growth is accompanied by disciplined token issuance.”

  4. #4Yiannis Varelas13-10-2026source ↗
    Hi all and thanks for all the feedback. 

    I'm posting our responses to Michael first, who posted the feedback on #886 so we can
    keep them unified. 

    1. Reporting and visibility. CC never moves on a dedicated synchronizer. It lives only on the Global Synchronizer, so every traffic purchase for a dSync is a burn on the gSync and is public through Scan like any other burn. In the current design, traffic can be purchased per participant, so those purchases are visible at the participant level, or it can be purchased in aggregate by the dSync operator, hiding the individual participants’ usage. Reward reporting is separate: each round, the operator submits a commitment (a Merkle root) over per-provider activity, and only the entries needed to mint rewards are revealed. Parties that don’t want to earn rewards don’t need to appear in it, and the operator can attribute that activity to itself. Actual traffic consumption and transaction-level activity on the dSync are never visible to the SVs, who don’t run or see its sequencers and mediators. In short, economic facts are public and operational details are not. We’d welcome your input on whether participant-level traffic purchases are a concern for your setup.


    2. Volume pricing.     The volume curve is based only on sustained throughput in MB/s. Because of Canton’s privacy model, the synchronizer has no visibility into the value of a transaction, so the same pricing applies to any use case, high-value institutional products included. We’ll update the Motivation section so it doesn’t read as limited to low-value flows.


    3. “Same MainNet.”     Even a dSync in a fully private configuration is part of MainNet in the sense that its assets can interoperate with the rest of the network. You can run your dSync and its validators the way you’d run a private Besu or Fabric network, with no connectivity to other synchronizers. When you’re ready to make your asset available on other venues, you connect your app’s validator to the gSync. The obligations are that production traffic burns CC, and that at least one validator connects to both the gSync and your dSync to purchase traffic. In the first release, we expect a dSync will need to be registered through an SV vote before traffic can be purchased for it. The reason for this is simply that it’s easier to implement, so we propose doing it in stages. Permissionless self-registration is planned for the following phase, expected within a few months.


    4. Verification.     The current design already bounds what an operator can claim: rewards minted can’t exceed the pro-rata share based on reported activity, which can’t exceed the pro-rata share based on traffic actually purchased, and the SVs set a per-synchronizer weight and a reporting deadline. Any further change to the trust model will go through a CIP with community consultation, will preserve confidentiality by design, and we’ll engage operators like you early.

    5. Licensing. There are two parts to this. For existing commercial agreements with Digital Asset: the CIP doesn’t change those terms itself, but license fees for dedicated synchronizers are phasing out as the protocol is open-sourced, and DA will work through that transition directly with each existing customer. Interim discounts are available in the meantime. For the open-source software going forward: we anticipate that future hardening of the trust model may require a license clause prohibiting tampering with tokenomics enforcement. That would be raised and discussed openly when we get there.


    Hope the above give clarity to the original Qs.

     
  5. #5Yiannis Varelas13-10-2026source ↗

    Thanks for the proposal @Abdulkadir.

    We see this as separate from Universal Burn:
    this CIP is about bringing dedicated synchronizer traffic into the existing burn and reward economy, not about changing issuance.

    If this is a new proposal you want to put forward, you can create a new thread under cip-discuss and we can take the conversation there. 

    Y.

  6. #6Yiannis Varelas14-10-2026source ↗
    Hi Daryn, thanks for the feedback and ideas. Responses are in-line in blue with your message for better tracking.

    See below.

    Y.

    On Tue, Oct 13, 2026 at 2:21 PM ds via lists.sync.global <ds=tokenisys.com@...> wrote:

    Thank you, Yiannis and Shaul, for setting this out so clearly. We support the central aim: dedicated synchronizers should sit inside the CC economy. While they pay no burn, the Global Synchronizer has no pricing power over them, and value that should accrue to the network leaves it.

    The questions below concern how that is achieved. Several of them were also raised from an operator's perspective in #886, and we think they share a common root: the price of capacity is administered rather than discovered.

    Questions for the authors

    1. Have you considered the direction of the feedback between traffic and CC demand? The list price is fixed in USD, so the CC burned per transaction is the USD price divided by the CC price. As CC appreciates, each transaction burns fewer CC, and demand for CC from traffic falls as its price rises. On Ethereum the relationship runs the other way: congestion raises the fee in ETH, and with it the demand for ETH. A USD peg caps the upside of CC unless the policy is continually revised; deriving traffic fees backwards from the CC price inverts the relationship a market would set.

    Pricing transactions in USD is critical to the BME feedback loop, i.e., tying the long-run price of CC to the value the Canton network provides its users. Separately, most companies model their unit economics and financial projections in fiat currency, so price stability in fiat is important for adoption. In any case, we see any such change to the core BME mechanism as out of scope for this CIP.


     
    1. Is $60/MB intended as a policy price or as the cost of a resource? Ethereum administers its gas schedule, the relative cost of each operation, but leaves the price of gas to a demand-responsive base fee and priority tips. Bitcoin clears block space by fee auction. Canton would be the only one of the three to administer the price per unit itself.

    This CIP doesn’t address the base price and instead inherits the base price from the preexisting cost of using the network. Canton doesn’t have the same blockspace limitation as Bitcoin and Ethereum, as it is horizontally scalable by adding dSyncs. So we can give a predictable unit price that isn’t subject to surge pricing.  
    1. What does the burn on a dedicated synchronizer pay for? The operator provisions and pays for its own infrastructure, so the burn recovers no network cost. A volume discount is a cost argument, economies of scale over fixed cost, applied to a charge with no cost behind it. It also lowers burn per transaction precisely where throughput is highest, which compounds the effect in point 1.

    It pays for the ability to compose with the rest of the ecosystem, benefiting all token holders for the value provided.  
    1. Have you considered pricing the cost of capital rather than fixing it? The commitment discount moves towards pricing locked CC, but it states the cost of capital explicitly in a schedule. A committed operator pays for committed traffic whether or not it is used, and is compensated by a discount set in advance rather than by a rate the market sets for locking CC over the term.

    This is an interesting avenue to explore, but we’d prefer to keep it simple at this stage.


    1. Have you considered how the network prices the option it is writing? Posting 20% collateral gives the committing operator what is in effect a call option on traffic at half the volume price. If the traffic materialises, it is bought at the strike; if not, the loss is capped at the collateral, which is returned if the commitment is met. Whether committed prices are protected from later parameter changes, left open in section 9, decides whether the holder is also long any vote that raises the list price. Any fixed set of curves, tiers and time constraints creates boundaries of this kind, and they will be arbitraged. A single schedule also cannot reflect utility that differs widely between synchronizers.

    I’m not sure I fully understand your argument, but you do raise an important point about protection from parameter changes, which we have not addressed explicitly. Our thinking is that the commitment gives you a percentage discount, so any change to the base price will still affect you. The reasoning is that, to date, base price changes have recalibrated the price of a typical transaction per CIP-0042. I think it makes sense for any future CIP that significantly changes the fees structurally to allow for an immediate penalty-free exit from the commitment.

     
    1. Where will traffic route? Paymasters can offer a fixed fiat price, and a staked operator of a dedicated synchronizer can resell committed capacity. Both draw traffic to the cheapest route to deliver, priced down to the committed operator's risk-adjusted cost of capital. If most traffic flows that way, burn is collected near the maximum discount, about a tenth of the volume price, and the spread accrues to intermediaries rather than to the network.

    Such providers deliver real value to the market by operating infrastructure, increasing network capacity, and assuming the risk of underwriting a fixed-for-float contract. They should be compensated for infrastructure expenses, the risks taken, and the value provided. Incentivizing companies to provide this value is aligned with the interests of token holders.
     
    1. Could metering be avoided rather than verified? The questions already raised on measurement suggest that equitable reporting is a larger task than the framework implies. If the price of capacity were implied by committed CC, metering for reward attribution would not be required. Enforcement would become a local admission check within the synchronizer, with nothing published about participants or counterparties, which would also meet the confidentiality concern in #886.

    I don't understand what you are asking here.
     
    1. Have you considered SV authorisation rather than permissionless operation? Canton admits participants through SV sponsorship today, and permissionless synchronizers would depart from that model. Authorisation need not touch privacy: what the SVs would authorise is the capacity a synchronizer offers, not visibility into its traffic.

    Why is it beneficial to make this gated and not permissionless? In the first phase we expect it will require SV authorization as a necessary evil because this is faster to implement, but we want this to be completely self-serve and permissionless.  
    1. Who will monitor the honesty of traffic reports? The draft leaves enforcement to a future CIP. If the burden falls to the Foundation, as the good-standing judgement does for featured apps under CIP-0116, it adds to an existing monitoring load and centralises control.

    If traffic reports are dishonest, the only parties negatively affected are dSync users, not the rest of the network, because the malicious dSync operator can route validator rewards to itself. So it can tamper with how rewards are split amongst its ecosystem, but it can’t tamper with the portion of overall rewards it receives. Therefore, the first phases will not address the trustworthiness of reports. In later phases, we can introduce mechanisms to monitor report honesty. Some options include requiring a decentralized dSync or requiring a ZKP- or TEE-based proof.

     
    1. Two definitions would help the second CIP. The appendix compounds the collateral discount multiplicatively (74% at 100% collateral) but the loyalty discount additively (60% at four years). It would also help to confirm that the collateral percentage is measured against the discounted spend, as the description of the 100% case implies.

    Yes, all of this is correct. We’ll make it clear in the second CIP. 

    A market mechanism for the committed tier

    We have shared a draft CIP on this list, Holdings-Denominated Capacity Rights (draft; scripts reproducing every figure at dark-sole/canton-capacity-rights). It addresses these questions by discovering the price of committed capacity rather than setting it, and we offer it for consideration as the mechanism for the commitments in section 4 and for the second CIP.

    In brief:

    • Capacity is issued by auction. Each synchronizer offers capacity below a conservative floor it undertakes to deliver. Participants bid CC to be locked, and the auction clears to a rate in bytes per epoch per locked CC. Governance sets the headroom and the maturity ladder, not the price.
    • Entitlement is absolute and fixed for the term. A party receives a stated number of bytes per epoch until maturity, enforced at admission. It does not move with other parties' locking or with later changes in capacity, so it can be budgeted on the day it is acquired.
    • Capacity and capital are separable. Locking mints a utility strip (TU), carrying the entitlement and expiring at maturity, and a capital strip (TC), redeeming to CC. A participant that needs only throughput buys TU and takes no CC price exposure; a holder retains TC and sells capacity it would not use.
    • The market reports what the schedule would have to guess. The TU forward curve across maturities signals scarcity ahead of time for provisioning, and the discount at which TC trades to spot CC is the market's cost of capital for locked CC over the term.

    This is compatible with universal burn. Committed capacity would be the senior tier, and uncommitted residual capacity would remain available at spot, for which the universal burn price is a natural reference. The CIP goes further in places, proposing to replace parts of the reward-offset construction, but the committed tier stands on its own.

     

    We’ll need to think about this more, but my first impression is that this is additive to the CIP we propose. At the ecosystem's current level of maturity, companies are looking for price stability, not necessarily the best possible price. So I expect that many companies will prefer a fixed mechanism over an auction mechanism. But more sophisticated actors (of which there will be more as the ecosystem matures) will probably look to optimize price. For now, I believe the fixed proposal is the best at the protocol level. An intermediary can implement your mechanism and “bulk-purchase” a discount by committing to a certain throughput, and then auction that capacity, getting paid for the risk they’re taking and the value they’re providing.


     

    How the two approaches compare

    Each row sets a question above against how the draft and the capacity-rights CIP treat it.

    Question Universal Burn draft Capacity-rights CIP
    Price of capacity (1, 2) Fixed in USD by governance; CC burned per transaction falls as CC rises Cleared at auction in CC; the price is discovered
    Volume pricing (3) Discount curve on sustained throughput, with no cost basis Not required; every participant bids at one clearing rate
    Cost of capital (4, 5) Fixed by the discount schedule; the option a commitment confers is unpriced Implied by the TC discount to spot CC
    Arbitrage and routing (5, 6) Tier boundaries and resale through paymasters and staked operators One rate per maturity; TU is fungible and traded openly
    Nature of the commitment (4) Take-or-pay obligation to spend, backed by collateral Right to a stated throughput, senior to spot
    CC price exposure Carried by the committing operator through its collateral Separable: TU carries none, TC carries all
    Reward attribution (7, 9) Operator self-reports per party; enforcement left to a future CIP Admission check against an epoch snapshot; nothing reported
    Confidentiality (#886) Per-party attribution published on the Global Synchronizer Traffic and counterparties stay within the synchronizer
    Synchronizer admission (8) Permissionless Not specified; SV authorisation would attach to the governed capacity floor each synchronizer offers
    Provisioning signal None specified TU forward curve across maturities
    Interim pricing Case-by-case SV votes on discounts Auction from the first issuance

     

    We would welcome the authors' views on whether a market-cleared committed tier could serve as the basis for section 4 and the second CIP, and we would be glad to contribute to that work.

    Daryn