ethereum · poojaranjan · Jan 3, 2026 · abcoathup · Jan 5, 2026 · abcoathup
@@ -12,7 +12,7 @@ created: 2024-06-12
 
 ## Abstract
 
-Define the stages that EIPs go through in the process of planning network upgrades: `Proposed for Inclusion`, `Considered for Inclusion`, `Scheduled for Inclusion`, `Declined for Inclusion` and `Included`.
+Defines the stages that EIPs go through in the process of planning network upgrades: `Proposed for Inclusion`, `Considered for Inclusion`, `Scheduled for Inclusion`, `Declined for Inclusion` and `Included`.
 
 ## Motivation
 
@@ -22,57 +22,57 @@ This EIP proposes definitions for the various stages EIPs go through when planni
 
 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.
 
-All EIP statuses apply to a single network upgrade. EIPs must be `Proposed`, `Considered`, `Declined` or `Scheduled` separately for each network upgrade. While an EIP cannot be `Included` in two network upgrades, an EIP being `Declined for Inclusion` in a previous upgrade does not prevent it from being `Proposed`, `Considered`, `Declined` or `Scheduled` for inclusion in any future upgrade. 
+All EIP stages apply to a single network upgrade. EIPs must be `Proposed`, `Considered`, `Declined` or `Scheduled` separately for each network upgrade. While an EIP cannot be `Included` in two network upgrades, an EIP being `Declined for Inclusion` in a previous upgrade does not prevent it from being `Proposed`, `Considered`, `Declined` or `Scheduled` for inclusion in any future upgrade. 
 
-The statuses below are generally defined for Core EIPs, which must be activated synchronously by all nodes on a network. To help with prioritization and communications, non-Core EIPs may also be assigned these statuses. The differences in the process and implications for non-Core EIPs are noted in each status definition.
+The stages below are generally defined for Standards Track-Core EIPs, which must be activated synchronously by all nodes on a network. To help with prioritization and communications, non-Core EIPs may also be assigned these stages. The differences in the process and implications for non-Core EIPs are noted in each stage's definition.
-The stages below are generally defined for Standards Track-Core EIPs, which must be activated synchronously by all nodes on a network. To help with prioritization and communications, non-Core EIPs may also be assigned these stages. The differences in the process and implications for non-Core EIPs are noted in each stage's definition.
+The stages below are generally defined for Standards Track: Core EIPs, which must be activated synchronously by all nodes on a network. To help with prioritization and communications, non-Core EIPs may also be assigned these stages. The differences in the process and implications for non-Core EIPs are noted in each stage's definition.
-The stages below are generally defined for Standards Track-Core EIPs, which must be activated synchronously by all nodes on a network. To help with prioritization and communications, non-Core EIPs may also be assigned these stages. The differences in the process and implications for non-Core EIPs are noted in each stage's definition.
+The stages below are generally defined for Standards Track: Core EIPs, which must be activated synchronously by all nodes on a network. To help with prioritization and communications, non-Core EIPs may also be assigned these stages. The differences in the process and implications for non-Core EIPs are noted in each stage's definition.
 
 ### Upgrade Meta EIPs
 
-Anyone **MAY** draft a Meta EIP to list EIPs for a network upgrade. This Meta EIP **SHOULD** include four categories in its specification section: `Proposed for Inclusion`, `Declined for Inclusion`, `Considered for Inclusion` and `Scheduled for Inclusion`. Even if a category is empty, it **SHOULD** be included in the initial draft for clarity. 
+Anyone **MAY** draft a Meta EIP to list EIPs for a network upgrade. This Meta EIP **SHOULD** include four categories in its specification section: `Proposed for Inclusion`, `Declined for Inclusion`, `Considered for Inclusion` and `Scheduled for Inclusion`. Even if a category is `TBD`, it **SHOULD** be included in the initial draft for clarity. 
 
 When the Upgrade Meta EIP is moved to `Last Call`, the `Proposed for Inclusion`, `Declined for Inclusion` and `Considered for Inclusion` lists **SHOULD** be removed, leaving only `Scheduled for Inclusion`. 
 
