Pull work back from ethereum/EIPs

.github/actions/merge-repos/action.yml

@@ -19,6 +19,6 @@ runs:
         cd $GITHUB_WORKSPACE/EIPS
         find . -name "erc-*.md" -type f -exec sh -c 'echo mv "$1" "$(echo "$1" | sed s/erc/eip/)"' _ {} \; | sh
         cd $GITHUB_WORKSPACE/assets
-        find . -name "erc-*" -type d -exec sh -c 'echo mv "$1" "$(echo "$1" | sed s/erc/eip/)"' _ {} \; | sh
+        find . -depth -name "erc-*" -type d -exec sh -c 'echo mv "$1" "$(echo "$1" | sed s/erc/eip/)"' _ {} \; | sh
         cd $GITHUB_WORKSPACE
         rm -rf ERCs

CONTRIBUTING.md

@@ -0,0 +1,130 @@
+# EIP Contribution Guidelines
+
+This document outlines how authors, contributors, and editors can collaborate effectively in the [Ethereum Improvement Proposals (EIPs)](https://eips.ethereum.org/) repository. 
+The goal is to keep contributions consistent, transparent, and easy to review - while respecting the authors’ intent.
+
+## For EIP Authors
+
+> You are listed as an author in the EIP header.
+
+### Do’s
+
+#### Text
+
+* Avoid mentioning specific commercial products.
+* Don't use [RFC 2119](https://www.ietf.org/rfc/rfc2119.html) keywords (all-caps SHOULD/MUST/etc.) outside of the specification section.
+* Prefer "on-chain" and "off-chain" when appearing before the noun they describe, and "on chain" or "off chain" when appearing after. 
+* Do not include punctuation at the end of headings (so no `# Example A:`, but `# Example A`).
+* Titles should be in title case: "In Title Case only Important Words are Capitalized".
+* Descriptions should be in sentence case: "Only the first word and proper nouns like Jupiter are capitalized".
+* Do not use articles (the/a/an/etc.) in front of EIP identifiers (so not "an ERC-20"), unless the EIP identifier is used as an adjective/compound noun (so "an ERC-20 token" is fine.)
+* Initialisms should be written in uppercase (eg. "NFT" instead of "nft".)
+* Only use backticks (\`) for code snippets.
+* Avoid single paragraph sentences and sections containing only bulleted lists.
+* Put abbreviations after the expanded form (so liquidity provider (LP) and not LP (liquidity provider).)
+* Use [example domains](https://en.wikipedia.org/wiki/Example.com) in examples, not real services.
+* It's "Ethereum", not "the Ethereum".
+* Unless you're writing a fork meta EIP, don't include fork activation criteria (eg. timestamp/epoch).
+
+#### Diagrams
+
+* Prefer SVG, but PNG is acceptable.
+* If possible, use [media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Media_queries/Using) (specifically prefers-color-scheme) to support dark mode. If not, provide light-mode compatible images.
+
+#### Other
+
+* **Monitor feedback regularly**: Respond to comments or PRs that relate to your EIP, especially specification clarifications or typo fixes.
+* **Acknowledge helpful community edits**: You don’t need to merge every PR yourself, but a short confirmation (“LGTM”) helps editors move things forward.
+* **Communicate before major revisions**: If changing motivation, specification, or rationale, explain reasoning in the PR or linked issue (recommended).
+* **Keep contact details up to date**: Editors use your listed email or GitHub for coordination; please keep them valid.
+* Draft pull requests prevent automatic merges and are effective in gauging agreement among authors.
+
+### Don’ts
+
+TBA.  
+
+## For Contributors (Non-Authors)
+
+> You are contributing to an existing EIP you did not author - to fix typos, formatting, or clarify technical descriptions.
+
+### Do’s
+
+* **Add in PR Description**  
+   Explain the purpose and scope - e.g., “Fixing typos in EIP-1559” or “Updating broken link in EIP-4844.”
+* **Make objective, non-semantic edits.**
+   Acceptable edits include:
+   * Typo, grammar, and style corrections 
+   * Markdown and formatting fixes 
+   * Broken or outdated link replacements 
+   * Small clarifications (e.g., referencing a spec or renaming variables for clarity)
+
+> Note: Non-authors may, and are often encouraged to, submit subjective or substantive pull requests; however, such changes require explicit approval from the EIP authors before they can be merged.
+>
+> Once an EIP reaches Final status, pull requests should be limited to objective, non-semantic edits only (for example, corrections to grammar, formatting, or references). The restrictions described above apply exclusively to EIPs in Final status.
+>
+> For EIPs that have not yet reached Final, contributors are welcome to open any relevant pull requests. Contributors should expect active review and potential pushback from the EIP authors, as the proposal may still be evolving.
+
+* **Cite authoritative sources.** 
+   When clarifying or aligning text, link to:
+   * [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) 
+   * [Consensus Specs](https://github.com/ethereum/consensus-specs) 
+   * Relevant client implementation notes
+* **Work with the authors.** 
+   Use `@username` for all listed authors, and if possible, connect with the author when making this PR.
+* **Keep PRs focused.** 
+   Only one EIP per PR and one topic per change (e.g., typo fix, link fix, or formatting fix - not multiple at once).
+* **Use clear PR titles.**  
+   Examples:
+   * “Fix typo in EIP-1559 rationale section.”  
+   * “Update broken link to EIP-1 reference.”  
+   * “Clarify \`gasUsed\` variable in EIP-4844 spec”
+
+### Don’ts
+
+* Don’t change semantics, logic, or intent.  
+* Don’t move or renumber EIPs.  
+* Don’t alter author metadata or statuses without the permission of existing authors.  
+
+## For Editors & Reviewers
+
+> Editors manage review and merging of EIP PRs. Their role is to maintain process integrity and consistency.
+
+### Do’s
+
+* **Check ownership and status.**  
+   * Authors, co-authors & champion can request status changes. 
+   * Confirm that non-author edits are non-semantic and author-approved if applicable.
+* **Enforce structure and format.**  
+   * Confirm all required header fields match [EIP-1](https://eips.ethereum.org/EIPS/eip-1).  
+   * Validate Markdown rendering, metadata, and links.
+* **Require author acknowledgment for community PRs.**  
+    * For content edits, ensure the author acknowledges or confirms changes before merging.
+    * In case the author is non-responsive (for over 2 weeks) and the change is trivial or approved by 2 editors, the PR can be merged to update an EIP without the author's approval. 
+* **Apply clear labels.**
+To clarify the merge blocker if needed, add applicable labels.  
+* **Communicate clearly.**  
+   If unclear, request additional context before rejecting or closing a PR.
+* **Maintain clean commit history.**  
+   Squash redundant commits and check that links, formatting, and front matter are valid.
+* **Handle typo-only PRs pragmatically.**  
+   * If a typo or formatting PR is approved by at least one editor and no author response is received within two weeks,  
+     it may be merged at the editor’s discretion.  
+   * This ensures small maintenance fixes don’t remain blocked indefinitely.
+
+### Don’ts
+
+* Don’t merge substantive changes without author approval.  
+* Don’t alter author list, status, or numbering silently.  
+* Don’t override the author’s technical intent or interpretation.  
+
+### Thank You
+
+Your contributions help maintain the integrity and accessibility of Ethereum’s open-source governance process.  
+Together, we make the protocol and its documentation stronger, clearer, and more collaborative.
+
+## References
+
+* [EIP-1: EIP Purpose and Guidelines](https://eips.ethereum.org/EIPS/eip-1) 
+* [EIP-5069: EIP Editor Handbook](https://eips.ethereum.org/EIPS/eip-5069)
+
+

EIPS/eip-1.md

@@ -15,13 +15,13 @@ EIP stands for Ethereum Improvement Proposal. An EIP is a design document provid
 
 We intend EIPs to be the primary mechanisms for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into Ethereum. Because the EIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
 
-For Ethereum implementers, EIPs are a convenient way to track the progress of their implementation. Ideally each implementation maintainer would list the EIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or library.
+For Ethereum implementers, EIPs are a convenient way to track the progress of their implementation. Ideally, each implementation maintainer would list the EIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or library.
 
 ## EIP Types
 
 There are three types of EIP:
 
-- A **Standards Track EIP** describes any change that affects most or all Ethereum implementations, such as—a change to 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. Standards Track EIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the [formal specification](https://github.com/ethereum/yellowpaper). Furthermore, Standards Track EIPs can be broken down into the following categories:
+- A **Standards Track EIP** describes any change that affects most or all Ethereum implementations, such as: a change to 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. Standards Track EIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the [formal specification](https://github.com/ethereum/yellowpaper). Furthermore, Standards Track EIPs can be broken down into the following categories:
   - **Core**: improvements requiring a consensus fork (e.g. [EIP-5](./eip-5.md), [EIP-101](./eip-101.md)), as well as changes that are not necessarily consensus critical but may be relevant to [“core dev” discussions](https://github.com/ethereum/pm) (for example, [EIP-90], and the miner/node strategy changes 2, 3, and 4 of [EIP-86](./eip-86.md)).
   - **Networking**: includes improvements around [devp2p](https://github.com/ethereum/devp2p/blob/readme-spec-links/rlpx.md) ([EIP-8](./eip-8.md)) and [Light Ethereum Subprotocol](https://ethereum.org/en/developers/docs/nodes-and-clients/#light-node), as well as proposed improvements to network protocol specifications of [whisper](https://github.com/ethereum/go-ethereum/issues/16013#issuecomment-364639309) and [swarm](https://github.com/ethereum/go-ethereum/pull/2959).
   - **Interface**: includes improvements around language-level standards like method names ([EIP-6](./eip-6.md)) and [contract ABIs](https://docs.soliditylang.org/en/develop/abi-spec.html).
@@ -91,7 +91,7 @@ A PR moving an EIP from Last Call to Final SHOULD contain no changes other than
 
 >*EIP Authors are notified of any algorithmic change to the status of their EIP*
 
-**Withdrawn** - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.
+**Withdrawn** - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at a later date, it is considered a new proposal.
 
 **Living** - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.
 
@@ -103,16 +103,16 @@ Each EIP should have the following parts:
 - Abstract - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.
 - Motivation *(optional)* - A motivation section is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. This section may be omitted if the motivation is evident.
 - Specification - The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (besu, erigon, ethereumjs, go-ethereum, nethermind, or others).
-- Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale should discuss important objections or concerns raised during discussion around the EIP.
-- Backwards Compatibility *(optional)* - All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their consequences. The EIP must explain how the author proposes to deal with these incompatibilities. This section may be omitted if the proposal does not introduce any backwards incompatibilities, but this section must be included if backward incompatibilities exist.
+- Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g., how the feature is supported in other languages. The rationale should discuss important objections or concerns raised during the discussion around the EIP.
+- Backwards Compatibility *(optional)* - All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their consequences. The EIP must explain how the author proposes to deal with these incompatibilities. This section may be omitted if the proposal does not introduce any backward incompatibilities, but this section must be included if backward incompatibilities exist.
 - Test Cases *(optional)* - Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Tests should either be inlined in the EIP as data (such as input/expected output pairs) or included in `../assets/eip-###/<filename>`. This section may be omitted for non-Core proposals.
 - Reference Implementation *(optional)* - An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. This section may be omitted for all EIPs.
-- Security Considerations - All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life-cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
+- Security Considerations - All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life-cycle of the proposal. E.g., include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
 - Copyright Waiver - All EIPs must be in the public domain. The copyright waiver MUST link to the license file and use the following wording: `Copyright and related rights waived via [CC0](../LICENSE.md).`
 
 ## EIP Formats and Templates
 
-EIPs should be written in [markdown](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) format. There is a [template](https://github.com/ethereum/EIPs/blob/master/eip-template.md) to follow.
+EIPs should be written in [markdown](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) format. There is a [template](https://github.com/ethereum/EIPs/blob/master/eip-template.md) and [contributor](https://github.com/ethereum/EIPs/blob/master/CONTRIBUTING.md) guidelines to follow.
 
 ## EIP Header Preamble
 
@@ -172,7 +172,7 @@ At least one author must use a GitHub username, in order to get notified on chan
 
 While an EIP is a draft, a `discussions-to` header will indicate the URL where the EIP is being discussed.
 
-The preferred discussion URL is a topic on [Ethereum Magicians](https://ethereum-magicians.org/). The URL cannot point to Github pull requests, any URL which is ephemeral, and any URL which can get locked over time (i.e. Reddit topics).
+The preferred discussion URL is a topic on [Ethereum Magicians](https://ethereum-magicians.org/). The URL cannot point to GitHub pull requests, any URL which is ephemeral, and any URL which can get locked over time (i.e. Reddit topics).
 
 ### `type` header
 
@@ -531,7 +531,7 @@ References to other EIPs should follow the format `EIP-N` where `N` is the EIP n
 
 ## Auxiliary Files
 
-Images, diagrams and auxiliary files should be included in a subdirectory of the `assets` folder for that EIP as follows: `assets/eip-N` (where **N** is to be replaced with the EIP number). When linking to an image in the EIP, use relative links such as `../assets/eip-1/image.png`.
+Images, diagrams and auxiliary files should be included in a subdirectory of the `assets` folder for that EIP as follows: `assets/eip-N` (where **N** is to be replaced with the EIP number). When linking to an image in the EIP, use relative links such as `../assets/eip-1/image.png`. Prefer SVG diagrams, then PNG, and finally everything else.
 
 ## Transferring EIP Ownership
 
@@ -590,13 +590,15 @@ The editors don't pass judgment on EIPs. We merely do the administrative & edito
 
 The `title` field in the preamble:
 
+- Should be in title case.
 - Should not include the word "standard" or any variation thereof; and
 - Should not include the EIP's number.
 
 ### Descriptions
 
 The `description` field in the preamble:
 
+- Should be in sentence case.
 - Should not include the word "standard" or any variation thereof; and
 - Should not include the EIP's number.
 
@@ -610,6 +612,8 @@ EIPs are encouraged to follow [RFC 2119](https://www.ietf.org/rfc/rfc2119.html)
 
 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
 
+Don't use RFC 2119 keywords (all-caps SHOULD/MUST/etc.) outside of the specification section.
+
 ## History
 
 This document was derived heavily from [Bitcoin's BIP-0001](https://github.com/bitcoin/bips) written by Amir Taaki which in turn was derived from [Python's PEP-0001](https://peps.python.org/). In many places text was simply copied and modified. Although the PEP-0001 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. Please direct all comments to the EIP editors.