Core Improvement Proposal (CIP) describe standards for the Core platform, including core protocol specifications, client APIs, and contract standards.
First you can open your proposal under issues of this repository as well as discussion in Core talk.
- Fork this repository
- Change template CIP-0 and move it to CIP folder
- Submit a Pull Request to Core's CIP repository
Put any graphical content into CIP image directory under your cip-x (x is the cip number).
CIP status terms
- Draft - a CIP that is open for consideration.
- Accepted - a CIP that is planned for immediate adoption, i.e. expected to be included in the next hard fork (for Core/Consensus layer CIPs).
- Final - a CIP that has been adopted in a previous hard fork (for Core/Consensus layer CIPs).
- Deferred a CIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork.
CIPs are separated into a number of types, and each has its own list of CIPs.
Standard Track Σ2
Describes any change that affects most or all Core implementations, such as a change to the the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Core. Furthermore Standard CIPs can be broken down into the following categories.
Improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions.
Includes improvements around devp2p, network protocol specifications of whisper and swarm.
Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before a CIP is submitted to the CIPs repository.
Application-level standards and conventions, including contract standards such as token standards, name registries, URI schemes, library/package formats and wallet formats.
Describes a Core design issue, or provides general guidelines or information to the Core community, but does not propose a new feature. Informational CIPs do not necessarily represent Core community consensus or a recommendation, so users and implementers are free to ignore Informational CIPs or follow their advice.
Describes a process surrounding Core or proposes a change to (or an event in) a process. Process CIPs are like Standards Track CIPs but apply to areas other than the Core protocol itself. They may propose an implementation, but not to Core's codebase; they often require community consensus; unlike Informational CIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Core development. Any meta-CIP is also considered a Process CIP.
forumCore Talk discordCore Coin redditr/CoreCoinCC
feedLast call feedActive feedAccepted feedFinal feedDraft feedDeferred