| CIP | Title | Status | Category | Authors | Implementors | Discussions | Created | License | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 |
Cardano Improvement Proposals |
Active |
Meta |
|
N/A |
2020-03-21 |
CC-BY-4.0 |
A Cardano Improvement Proposal (CIP) is a formalised design document for the Cardano community and the name of the process by which such documents are produced and listed. A CIP provides information or describes a change to the Cardano ecosystem, processes, or environment concisely and in sufficient technical detail. In this CIP, we explain what a CIP is; how the CIP process functions; the role of the CIP Editors; and how users should go about proposing, discussing and structuring a CIP.
The Cardano Foundation intends CIPs to be the primary mechanisms for proposing new features, collecting community input on an issue, and documenting design decisions that have gone into Cardano. Plus, because CIPs are text files in a versioned repository, their revision history is the historical record of significant changes affecting Cardano.
CIPs aim to address two challenges mainly:
-
The need for various parties to agree on a common approach to ease the interoperability of tools or interfaces.
-
The need to propose and discuss changes to the protocol or established practice of the ecosystem.
The CIP process does not by itself offer any form of governance. For example, it does not govern the process by which proposed changes to the Cardano protocol are implemented and deployed. Yet, it is a crucial, community-driven component of the governance decision pipeline as it helps to collect thoughts and proposals in an organised fashion. Additionally, specific projects may choose to actively engage with the CIP process for some or all changes to their project.
A CIP is, first and foremost, a document which proposes a solution to a well-defined problem. Documents are Markdown files with a Preamble and a set of pre-defined sections. CIPs authors must abide by the general structure, though they are free to organise each section as they see fit.
The structure of a CIP file is summarised in the table below:
| Name | Description |
|---|---|
| Preamble | Headers containing metadata about the CIP (see below). |
| Abstract | A short (~200 word) description of the proposed solution and the technical issue being addressed. |
| Motivation: why is this CIP necessary? | A clear explanation that introduces a proposal's purpose, use cases, and stakeholders. If the CIP changes an established design, it must outline design issues that motivate a rework. For complex proposals, authors must write a Cardano Problem Statement (CPS) as defined in CIP-9999 and link to it as the Motivation. |
| Specification | The technical specification should describe the proposed improvement in sufficient technical detail. In particular, it should provide enough information that an implementation can be performed solely based on the design outlined in the CIP. A complete and unambiguous design is necessary to facilitate multiple interoperable implementations. This section must address the Versioning requirement unless this is addressed in an optional Versioning section. If a proposal defines structure of on-chain data it must include a CDDL schema. |
| Rationale: how does this CIP achieve its goals? | The rationale fleshes out the specification by describing what motivated the design and what led to particular design decisions. It should describe alternate designs considered and related work. The rationale should provide evidence of consensus within the community and discuss significant objections or concerns raised during the discussion. It must also explain how the proposal affects the backward compatibility of existing solutions when applicable. If the proposal responds to a CPS, the 'Rationale' section should explain how it addresses the CPS and answer any questions that the CPS poses for potential solutions. |
| Path to Active | Organised in two sub-sections (see Path to Active for detail): Describes what are the acceptance criteria whereby a proposal becomes 'Active'. Either a plan to meet those criteria or N/A if not applicable. |
| optional sections | May appear in any order, or with custom titles, at author and editor discretion: Versioning: if Versioning is not addressed in Specification References Appendices Acknowledgements |
| Copyright | The CIP must be explicitly licensed under acceptable copyright terms (see below). |
Note Each of these section titles (Abstract onward) should be an H2 heading (beginning with markdown
##). Subsections like Versioning or Acceptance Criteria should be H3 headings (e.g.### Versioning). Don't include a H1 title heading (markdown#): for web friendly contexts, this will be generated from the Preamble.
Each CIP must begin with a YAML key:value style header preamble (also known as front matter data), preceded and followed by three hyphens (---).
| Field | Description |
|---|---|
CIP |
The CIP number (without leading 0), or "?" before being assigned |
Title |
A succinct and descriptive title. If necessary, use a - delimiter to begin with an applicable classification (see Naming CIPs with similar subjects). |
Status |
Proposed | Active | Inactive (..reason..) |
Category |
One of the registered categories covering one area of the ecosystem. |
Authors |
A list of authors' real names and email addresses (e.g. John Doe [email protected]) |
Implementors |
A list of implementors committed to delivering an implementation of the proposal, when applicable. N/A when not applicable and [] when there's currently no implementor. |
Discussions |
A list of links where major technical discussions regarding this CIP happened. Links should include any discussion before submission, and must include a link to the pull request that created the CIP and any pull request that modifies it. |
Solution-To |
A list of CPS that this CIP addresses, if any. Omitted when not applicable. |
Created |
Date created on, in ISO 8601 (YYYY-MM-DD) format |
License |
Abbreviation of an approved license(s) |
For example:
---
CIP: 1
Title: Cardano Improvement Proposals
Status: Active
Category: Meta
Authors:
- Frederic Johnson <[email protected]>
- Sebastien Guillemot <[email protected]>
- Matthias Benkort <[email protected]>
- Duncan Coutts <[email protected]>
Implementors: N/A
Discussions:
- https://github.com/cardano-foundation/cips/pulls/1
Created: 2020-03-21
License: CC-BY-4.0
---Note A reference template is available in .github/CIP-TEMPLATE.md
A CIP must be stored in a specific folder named after its number (4-digit, left-padded with 0) and in a file called README.md. Before a number is assigned, a placeholder folder name should be used (e.g. CIP-my-new-feature). After a number has been assigned, rename the folder.
Additional supporting files (such as diagrams, binary specifications, dialect grammars, JSON schemas etc.) may be added to the CIP's folder under freely chosen names.
For example:
CIP-0010
├── README.md
├── registry.json
└── registry.schema.json
While CIPs are mainly technical documents meant to be read primarily by developers -- and thus often written in English; some may be translated into various languages to increase their outreach. Any file in a CIP folder may also include translated content satisfying the following rules:
-
Any translated file shall share a common basename with its original source.
-
Translation file basenames must have a suffix using an ISO 639-1 language code, separated by a dot
.character. (e.g.README.fr.md). -
When no language code is provided as suffix, the default language for the document is assumed to be English (UK/US).
-
Translated CIPs (i.e.
READMEfiles), must not include the original preamble. They must, however, include the following preamble as yaml frontmatter data:
| Field | Description |
|---|---|
CIP |
The CIP number (without leading 0) |
Source |
The canonical GitHub link to the original CIP document |
Title |
A translation of the CIP's title |
Revision |
Whenever possible, the commit hash (7 first hex-digits, e.g. 12ab34c) of the source in the main repository. If the source was not committed to the main repo, use the best known translation date in ISO format (if unknown, use the date posted in the translation's PR branch). |
Translators |
A list of translators names and email addresses (e.g. John Doe <[email protected]>) |
Language |
An ISO 639-1 code of the target language (e.g. fr) |
- Translated CIPs inherit the same licensing terms as their original sources.
CIPs must indicate how the defined Specification is versioned. Note this does not apply to the CIP text, for which annotated change logs are automatically generated and available through the GitHub UI as a history of CIP files and directories.
Authors are free to describe any approach to versioning that allows versioned alterations to be added without author oversight. Stipulating that the proposal must be superseded by another is also considered to be valid versioning.
Since this is a functional definition it would typically be in one or more subsections of the Specification, but may also be placed in an optional Versioning section.
CIPs are licensed in the public domain. More so, they must be licensed under one of the following licenses. Each new CIP must identify at least one acceptable license in its preamble. In addition, each license must be referenced by its respective abbreviation below in the "Copyright" section.
| Purpose | Recommended License |
|---|---|
| For software / code | Apache-2.0 - Apache License, version 2.0 |
| For documentation | CC-BY-4.0 - Creative Commons Attribution 4.0 International Public License |
Warning
All licenses not explicitly included in the above lists are not acceptable terms for a Cardano Improvement Proposal unless a later CIP extends this one to add them.
CIPs can have three statuses: Proposed, Active or Inactive. The CIP Process section highlights how CIPs move through these statuses; no CIP should be given one of these statuses without satisfying the criteria described here below.
Note There is no "draft" status: a proposal which has not been merged (and hence exists in a PR) is a draft CIP. Draft CIPs should include the status they are aiming for on acceptance. Typically, but not always, this will be 'Proposed'.
A 'Proposed' CIP is any CIP that meets the essential CIP criteria but is not yet 'Active'. The criteria that must meet a CIP to be merged as 'Proposed' are:
- It must contain all the sections described in Structure.
- The quality of the content must be to the Editors’ satisfaction. That means it must be grammatically sound, well-articulated and demonstrates noticeable efforts in terms of completeness and level of detail.
- Its technical soundness should have been established. Where necessary, this may require review by particular experts and addressing their concerns. Note that the requirement is that the proposal makes sense (i.e. be technically sound), yet no consulted experts need to think it is a good idea.
- It must have a valid Path to Active as defined below.
An 'Active' CIP has taken effect according to the criteria defined in its 'Path to Active' section. Said differently, each CIP defines by which criteria it can become 'Active' and those criteria are included in the review process. Exact criteria thereby depends on the nature of the CIP, typically:
- For CIPs that relate to particular projects or pieces of technology, it becomes 'Active' by being implemented and released;
- For changes to the Cardano protocol, a CIP becomes 'Active' by being live on the Cardano mainnet;
- For ecosystem standards, it means gaining sufficient and visible adoption in the community.
- It must have a valid Path to Active as defined below: even the CIP is already acknowledged as
Activeor being documented retroactively (after acceptance and implementation).
A proposal that is 'Active' is considered complete and is synonymous with "production readiness" when it comes to the maturity of a solution. 'Active' CIPs will not be updated substantially (apart from minor edits, proofreading and added precisions). They can, nevertheless, be challenged through new proposals if need be.
An 'Inactive' CIP describes any proposal that does not fit into the other types. A CIP can therefore be 'Inactive' for various reasons (e.g. obsolete, superseded, abandoned). Hence the status must indicate a justification between parentheses; for example:
Status: Inactive (superseded by CIP-0001)
This must be subdivided into two sub-sections:
-
'Acceptance Criteria'
This sub-section must define a list of criteria by which the proposal can become active. Criteria must relate to observable metrics or deliverables and be reviewed by editors and project maintainers when applicable. For example: "The changes to the ledger rules are implemented and deployed on Cardano mainnet by a majority of the network", or "The following key projects have implemented support for this standard".
-
'Implementation Plan'
This sub-section should define the plan by which a proposal will meet its acceptance criteria, when applicable. More, proposals that require implementation work in a specific project may indicate one or more implementors. Implementors must sign off on the plan and be referenced in the document's preamble.
In particular, an implementation that requires a hard-fork should explicitly mention it in its 'Implementation Plan'.
Note the statuses of
ProposedandActiveboth require a Path to Active section, making this a required section for all viable proposals. Even if a CIP is edited or submitted with anInactivestatus, it may still be helpful to have aPath to Activeif there are conditions that might lead to its acceptance or implementation.
CIPs are classified into distinct categories that help organise (and thus, find) them. Categories are meant to be flexible and evolve as new domains emerge. Authors may leave the category as ? should they not be sure under which category their proposal falls; editors will eventually assign one or reject the proposal altogether should it relate to an area where the CIP process does not apply.
At present, we consider the following list of initial categories:
| Category | Description |
|---|---|
| Meta | Designates meta-CIPs, such as this one, which typically serves another category or group of categories. |
| Wallets | For standardisation across wallets (hardware, full-node or light). |
| Tokens | About tokens (fungible or non-fungible) and minting policies in general. |
| Metadata | For proposals around metadata (on-chain or off-chain). |
| Tools | A broad category for ecosystem tools not falling into any other category. |
Additionally, projects of the ecosystem may explicitly enlist as new categories. The following section describes how projects can engage with the CIP process.
Registered categories for explicitly enlisted projects are otherwise listed below.
| Category | Description |
|---|---|
| Plutus | Changes or additions to Plutus, following the process described in CIP-0035 |
| Ledger | For proposals regarding the Cardano ledger, following the process described in CIP-0084 |
| Catalyst | For proposals affecting Project Catalyst or the Jörmungandr project, following the process described in ? |
Projects of the Cardano ecosystem that intend to follow the CIP process must explicitly enlist themselves and commit to the following:
- a) allocating time to review proposals from actors of the community when solicited by editors (i.e. after one first round of reviews);
- b) defining additional rules and processes whereby external actors can engage with their project as part of the CIP process;
- c) defining boundaries within their project for which the CIP process does apply;
- d) writing CIPs for significant changes introduced in their projects when it applies.
Enlisting for the CIP process happens by creating a CIP. That CIP must encapsulate the information listed above, as well as any other pieces of information deemed helpful to future authors. Of course, only team members of a target project can author such a proposal.
Warning A positive review by the maintainers of a project does not constitute a commitment to implement the CIP. It is still the CIP author's responsibility to create an implementation plan and identify implementors. The maintainers of the project may volunteer to participate in implementation, but also may not. Projects' maintainers ultimately define how a proposal can move from the state of idea (i.e. CIP) to actual implementation work. We, however, expect each team that enlists in the CIP process to provide clarity on these elements as they enlist.
Editors occasionally invite project maintainers to speak during review meetings and solicit them for ultimate approvals of proposals affecting a project under their authority. Said differently, CIPs that concern (part of) an enlisted project will only be merged after explicit acceptance of the enlisted reviewers.
Note Optionally, projects may show their enlisting using the following badge on their introductory README: 
](https://github.com/cardano-foundation/CIPs%5D(https://raw.githubusercontent.com/cardano-foundation/CIPs/master/.github/badge.svg)){kind=link}
Proposals must be submitted to the cardano-foundation/CIPs repository as a pull request named after the proposal's title. The pull request title should not include a CIP number (and use ? instead as number); the editors will assign one. Discussions may precede a proposal. Early reviews and discussions streamline the process down the line.
Note Proposals addressing a specific CPS should also be listed in the corresponding CPS header, in 'Proposed Solutions', to keep track of ongoing work.
When a CIP title and subject matter share a common element, begin the CIP title with that common element and end it with the specifc portion, delimited with the - character. Example (CIP-0095):
Web-Wallet Bridge - Governance
CIP editors will help determine these common elements and, whenever necessary, rename both CIP document titles and PR titles accordingly. The objective is to provide commonly recognisable names for similar developments (e.g. multiple extensions to another CIP or scheme).
In the original comment for your pull request, please include a link to the directory or the README.md for the CIP in your working branch, so readers and reviewers can easily follow your work. This makes it easier for editors and the community to read and review your proposal.
Note If this link changes (e.g. from the CIP directory being renamed), please keep this link updated.
Authors shall champion their proposals. The CIP process is a collaborative effort, which implies discussions between different groups of individuals. While editors may provide specific inputs and help reach out to experts, authors shall actively seek feedback from the community to help move their proposal forward.
Discussions and comments shall mainly happen on Github in pull requests. When discussed on other mediums, we expect authors or participants to report back a summary of their discussions to the original pull request to keep track of the most critical conversations in a written form and all in one place.
As much as possible, commenters/reviewers shall remain unbiased in their judgement and assess proposals in good faith. Authors have the right to reject comments or feedback but are strongly encouraged to address concerns in their 'Rationale' section. Ultimately, CIP editors shall make the last call concerning the various statements made on a proposal and their treatment by the author(s).
By opening pull requests or posting comments, commenters and authors agree to our Code of Conduct. Any comment infringing this code of conduct shall be removed or altered without prior notice.
CIP editors meet regularly in a public Discord server to go through newly proposed ideas in a triage phase. As a result of a triage, editors acknowledge new CIPs, and briefly review their preamble. Editors also assign numbers to newly proposed CIPs during this phase. Incidentally, the triage allows new CIPs to get visibility for potential reviews.
In every meeting, editors will also review in more depth some chosen CIPs (based on their readiness and the stability of the discussions) and assess if they meet the criteria to be merged in their aimed status.
During review sessions, editors will regularly invite project maintainers or actors from the ecosystem who are deemed relevant to the meeting's agenda. However, meetings are open and held in public to encourage anyone interested in participating.
A dedicated Discord channel may also be created for some long-running discussions to support quick chats and progress on particular topics (while still being regularly summarised on the repository).
Once a proposal has reached all requirements for its target status (as explained in Statuses) and has been sufficiently and faithfully discussed by community members, it is merged with its target status.
Warning Ideas deemed unsound shall be rejected with justifications or withdrawn by the authors. Similarly, proposals that appear abandoned by their authors shall be rejected until resurrected by their authors or another community member.
CIPs are generally merged with the status 'Proposed' until they meet their 'Path to Active' requirements. In some rare cases (mainly when written after the facts and resulting in a broad consensus), proposals may be merged as 'Active' immediately.
Each proposal is unique and has a bespoke 'Path to Active', which must be reviewed case-by-case. There must be sufficient time between the first appearance of a proposal and its merge into the repository to ensure enough opportunity for community members to review it.
Once merged, implementors shall execute the CIP's 'Implementation Plan', if any. If a proposal has no implementors or no 'Implementation Plan', it may simply remain as 'Proposed' in the repository.
Warning It is perfectly fine to submit ideas in the repository with no concrete implementation plan, yet they should be treated as such: ideas.
Besides, once all of the 'Path to Active' requirements have been met, authors shall make another pull request to change their CIP's status to 'Active'. Editors may also do this on occasion.
CIP Editors safeguard the CIP process: they form a group enforcing the process described in this document and facilitating conversations between community actors. CIP editors should strive to keep up to date with general technical discussions and Cardano proposals. For each new draft proposal submitted on cardano-foundation/CIPs an editor might review it as follows:
- Read the proposal to check if it is ready, sound, and complete.
- Check if it has been properly formatted.
- Check if sufficient time has been allowed for proper discussion amongst the community.
- Ensure the motivation behind the CIP is valid and that design choices have relevant justifications or rationale.
- Confirm licensing terms are acceptable.
- Assign a CIP number
- Assign a given category to help with searching
- Request wording/grammar adjustments
CIPs that do not meet a sufficient level of quality or don't abide by the process described in this document will be rejected until their authors address review comments.
Note that editors may provide technical feedback on proposals in some cases, although they aren't expected to be the sole technical reviewers of proposals. CIPs are, before anything, a community-driven effort. While editors are here to facilitate the discussion and mediate debates, they aren't necessarily technical experts on all subjects covered by CIPs.
Therefore, CIPs authors are encouraged to reach out to known experts to demonstrate their good faith and openness when they champion a proposal. Editors may help with such efforts but cannot be expected to do this alone.
Existing editors or the community may nominate new editors, provided they have proven to be already existing and active contributors to the CIP process and are ready to commit some of their time to the CIP process regularly.
The missions of an editor include, but aren't exclusively limited to, any of the tasks listed above. Active members that seek to become listed editors may also come forth and let it be known. Any application will take the form of a pull request updating this document with a justification as the pull request's description.
Current editors are listed here below:
| Matthias Benkort @KtorZ |
Sebastien Guillemot @SebastienGllmt |
Robert Phair @rphair |
Ryan Williams @Ryun1 |
Adam Dean @Crypto2099 |
|---|
A significant friction point regarding complex CIPs is often how the main problem is stated. The 'Motivation' is often insufficient (or simply underused) to describe various aspects of a problem, its scope, and its constraints. This lack of clarity leads, in the end, to poorly defined issues and debates over solutions that feel unclear amongst different participants.
The introduction of CIP-9999: Cardano Problem Statements addresses this gap by introducing a formal template and structure around problem statements. However, requiring any CIP to be preceded by a CPS would likely be overkill and become an obstacle to the overall adoption of the CIP process for more straightforward problems. At this stage, it is reasonable to think either (a) that CIP authors would foresee the complexity and state their problem as a CPS beforehand or (b) that editors or reviewers will require authors to write a CPS to clarify a perhaps ambiguous motivation on complex CIPs.
We also anticipate project maintainers or community actors will write standalone CPS to document well-known issues for which the design space is still to be explored.
A recurring pain point with the previous CIP process was the lack of clear ownership/accountability of some proposals affecting remote parts of the ecosystem. On several occasions, proposals from community members have concerned, for example, core components of the Cardano architecture. However, those proposals have been hard to move forward with and to either reject or turn into concrete action steps. Authors usually do not have the technical proficiency required to implement them and rely on the core engineering team in charge of projects to do so. Thus, explicit compliance and collaboration of those engineering teams are necessary to propose changes affecting their work.
By asking teams to explicitly state their compliance with the CIP process with clear, accountable owners (as individuals), it becomes plausible to now establish a dialogue between community members and technical leadership responsible for specific ecosystem projects. Furthermore, projects that, on the contrary, do not seek to participate in CIP or receive contributions in the form of CIP/CPS are automatically taken out of this process, saving time and energy for both reviewers and authors.
The 'Editors' section now details how to become a CIP editor. The process aims to be simple and define those involved the most with editorship tasks as editors. Thus, being an active contributor to the CIP process as a prerequisite only makes sense. We want to leave the room open for either existing editors to refer an existing community as an editor or for community members to formulate that request explicitly.
There are no delays or number of contributions necessary to pretend to become an editor. Those criteria are often less relevant than others and more subjective, such as the quality of one's participation or their relevance. Since editors also need to work with one another in the end, it seems logical that existing editors have their final say about whom they intend to work with.
The type field in the header has shown to be:
- confusing (often authors are getting it wrong);
- not-too-useful (as a
typetells you very little about the nature of the CIP).
An ad-hoc classification by non-rigid categories, which may evolve over time to reflect ecosystem areas, seems better suited. Therefore, we do not require authors to categorise their CIPs; instead, categories will be added and maintained by editors as a side task atop the CIP process.
Over time we've learnt that the valuable information a status should convey is really about the readiness of a CIP, especially regarding standards. For a long time, many CIPs have lived as Draft despite some being used in dozens of systems. Consequently, the status has lost a bit of its meaning. The frontier between Draft and Proposed hasn't always been clear, and it has proven challenging to come up with good statuses to describe all possible rejections. So instead, the current division of statuses is as simple-as-it-can-be and remains flexible regarding rejections.
The choice of a code of conduct follows other popular open source initiatives. It serves as a good, unilaterally accepted foundation which can be later revisited if necessary.
-
The proposal has been reviewed by the community and sufficiently advertised on various channels.
- Cardano Forum
- IOG Technical Community Discord
- Cardano Summit 2022
- IO ScotFest 2022
-
All major concerns or feedback have been addressed. The document is as unambiguous as it can be and it outlines a process that a supermajority of reviewers is happy to follow.
- Rework existing draft CIPs to adopt this new format and process. In particular, CIPs affecting enlisted projects should be brought to the attention of the respective project maintainers.
- Edit / align old CIPs preambles and sections to at least reflect also this new format.
This CIP is licensed under CC-BY-4.0.