Every blockchain makes promises about decentralization. Few spell out exactly how decisions get made. Canton Network does. Every protocol change, every tokenomics adjustment, every governance rule modification goes through a single documented process, open to anyone, with no shortcuts and no veto power for any single entity. That process is the Canton Improvement Proposal, or CIP.
With more than 117 CIPs approved to date, the system has a track record. This is how it works.
What a CIP Actually Is
A Canton Improvement Proposal is a formal design document. It describes a change to the network — technical, governance, or otherwise — in enough detail that independent teams could implement it and arrive at compatible results. The format is deliberately structured: every CIP requires a preamble with metadata, an abstract, a motivation section explaining why the current state is inadequate, a precise specification, a rationale covering design decisions and rejected alternatives, a backwards compatibility analysis, and for Standards Track proposals, a reference implementation.
That level of rigor is intentional. Vague proposals lead to extended debate and inconsistent implementation. The CIP format forces authors to answer the hard questions before the community has to ask them.
CIPs fall into five categories. Standards Track proposals cover technical specifications and protocol changes that affect how the Global Synchronizer operates. Governance proposals define or modify Super Validator rights and voting rules. Tokenomics proposals cover Canton Coin fees, reward structures, and traffic pricing. Process proposals adjust workflows and meta-level rules. Informational proposals offer guidelines and recommendations without carrying binding effect. The category determines the required discussion period and the path to approval.
Who Can Submit
Anyone. That is not a marketing line. Any member of the public can author a CIP, join the cip-discuss mailing list at lists.sync.global, and begin the process. In practice, authors include Super Validator operators, application developers, and ecosystem contributors, but the process imposes no gatekeeping on who can propose a change.
That said, not everything requires a CIP. Small improvements to a specific software project go through that project's own development workflow. A CIP is warranted when a change affects interoperability across validators, modifies governance rules, alters tokenomics parameters, or establishes a network-wide standard that multiple parties must implement. If the scope is unclear, the cip-discuss list is the right place to ask before investing in a full proposal.
The Five Steps
Once an idea is ready to become a formal proposal, it moves through a defined sequence.
The first step is drafting. The author writes the proposal and submits it as a pull request to the public CIP repository on GitHub. At this stage, the proposal uses a descriptive alias rather than an official number. Discussion happens through GitHub comments, the cip-discuss mailing list, and relevant community channels. Authors should expect substantive feedback and be prepared to revise. The discussion period has minimum durations tied to category: Standards Track proposals require three months of community discussion given their potential impact on protocol behavior. Governance and Tokenomics proposals require one month each. Process proposals require one month. Informational proposals require two weeks.
The second step is working group review. Depending on scope, the relevant working group — Tokenomics, Technical, or Governance — evaluates the proposal against operational and ecosystem requirements. This is where expert scrutiny happens before the broader Super Validator set is asked to vote. The working group can recommend the proposal as written, suggest modifications, or reject it at this stage.
The third step is sponsorship and formal submission. To move from discussion to a formal vote, the author needs sponsorship from two Super Validators. Sponsorship is not an endorsement of the proposal's content. It signals that at least two SV operators consider the proposal worth putting to a network-wide vote. With sponsorship secured and the discussion period satisfied, a CIP editor assigns the official sequential number in the four-digit zero-padded format the network uses, CIP-0000 through CIP-0117 and counting, and the proposal moves to the cip-vote mailing list.
The fourth step is the Super Validator vote. All 55 Super Validators vote through the SV governance interface. The voting window lasts 10 days. Approval requires a two-thirds supermajority of Super Validator rights holders voting in favor. No single entity holds veto power. A proposal that fails to reach the threshold can be revised and resubmitted, or withdrawn.
The fifth step is implementation. An approved CIP does not take effect the moment the vote closes. For proposals requiring on-chain changes, Super Validators must adopt the change through an on-chain governance action. A CIP reaches Final status only after two-thirds of Super Validators have implemented the change on-chain, moving through DevNet first, then TestNet, then MainNet. This two-phase structure separates design consensus from operational commitment, ensuring that approved proposals are actually deployed before becoming authoritative. On-chain implementation status is publicly verifiable through the Canton Coin Scan APIs.
What Happens to Proposals That Do Not Pass
Not every CIP reaches Final status. A proposal can be withdrawn by its author at any point during the process. It can be deferred for future consideration if the timing is not right. It can be rejected outright if it fails to achieve the two-thirds threshold. It can also be replaced by a later proposal that supersedes it. CIP-0073, for example, was replaced by CIP-0096, which refined the validator reward model it had introduced. The status of every CIP is tracked publicly in the repository.
Some CIPs Worth Knowing
The range of issues the process has addressed illustrates how much ground it covers.
CIP-0056, the Canton Network Token Standard, defines six standardized APIs for token operations covering metadata, holdings, peer-to-peer transfers, and delivery-versus-payment settlement. If you are building a token on Canton, this is the specification you implement. It has since been significantly extended by CIP-0112, which introduced Token Standard V2 with privacy-enhanced batch settlement, traditional custody chain support, and committed allocations for prefunded trading, while maintaining full backwards compatibility.
CIP-0078 eliminated transaction fees on Canton Coin transfers. The change was viable because approximately 95% of MainNet burn already came from traffic purchases rather than transfer fees, simplifying developer workflows without meaningfully affecting network economics.
CIP-0103, the dApp Standard, specifies a vendor-neutral API that decouples network connectivity and key management from application logic, allowing any dApp to work with any wallet implementation. It is the standard that wallets like Loop, Send Connect, and others build against.
CIP-0117, approved in June 2026, introduced Logical Synchronizers, replacing the multi-hour coordinated network halts previously required for protocol upgrades with an automated switchover that takes seconds. Prior upgrade procedures required a live coordination call across all Super Validator operators, migration dump exports, and manual deployment steps from every validator. CIP-0117 moved coordination on-chain and made protocol evolution a routine operation.
Why This Matters
Institutional participants evaluating blockchain infrastructure need to understand not just what a network can do today, but how it will change over time and who controls that process. A network where changes happen through undocumented decisions, or where a small group of insiders can push through modifications without community scrutiny, carries a different risk profile than one with an open, documented governance process.
Canton's answer to that question is 117 numbered proposals, a public GitHub repository, documented voting rules, a two-thirds supermajority requirement, and no single entity with the power to override the process.
The full CIP repository is available at github.com/canton-foundation/cips
