Back to Homepage
Canton’s CIPs explained: the upgrades that keep the network evolving
TECHNOLOGYANALYSIS

Canton’s CIPs explained: the upgrades that keep the network evolving

Canton’s proposal history runs from early reward adjustments to shared token standards, development funding and Universal Burn. The key milestones show how the network changes its rules and why approval is only one step.

6 min read

A selected history of Canton’s proposals and approvals, checked through October 25, 2026 at 14:59 UTC. Approval milestones are distinct from software rollout and application adoption.

Canton has a documented way to change its rules. A token standard can gain new settlement features; a reward policy can acquire an enforcement mechanism; a funding decision can be followed by rules for choosing and paying projects. Those steps are recorded in Canton Improvement Proposals, or CIPs.

The history shows how the network responds to new requirements. A common token interface gave wallets and applications a shared way to handle assets. A later version addresses more complex privacy and custody arrangements. The newer proposal builds on what came before, while preserving ways for existing integrations to keep working.

An early history of revision

The public records reach back to proposals created in December 2023. CIP-0001 and CIP-0002 were approved on January 26, 2024, covering early Super Validator reward and tokenomics changes. Super Validators are the operators responsible for the Global Synchronizer, the shared service that helps Canton applications coordinate transactions.

Revision was part of that early work. CIP-0002 and its subsequent refinement, CIP-0008, are now marked “Replaced”. CIP-0020, another refinement of CIP-0002, is marked “Final”. The record preserves earlier decisions as well as their successors.

The formal process document, CIP-0000, was approved on March 3, 2025, after those earlier decisions. Its motivation explains that growing participation required a more transparent and consistent alternative to the previous ad hoc process.

Selected CIP approval milestones

  • January 26, 2024: CIP-0001 / 0002. Early reward and tokenomics adjustments.
  • March 3, 2025: CIP-0000. Formal proposal and decision process.
  • March 31, 2025: CIP-0056. Common token interfaces for wallets, issuers and applications.
  • September 15, 2025: CIP-0078. Removal of specific CC transfer fees and changes to holding-fee handling.
  • October 1, 2025: CIP-0082. A development fund receiving 5% of future CC minting.
  • March 2 / May 20, 2026: CIP-0105 / CIP-0116. Locking policies for Super Validators and Featured Apps.
  • June 5 / June 12, 2026: CIP-0117 / CIP-0112. Logical Synchronizers and token standard V2.
  • October 23, 2026: CIP-0127 / CIP-0129. Locking implementation and Universal Burn framework approvals.

Selected Canton approvals by year: rewards and tokenomics in 2024; proposal process, token standards and development funding in 2025; locking, token standard V2 and the Universal Burn framework in 2026. Approval and rollout are separate.

Selected approval milestones, rather than a timetable for every deployment. Sources: the linked CIP records and October 23 approval announcement. Exact dates and implementation conditions are explained in the text. Checked through October 25, 2026 at 14:59 UTC.

Why CIP-0056 is a cornerstone

For connecting assets, wallets and applications, CIP-0056 stands out. Its importance is practical: a wallet or exchange can work with common interfaces instead of depending on the internal design of every asset issuer. This is an assessment of its role in interoperability, rather than an official ranking of all CIPs.

The standard covers holdings, direct transfers and allocating assets for settlement. An allocation reserves assets for a particular transaction. Once the required allocations are present, an application can complete the security and payment transfers together, so one side does not settle without the other.

That common language gives developers a basis for reusable integrations. Issuers retain control over their asset workflows and permissions; supporting an interface does not remove an asset’s eligibility rules.

The June 2026 approval of CIP-0112 shows how that foundation can develop. Token standard V2 adds more flexible settlement, privacy for multi-party transactions and support for custody chains, where intermediaries maintain accounts between an issuer and the final owner. Compatibility arrangements let V1 and V2 coexist, although older integrations do not automatically gain every V2 capability.

The changes extend beyond token standards

CIP-0078 addressed an everyday source of complexity: fees attached to CC transfers and their accounting. It set specified CC fees to zero and changed how holding fees were handled when coins were transferred. Network traffic still has a cost. Simplifying the token’s transfer rules and paying for network capacity are different parts of the operating model.

CIP-0082 established a fund equal to 5% of future CC mint emissions, taken proportionally from the existing issuance streams. It reallocates planned issuance rather than adding another 5% on top. CIP-0100 then set out governance for that fund. The resulting Development Fund process connects priorities such as security, infrastructure and developer tools with proposals, review and accountable delivery.

Other proposals make the network easier to operate. Logical Synchronizers under CIP-0117 keep a stable connection identity while the underlying synchronizer infrastructure changes. Its upgrade design replaces earlier dump-and-restore migrations with a successor running alongside the existing system. Applications can experience a shorter switchover pause, while some network administration changes still need a longer freeze.

A policy can need a second proposal to work in practice

The locking framework for Super Validators and Featured Apps provides another example. CIP-0105 and CIP-0116 established capital commitments for different network roles. CIP-0127 specifies the on-ledger machinery for operating and enforcing those commitments.

The implementation also refines the policies. It temporarily suspends underlocked Featured App rights, with a grace period before permanent removal, and defines how ownership and permissions can change while funds remain locked. The official October 23 approval notice records ten votes in favour and three non-votes. The migration windows depend on the required software increments reaching MainNet, Canton’s production network. Approval alone does not start every migration clock.

Two examples of specifications building on earlier rules: CIP-0056 shared token interfaces followed by CIP-0112 privacy and custody refinements; CIP-0105 and CIP-0116 commitment rules followed by CIP-0127 operations and enforcement.

Two examples of proposals building on earlier specifications. Sources: CIP-0056, CIP-0112, CIP-0105, CIP-0116 and CIP-0127. Approval of a specification and adoption by a particular application are separate stages.

Universal Burn shows the next stage of economic coordination

The official October 23 notice for CIP-0129 records approval with 13 votes in favour. The Universal Burn framework would bring production traffic on dedicated synchronizers into the CC burn-and-reward economy, alongside the Global Synchronizer. Dedicated systems have historically paid licence fees instead.

The approved framework leaves further work to do. Universal Burn requires implementation and a deployment vote. A second CIP is intended to set out the detailed pricing curve, discounts and initial parameters. The proposal separates agreement on the direction from the later decisions needed to run it. It does not change the issuance schedule or reward split, and broader fee coverage does not establish a future CC price or guarantee that burns exceed minting.

How change remains open, but coordinated

CIPs cover standards, governance, tokenomics and processes for the Global Synchronizer. Any member of the public can write a proposal and join discussion. A proposal needs Super Validator sponsorship and endorsement to reach a vote. Designated representatives of Super Validator rights owners cast the votes; approval requires a two-thirds majority in favour. Changes requiring on-chain adoption then need the relevant implementation steps. Smaller software fixes can follow the individual project’s normal development process.

A new requirement can therefore lead to a revision, a replacement or a follow-on proposal. The earlier decision remains visible, along with the reason for changing it. That gives Canton a way to improve its design without expecting its original rules to anticipate every future use case.

For readers following the next CIP, three details are especially useful: what problem it addresses, what earlier rule it changes and what must happen before it takes effect. Those details turn a proposal number into a clear account of how the network is developing.

Sources: the public CIP repository, the CIP process specification and the October 23 Universal Burn and locking implementation approval notices. Individual specifications are linked beside each milestone.

Have a question about this story?
Ask CantonNews AI for context, its impact on the Canton ecosystem, or the latest related news.
Explore Further
Developer ResourcesExplore Daml, CIP-56 & Zenith →Canton Learning Hub46 Q&As from beginner to expert →