Ethereum Governance 101
How Ethereum governance works
Ethereum's rules change all the time. Here's how a change goes from idea to a live upgrade, who controls each step, and how validators get a say.
A common misconception
Most people assume changing Ethereum is rigid and formal - a vote, a committee, a rulebook. It is almost the opposite. Ethereum has no on-chain governanceDeciding protocol changes through votes recorded on the blockchain, usually weighted by governance tokens. Ethereum does not use this for protocol governance.: no board, no company, and no coin-vote that decides the protocol. Changes happen when researchers, client teamsIndependent groups that build different implementations of Ethereum's software. Multiple teams implement the same protocol rules, so no single team controls the network., and the wider community reach rough consensusBroad enough agreement among relevant Ethereum stakeholders to move forward without a formal vote. Serious objections are discussed rather than simply outvoted.: enough agreement, among the people who build and run the network, that no one with a serious objection is being ignored. It is far more fluid than most people expect, and the rest of this page is just the shape that process takes.
The lifecycle of a change
From an idea to a live upgrade
Each step has a typical trigger and a set of actors with the most direct influence. Watch how responsibility shifts as an idea moves toward a live upgrade.
- 1
An idea takes shape
Someone spots a problem or an improvement and writes it up. At this point it is just an idea, with no status and no EIPAn Ethereum Improvement Proposal: a standard document for proposing or documenting changes to Ethereum. number.
- Trigger
- Anyone publishes a write-up or research post.
- Driven by
- Anyone. There is no gatekeeper to have an idea.
- 2
The community debates it
EVA signal windowThe idea is pressure-tested in the open. Most of this debate happens on Ethereum Magicians, and for earlier-stage research on ethresear.ch, where developers and researchers challenge the design, surface objections, and refine it. Every Draft EIP links to its own discussion thread so the conversation stays in one place.
- Trigger
- The author opens a discussion thread and invites feedback.
- Driven by
- The author drives it; anyone can weigh in. No approval needed.
- 3
It becomes a formal EIP
EVA signal windowThe proposal is submitted to the canonical EIP repository. An EIP editor reviews it for completeness, format, and basic technical soundness, assigns an EIP number, and merges it as a Draft. Until it is merged it has no canonical number, which is why some proposals show as pending. Being tracked as an EIP says nothing about whether it will ultimately be adopted.
- Trigger
- The author opens a pull request that meets EIP-1's format; an editor reviews it, assigns a number, and merges it as a Draft.
- Driven by
- EIP editors: a small, defined group responsible for the editorial process, not deciding whether a proposal should ship.
- 4
Core developersThere is no official title or roster. In practice, the contributors whose protocol work the community trusts - client-team maintainers, protocol researchers, and long-time EIP contributors. Earned through track record, not appointed. consider it for an upgrade
EVA signal windowFor protocol-level (Core) changes, client teams, researchers, and other protocol contributors review the proposal through the All Core DevsRecurring calls where Ethereum protocol contributors discuss technical changes and coordinate network upgrades. process. Proposals can be considered and later scheduled for inclusion in a specific network upgrade.
- Trigger
- Rough consensus on an All Core Devs call to consider, then schedule, the EIP for an upgrade.
- Driven by
- Client teams and protocol contributors coordinating through All Core Devs. There is no formal validator vote.
- 5
Client teams implement it
Each independent team builds the change into its own software. Ethereum's client diversity means no single team can push a change through alone.
- Trigger
- An EIP is scheduled for an upgrade.
- Driven by
- Each client team, independently, across several execution and consensusEthereum's software has two halves: an execution layer (runs transactions) and a consensus layer (agrees on the chain). clients.
- 6
Everything gets tested
Implementations run on shared devnetsUsually short-lived developer networks for testing an upgrade across clients before it reaches public testnets. and public testnetsPublic practice networks that behave like Ethereum using test ETH intended to have no real-world value. with cross-client tests. A mainnet date is not set until testing holds up.
- Trigger
- Implementations are ready to run against each other.
- Driven by
- Testing teams and client teams, coordinating devnets and test suites.
- 7
It ships in an upgrade
Core developers coordinate an activation time and client teams publish releases containing the upgrade. Node operators and validators then choose whether to run those releases. No developer or client team can force operators to adopt new protocol rules.
- Trigger
- Core devs coordinate an activation time, then node operators and validators upgrade.
- Driven by
- All Core Devs coordinates activation; client teams ship the software; node operators and validators choose what to run.
Where EVA fits in
Giving validators a voice, without changing the rules
ValidatorsValidator instances backed by staked ETH that participate in Ethereum consensus by proposing and attesting to blocks. A single operator may run many validators. secure the chain and ultimately choose which software to run, yet they have never had a formal voice in protocol decisions - until now. EVA gives them one: a private, verifiable, stake-weightedEach signal counts in proportion to the ETH staked behind it, so results reflect the amount of stake represented, not the number of wallets. signal of support or opposition, as one more input into rough consensus.
Sentiment, not governance
EVA is deliberately non-binding. It does not decide whether an EIP ships, and it takes no position on any proposal. It shows what validators think, accurately and verifiably, and leaves the decision where it has always been: with Ethereum's open, rough-consensus process.
How to participate
Find your lane
You run validators
Connect your wallet, prove your validators, and signal privately on the EIPs that matter to you. Your weight scales with your stake.
Start signalingYou are writing an EIP
Feature your proposal as a campaign and get stake-weighted feedback from validators worldwide, early, while it still counts.
Launch a campaignYou want to follow along
No wallet needed. The whole process is public - read the proposals, join the discussion, and follow the dev calls as they happen.
Browse the EIPsCommon questions
FAQ
Is rough consensus decided by a vote?
No, there is no formal ballot. On the All Core Devs calls a facilitator reads the sense of the room: client teams and researchers voice support or objections, and if no one has a serious, unaddressed objection, it moves forward. Informal temperature checks are sometimes used, but they are advisory, not binding. The test is whether any credible objection is being ignored, not whether a majority said yes.
Where and when does that actually happen?
On the All Core Devs calls, split between the execution layer (ACDE) and the consensus layer (ACDC), held roughly every two weeks and streamed in public. That is where an EIP is considered for, then scheduled into, a specific network upgrade, and the notes are published openly. See the meeting notes.
Is there a deadline after which an EIP can't be challenged?
Not exactly. An EIP's Last Call is typically a two-week final review period before its specification can become Final, but EIP status and network-upgrade inclusion are separate processes. A Core EIP can still be changed, delayed, or removed from an upgrade if implementation, testing, security review, or further discussion surfaces a serious problem. The later you raise it, the stronger your technical case has to be, but that openness is a safety feature, not a loophole.
Who is allowed to signal?
Verified validator operators who can prove control of one or more active validators. Verification happens by signing a message from the wallet that deposited the stake.
Is my individual signal public?
No. Individual signals are private by default, only aggregate, stake-weighted results are shown. See the methodology.
How is my signal weighted?
By the ETH staked behind the validators you control, so results reflect stake at risk, not wallet counts. See the methodology.