Add Optional “Upgrade” Field to Standards Track Core EIPs

EIPs EIPs core
,
1

This is a proposal open for discussion to add an optional upgrade field to Standards Track Core EIPs.

Problem Statement

At present, it is difficult to clearly identify which finalized Standards Track Core EIPs were deployed with which Ethereum network upgrade by looking at the Final EIP itself.

While this mapping is possible through:

  • Upgrade Meta EIPs,
  • Network upgrade announcements, or
  • External tools and dashboards (such as custom UIs built by the EIPsInsight),

This information is not directly visible on the official EIP document. The official EIP repository lacks a simple, authoritative way to link a Final Standards Track Core EIP to its activating upgrade.

This creates unnecessary friction for users trying to understand protocol evolution, upgrade scope, and historical context. As a result, developers, protocol testing team and other community participants frequently reach out requesting an easier way to identify the upgrade name.

The Proposal (Specification)

This proposal defines an optional Upgrade field in the EIP preamble with the following semantics.

  • The Upgrade field is optional and informational.
  • It is applicable only to Standards Track – Core EIPs.
  • The field MUST NOT be present during the Draft, Review, or Last Call statuses.
  • The field MUST be added only when an EIP transitions from Last Call to Final status.
  • The field MUST specify the name of the Ethereum Network Upgrade in which the EIP was deployed.
  • The Upgrade field may be retroactively added to all finalized Standards Track Core EIPs that were included in previous Meta EIPs.
  • EIPs that were activated asynchronously (i.e., not tied to a specific network upgrade) would not receive this field.

Responsibility for adding this field would lie with the EIP co-authors or EIP champion.

Next steps

  • Document the addition of this new “field” (trivial process change) via an EIP.
  • Update EIP template to add “upgrade” to preamble
  • Update EIP-1 providing authoring and editorial guidelines to:
    • Clarify when and how the Upgrade field should be added.
    • Emphasize that it is optional and informational, not normative.

This proposal aims to improve clarity, discoverability, and historical accuracy of Ethereum protocol changes without altering EIP lifecycle semantics or adding burden on authors or EIP editors during early proposal stages.

The proposal is the outcome of EIPIP #122, where call participants agreed to bring it forward for broader input from authors, developers, and the community. It is open for further discussion and feedback, particularly from EIP editors, client teams, and tooling maintainers.

However, after giving some more thought during the holiday season, I came up with multiple flavors of this proposal documented here.
Adding summary for quick reference

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 (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;
Upgrade and stage retained only for Core EIPs at Final		 Maximum transparency across planning and deployment Proposed

Thank you for reading this long post. I sincerely appreciate your feedback :folded_hands:

1 Like
2

The clear historical record should be the Network Upgrade Meta EIP, to show upgrade and stage.

We should avoid duplicating information wherever possible, to avoid divergence or confusion on what is the correct information.

Ideally any website (including eips.ethereum.org) would use the Network Upgrade Meta EIP to obtain this information. If we absolutely can’t do this automagically, then we should have the bare minimum, which is an upgrade field set only when EIPs are set to final. (1A)

1 Like
3

I’m fine with rendering upgrade information on the individual proposals, but the source of truth should always be the fork meta EIPs.

It wouldn’t need any interaction with the EIP status. If Glamsterdam’s fork meta EIP lists proposal 1234, then proposal 1234’s page shows Glamsterdam: CFI (or whatever).

2 Likes
4

If you have a preference from above the table, please let us know.

As we understand, only Core EIPs are deployed at the time of upgrade.

  1. Would you want to limit it to
    a. Standards Track Core Only?
    b. Core and Others mentioned in Meta?
  2. Any thoughts on CoreEIP deployed out of the scheduled upgrade?
  3. Would you be open to adding stage field as well for clarity?

Agreed. Status is added for clarity purposes.

5

None. These all require modifying the feature proposal, as far as I understand them.

I’d like Jekyll, or whatever renderer we end up using, to parse network upgrade EIPs and add the links from feature EIP to network upgrade EIP on the fly.

1 Like
6

:partying_face:
Awesome, no data duplication, let the renderer do it.

I’ve created an Issue