# Proposal(s) for Meta EIP(s) specification for Upgrade coodrintion
## Summary
### Meta EIPs for Network Upgrade Coordination — Proposal Options
| Proposal | What It Adds | Who It Applies To | When Field Appears | When Field Is Removed | Key Benefit | Status |
|---------|---------------|------------------|-------------------|----------------------|-------------|--------|
| **1A** | `Upgrade` field | Standards Track **Core EIPs only** | From `Last Call` to `Final` only | Async finalized Core EIPs| Clear historical record of which upgrade deployed a Core EIP | Agreed (EIPIP Dec 2025) |
| **1B** | `Upgrade` field | **All EIPs** listed in an upgrade Meta EIP | `Draft` → `Final` (added after initial Draft) | Removed from all non-Core EIPs at `Final`; removed if `Stagnant` or `Withdrawn` | Early visibility of upgrade association across all EIPs | Proposed |
| **2A** | `Stage` field | Standards Track **Core EIPs only** | `Draft` → `Final` (added after initial Draft) | Removed if `Stagnant` or `Withdrawn` | Tracks upgrade readiness of Core EIPs during planning | Proposed |
| **2B** | `Stage` field | **All EIPs** listed in an upgrade Meta EIP | `Draft` → `Final` (added after initial Draft) | Removed if `Stagnant` or `Withdrawn` | End-to-end visibility of EIP maturity across upgrades | [Previously discussed](https://hackmd.io/O3TojQP3Tfe2rXSR2hSlkw?view) (no consensus) |
| **3A** | `Stage` + `Upgrade` fields | Standards Track **Core EIPs only** | `Draft` → `Final` (added after initial Draft) | Both removed if `Stagnant` or `Withdrawn` | Combines planning visibility and final attribution for Core EIPs | Proposed |
| **3B** | `Stage` + `Upgrade` fields | **All EIPs** listed in an upgrade Meta EIP | `Draft` → `Final` | Remove `stage` and `upgrade` from all non-Core EIPs at `Final`; `Stage` and `upgrade` removed if `Stagnant` or `Withdrawn` irrespective of type;<br>`Upgrade` and `stage` retained only for Core EIPs at `Final` | Maximum transparency across planning and deployment | Proposed |
## Proposal 1A — Optional `Upgrade` Field (Core EIPs in Final status Only)
(Agreed in EIPIP meeting (Dec 2025) by Sam Wilson & Jochem B.)
### Specification
This proposal defines an optional `Upgrade` field in the EIP preamble.
The `Upgrade` field is an **OPTIONAL**, informational metadata field that records the Ethereum network upgrade in which a finalized EIP was deployed. This field **MUST** be used only for **Standards Track – Core** EIPs.
The `Upgrade` field **MUST** be added only when an EIP transitions from `Last Call` to `Final` and the EIP is confirmed to be deployed in a named network upgrade. The field **MUST NOT** be present during `Draft`, `Review`, or `Last Call` stages.
The `Upgrade` field **MUST NOT** be used for Networking, Interface, Informational, or Meta EIPs.
The `Upgrade` field **MUST** be removed when the EIP transitions to `Stagnant`, or `Withdrawn`.
Standards Track Core EIPs that were activated asynchronously and not tied to a coordinated network upgrade **MUST NOT** include this field.
## Proposal 1B — Optional `Upgrade` Field (All EIPs listed in upgrade Meta EIP - Core & non-Core and in Draft to Final statuses)
(I want to propose with slight changes to 1A)
### Specification
This proposal defines an optional `Upgrade` field in the EIP preamble for multiple EIP types.
The `Upgrade` field is an **OPTIONAL**, informational metadata field that records the Ethereum network upgrade associated with an EIP.
This field **MAY** be used by Standards Track (Core, Networking, and Interface) and Informational EIPs those are part of any Ethereum Network Upgrade Meta EIP.
The field **MUST NOT** be present in the initial Draft submission and **MAY** be added later via a subsequent PR. The field **MUST** be present during `Draft`, `Review`, `Last Call`, or `Final` statuses.
When an EIP reaches `Final` status, the `Upgrade` field **MUST** be retained only for **Standards Track – Core** EIPs and **MUST** be removed from all other EIP types.
The `Upgrade` field **MUST** be removed when the EIP transitions to `Stagnant`, or `Withdrawn`.
The `Upgrade` field **MUST NOT** be used for Meta EIPs.
## Proposal 2A — Network Upgrade `Stage` Field (Core EIPs Only in Draft to Final statuses)
(with 1B)
### Specification
This proposal defines an optional `Stage` (or `N/W Stage`) field in the EIP preamble.
The `Stage` field is an **OPTIONAL**, informational metadata field that indicates the network upgrade stage of an EIP during upgrade planning. This field **MAY** be used only for **Standards Track – Core** EIPs.
The field **MUST** be used while the EIP is in `Draft`, `Review`, `Last Call` or `Final` status. It **MUST NOT** be present in the initial Draft submission and **MUST** be added only via a subsequent PR.
The `Stage` field **MUST** be removed when the EIP transitions to `Stagnant`, or `Withdrawn`.
The field **MUST** reflect inclusion stages defined in EIP-7723 and **MUST NOT** imply guaranteed inclusion in a network upgrade unless the status is `Final`.
## Proposal 2B — Network Upgrade `Stage` Field (All EIPs listed in upgrade Meta EIP - Core & non-Core in Draft to Final statuses)
### Specification
This proposal defines an optional `Stage` (or `N/W Stage`) field in the EIP preamble.
The `Stage` field is an **OPTIONAL**, informational metadata field that indicates that an EIP is being discussed or considered in the context of a specific Ethereum network upgrade. This field **MAY** be used by Standards Track (Core, Networking, and Interface) and Informational EIPs.
The field **MAY** be present only while the EIP is in `Draft`, `Review`, `Last Call` or `Final` status. It **MUST NOT** be present in the initial Draft submission and **MAY** be added only when a corresponding PR is made to update the Meta EIP of the respective upgrade.
The `Stage` field **MUST** be removed when the EIP transitions to `Stagnant`, or `Withdrawn`, regardless of EIP type.
The field **MUST** reflect inclusion stages defined in EIP-7723 (`Proposed for Inclusion`, `Considered for Inclusion`, `Declined for Inclusion`, `Scheduled for Inclusion`, `Included`) and is strictly informational, conveying network upgrade coordination stage without implying guaranteed inclusion except when status is `Final`.
## Proposal 3A — Add `Stage` and `Upgrade` Fields (Core EIPs Only)
### Specification
This proposal defines two optional EIP preamble fields, `Stage` (or `N/W Stage`) and `Upgrade`, to support both **in-progress coordination** and **final historical attribution** for Standards Track Core EIPs.
#### Stage
* The `Stage` field is an **OPTIONAL**, informational metadata field that **indicates the network upgrade stage** of a Core EIP during upgrade planning.
* This field **MUST** be used only for Standards Track – Core EIPs while the EIP is in `Draft`, `Review`, or `Last Call` status.
* The `Stage` field **MUST NOT** be present in the initial Draft submission and **MUST** be added only via a subsequent PR, typically aligned with a PR updating the Meta EIP of the respective upgrade. The `Stage` field **MUST** be removed when the EIP transitions to `Stagnant`, or `Withdrawn`.
* The `Stage` field **MUST** reflect inclusion stages defined in EIP-7723 and is strictly informational, conveying coordination state without implying guaranteed inclusion unless "stage" = "Included".
#### Upgrade
* The `Upgrade` field is an **OPTIONAL**, informational metadata field that **records the Ethereum network upgrade** for Core EIP.
* The `Upgrade` field **MUST** be used while the EIP is in `Draft`, `Review`,`Last Call` or `Final` status.
* The `upgrade` field **MUST NOT** be present in the initial Draft submission and **MUST** be added only via a subsequent PR, typically aligned with a PR updating the Meta EIP of the respective upgrade.
* The `Upgrade` field **MUST** be removed when the EIP transitions to `Stagnant`, or `Withdrawn`.
* The `Upgrade` field **MUST** reflect network upgrade name in which it is or will be deployed and is strictly informational, conveying coordination state without implying guaranteed inclusion unless "status" = "Final".
Both fields **MUST NOT** be used for non-Core EIPs or Meta EIPs. Standards Track Core EIPs that were activated asynchronously and not tied to a coordinated network upgrade **MUST NOT** include the `ugrade` or stage` field.
## Proposal 3B — Add both `Stage` and `Upgrade` Fields (All EIP Types)
### Specification
This proposal defines two optional EIP preamble fields, `Stage` (or `N/W Stage`) and `Upgrade`, to provide unified coordination visibility and deployment attribution across EIP types.
#### Stage
The `Stage` field is an **OPTIONAL**, metadata field that indicates that an EIP is being discussed or considered in the context of a specific Ethereum network upgrade. This field **MAY** be used by Standards Track (Core, Networking, and Interface) and Informational EIPs while the EIP is in `Draft`, `Review`, `Last Call` or `Final` status. The field **MUST NOT** be present in the initial Draft submission and **MAY** be added only when a corresponding PR is made to update the Meta EIP of the respective upgrade. The `Stage` field **MUST** be removed when the EIP transitions to `Stagnant`, or `Withdrawn`, regardless of EIP type.
The `Stage` field **MUST** reflect inclusion stages defined in EIP-7723 and is strictly informational, conveying coordination state without implying guaranteed inclusion unless "stage" = "Included".
#### Upgrade
The `Upgrade` field is an **OPTIONAL**, metadata field that records the Ethereum network upgrade in which an EIP is planned to be or was deployed. The `Upgrade` field **MAY** be added only while the EIP is in `Draft`, `Review`, `Last Call` or `Final` status.
When an EIP reaches `Final` status, the `Upgrade` field **MUST** be retained only for Standards Track – Core EIPs and **MUST** be removed from Networking, Interface, and Informational EIPs. The `Upgrade` field **MUST NOT** be used for Meta EIPs.
Standards Track Core EIPs that were activated asynchronously and not tied to a coordinated network upgrade **MUST NOT** include the `stage` or `Upgrade` field.
Sign in with Wallet
Connect another wallet