CIP Work Flow

Parties involved in the process are you, the champion or CIP author, the CIP editors, and the Core Developers.

⚠️ Before you begin, vet your idea, this will save you time. Ask the Core community first if an idea is original to avoid wasting time on something that will be be rejected based on prior research (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Core is used. Examples of appropriate public forums to gauge interest around your CIP include Core Talk, Subreddit, the Issues section of this repository, and Discord chat. In particular, the Issues section of this repository is an excellent place to discuss your proposal with the community and start creating more formalized language around your CIP.

Your role as the champion is to write the CIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea. Following is the process that a successful CIP will move along:

[ WIP ] -> [ DRAFT ] -> [ LAST CALL ] -> [ ACCEPTED ] -> [ FINAL ]

Each status change is requested by the CIP author and reviewed by the CIP editors. Use a pull request to update the status. Please include a link to where people should continue discussing your CIP. The CIP editors will process these requests as per the conditions below.

Other exceptional statuses include:

What belongs in a successful CIP?

Each CIP should have the following parts:

CIP Formats and Templates

CIPs should be written in markdown format. Image files should be included in a subdirectory of the assets folder for that CIP as follow: assets/images/cip-X (for cip X). When linking to an image in the CIP, use relative links such as ../assets/images/cip-X/image.png.

CIP Header Preamble

Each CIP must begin with an RFC 822 style header preamble, preceded and followed by three hyphens (---). The headers must appear in the following order. Headers marked with 🔸 are optional and are described below. All other headers are required.

cip: (this is determined by the CIP editor)

title:

author: <a list of the author’s or authors’ name(s) and/or username(s), or name(s) and email(s). Details are below.>

🔸 discussions-to:

status: <Draft | Last Call | Accepted | Final | Active | Deferred | Rejected | Superseded>

🔸 review-period-end: YYYY-MM-DD

type: <Standards Track (Core, Networking, Interface, CRC) | Informational | Meta>

🔸 category: <Core | Networking | Interface | CRC>

created: <date created on, in ISO 8601 (yyyy-mm-dd) format>

🔸 requires: <CIP number(s)>

🔸 replaces: <CIP number(s)>

🔸 superseded-by: <CIP number(s)>

🔸 resolution:

Author header

The author header optionally lists the names, email addresses or usernames of the authors/owners of the CIP. Those who prefer anonymity may use a username only, or a first name and a username. The format of the author header value must be:

John Doe <[email protected]>

or

Richard Roe (@raisty)

if the email address or GitHub username is included, and

Janie Doe

if the email address is not given.

Note: The resolution header is required for Standards Track CIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the CIP is made.

While an CIP is a draft, a discussions-to header will indicate the mailing list or URL where the CIP is being discussed. As mentioned above, examples for places to discuss your CIP include Core Talk, Subreddit, the Issues section of this repository, and Discord chat. No discussions-to header is necessary if the CIP is being discussed privately with the author.

The type header specifies the type of CIP: Standards Track, Meta, or Informational. If the track is Standards please include the subcategory (core, networking, interface, or CRC).

The category header specifies the CIP’s category. This is required for standards-track CIPs only.

The created header records the date that the CIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-05-31.

CIPs may have a requires header, indicating the CIP numbers that this CIP depends on.

CIPs may also have a superseded-by header indicating that an CIP has been rendered obsolete by a later document; the value is the number of the CIP that replaces the current document. The newer CIP must have a Replaces header containing the number of the CIP that it rendered obsolete.

Headers that permit lists must separate elements with commas.

Auxiliary Files

CIPs may include auxiliary files such as diagrams. Such files must be named CIP-XXXX-Y.ext, where “XXXX” is the CIP number, “Y” is a serial number (starting at 1), and “ext” is replaced by the actual file extension (e.g. “png”).

Transferring CIP Ownership

It occasionally becomes necessary to transfer ownership of CIPs to a new champion. In general, we’d like to retain the original author as a co-author of the transferred CIP, but that’s really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the CIP process, or has fallen off the face of the ‘net (i.e. is unreachable or isn’t responding to email). A bad reason to transfer ownership is because you don’t agree with the direction of the CIP. We try to build consensus around an CIP, but if that’s not possible, you can always submit a competing CIP.

If you are interested in assuming ownership of an CIP, send a message asking to take over, addressed to both the original author and the CIP editor. If the original author doesn’t respond to email in a timely manner, the CIP editor will make a unilateral decision (it’s not like such decisions can’t be reversed :)).

Copyright and related rights waived via CC0.