CIP-TBD: Universal Burn and Synchronizer Pricing f/back
As an operator building institutional workflows on a dedicated Canadian synchronizer, we understand the goal of tighter integration with the Global Synchronizer, and want to share the following points from that perspective:
1. Reporting should be configurable, with operator-level aggregation. The proposal requires traffic to be reported and attributed per party. For institutional networks, that would expose information about participants and counterparties that we're contractually and, in some cases, regulatorily obliged to protect. Many of these parties also have no interest in being visible as reward earners at all. We'd ask that who reports, and at what granularity, be configurable, so that a single network operator can aggregate activity across its participants and report on behalf of the network as a whole.
2. Volume pricing isn't only for low-value use cases. The proposal frames discounted pricing around high-throughput, low-value flows like payments. Higher-value institutional products are also highly cost-sensitive, because they compete directly with incumbent infrastructure on per-transaction economics. We'd encourage pricing tiers that reflect that.
3. Clarifying "same MainNet." The description of dedicated synchronizers as part of the same MainNet, carrying the same assets, is hard to map to how we operate today. It would help to spell out concretely what is shared, what interoperates, and what obligations follow from that.
4. Verification roadmap. The note says reports will initially rely on operator honesty. If verification is planned later, we'd ask that the approach preserve confidentiality by design and that operators be consulted early.
Finally, could the authors confirm whether this proposal anticipates any changes to Canton licensing terms? If so, we'd ask that those be raised explicitly as part of this discussion.- Hi Michael.
Thanks for the feedback and for raising these points. Please see below our responses. I'm also posting the same responses to the main thread here: https://lists.sync.global/g/cip-discuss/message/882 where we posted the original proposal.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.
Please let's keep the convo in the main thread so everyone can follow.
Thanks again.