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.