📜 Canto Improvement Proposal (CIP) Template & Process

Hey folks :wave:

I wanted to get a start on exploring process and templates to continue the momentum around Canto Improvement Proposals (CIPs). The goal is to keep things simple to promote Canto’s unique position to iterate rapidly and attract developer talent. Bureaucracy must be avoided!


Canto has proven itself as a leader in economic experiments and moving quickly on improvements of shared concern with other EVM networks, like CIP-1 and the introduction of Contract Secured Revenue to protocol deployers. Notably, CSR has already inspired improvements to the Ethereum L2, Optimism, and might be just the beginning of a positive feedback loop with other developer ecosystems.

There are many cool things to try out with Canto, both native (e.g., building around CSR and protocols-as-public-goods mentality of network) and complimentary, such as being a testing ground for upgrades in the docket for Ethereum, like EIP-3074 as proposed to CIP-2.

To simplify onboarding to make new CIPs and iterate going forward, let’s discuss:

(1) Where should CIPs be made?

Right now there is a separate repository for CIPs started by
zscole apart from the other active Canto organization on GitHub. While this is different than the more consolidated Ethereum project approach, it seems easiest to continue this way, as well as more decentralized. I wanted to flag this point in any case for feedback.

(2) How should CIPs be made?

Using PRs and chronological numbering seems easiest to model after EIP process — it should probably be our collective understanding that the CIP process integrates meta like EIP-1 but with its own custom template and fast track (see below). So, the first PR related to Canto network improvements (i.e., not just changing local docs) is marketed as CIP-1, numbered with three digits as CIP-001 in the repository.

Within a new CIP PR, I have suggested a form of CIP template modeled on CIP-1, which is simpler than the form used for EIPs.

(3) How should CIPs be reviewed and finalized?

Before a formal PR is made for a CIP, it makes the most sense (socially) to begin discussion in this Forum. This is why it is included by default in the CIP template.

If a PR is made and requires validators and greater Canto DAO to implement at protocol level (i.e., Core), it should not be merged unless so accepted by governance. If the PR and CIP relate to the Canto application layer, such as a CRC or contract interface standard, it should be merged after 2-of-3 editors give approval. Editors should apply a high level of technical understanding in performing their CIP review, as well as consider the needs of broader Canto developers and products — to this end, and to avoid cold start issues, editors should initially be selected by zscole as maintainer of CIP repository.

Hopefully this all makes sense and can provide some discussion to smooth CIP process and keep things moving. The particulars are not so terribly important as just getting something down.


Hey Ross, thanks for kicking things off! I’m generally in favor of continuing in the spirit of what we’ve done within the Ethereum community (thank you to all who have contributed and continue to contribute) and have used that as a model for future experiments within the Canto network. As all networks should, let us strive for inclusivity. Making the process of contribution easier on those who would like to participate should be our primary goal.

A couple things I’d also like to add that may not be directly related to this thread and may sound totally lame; if anyone needs resources to get things going, please don’t hesitate to reach out! We’re here for you!

We’re also all in this together, so let’s make sure to be good models for one another as we all strive for excellence!

That being said, what are the best ways to ensure effective coordination between contributors?


Hello Ross, amazing first post here ser.

I’m not of technical BG… to answer @zscole question of potential best ways; one thing comes to mind trying to make effective coordination between contributors is having as much integration with GitHub as possible. (ie sign-in via github…).

Of course it could expand on other potential plugins that could help…


Thanks for adding thoughts @zscole @pujimak!

I definitely agree with making sure CIPs are inclusive. I think the simple format of using template and making PR to CIP repo should make this easy for contributors to access.

Thoughts on merging the template?

1 Like

An update on this process:

I am currently drafting a document that outlines my ideas regarding best practices for core development workflow. I will be circulating this document for community feedback and review as soon as it is complete. Hoping to have it done tonight.

For those in the community that are interested, it would also be helpful if you took some notes or shared your ideas here regarding the above subject. Thank you!


Yeah, let’s merge this. Considering consolidating in a larger repo as well.


Cool cool. Look forward to checking the process doc.


So, I’ve completed this doc, but decided to turn it into a website. I will share with you shortly. If you, or anyone else, is interested in collaborating in this regard, please DM me on Telegram and I can share the draft for review.


The document to which I was referring in the previous post has been turned into this website; the sourcecode for which can be viewed in the CPIC GitHub organization. Open for feedback or suggestions regarding further structure.

We’re going to start holding public core dev calls in the coming weeks.

1 Like