Skip to content

Update EIP-7723: update SFI definition based on ACDT#74 #11475

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
lightclient merged 6 commits into from
May 8, 2026
Merged

Update EIP-7723: update SFI definition based on ACDT#74 #11475

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
1c8cbb1
update SFI definition based on ACDT#74
nixorokish Apr 1, 2026
54d18cc
CFI & SFI definition changes based on the ACD process session at Sval…
May 6, 2026
1c18d5a
Apply suggestions from code review
nixorokish May 6, 2026
2cfb3c2
Update eip-7723.md
nixorokish May 6, 2026
577383d
address markdown linter errors
nixorokish May 7, 2026
8a41b5d
linter errors
nixorokish May 7, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 27 additions & 11 deletions EIPS/eip-7723.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,17 +42,19 @@ Since client developers' ability to include EIPs in a network upgrade is constra

### 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.
To propose an EIP for inclusion, someone **MUST** open a pull request to add it to the `Proposed for Inclusion` (PFI) 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.

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
### 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` (CFI) 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.
`Considered for Inclusion` signals that client developers intend to attempt to include the EIP in devnets. The All Core Devs Execution (ACDE) and Consensus (ACDC) call facilitators should work with the testing teams to propose a priority ordering of CFI EIPs to be reviewed by client developers, and then reflect this prioritization in the Meta EIP. This prioritization should inform which EIPs should be included in upcoming devnets, with some flexibility if circumstances change.

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.

Expand All @@ -64,21 +66,35 @@ Any updates to an EIP that is already at this stage **SHOULD** be accompanied by

### 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** move EIPs from any other stage to the `Declined for Inclusion` (DFI) 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.

`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
### Scheduled for Inclusion

An EIP can be moved to Scheduled for Inclusion (SFI) when core developers:

1. Agree upon a strong intent to include the EIP in the next network upgrade.
2. Agree that an EIP's specifications and implementations have reached a certain level of maturity.

I.e., an SFI status signals that the EIP is on track for inclusion barring unforeseen issues.

The following critieria can be applied to ascertain whether an EIP is mature (stable) enough to move to SFI:

- It has been included in a devnet that has demonstrated stability (e.g., high participation, no critical bugs for ≥1 week).
- The EIP specification is close to final (no placeholder values or pending design decisions).
- It has minimal interactions with other CFI EIPs, OR those interactions have been tested in the same devnet.
- Testing coverage is adequate (clients pass consensus tests, no known divergence across clients).

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.
All Core Devs Testing (ACDT) calls may review EIPs to determine SFI eligibility. Status changes will then be ratified on ACDE or ACDC before assigning SFI status.

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.
`Scheduled for Inclusion` signals that the EIP is on track for inclusion barring unforeseen issues. EIPs with incomplete specs or untested interactions should remain CFI until these conditions are met. The latest Upgrade Devnet must contain all `Scheduled for Inclusion` Core EIPs.

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.
An EIP **MAY** be moved from `Scheduled for Inclusion` to `Declined for Inclusion` if circumstances necessitate removal, as agreed by client teams. An EIP **MAY** also be moved from `Scheduled for Inclusion` to `Considered for Inclusion` if client teams remain in favor of including the EIP in the network upgrade but cannot commit to including it in the **next** Upgrade Devnet.

`Scheduled for Inclusion` signals that implementation and testing work are underway. The EIP **SHOULD** be included in the network upgrade if no issues arise. The latest Upgrade Devnet must contain all `Scheduled for Inclusion` Core EIPs.
An EIP **MUST** have a Python implementation accompanied by tests in [execution-specs](https://github.com/ethereum/execution-specs/blob/5cdb055e069e246a877c8aa018079eb0b9093f57/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/5cdb055e069e246a877c8aa018079eb0b9093f57/README.md) implementation, but the tests are strictly mandatory.

An EIP **MAY** be moved from `Scheduled for Inclusion` to `Declined for Inclusion` if client teams are against including the EIP in the network upgrade. An EIP **MAY** also be moved from `Scheduled for Inclusion` to `Considered for Inclusion` if client teams are in favor of including the EIP in the network upgrade but cannot commit to including it in the **next** Upgrade Devnet.
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/5cdb055e069e246a877c8aa018079eb0b9093f57/README.md) if deemed necessary by client developers.

### Included

Expand Down
Loading