-Before the Upgrade Meta EIP is moved to `Final`, the `Scheduled for Inclusion` stage **MUST** be renamed to `Included` and contain only EIPs that were activated in the upgrade. 
+Before the Upgrade Meta EIP is moved to `Final`, the `Scheduled for Inclusion` stage **MUST** be renamed to `Included` and contain only EIPs that were activated with the upgrade. 
 
 ### Upgrade Devnets
 
-When preparing a network upgrade, client developers typically implement EIPs first on an ephemeral test network (upgrade devnet) to verify client interoperability, before deploying to long-lived test networks. These upgrade devnets follow a naming convention of `upgradeName-devnet-version` (e.g. `pectra-devnet-0` for the first upgrade devnet of the Pectra network upgrade, `dencun-devnet-1` for the second upgrade devnet of the Dencun update, etc).
+When preparing a network upgrade, client developers typically implement EIPs first on an ephemeral test network (upgrade devnet) to verify client interoperability before deploying to long-lived test networks. These upgrade devnets follow a naming convention of `upgradeName-devnet-version` (e.g. `pectra-devnet-0` for the first upgrade devnet of the Pectra network upgrade, `dencun-devnet-1` for the second upgrade devnet of the Dencun update, etc).
 
 Since client developers' ability to include EIPs in a network upgrade is constrained by what can be implemented and tested in these upgrade devnets, the [Considered for Inclusion](#considered-for-inclusion) and [Scheduled for Inclusion](#scheduled-for-inclusion) sections below propose aligning these statuses with EIPs' implementation status in upgrade devnets.
 
 ### Proposed for Inclusion
 
 To propose an EIP for inclusion, someone **MUST** open a pull request to add it to the `Proposed for Inclusion` section of the Upgrade Meta EIP. The proposer of an EIP **SHOULD** serve as the primary point of contact for that EIP for the duration of the upgrade cycle or **SHOULD** designate another person to serve in that role. Reasonable pull requests **SHOULD** be merged in a timely fashion by the Upgrade Meta EIP author.
 
-At this stage, implementation teams **SHOULD** review the EIP. For Core EIPs, this should be in the context of including it in the next upgrade. For non-Core EIPs, this should be in the context of supporting the EIP before the network upgrade is activated. 
+At this stage, implementation teams **SHOULD** review the EIP. For Core EIPs, this should be in the context of including it in the said upgrade. For non-Core EIPs, this should be in the context of supporting Core EIPs before the network upgrade is activated. 
-At this stage, implementation teams **SHOULD** review the EIP. For Core EIPs, this should be in the context of including it in the said upgrade. For non-Core EIPs, this should be in the context of supporting Core EIPs before the network upgrade is activated. 
+At this stage, implementation teams **SHOULD** review the EIP. For Core EIPs, this should be in the context of including it in the said upgrade. For non-Core EIPs, this should be in the context of supporting the EIP before the network upgrade is activated. 
-At this stage, implementation teams **SHOULD** review the EIP. For Core EIPs, this should be in the context of including it in the said upgrade. For non-Core EIPs, this should be in the context of supporting Core EIPs before the network upgrade is activated. 
+At this stage, implementation teams **SHOULD** review the EIP. For Core EIPs, this should be in the context of including it in the said upgrade. For non-Core EIPs, this should be in the context of supporting the EIP before the network upgrade is activated. 
 
 Note that EIPs must be `Proposed for Inclusion` for each network upgrade. In other words, proposals do not "carry over" to the next upgrade if an EIP is not included in the one it was first proposed for. 
 
 ### Considered for Inclusion 
 
