跳到主要内容

CIP Categories

We have six categories for CIP.

Core

Improvements that require a consensus fork, as well as those that aren't necessarily consensus-critical but might be relevant to "core dev" discussions.

Networking

This includes improvements related to devp2p and Light Core Subprotocol, as well as proposed enhancements to the network protocol specifications of Whisper and Swarm.

Interface

This category involves improvements around client API/RPC specifications and standards. It also includes certain language-level standards, such as method names and contract ABIs. The label “interface” aligns with the [interfaces repo], and discussions should primarily take place in that repository before a CIP is submitted to the CIPs repository.

CBC

Application-level standards and conventions, including contract standards like token standards, name registries, URI schemes, library/package formats, and wallet formats.

Informational

This describes a Core design issue or provides general guidelines or information to the Core community. It doesn't propose a new feature. Informational CIPs don't necessarily represent the consensus of the Core community or a recommendation. Thus, users and implementers can either heed or ignore Informational CIPs.

Meta

This describes a process related to Core or suggests a change to (or an event in) a process. Process CIPs resemble Standards Track CIPs but pertain to areas other than the Core protocol. They might propose an implementation, but not to the Core's codebase. Often, they require community consensus. Unlike Informational CIPs, they are more directive, and users typically can't ignore them. Examples include procedures, guidelines, changes to the decision-making process, and alterations to the tools or environment utilized in Core development. All meta-CIPs are also deemed Process CIPs.


It's strongly advised that a single CIP should encompass just one primary proposal or idea. The more concise a CIP is, the more likely it is to succeed. A modification to one client doesn't mandate a CIP. However, a change that impacts multiple clients or sets a standard for various apps does.

A CIP must meet certain essential criteria. It should clearly and comprehensively describe the proposed enhancement. This enhancement should represent a net benefit. If there's a suggested implementation, it needs to be robust and must not unduly complicate the protocol.