# Ethereum Improvement Proposal Charter We, the Ethereum Improvement Proposal (EIP) Editors, maintain a repository of documents related to the Ethereum protocol and its ecosystem. Consider us both _archivists_ making sure the community as a whole does not lose its history, and a _publisher_ making sure interested parties can stay up-to-date with the latest proposals. ## Mission ### What we Do Our mission is to serve the broad Ethereum community, both present and future, by: - **Publishing Proposals**: Making proposals, including their history and associated discussions available over the long term at no cost. By doing so, we foster transparency and ensure that valuable insights from past proposals are accessible for future decision-making and learning. - **Facilitating Discussion**: Providing a forum for discussing proposals open to anyone who wants to participate civilly. By encouraging open dialogue and collaboration, we aim to harness the collective knowledge and expertise of the Ethereum community in shaping proposals. - **Upholding Quality**: Upholding a measure of minimally-subjective quality for each proposal as defined by its target audience. By adhering to defined criteria, we promote the development of high-quality and relevant proposals that drive the evolution of Ethereum. ### What we Don't On the other hand, we do _not_: - **Decide Winners**: If there are multiple competing proposals, we will publish all of them. We are not in the business of deciding what is the right path for Ethereum, nor do we believe that there is One True Way to satisfy a need. - **Assert Correctness**: While we might offer technical feedback from time to time, we are not experts nor do we vet every proposal in depth. Publishing a proposal is not an endorsement or a statement of technical soundness. - **Manage**: We do not track implementation status, schedule work, or set fork dates or contents. - **Track Registries**: We want all proposals to eventually become immutable, but a registry will never get there if anyone can keep adding items. To be clear, exhaustive and/or static lists are fine. Documenting all of the things we would not do is impossible, and the above are just a few examples. We reserve the right to do less work whenever possible! ## Structure ### EIP Editors We, the Editors, consist of some number of EIP Editors and one Keeper elected by and from the EIP Editors. EIP Editors are responsible for governing the EIP process itself, electing a Keeper, and stewarding proposals in immutable statuses. The Keeper's two responsibilities (above their EIP Editor duties) are: to determine when rough consensus has been reached on a matter, and determine when/if it is appropriate to re-open an already settled matter. ### Working Groups Working Groups are semi-autonomous bodies focused on proposals related to specific topics or areas. They are bound by the policies set by the EIP Editors, but otherwise are responsible for defining their own governance, membership, and workflows. Working Groups steward proposals not in immutable statuses. EIP Editors may be members of Working Groups, though their editorship does not imply any special privilege in the Working Group. Working Groups are self-organizing, and can have their formal privileges granted or revoked by the EIP Editors as needed. Working Groups are free to separate from this organization at any time. ## Conflict Resolution Aside from defining reasonable policies, EIP Editors cannot interfere in the day-to-day running of a Working Group. ## Membership Anyone may apply to join as an EIP Editor. Specific eligibility requirements are left to individual current EIP Editors, but the general requirements are: - A strong belief in the above mission; - Proficiency with English (both written and spoken); - Reading and critiquing EIPs; - Participation in governance. EIP Editors are expected to meet these requirements throughout their tenure, and not doing so is grounds for removal. Any member may delegate some or all of their responsibilities/powers to tools and/or to other people. Membership requirements for Working Groups are defined in their respective charters. ## Making Decisions ### Informally For decisions that are unlikely to be controversial&mdash;especially for decisions affecting a single proposal&mdash;an EIP Editor may choose whatever option they deem appropriate in accordance with our mission. ### Formally Electing a Keeper, adding/removing EIP Editors, and any possibly-controversial decisions must all be made using variations of this formal process. #### Preparation ##### Call for Input For any matter requiring a decision, a call for input must be published in writing to the usual channels frequented by EIP Editors. ##### Quorum Initially, to establish a valid quorum, all EIP Editors must express their opinion (or vote where appropriate) on the matter under consideration. After thirty days from the call for input, if not all EIP Editors have responded, the quorum is reduced to the Editors that have responded. This deadline may be extended in exceptional situations. #### Deciding ##### Electing a Keeper Any EIP Editor can call for an election for Keeper. The EIP Editor with the most votes once quorum is met is named Keeper until the next election completes. If there is a tie, we'll randomly choose between the EIP Editors with the most votes. Business continues as usual while the election is running. ##### Adding an EIP Editor An EIP Editor is added once quorum is met, provided no current EIP Editor objects. ##### Removing an EIP Editor An EIP Editor is removed once quorum is met, provided no current EIP Editor (aside from the one being removed) objects. If the removed Editor was also the Keeper, an election for a new Keeper begins immediately. ##### Other Decisions All other decisions are made through a "rough consensus" process. This does not require all EIP Editors to agree, although this is preferred. In general, the dominant view of the Editors shall prevail. Dominance, in this process, is not determined by persistence or volume but rather a more general sense of agreement. Note that 51% does not mean "rough consensus" has been reached, and 99% is better than rough. It is up to the Keeper to determine if rough consensus has been reached. Every EIP Editor is entitled to have their opinion heard and understood before the Keeper makes that determination. No one, not the EIP Editors and certainly not the Keeper, holds veto powers (except when adding/removing an Editor as defined above.) It is imperative that the EIP process evolve, albeit cautiously. _This section has been adapted from [RFC 2418]._ ## Proposals ### Identifiers Proposals are assigned an identifier by the EIP Editors before being accepted into a Working Group. ### Stewardship The steward of a proposal defines the rules it must follow and is responsible for enforcing those rules. The steward is distinct from the authors of a proposal, who do the important bits, like writing the proposal in the first place. When created, a proposal is first stewarded by a Working Group. When the proposal moves into an immutable status (more on that later), it changes hands and enters the stewardship of the EIP Editors. The stewards of a proposal make sure that it is (or at least eventually becomes): - Relevant to Ethereum; - Necessary to coordinate multiple implementers; - Plausibly technically sound and implementable; - Reasonably well-written and understandable; and - Styled consistently with other proposals. Stewards may make minor changes to proposals to keep things moving smoothly, but they should not make normative changes without author consent. ### Process & Statuses Each proposal moves through several statuses as it progresses through the editorial process. Each Working Group defines the statuses for proposals relevant to their topic, and how a proposal moves between them. As alluded to earlier, there are two types of statuses: mutable and immutable. The ultimate goal of every Working Group is to have their proposals graduate to an immutable status. Mutable statuses are assigned to proposals in active development. Code review is not necessarily required for changes while in a mutable status, although individual Working Groups may mandate otherwise. Proposals in mutable statuses are stewarded by their respective Working Groups. When ready, a proposal can be moved into an immutable status. Proposals in immutable statuses do not change, except for errata and markup/formatting. These proposals are either completed and ready for use, or permanently withdrawn. Proposals in immutable statuses are stewarded by the EIP Editors, and always require code reviews. ### Content, Formatting & Metadata In addition to the requirements set out by each Working Group, all proposals must adhere to some overarching rules. #### General Notes ##### Dates & Times Whenever present, dates should be in the `yyyy-mm-dd` format. If more precision is required, use a format from [RFC 3339]. ##### Proposal References When mentioning other proposals, use the format "EIP-X" or "ERC-X" as appropriate, without the quotes. There should be a single hyphen between the prefix and the number, with no intervening white space. ##### Auxiliary Files Images, diagrams and auxiliary files should be included in a subdirectory of the `assets` folder for that proposal as follows: `assets/eip-N` (where **N** is to be replaced with the proposal's number). When linking to an auxiliary file, use relative paths such as `../assets/eip-1/image.png`. ##### Transitive Mutability Keeping a proposal immutable upon completion is an important property of the EIP process. Mentioning/linking to other proposals or external resources pokes a hole in that immutability. In practice, this means: * Proposals in immutable statuses may only mention/link to other immutable proposals; and * Proposals in mutable statues can mention/link to any other proposals. Similarly, external links (`http://...`, `doi:10.17487/RFC1034`, `The Hobbit by J.R.R. Tolkien`, etc.) should meet the requirements set out in [EIP-5757] and are approved by the proposal's Working Group. See that Working Group for more information. ##### Intellectual Property Rights All content contained within a proposal's file must be available under [CC0 1.0 Universal][cc0], and may be made additionally available under other terms. For example, content released with an SPDX ID of `CC0 OR GPL-2.0` is acceptable, while `CC0 AND GPL-2.0` is not. Auxiliary files should be made available under [CC0 1.0 Universal][cc0]. If you hold or are aware of any legal protections (copyright, patent, trademark, etc.) that might interact with a proposal, please inform the EIP Editors. We will do our best to publish this information, however we cannot guarantee its correctness or completeness. #### Preamble Each proposal must begin with an [RFC 822] style header preamble. The preamble must be preceded and followed by a single line containing three hyphens (`---`). The first seven headers must be the following, in order: `eip`, `title`, `description`, `author`, `discussions-to`, `working-group`, and `status`. Only the headers explicitly listed here and by a proposal's Working Group are permitted. Other headers shall not be present. ##### Header: `eip` A unique unsigned integer assigned by the EIP Editors as a permanent identifier for the proposal. For example: ``` eip: 1234 ``` ##### Header: `title` A short (44 octets or less) collection of words&mdash;not a sentence&mdash;identifying the proposal without too much ambiguity. Avoid variations of the word "standard", because nearly all proposals are standards of some kind. Similarly, don't include the proposal's number. For example: ``` title: Limit account nonce to 2^64-1 ``` ##### Header: `description` A full, but short (140 octets or less), sentence that conveys the essence of the proposal. Avoid variations of the word "standard", because nearly all proposals are standards of some kind. Similarly, don't include the proposal's number. For example: ``` description: Introduce an instruction which pushes the constant value 0 onto the stack. ``` ##### Header: `author` List of the author(s) of the proposal, plus their username(s) and/or email address(es). Used for notifications and access control. Those who prefer anonymity may use a pseudonym in place of a real name. The format of the `author` header value must be: > Random J. User &lt;address@example.com&gt; or > Random J. User (@username) or > Random J. User (@username) &lt;address@example.com&gt; if the email address and/or GitHub username is included, and > Random J. User if neither the email address nor the GitHub username are given. At least one author must be paired with a GitHub username. For example: ``` author: Paul Simon (@paulsimon) <paul.simon@example.com>, Art Garfunkel, Joni Mitchell (@jmitchell) ``` ##### Header: `discussions-to` Location (URL) where discussions related to the proposal can be found. This header should not change once a proposal is accepted. The preferred location for discussions is the [Ethereum Magicians] forum, though Working Groups may permit other locations that have a proven history of availability, openness, and the ability to continue the discussion after long periods of inactivity (unlike, for example, Reddit.) For example: ``` discussions-to: https://ethereum-magicians.org/t/example/12345 ``` ##### Header: `working-group` The identifier of the Working Group originally stewarding a proposal. For example: ``` working-group: Core ``` ##### Header: `status` Where the proposal sits in the EIP process. See the proposal's Working Group documentation for permitted values. For example: ``` status: Final ``` #### Body Proposal content must be formatted with Markdown, specifically CommonMark as registered in [RFC 7764] with some extensions. ## Editors ### Current See the [List of EIP Editors][editors]. ### Emeritus We thank the following Editors for their time and effort over the years: - Casey Detrio (@cdetrio) - Hudson Jameson (@Souptacular) - Martin Becze (@wanderer) - Micah Zoltu (@MicahZoltu) - Nick Johnson (@arachnid) - Nick Savers (@nicksavers) - Vitalik Buterin (@vbuterin) ## History This document was derived heavily from Bitcoin's [BIP 1] written by Amir Taaki which in turn was derived from Python's [PEP 1]. In many places text was simply copied and modified. Although the PEP 1 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Ethereum Improvement Process, and should not be bothered with technical questions specific to Ethereum or the EIP Process. Please direct all comments to the EIP Editors. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md). [editors]: https://github.com/ethereum/EIPs/blob/master/config/eip-editors.yml [Ethereum Magicians]: https://ethereum-magicians.org/ [EIP-5757]: https://eips.ethereum.org/EIPS/eip-5757 [RFC 822]: https://www.rfc-editor.org/rfc/rfc822 [RFC 2418]: https://www.rfc-editor.org/rfc/rfc2418 [RFC 3339]: https://www.rfc-editor.org/rfc/rfc3339 [RFC 7764]: https://www.rfc-editor.org/rfc/rfc7764 [BIP 0001]: https://github.com/bitcoin/bips [PEP 1]: https://peps.python.org/ [cc0]: https://creativecommons.org/publicdomain/zero/1.0/legalcode
Last changed by  
 
SamWilsn
313
Published on HackMD