Navigating the Process
The mechanics of how EIPs move through the Ethereum governance process, from proposal to mainnet.
Headliners vs. Non-Headliners
Since the Pectra upgrade, Ethereum forks follow a headliner-first model. A small number of major features (typically one per layer) are chosen first to define the fork's goals. Non-headliner EIPs are then collected during a proposal window and evaluated as a batch, and they're expected not to delay the headliners.
EIP Stages: PFI → CFI → SFI
Defined in EIP-7723, these are the inclusion stages every Core EIP moves through for a given fork:
Anyone can open a PR against the fork's Meta EIP to propose an EIP during the PFI window. After PFI, your job is to ensure implementations are progressing, surface concerns early, stay active in R&D Discord, and optionally create a Forkcast entry to help ACD participants understand your EIP.
Moving PFI → CFI happens when your EIP is discussed on an ACD call during the designated window and rough consensus is reached. The ACD facilitator updates the Meta EIP. This is your green light to get serious about implementation: CFI means the EIP will be part of the devnet cycle.
SFI means the EIP has achieved rough consensus and is on the path to mainnet (devnets → testnets → mainnet). To reach SFI, your EIP musthave executable specifications. The bar is higher than CFI: SFI means “we're confident this will ship.”
Where Decisions Happen
Ethereum protocol decisions happen across a handful of recurring calls and async channels. Understanding which venue is appropriate for what saves you time and gets you heard.
| Call | When | Focus |
|---|---|---|
| ACDE | Every other Thursday, 14:00 UTC | Execution layer: what goes in the fork + status updates |
| ACDC | Alternating Thursdays, 14:00 UTC | Consensus layer: same scope as ACDE but for CL |
| ACDT | Every Monday, 14:00 UTC | Implementation & testing: how to build it, debugging, devnets |
Async: The Eth R&D Discord is the primary async venue. Key channels include #allcoredevs, #execution-dev, #consensus-dev, and the relevant testing channels.
Getting on the agenda:Anyone can propose a topic by commenting on the relevant call's ethereum/pm issue. Agendas are typically finalized the day before the call.
Call Expectations
When your EIP is on the agenda, attend the call (or send a representative). Decisions can be made without you.
- Submit a written update ahead of time (on the agenda issue or in R&D Discord)
- Send someone to represent your update
- Catch up by reading the transcript and summary on Forkcast
Staying Informed
Protocol decisions can move fast. To avoid being caught off guard:
Running a Breakout Call
If your EIP has active development work or open questions that can't fit in the ACD agenda, consider organizing a breakout call. You'll be responsible for getting the right people to attend.
When to start one:There's active work or open questions, it can't fit in ACD, and enough people will attend to make it worthwhile.
Breakouts are organized via issues in the ethereum/pm repo. See the guide to running a breakout call for setup details.
Implementation & Testing
Implementing your EIP in the relevant Python specifications early is one of the strongest things you can do. It lets the community collaboratively disambiguate the spec and generates reference tests for client teams. To reach SFI, executable specifications are required.
Execution Layer
- Implement changes in execution-specs (EELS). EIP authors are encouraged to try the implementation themselves; EELS maintainers regularly step in once a PR is created.
- Reference the EIP Author's Manual.
- Add test cases in the
tests/unscheduled/directory. - Reach out to the STEEL Team in R&D Discord
#el-testingfor help.
Consensus Layer
- Implement the feature in the consensus-specs repository. Maintainers will provide feedback once a PR is created.
- Reference the feature addition docs.
- Reach out in R&D Discord
#cl-testingfor help.