-Once client developers have reviewed an EIP which was `Proposed for Inclusion`, they **MAY** move it to the `Considered for Inclusion` stage. Once a decision is made by client teams to move an EIP to `Considered for Inclusion`, the Upgrade Meta EIP **SHOULD** be updated to reflect this. 
+Once client developers have reviewed an EIP which was `Proposed for Inclusion`, they **MAY** move it to the `Considered for Inclusion` stage. Once a decision is made in the "All Core Devs meeting" to move an EIP to `Considered for Inclusion`, the Upgrade Meta EIP **SHOULD** be updated to reflect this. 
-Once client developers have reviewed an EIP which was `Proposed for Inclusion`, they **MAY** move it to the `Considered for Inclusion` stage. Once a decision is made in the "All Core Devs meeting" to move an EIP to `Considered for Inclusion`, the Upgrade Meta EIP **SHOULD** be updated to reflect this. 
+Once client developers have reviewed an EIP which was `Proposed for Inclusion`, they **MAY** move it to the `Considered for Inclusion` stage. Once a decision is made by client teams to move an EIP to `Considered for Inclusion`, the Upgrade Meta EIP **SHOULD** be updated to reflect this. 
-Once client developers have reviewed an EIP which was `Proposed for Inclusion`, they **MAY** move it to the `Considered for Inclusion` stage. Once a decision is made in the "All Core Devs meeting" to move an EIP to `Considered for Inclusion`, the Upgrade Meta EIP **SHOULD** be updated to reflect this. 
+Once client developers have reviewed an EIP which was `Proposed for Inclusion`, they **MAY** move it to the `Considered for Inclusion` stage. Once a decision is made by client teams to move an EIP to `Considered for Inclusion`, the Upgrade Meta EIP **SHOULD** be updated to reflect this. 
 
 `Considered for Inclusion` signals that client developers are positive towards the EIP. A Core EIP that is `Considered for Inclusion`  **SHOULD** be implemented in future Upgrade Devnets. Assuming it meets all the requirements for mainnet deployment it **MAY** be included in the network upgrade. This stage is similar to "concept ACK" in other open source projects, and is not sufficient to result in deployment to mainnet. 
 
 Non-Core EIPs that are `Considered for Inclusion` **SHOULD** be supported prior to the network upgrade being activated. 
 
