Cardano CIPs: the written record of how the protocol changes

CIP-0001 is the process, not a proposal

A Cardano Improvement Proposal is a formalised design document for the Cardano community, and the name of the process by which such documents are produced and listed. That second half matters, because the repository holds both the proposals and the machinery that governs them.

CIP-0001 is the CIP process itself. The README describes what that document contains: 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.

So the design of the repository is a self describing one. The first numbered document explains the rules, and every other numbered document is an instance of them. The README also frames the intent, saying 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.

The last clause is the one that matters for an engineer reading the tree. These are not proposals in flight, they are the record of decisions that have already been made and shipped. CIP-0009 is the protocol parameters for the Shelley era, CIP-0028 does the same for Alonzo and CIP-0055 for Babbage. A developer implementing against the chain reads these as the specification, and the same document is the proposal that justified the change.

The status column tells you whether a document still governs

Every entry in the index table carries a status, and the vocabulary is small: Active, Proposed and Inactive. There is no draft state and no rejected state in the listing, which is itself informative about how the process works.

Active means the document describes the current, accepted behaviour of the ecosystem. Proposed means the document has been written and submitted but has not completed review, so it describes an intent rather than a reality. Inactive means the document was once in force and is not any more.

Looking at the list makes the lifecycle visible. CIP-0002 on coin selection algorithms is Active, CIP-0003 on wallet key generation is Active, CIP-0005 on common Bech32 prefixes is Active, CIP-0019 on Cardano addresses is Active, and CIP-0016 on cryptographic key serialisation formats is Active. CIP-0004 on wallet checksums is Proposed, and CIP-0012 on stake pool operator to delegate communication is Proposed. CIP-0017 on the delegation portfolio is Inactive, and CIP-0058 on Plutus bitwise primitives is Inactive.

That last pair is the useful signal. A protocol that evolves will supersede parts of its own specification, and the Inactive marker is how a reader knows which document to stop reading. For an implementer, the Active set is the list of documents that matter, and the Proposed set is the roadmap of what will soon change under them.

The subjects in the table also show the range. Beyond protocol parameters, there are metadata standards such as the transaction metadata label registry and the media token metadata standard, key and address formats, the Cardano URI scheme, the dApp-Wallet web bridge, Plutus topics such as the contract blueprint, Plutus Core evolution and script type uniformization, and operational proposals such as transaction serialization deprecation and the chain ID registry.

Problem Statements sit beside the proposals as a second type

The repository holds a second document type. A Cardano Problem Statement is a formalised document for the Cardano ecosystem, with its own process, its own numbering space and its own entry in the tree, CIP-9999, and a template of its own in .github/CPS-TEMPLATE.md.

The README says CPSs are meant to complement CIPs and live side by side in the CIP repository as first-class citizens. That is the whole description, and it is a deliberate design choice rather than a missing section.

The distinction that follows from it is a separation of concerns in the governance process. A Problem Statement is a statement of a problem, and it is the natural first artefact for someone who knows that something is wrong but does not yet know what the fix is. A CIP is the design document that proposes a change, and it is the artefact that has to carry enough technical detail for the ecosystem to implement it.

For a contributor, this means the point of entry depends on how much you know. If you can describe the problem but not the solution, a CPS is the document type that fits, and it is filed in the same repository under the same process so that the discussion history is not split across two places.

How a proposal actually travels

The process described in the README has a visible path, and it is worth following in order because the first step is not a pull request.

Ideas are extended or discussed in the Developer Forums, in Cardano's official Developer Telegram Group, or in the developers channel in the Cardano Ambassadors Slack. The CIP Editors facilitate the discussions and progress the submissions on GitHub, and they review progress in bi-weekly meetings held on Discord, which are open to the public. The Discord server also has channels for developer working groups to discuss details and implementations of selected CIPs.

So the sequence is discussion first, then a document, then review, and the review is a scheduled and public event rather than a private exchange. A proposal that nobody has argued about in the forum is unlikely to move.

The templates make the submission step mechanical. The README points at .github/CIP-TEMPLATE.md as a reference template for new CIPs and .github/CPS-TEMPLATE.md for new Problem Statements, and a contributor following that path gets the same section structure as everything already merged.

For non-GitHub readers, the README notes that an auto-generated site is provided at cips.cardano.org, which is also the homepage recorded in the repository metadata. That last point is a genuine accessibility decision: a specification that most implementers will never open a repository for is a specification half its audience will miss.

Text files in version control are the historical record

The README gives a reason for the format that is easy to miss. Because CIPs are text files in a versioned repository, their revision history is the historical record of significant changes affecting Cardano.

That is a deliberate argument for markdown over a database, a document platform or a wiki. A proposal that is a text file in git has a diff, an author and a date for every change, and a change to a specification that altered the meaning of a consensus rule would show up in the history the same way a code change does.

The repository layout follows the same logic. Each proposal is its own top level directory, CIP-0001 through CIP-0080 and beyond, plus a BiweeklyMeetings directory for the editors' meeting material and a .github directory holding the templates and the repository configuration.

There is also a Wiki tab, linked from the README, which the description places as the place to read about the human factors of the CIP process and how to get involved. The separation is sensible. The repository holds the artefacts, the wiki holds the process guidance, and the forum holds the arguments that produced them.

The licence is CC-BY-4.0, a Creative Commons attribution licence, which is the right category for a set of prose specifications, and it is worth noting that the repository publishes no GitHub releases, because the artefacts are numbered directories rather than versioned packages.

An active trunk with a very large numbering space

The maintenance picture is simple. The repository is not archived and the last push was on 2026-10-22, so the tree is being worked on, and it publishes no GitHub releases because a CIP is identified by its number, not by a version tag.

The default branch is master, which is the convention for the project, and the numbering is shared with the Problem Statements, so CIP-9999 is the problem statement process and the CIP numbers are the proposal space. The highest numbers visible in the index are in the 0090s, and the numbering has gaps, since the table jumps from CIP-0089 to CIP-0091 and then to CIP-0093, CIP-0094 and CIP-0095. Numbers that are not in the table are either withdrawn, superseded, or in another state that the index does not record, and the README does not explain the gaps.

The subjects in the recent numbers give a good sense of where the protocol is heading. CIP-0093 covers authenticated Web3 HTTP requests, which is about how a wallet identifies a caller to an application. CIP-0095 covers the Web-Wallet bridge for the Conway ledger era, a follow-on to the bridge work in CIP-0030. CIP-0089 covers distributed dApps and beacon tokens, and CIP-0084 covers Cardano ledger evolution, which sits on top of the Plutus contract blueprint in CIP-0057.

For a team building on Cardano, the practical use of this repository is narrow and important. The Active documents are the specification you implement against, the Proposed ones are the changes coming, and the Inactive ones tell you which parts of your current implementation are already historical.

Editorial conclusion

Adopt the CIP process if you are proposing a change to the Cardano ecosystem, a protocol parameter, a metadata format or a wallet standard, because the repository is where that change has to be described before it can be implemented. Do not adopt it as a place to argue about implementation details that a protocol update already covers, since the CIPs record design decisions rather than day to day engineering. Verify first which status the proposals you care about are in, since Active, Proposed and Inactive carry different weight, whether the CIP Editors have a bi-weekly meeting slot your topic fits, and that the template you use is the current one, because the repository has a .github directory with separate templates for each document type.

Frequently asked questions

Official sources

1. cardano-foundation/CIPs on GitHub
2. Issues
3. License: CC-BY-4.0
4. Project website
5. README