PIPs

Pie Improvement Proposals (PIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards.

Contributing

First review PIP-1. Then clone the repository and add your PIP to it. There is a template PIP here. Then submit a Pull Request to Ethereum's PIPs repository.

PIP status terms

• Draft - an PIP that is open for consideration and is undergoing rapid iteration and changes.
• Last Call - an PIP that is done with its initial iteration and ready for review by a wide audience.
• Accepted - a core PIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode an PIP into their clients as part of a hard fork is not part of the PIP process. If such a decision is made, the PIP will move to final.
• Final (non-Core) - an PIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author.
• Final (Core) - an PIP that the Core Devs have decided to implement and release in a future hard fork or has already been released in a hard fork.

PIP Types

PIPs are separated into a number of types, and each has its own list of PIPs.

Standard Track (0)

Describes any change that affects most or all Ethereum 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 Ethereum. Furthermore Standard PIPs can be broken down into the following categories.

Core (0)

Improvements requiring a consensus fork (e.g. PIP5, PIP101), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, the miner/node strategy changes 2, 3, and 4 of PIP86).

Networking (0)

Includes improvements around devp2p (PIP8) and Light Ethereum Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.

Interface (0)

Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (PIP6) and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before an PIP is submitted to the PIPs repository.

PRC (0)

Application-level standards and conventions, including contract standards such as token standards (PRC20), name registries (PRC137), URI schemes (PRC681), library/package formats (PIP190), and wallet formats (PIP85).

Meta (1)

Describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process PIPs are like Standards Track PIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational PIPs, 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 Ethereum development. Any meta-PIP is also considered a Process PIP.

Informational (0)

Describes a Ethereum design issue, or provides general guidelines or information to the Ethereum community, but does not propose a new feature. Informational PIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational PIPs or follow their advice.