Grams Improvement Proposals

The goal behind GIP is to standardize and provide high-quality documentation for Grams itself and conventions built upon it. This repository tracks past and ongoing improvements to Grams in the form of Grams Improvement Proposals (GIPs). GIP-1 governs how GIPs are published.

Contributing

1. Review GIP-1.
2. Clone the repository and add your GIP to it. There is a template GIP here.
3. Submit a Pull Request to Grams's GIPs repository.

GIP status terms

• Idea - An idea that is pre-draft. This is not tracked within the GIP Repository.
• Draft - The first formally tracked stage of an GIP in development. An GIP is merged by an GIP Editor into the GIP repository when properly formatted.
• Review - An GIP Author marks an GIP as ready for and requesting Peer Review.
• Last Call - This is the final review window for an GIP before moving to FINAL. An GIP editor will assign Last Call status and set a review end date (last-call-deadline), typically 14 days later. If this period results in necessary normative changes it will revert the GIP to Review.
• Final - This GIP represents the final standard. A Final GIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.
• Stagnant - Any GIP in Draft or Review if inactive for a period of 6 months or greater is moved to Stagnant. An GIP may be resurrected from this state by Authors or GIP Editors through moving it back to Draft.
• Withdrawn - The GIP Author(s) have withdrawn the proposed GIP. This state has finality and can no longer be resurrected using this GIP number. If the idea is pursued at later date it is considered a new proposal.
• Living - A special status for GIPs that are designed to be continually updated and not reach a state of finality. This includes most notably GIP-1.

GIP Types

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

Core (220)

Improvements requiring a consensus fork (e.g. GIP-5, GIP-211), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, the PoA algorithm for testnets described in GIP-225).

Networking (15)

Includes improvements around devp2p (GIP-8) and Light Grams Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.

Interface (48)

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

ERC (338)

Application-level standards and conventions, including contract standards such as token standards (GIP-20), name registries (GIP-137), URI schemes (GIP-681), library/package formats (GIP-190), and account abstraction (GIP-4337).

Meta (22)

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

Informational (7)

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