Update EIP-7723: Move to Living

[nixorokish]

EIP-7723 was listed as a requirement for EIP-7607, so it will need either Living or Final status in order for the Fusaka Meta to be moved to Final

Living makes sense as a process doc and to match EIP-1

[eth-bot]

File EIPS/eip-7723.md

Requires 1 more reviewers from @ralexstokes, @timbeiko
Requires 1 more reviewers from @g11tech, @jochem-brouwer, @lightclient, @SamWilsn, @xinbenlv

[abcoathup]

Living makes sense as a process doc

My preference is final. If we want to change the inclusion stages again we should have a new EIP.

[nixorokish]

"Living" aligns better with its mostly closely related EIP, EIP-1. Why freeze the inclusion stages when they can be descriptive of a process that is evolving to find the most efficient path? Freezing them adds unnecessary bureaucracy and makes people feel like they have to conform reality to rules that described a process at a snapshot, but may not be the most efficient process now. Requiring that a whole new EIP gets written seems really unnecessary

[abcoathup]

Why freeze the inclusion stages when they can be descriptive of a process that is evolving to find the most efficient path?

The EIP only covers the inclusion stages and guidance on the stage transitions. It doesn't dictate the process beyond this. e.g. It doesn't cover headliners at all. Which gives plenty of scope for the process to evolve without changing the inclusion stages.

The EIP process should work for the core devs (and not the other way around). So I won't oppose making this living.

I generally dislike living EIPs as they need to be maintained and we don't know who the future maintainers will be in years to come. e.g. the OG author is moving on from L1 R&D.

I'm concerned about capture, which in my view, appears easier with modifying a living EIP compared with have to convince core devs to adopt a completely new EIP.

[poojaranjan]

With due respect, before debating the “EIP status”, I would argue that the EIP itself is confusing in its current form.

The Motivation states: “This EIP proposes definitions for the various stages EIPs go through when planning network upgrades.”

However, throughout the document, the term “status” is used interchangeably with “stage”, which creates ambiguity.

To be clear:

• EIP status refers to the standardization and review lifecycle of an EIP.
• EIP stages refer to the network upgrade planning and deployment process.

These are two distinct concepts, and conflating them risks long-term confusion, especially for new contributors and readers of the specification.

This may have been missed earlier, but it can still be corrected. There is an open PR addressing this inconsistency. I would request the authors to review it and either merge it if appropriate, or explicitly explain the rationale for rejecting it.

The purpose of progressing through EIP statuses is to enable review and convergence. A clear response from the authors, whether to accept or close earlier PR before responding to this change, would help keep the process moving forward.

[poojaranjan]

"Living" aligns better with its mostly closely related EIP, EIP-1. Why freeze the inclusion stages when they can be descriptive of a process that is evolving to find the most efficient path? Freezing them adds unnecessary bureaucracy and makes people feel like they have to conform reality to rules that described a process at a snapshot, but may not be the most efficient process now. Requiring that a whole new EIP gets written seems really unnecessary

I understand the concern about adding extra process, and I agree that rules should not force people to follow an outdated snapshot of reality.

That said, EIP stands for Ethereum Improvement Proposal. If something is meant to be treated as a standard process, it needs to be clearly defined and moved to Final status. When the situation changes, writing a new EIP is completely reasonable. It helps clearly document what changed and why, which is useful for future contributors.

Editors have always preferred lightweight EIPs, and I support creating new EIPs when needed instead of stretching existing ones beyond their original scope.

Regarding EIP-7723 blocking the Fusaka Meta EIP: similar to what was done for Pectra Meta EIP, it does not need to be listed as required considering the process is still experimental. In that case, EIP-7606 can still move to Final status and status for EIP-7723 can be discussed separately.

[nixorokish]

removing 7723 from 7607