Update EIP-7723: Update eip-7723.md#11006
Open
poojaranjan wants to merge 1 commit intoethereum:masterfrom
Open
Update EIP-7723: Update eip-7723.md#11006poojaranjan wants to merge 1 commit intoethereum:masterfrom
poojaranjan wants to merge 1 commit intoethereum:masterfrom
Conversation
Added edits for clarity and replaced "Status" with "Stages" as needed.
Collaborator
File
|
3 tasks
abcoathup
reviewed
Jan 5, 2026
| ### 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. |
Contributor
There was a problem hiding this comment.
Suggested change
| 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. |
We shouldn't restrict the decision to DFI to only ACD meetings, though ideally they would predominantly occur there.
eth-bot
changed the title
abcoathup
reviewed
Jan 5, 2026
| 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. |
Contributor
There was a problem hiding this comment.
Suggested change
| 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. |
I'd leave this as is. Decisions are made by rough consensus. Whilst multiple is mostly implied by "client teams", want to explicitly avoid defining consensus rules.
abcoathup
reviewed
Jan 5, 2026
| 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. |
Contributor
There was a problem hiding this comment.
Suggested change
| 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. |
I would leave as is, but if the prefix is needed, should it be a colon.
abcoathup
reviewed
Jan 5, 2026
| 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. |
Contributor
There was a problem hiding this comment.
Suggested change
| 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. |
Sentence is about non-Core EIPs.
abcoathup
reviewed
Jan 5, 2026
| ### 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. |
Contributor
There was a problem hiding this comment.
Suggested change
| 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. |
I'd leave as is. We shouldn't restrict the decision to CFI to only ACD meetings, though ideally they would predominantly occur there.
scutuatua-crypto
approved these changes
Jan 5, 2026
3 tasks
This was referenced Feb 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Added edits for clarity and replaced "Status" with "Stages" as needed.