The mechanics of how EIPs move through the Ethereum governance process — from proposal to mainnet.
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 — they're expected not to delay the headliners.
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 must have executable specifications. The bar is higher than CFI — SFI means “we're confident this will ship.”
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.
When your EIP is on the agenda, attend the call (or send a representative). Decisions can be made without you.
Protocol decisions can move fast. To avoid being caught off guard:
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.
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.
tests/unscheduled/ directory.#el-testing for help.#cl-testing for help.