-An EIP **MAY** be moved from `Considered for Inclusion` to `Declined for Inclusion` if client teams are against including the EIP in the network upgrade. 
+An EIP **MAY** be moved from `Considered for Inclusion` to `Declined for Inclusion` if multiple client teams are against including the EIP in the network upgrade. 
-An EIP **MAY** be moved from `Considered for Inclusion` to `Declined for Inclusion` if multiple client teams are against including the EIP in the network upgrade. 
+An EIP **MAY** be moved from `Considered for Inclusion` to `Declined for Inclusion` if client teams are against including the EIP in the network upgrade. 
-An EIP **MAY** be moved from `Considered for Inclusion` to `Declined for Inclusion` if multiple client teams are against including the EIP in the network upgrade. 
+An EIP **MAY** be moved from `Considered for Inclusion` to `Declined for Inclusion` if client teams are against including the EIP in the network upgrade. 
 
 An EIP **SHOULD** have a Python implementation accompanied by tests in [execution-specs](https://github.com/ethereum/execution-specs/blob/78fb726158c69d8fa164e28f195fabf6ab59b915/README.md) submitted as an open PR. The EIP writer is encouraged to reach out to the maintainers of execution-specs for assistance with implementation. Client developers **MAY** decide to allow an EIP to be moved to `Considered for Inclusion` without either implementation, being aware that the absence of these implementations could lead to delays in the testing cycle.
 
 Any updates to an EIP that is already at this stage **SHOULD** be accompanied by the appropriate updates to its implementation and tests in [execution-specs](https://github.com/ethereum/execution-specs/blob/78fb726158c69d8fa164e28f195fabf6ab59b915/README.md) if deemed necessary by client developers.
 
 ### Declined for Inclusion
 
-At any time during the network upgrade planning process, client developers **MAY** move EIPs from any other stage to the `Declined for Inclusion` stage if client teams are against including the EIP in the network upgrade. Once a decision is made by client teams to move an EIP to `Declined for Inclusion`, the Upgrade Meta EIP **SHOULD** be updated to reflect this.
+At any time during the network upgrade planning process, client developers **MAY** decide to move EIPs from any other stage to the `Declined for Inclusion` stage if the ACD Meeting decision is against including the EIP in the network upgrade. Once a decision is made to move an EIP to `Declined for Inclusion`, the Upgrade Meta EIP **SHOULD** be updated to reflect this.
-At any time during the network upgrade planning process, client developers **MAY** decide to move EIPs from any other stage to the `Declined for Inclusion` stage if the ACD Meeting decision is against including the EIP in the network upgrade. Once a decision is made to move an EIP to `Declined for Inclusion`, the Upgrade Meta EIP **SHOULD** be updated to reflect this.
+At any time during the network upgrade planning process, client developers **MAY** decide to move EIPs from any other stage to the `Declined for Inclusion` stage if client teams are against including the EIP in the network upgrade. Once a decision is made to move an EIP to `Declined for Inclusion`, the Upgrade Meta EIP **SHOULD** be updated to reflect this.
-At any time during the network upgrade planning process, client developers **MAY** decide to move EIPs from any other stage to the `Declined for Inclusion` stage if the ACD Meeting decision is against including the EIP in the network upgrade. Once a decision is made to move an EIP to `Declined for Inclusion`, the Upgrade Meta EIP **SHOULD** be updated to reflect this.
+At any time during the network upgrade planning process, client developers **MAY** decide to move EIPs from any other stage to the `Declined for Inclusion` stage if client teams are against including the EIP in the network upgrade. Once a decision is made to move an EIP to `Declined for Inclusion`, the Upgrade Meta EIP **SHOULD** be updated to reflect this.
 
 `Declined for Inclusion` signals that client developers wish to exclude the EIP from the current network upgrade and stop discussing its potential inclusion or implementation status in relation to this upgrade. An EIP which was `Declined for Inclusion` in a particular upgrade **MAY** still be `Proposed for Inclusion` in a subsequent upgrade. In exceptional circumstances, client developers **MAY** choose to move an EIP from `Declined for Inclusion` to `Considered for Inclusion` or `Scheduled for Inclusion`. 
 
 ### Scheduled for Inclusion 
 
 When client teams agree to implement a Core EIP in the **next** Upgrade Devnet, the EIP **SHOULD** move to the `Scheduled for Inclusion` stage, and the Upgrade Meta EIP **SHOULD** be updated to reflect this. Non-Core EIPs **SHOULD** move to `Scheduled for Inclusion` when client teams agree to immediately prioritize their implementation. 
 
-An EIP **MUST** have a Python implementation accompanied by tests in [execution-specs](https://github.com/ethereum/execution-specs/blob/78fb726158c69d8fa164e28f195fabf6ab59b915/README.md), submitted as an open PR or merged to the `devnets/upgradeName/version` branch of the repository. Client developers **MAY** decide to allow an EIP to be moved to `Scheduled for Inclusion` without an [execution-specs](https://github.com/ethereum/execution-specs/blob/78fb726158c69d8fa164e28f195fabf6ab59b915/README.md) implementation, but the tests are strictly mandatory.
+An EIP **MUST** have a Python implementation accompanied by tests in [execution-specs](https://github.com/ethereum/execution-specs/blob/78fb726158c69d8fa164e28f195fabf6ab59b915/README.md), submitted as an open PR or merged to the `devnets/upgradeName/version` branch of the repository. Client developers **MAY** decide to allow an EIP to be moved to `Scheduled for Inclusion` without an [execution-specs](https://github.com/ethereum/execution-specs/blob/78fb726158c69d8fa164e28f195fabf6ab59b915/README.md) implementation, but tests are strictly mandatory.
 
 Any updates to an EIP that is already at this stage **MUST** be accompanied by appropriate updates to its implementation and tests in [execution-specs](https://github.com/ethereum/execution-specs/blob/78fb726158c69d8fa164e28f195fabf6ab59b915/README.md) if deemed necessary by client developers.
 
@@ -90,9 +90,9 @@ After network upgrade activation, all included Core EIPs and activated non-Core
 
 Formalizing the `Proposed for Inclusion`, `Considered for Inclusion`, `Scheduled for Inclusion`, `Declined for Inclusion` and `Included` stages provides better legibility to both protocol maintainers and the broader Ethereum community.
 
-The specification tries to minimize steps which **MUST** be followed to align with Ethereum's "rough consensus" governance model. 
+The specification tries to minimize steps that **MUST** be followed to align with Ethereum's "rough consensus" governance model. 
 
-Assuming it is adopted, the process outlined in this EIP should be used for at least one full network upgrade cycle before moving to `Last Call` and at least two full network upgrades cycles before moving to `Final`. This way, the EIP can be updated to reflect changes made to the process over time. 
+Assuming it is adopted, the process outlined in this EIP should be used for at least one full network upgrade cycle before moving to `Last Call` and at least two full network upgrade cycles before moving to `Final`. This way, the EIP can be updated to reflect changes made to the process over time. 
 
 ## Backwards Compatibility