This EIP documents the naming conventions used for Ethereum network upgrades across the Execution Layer, Consensus Layer, post-Merge combined upgrades, and Blob-Parameter-Only upgrades. It provides a canonical reference for how upgrade names have evolved to improve clarity, consistency, and shared understanding across the ecosystem.
In brief: early upgrades used thematic or milestone-based names; subsequent Execution Layer upgrades are named after Devcon/Devconnect host cities; Consensus Layer upgrades follow an alphabetical sequence of star names; post-Merge combined upgrades MAY adopt a portmanteau of the two layer names; and Blob-Parameter-Only upgrades use a sequential numeric identifier (BPO<n>).
Ethereum has undergone multiple major network upgrades, including the transition from Proof of Work to Proof of Stake. Each upgrade has been assigned a distinct and meaningful name, and after the initial upgrades, consistent naming patterns emerged and continue to be followed.
As upgrades now occur more frequently and span multiple protocol layers, it can become difficult to consistently interpret upgrade names and their relationships. This EIP documents existing naming conventions to provide a canonical reference for Ethereum upgrade nomenclature, improving clarity, reducing ambiguity, and supporting consistent communication and coordination across the ecosystem without constraining future naming decisions.
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.
Ethereum upgrade naming conventions have evolved alongside protocol architecture, governance maturity, and coordination practices. Early upgrades followed planned development phases (Frontier, Homestead, Metropolis, and Serenity), reflecting milestones toward a stable, production-ready network. After the Merge, naming conventions began reflecting the separation between the Execution Layer (EL) and Consensus Layer (CL).
This section documents the observed evolution of upgrade naming conventions.
Early Ethereum upgrades used names that reflected the experimental state of the network, major milestones, or thematic concepts associated with shipped functionality.
Observed upgrades include:
These names reflect the exploratory nature of early protocol development.
During the Metropolis development phase, upgrades adopted names based on historically connected cities to provide consistency and symbolic continuity. The naming reflected Ethereum’s transition toward a more mature, user-friendly platform.
Observed upgrades include:
This convention standardized naming during frequent upgrade cycles.
Upgrades primarily targeting the Difficulty Bomb adopted glacier-themed naming to reflect mining difficulty progression.
Observed upgrades include:
These names signaled functional scope rather than feature expansion.
Execution Layer upgrades MAY be named after the host city of a Devcon or Devconnect conference. The convention originated with Devcon host cities and later expanded to include Devconnect host cities.
One exception applies: the Merge included Paris as a reference to EthCC to commemorate the first biggest Ethereum Community Conference.
Observed examples include:
Additional past and announced event host cities include, but are not limited to, Istanbul, Bangkok, Buenos Aires and Mumbai.
Future Execution Layer upgrade names MAY continue referencing Devcon or Devconnect host cities.
This convention provides geographic neutrality, cultural diversity, and predictable sequencing for roadmap planning and external communication.
Following the Serenity roadmap phase and the launch of the Beacon Chain, Consensus Layer network upgrades adopt a naming convention based on star names in alphabetical order.
Consensus Layer (formerly Eth2 / Beacon Chain) upgrades MUST be named after stars, with each upgrade name advancing alphabetically by first letter.
Each selected name MUST correspond to a recognized star name based on rough consensus. This convention was established through open community coordination to provide a consistent, neutral, and globally recognizable naming scheme.
The sequence begins with Altair, activated in October 2021 as the first Consensus Layer upgrade, which established the star-based naming convention and serves as the reference point for all subsequent upgrades, followed in alphabetical order by names including but not limited to Bellatrix, Capella, Deneb, Electra, Fulu, Gloas, and Heze.
This convention provides predictable sequencing of upgrades, clear differentiation between Consensus Layer and Execution Layer upgrades, long-term scalability without name reuse or ambiguity, and a shared vocabulary across protocol developers, client teams, researchers, operators, and ecosystem participants.
The Merge is a special case in Ethereum upgrade naming and activation semantics.
Unlike subsequent post-Merge upgrades, where Execution Layer (EL) and Consensus Layer (CL) upgrades may activate simultaneously and MAY adopt a combined portmanteau name, the Merge was executed through a staged activation process and did not adopt a combined name.
The Consensus Layer upgrade Bellatrix activated on the Beacon Chain on September 6, 2022 (Epoch 144896). Bellatrix enabled the Beacon Chain to recognize and coordinate the upcoming Execution Layer transition.
The Execution Layer upgrade Paris activated on September 15, 2022 at 06:42 UTC, when the network reached the predefined Terminal Total Difficulty (TTD). This activation finalized the transition of Ethereum mainnet from Proof-of-Work to Proof-of-Stake at block 15,537,393.
Although the protocol transition completed on September 15, 2022, the Merge process was operationally initiated by the Bellatrix upgrade on September 6, 2022.
The upgrade is canonically referred to as The Merge. No combined portmanteau name was adopted for this event.
Future simultaneous EL and CL upgrades follow the combined naming convention defined in the Combined Upgrade Naming section.
Following the Merge, Execution Layer and Consensus Layer upgrades MAY activate simultaneously within a single network upgrade.
When simultaneous activation occurs, each layer retains its independent naming convention. The ecosystem MAY additionally adopt a combined portmanteau name derived from the Execution Layer upgrade name and the Consensus Layer upgrade name to simplify external communication and coordination.
The combined name is informational only and MUST NOT replace the canonical layer-specific upgrade names used in specifications, client implementations, or protocol documentation.
Observed examples include:
Additional combined names MAY be adopted in future upgrades following the same convention.
Blob-Parameter-Only upgrades (BPO upgrades) are network upgrades whose scope is limited to modifying blob-related parameters, including blob target and maximum limits, without introducing additional protocol changes.
BPO upgrades support Ethereum’s data availability scaling objectives under the Surge roadmap by enabling incremental capacity increases with reduced operational risk.
BPO upgrades MUST be named using a sequential numeric identifier in the format BPO<n>, where n is a monotonically increasing positive integer starting from 1.
The naming intentionally avoids descriptive or thematic labels. Sequential numbering preserves direct ordinal mapping, minimizes naming indirection, and reflects the single-purpose and templated nature of these upgrades.
The BPO naming convention is specified in EIP-7892 and applies exclusively to upgrades limited to blob parameter adjustments.
Observed examples include:
BPO upgrades MAY be deployed independently or alongside larger multi-change upgrades. The numeric identifier remains the canonical reference.
Early upgrades used thematic or milestone-inspired names reflecting the state of the network at launch. "Frontier" conveyed an experimental frontier environment for developers; "Homestead" signaled a transition to a more stable and production-ready network; "Tangerine Whistle" emphasized urgency (an emergency whistle), deployed to mitigate active denial-of-service attacks; "Spurious Dragon" reflected the goal of removing millions of "spurious" (empty) accounts created during those attacks.
Historic city upgrades followed Ethereum's Metropolis development phase. Byzantium, Constantinople, St. Petersburg, and Istanbul form a historically connected sequence—Byzantium became Constantinople, which became Istanbul—symbolizing the staged maturation of the protocol. Constantinople and St. Petersburg were activated at the same block height, with St. Petersburg ensuring the removal of EIP-1283.
Glacier upgrades used names of real, retreating glaciers (Muir, Arrow, Gray) to symbolize temporary measures slowing the "Ice Age" difficulty bomb, buying time for the Proof-of-Stake transition. Gray Glacier merges into another glacier, a subtle nod to Ethereum's imminent Merge.
Execution Layer city names provide geographic neutrality, cultural diversity, and predictable sequencing tied to the global Devcon/Devconnect event calendar.
Consensus Layer star names provide a consistent, politically neutral, globally recognizable naming scheme with a natural alphabetical ordering that ensures long-term scalability without name reuse.
Combined portmanteau names (e.g., Shapella, Dencún, Pectra) are informational conveniences for ecosystem communication. They do not replace the canonical layer-specific names used in specifications and client implementations.
BPO numeric identifiers reflect the single-purpose, templated nature of blob-parameter-only upgrades. Descriptive or thematic names would add indirection without benefit; sequential numbering preserves direct ordinal mapping.
As the protocol matures and the cadence of upgrades increases, documenting naming conventions helps reduce ambiguity, limit speculation, and provide clearer expectations around upgrade naming. A well-defined reference improves transparency, strengthens shared understanding, and supports informed participation and coordination.
This EIP does not establish binding authority over future naming decisions. It documents established conventions and current practice. Future upgrade naming remains governed by community coordination and can be found in upgrade-specific Meta EIPs.
This EIP is informational and introduces no protocol changes.
None.
Copyright and related rights waived via CC0.