The Cardano Improvement Proposal (CIP) process is the formal governance mechanism for creating and maintaining the voluntary, off-chain standards that ensure interoperability across the Cardano ecosystem. Unlike on-chain protocol parameter changes governed by CIP-1694, the CIP process is a social and editorial governance system managed by a community editor group within the CIP GitHub repository. It defines the lifecycle for proposals covering everything from token metadata (CIP-25) and wallet-dApp communication (CIP-30) to identity primitives and transaction serialization. For builders, wallet teams, and exchanges, the CIP process is the primary venue for shaping the technical standards that determine how applications, assets, and users interact on Cardano.
Cardano Improvement Proposal (CIP) Process and Lifecycle
The Governance of Cardano Standards
How the Cardano community proposes, edits, and ratifies the off-chain standards that define ecosystem interoperability.
A CIP progresses through a defined lifecycle: Proposed, Draft, Active, or Rejected (with intermediate states like Last Call for final community review). The path from an initial idea to an Active standard requires meeting editorial criteria for formatting and technical soundness, building rough consensus within the community, and demonstrating working implementations. The CIP editor group—composed of community volunteers—is responsible for merging proposals, managing the repository, and adjudicating editorial disputes, but they do not unilaterally ratify standards. This separation of editorial stewardship from technical authority means that a CIP's adoption ultimately depends on ecosystem implementers choosing to support it, creating a market-driven standards dynamic that differs from binding on-chain governance.
For teams proposing new standards, navigating the CIP process requires understanding the editorial workflow, the expectations for reference implementations, and the practical path to achieving Active status. Proposals that lack clear motivation, fail to engage relevant stakeholders, or do not demonstrate a path to adoption often stall in Draft indefinitely. Chainscore Labs helps protocol teams, wallet providers, and enterprises navigate this process by providing technical drafting support, community engagement strategy, and implementation planning to move proposals efficiently from idea to ecosystem adoption.
CIP Process Quick Facts
Operational facts about the Cardano Improvement Proposal process to help teams navigate the standards lifecycle, from drafting to activation or rejection.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Proposal Status | A CIP transitions through Draft, Proposed, Active, or Rejected status based on community editor review and ecosystem adoption signals. | Proposal authors, wallet teams, dApp builders, and exchanges tracking emerging standards. | Verify the current status of a CIP against the official repository before committing to an implementation. |
Community Editors | A group of community editors manages the CIP repository, enforces formatting, and judges proposal readiness for advancement. | Authors seeking to propose a new standard; teams relying on CIPs for integration roadmaps. | Engage editors early for proposal feedback. Teams should monitor editor decisions for signals on standard viability. |
Draft to Proposed | A Draft CIP must meet editorial criteria for completeness, clarity, and community support before being merged as Proposed. | Protocol architects and product leads planning feature rollouts dependent on a CIP. | Do not build production systems against Draft CIPs. Wait for Proposed status and conduct an independent review of the specification. |
Path to Active | A Proposed CIP becomes Active through demonstrable ecosystem adoption, not a formal on-chain vote. This is a social consensus process. | Wallet providers, exchanges, and DeFi protocols deciding when to support a new standard. | Monitor adoption signals from major ecosystem players. A Chainscore adoption readiness review can help assess the risk of early support. |
Rejection and Stagnation | CIPs can be Rejected by editors or become stagnant if authors do not advance them. Rejected CIPs should not be implemented. | Teams that have built prototypes or integrations against a now-rejected CIP. | Audit your dependency list for Rejected or Stagnant CIPs. Plan migration away from any standard that loses community consensus. |
Relationship to On-Chain Governance | CIPs define off-chain standards. On-chain governance actions under CIP-1694 are required to change protocol parameters or enact hard forks. | Governance platforms, DReps, and SPOs coordinating off-chain standards with on-chain votes. | Do not confuse CIP status with on-chain enactment. A CIP may be Active as a standard but still require a governance action for protocol-level changes. |
Repository Management | The CIP repository on GitHub is the canonical source of truth. Changes to a CIP after it is Active require a new proposal or a formal amendment process. | All integration teams, auditors, and compliance officers referencing CIPs. | Pin your integrations to a specific CIP commit hash. Monitor the repository for amendments that may affect your implementation. |
The CIP Lifecycle and Repository Mechanics
How a Cardano Improvement Proposal moves from idea to active standard through community editors and a public repository.
The Cardano Improvement Proposal (CIP) process is the off-chain governance mechanism for voluntary ecosystem standards. Unlike on-chain protocol upgrades governed by CIP-1694, the CIP lifecycle is managed through a GitHub repository (cardano-foundation/CIPs) and a group of community editors who enforce formatting, clarity, and progression rules. This process defines how standards for token metadata (CIP-25), wallet-dApp communication (CIP-30), and identity primitives are formally proposed, debated, and adopted.
A CIP progresses through distinct statuses: Proposed, Draft, Active, or Rejected. The Proposed status indicates a new idea under initial review by editors. Draft signals that the proposal has met structural requirements and is open for community refinement. Active status is reserved for standards that have achieved broad ecosystem adoption and are considered stable. Crucially, Active does not require on-chain ratification; it reflects real-world implementation by wallets, explorers, and dApps. A CIP can also be Rejected or marked as Inactive if it is superseded or abandoned.
For builders, the repository mechanics dictate how to structure a proposal using the CIP template, which requires a clear abstract, motivation, and specification. The editors act as gatekeepers for technical soundness and document quality, not as a central standards body. This means a CIP's path to Active depends on building consensus among implementers. Teams proposing new standards must navigate this social layer, and a common failure mode is a well-specified CIP that stalls due to insufficient coordination with wallet providers or DApp developers who would need to adopt it.
Operators and integrators should monitor the CIP repository for changes to standards they depend on, such as new versions of the wallet connector or asset metadata schemas. A CIP moving to Active can signal that an integration pattern is mature, while a move to Inactive may indicate a deprecated approach. Chainscore Labs assists teams in drafting CIPs, reviewing proposals for technical completeness, and assessing the ecosystem readiness required for a standard to progress from Draft to Active.
Who Is Affected by the CIP Process
Builders & DApp Teams
DApp developers are the primary consumers of CIPs. Standards like CIP-30 (dApp-Wallet Web Bridge) and CIP-68 (Datum Metadata) directly dictate how frontends interact with wallets and how smart contracts manage on-chain state.
Impact:
- Integration Architecture: A new standard can require a complete redesign of transaction construction logic, especially in the eUTXO model.
- Competitive Edge: Early adoption of a standard like CIP-68 for NFTs can differentiate a project, but requires careful migration planning.
- Compatibility Risk: Ignoring active CIPs can lead to broken integrations when wallets or indexers upgrade their default behaviors.
Action: Before starting a new build, audit the relevant CIPs in "Proposed" or "Active" status. Chainscore Labs can review your architecture for standard compliance and identify integration risks before they reach production.
Impact Areas for Builders and Operators
The CIP process is the entry point for all off-chain standards on Cardano. Understanding its lifecycle and editorial governance is critical for teams proposing new standards or implementing existing ones.
Proposal Lifecycle Management
A CIP progresses through well-defined statuses: Proposed, Draft, Active, or Rejected. Builders must understand the editorial review gates, community feedback expectations, and the path to 'Active' status. Proposing a standard without a clear champion or failing to address editor feedback is the most common reason for stagnation. Teams should assign a dedicated owner to shepherd the proposal through the entire lifecycle, ensuring it meets the formatting and technical soundness criteria required by the CIP editors.
Editorial Governance and Repository Mechanics
The CIP process is governed by a community editor group, not an on-chain vote. Editors manage the CIP GitHub repository, enforce the template, and decide when a proposal is ready to merge. For builders, this means the primary interface is a pull request. Understanding the review conventions, the role of the CIP editor meeting, and the distinction between 'Last Check' and 'Stale' labels is essential to avoid administrative rejection. Teams should treat the editor group as a technical review board, not a general governance body.
Path to Active and Ecosystem Adoption
Reaching 'Active' status does not guarantee ecosystem adoption. It signals that the standard is stable and has a reference implementation. For wallet providers, dApps, and explorers, the real work begins here. Teams must monitor which CIPs become de facto requirements for interoperability, such as CIP-30 for dApp connections. Operators should establish an internal process to track CIPs moving from 'Proposed' to 'Active' and assess the integration cost and security implications of each new standard on their product roadmap.
CIP Categories and Scope Boundaries
CIPs are organized into categories like Wallets, Tokens, and Metadata. Understanding these boundaries prevents proposal rejection. A change requiring a hard fork combinator event is not a CIP; it is a protocol parameter change under on-chain governance. Builders must correctly classify their proposal to route it to the right reviewers. Misalignment between the standard's scope and the CIP process is a critical failure mode that delays technical progress. Teams should validate their idea against the existing CIP taxonomy before drafting.
Interaction with On-Chain Governance
With the Voltaire era, the line between off-chain standards (CIPs) and on-chain governance actions (CIP-1694) is critical. A CIP may define the metadata format for a governance action, but the action itself is ratified on-chain. Builders of governance tools must integrate both systems: pulling proposal rationale from a CIP's off-chain JSON while verifying the binding vote on-chain. Confusing these two domains creates security risks where a front-end displays a rationale that does not match the on-chain intent.
Backward Compatibility and Migration Risks
New CIPs can deprecate or conflict with existing active standards. For example, CIP-68 introduces a new asset metadata pattern that differs from CIP-25. Operators must assess whether adopting a new standard requires a migration of existing user assets, a dual-support period, or a breaking change in wallet interfaces. A Chainscore Labs impact assessment can map the dependencies between CIPs in your stack and identify the operational risks of adopting a new standard before it reaches widespread ecosystem consensus.
Process and Governance Risks
Identifies the informal governance risks, bottlenecks, and coordination failures inherent in the off-chain CIP process that can delay standards adoption or create ecosystem fragmentation.
| Area | Failure mode | Who is affected | Mitigation |
|---|---|---|---|
Editor Bottleneck | A small group of community editors controls merging and progression; proposals can stall indefinitely if editors are unresponsive or lack domain expertise. | Proposal authors, wallet teams, DApp builders | Socialize proposals widely before submission; seek pre-review from domain experts; monitor CIP repository activity for editor availability. |
Status Stagnation | Proposals remain in 'Proposed' status for years without clear signals of rejection or acceptance, creating uncertainty for implementers. | Wallet providers, exchanges, DeFi protocols | Do not build against a CIP until it reaches 'Active' status; verify implementation momentum independently of CIP status. |
Competing Standards | Multiple CIPs may address the same problem (e.g., metadata, royalties) without a formal process for selection or deprecation, fragmenting the ecosystem. | Marketplaces, wallet teams, token issuers | Audit which standard has dominant ecosystem adoption before committing; monitor CIP repository for competing proposals. |
Informal Consensus | Progression from 'Proposed' to 'Active' relies on rough ecosystem consensus rather than on-chain signaling, leading to ambiguity about when a standard is truly adopted. | Exchanges, custodians, governance platforms | Track implementation status across major wallets and explorers as the real signal of activation; do not rely solely on CIP status labels. |
No Binding Rejection | There is no formal mechanism to reject or deprecate a CIP; abandoned proposals remain in the repository, confusing new developers. | New ecosystem entrants, integration engineers | Check latest commit dates and community discussion threads to gauge proposal vitality; maintain an internal list of deprecated or abandoned CIPs. |
Governance Capture | Well-resourced entities could dominate the editorial process or steer standards toward proprietary interests, undermining the voluntary, community-driven model. | Protocol architects, governance delegates, risk teams | Monitor editor diversity and participation; support community funding for independent editors; escalate concerns via Cardano Foundation or Intersect channels. |
CIP-1694 Interaction | The off-chain CIP process is separate from on-chain Voltaire governance; a CIP may define a standard that conflicts with or is superseded by an on-chain governance action. | Governance platform builders, DReps, SPOs | Cross-reference active CIPs with on-chain governance actions; ensure governance tooling can handle conflicts between off-chain standards and on-chain rules. |
Authoring and Navigation Checklist
A practical checklist for teams preparing to author a new Cardano Improvement Proposal or navigate an existing one through the lifecycle. Each item identifies a critical signal that confirms the proposal is ready for the next stage of community review and adoption.
Before drafting, confirm that no existing CIP already solves the same problem or that your proposal meaningfully extends a prior standard.
- What to check: Search the CIPs repository for related proposals in
CIP-XXXX/directories. Review theREADME.mdindex for active, proposed, and rejected CIPs. - Why it matters: Duplicate or overlapping proposals fragment the ecosystem and slow adoption. A new CIP must demonstrate a clear gap or a superior approach.
- Readiness signal: You can articulate in one paragraph how your CIP differs from the closest existing standard, with links to the specific CIPs it supersedes or complements.
Canonical Resources
Use these canonical sources to verify CIP status, review lifecycle rules, track editor activity, and plan implementation work against accepted Cardano standards.
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
Frequently Asked Questions
Practical answers for teams navigating the Cardano Improvement Proposal lifecycle, from initial drafting through community review and final status assignment.
Begin by socializing the idea in the Cardano developer community (Discord, forums, or developer calls) to gauge interest and gather early feedback. Once the concept is refined, fork the CIPs repository and draft your proposal using the standard template. The template requires a clear abstract, motivation, and specification. Submit a pull request with your draft marked as 'Proposed.' At this stage, the CIP editors will review it for formatting and completeness, not technical merit. Teams should ensure their specification is unambiguous and testable before submission to avoid early rejection.
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.