Short answer: Ethereum in 2026 is strongly decentralized at the node and validator-count layer, and measurably centralized at three specific chokepoints — consensus client software, staking custody, and block building. Anyone asking how decentralized is ethereum deserves a number rather than an adjective, so this page measures six axes, shows the source and snapshot date for every figure, and calculates a Nakamoto coefficient ourselves because no dashboard we checked publishes one for Ethereum. The headline finding: at least one consensus client sits above the 33% safety threshold, and the two most-cited datasets disagree about which one it is.
Last verified: 31 July 2026. Every value below carries its own as-of date. Crypto metrics decay in weeks, not years — if you are reading this months later, treat the dates as the real content and re-read the linked dashboards yourself.
The short answer: how decentralized Ethereum is in 2026
Decentralization is not one property. It is a bundle of independent failure modes, and Ethereum scores very differently on each. The protocol has tens of thousands of independently operated consensus nodes and a validator set that no single party can unilaterally halt — that part is genuinely robust. But the software those validators run, the entities that custody their stake, and the handful of relays that deliver their blocks are all far more concentrated than the validator count suggests.
The distinction that matters most, and that most coverage collapses: custody of stake is not the same thing as control of consensus, and neither is the same thing as control of block content. A staking pool can hold a quarter of all staked ETH while its individual node operators each sign with their own keys and their own client software. A relay can deliver 40% of blocks without ever being able to alter the chain’s history. Conflating these produces either false alarm or false comfort. Below, each is measured separately.
A concrete illustration makes the distinction easier to hold onto. Take a staking pool holding roughly a quarter of all staked ETH, split across several hundred professional node operators spread across a dozen or more jurisdictions, each running its own hardware and, between them, a mix of consensus clients. That pool’s headline size says almost nothing about consensus risk on its own, because no single operator inside it can act without the others agreeing, and the pool’s governance cannot make an individual operator’s validators sign anything. Now compare a single custodial exchange holding a tenth of staked ETH on its own servers: every validator in that pile runs on the same infrastructure, under the same legal jurisdiction, and can be redirected by one internal decision. Two entities that look similar in size on a pie chart carry entirely different collusion risk — which is exactly why the staking axis further down this page computes a coefficient two different ways rather than settling on one number.
There are exceptions to the “the base layer is fine, the chokepoints aren’t” framing above, and they are worth stating rather than glossing over. Solo stakers running their own validator score well on every axis by definition, but they are a shrinking share of new deposits, because funding 32 ETH and running dedicated hardware is a higher bar than delegating to a pool or handing custody to an exchange — the axis that looks healthiest in aggregate today is also the one most exposed to slow erosion at the margin over the coming years. Node count itself is not immune to concentration either: a meaningful share of reachable consensus nodes run on a small number of cloud hosting providers, so a single hyperscaler outage, not a protocol bug, is a realistic way for what looks like “tens of thousands of independent nodes” to go offline in a correlated way within minutes.
The 2026 scorecard at a glance
One row per axis. The risk threshold column is the mechanical boundary at which that axis starts to affect chain security or neutrality — not an opinion, but a property of the consensus rules or of the market structure.
| Axis | Metric | Value | As of | Source | Risk threshold | Status |
|---|---|---|---|---|---|---|
| 1. Consensus clients | Largest client share of the validator set | 50.45% (Lighthouse) or 53.86% (Teku) — the two datasets disagree | 26 Jul 2026 | Miga Labs / monitoreth.io; Rated.Network | 33% breaks the inactivity leak; 66% enables finality reversal | Fail — both readings breach 33% |
| 2. Execution clients | Largest client share | Current reading unverified at time of writing; widely quoted 43% figures are stale | — | execution-diversity.info (current); supermajority.info (stale) | 33% for a client-triggered chain split | Unverified — data layer is the problem |
| 3. Staking concentration | Largest single staking entity’s share of staked ETH | Lido, ≈mid-20s% on last published readings; exact current share unverified | Unverified at time of writing | Dune, beaconcha.in, lido.fi/scorecard | 33% of stake for liveness influence | Watch |
| 4. ETF custody | Share of US spot ETH ETF assets at a single custodian | Coinbase Custody is the dominant named custodian across issuers; exact aggregate share not published in a single filing | Unverified at time of writing | Issuer prospectuses and N-CSR/8-K filings | No consensus threshold — this is a counterparty risk, not a chain risk | Concentrated |
| 5. MEV relays and builders | Share of blocks via MEV-Boost; top builder share | Majority of blocks are relay-delivered; per-relay and per-builder shares unverified at time of writing | Unverified at time of writing | relayscan.io, mevboost.pics | Censorship becomes practical when few builders serve most blocks | Fail on structure, regardless of exact split |
| 6. Node cost and access | Hardware and storage needed for a full node | Consumer-grade NVMe machine still sufficient per client docs | Client repo docs, 2026 | Geth, Nethermind, Lighthouse, Teku, ethrex repositories | Cost that prices out home operators | Pass |
Verdict in one line: Ethereum passes on permissionless participation and fails on software monoculture and block-building concentration. Those two failures are unrelated to each other and have different fixes.
How do you actually measure blockchain decentralization?
There is no single accepted answer to how is blockchain decentralization measured, which is precisely why so much writing on the subject is unfalsifiable. The workable approach is to stop asking whether a chain “is decentralized” and instead ask: for each way this chain could fail or be captured, how many independent parties would have to cooperate? That reframing turns a philosophical argument into arithmetic. If you are new to the underlying mechanics, our explainer on how blockchain technology works covers the consensus layer this page assumes.
Every figure in this article is presented in the same five-part shape: metric, value, as-of date, source, risk threshold. The risk thresholds used throughout come from Ethereum’s proof-of-stake consensus rules as specified in the Ethereum consensus and execution layer specifications, and they are mechanical, not rhetorical:
- 33% (one third) — the inactivity leak boundary. Ethereum finalizes when two thirds of the staked ETH attests to a checkpoint. If more than one third of the validator set goes offline or attests incorrectly at once, the chain cannot finalize. The inactivity leak then bleeds stake from the non-participating validators until the participating set climbs back above two thirds. The chain survives, but finality stalls for a period measured in days, and the offline validators are penalized whether or not their absence was intentional.
- 50% — the point at which a coordinated set can consistently win the fork-choice race and build a chain other honest validators follow, enabling short-range reorganizations and reliable transaction exclusion.
- 66% (two thirds) — the finality reversal boundary. Above this, a coordinated set can finalize two conflicting checkpoints. This is the catastrophic case; it is also the one where social-layer recovery and mass slashing are explicitly designed to apply.
Client diversity thresholds map onto these directly. As clientdiversity.org sets out, a client above 33% of the validator set means a single software bug can push more than a third of validators into wrong or absent attestations simultaneously — a correlated fault. Above 66%, a buggy client can finalize an invalid chain that the rest of the network will reject, and the bug becomes the canonical chain for anyone running that client.
Why every figure on this page carries a date
A staking share, a client share and a relay share are all moving targets that can shift several percentage points inside a month. An undated number in this subject area is not a fact — it is a claim about an unspecified past. That is why this page states a snapshot date per cell, and why we say “unverified” or “not published” rather than estimating when a primary source could not be read at the time of writing.
The stale-data problem is not hypothetical here. It is the entire story of Axis 2 below, where the execution-client figures most frequently quoted in 2026 come from a dashboard that stopped updating more than a year ago, and are still being repeated as current.
Axis 1 — Consensus clients: does Ethereum have a supermajority client, and can anyone tell?
This is the finding that should lead any honest 2026 scorecard, and it is uncomfortable: the two most authoritative public datasets on consensus client distribution disagree about which client holds a supermajority.
On the 26 July 2026 readings that prompted this audit, Miga Labs / monitoreth.io showed Lighthouse at 50.45% of the validator set, while Rated.Network showed Teku at 53.86%. These are not adjacent numbers with overlapping error bars pointing at the same client. They name different clients as the dominant one, at similar magnitudes. Both readings put a single client above half the validator set, and both are far past the 33% line.
| Source | Client named as largest | Reported share | As of | Method | Known limitation |
|---|---|---|---|---|---|
| Miga Labs / monitoreth.io | Lighthouse | 50.45% | 26 Jul 2026 | Network crawler — connects to peers on the discovery layer and fingerprints them from protocol-level behavior and version strings | Measures nodes reachable on the p2p network, not validators. Large operators run many validators behind few nodes; unreachable and firewalled nodes are undersampled |
| Rated.Network | Teku | 53.86% | 26 Jul 2026 | Inference from on-chain behavior — attestation timing, aggregation patterns and block-packing fingerprints attributed to validator indices | Inference, not observation. Clients whose behavioral signatures converge are hard to separate; attribution confidence is not uniform across the set |
| Adjudication | — | Not possible with public data | 31 Jul 2026 | — | There is no on-chain field in which a validator declares its client. Any figure is an estimate from one of the two methods above |
The methodological divergence explains how both can be produced in good faith. A crawler counts hosts; a behavioral classifier counts validators. A single Teku node running several thousand validators appears once to a crawler and several thousand times to a validator-weighted classifier. If the largest professional operators cluster on one client and the long tail of home stakers clusters on another, the two methods will name different winners — which is close to what these two readings look like.
The honest position, and the one we take: the Ethereum ecosystem currently cannot adjudicate which consensus client holds the supermajority. That is itself a finding about decentralization measurement, not a footnote. What is not in dispute is the part that matters for risk: on both readings, one client is above 33%, and on both readings it is above 50%. The ethereum consensus client supermajority 2026 question does not hinge on resolving the disagreement.
What a client supermajority would actually do to the chain
A consensus-critical bug in a client running under 33% of validators is a bad day for that client’s users: their validators miss attestations, leak a little stake, and get fixed. The chain finalizes throughout. Above 33%, the same bug becomes a network event — finality stalls, the inactivity leak activates, and every validator running the affected client bleeds stake for as long as the fix takes to ship and be adopted. Recovery is measured in hours to days, and requires client teams to diagnose and patch under pressure.
Above 66% the failure mode inverts and gets worse. A supermajority client that produces an invalid block will finalize it among its own users, because it holds enough attesting weight to satisfy the finality rule by itself. Minority clients correctly reject the chain and follow a different fork. Now there are two finalized, mutually incompatible chains, and no protocol-level rule resolves it — the resolution is social, slow and contested, and the affected validators face correlated slashing, where the penalty scales with how many validators committed the same offense at the same time. That scaling is deliberate: it makes isolated mistakes cheap and coordinated ones ruinous, which is exactly why a monoculture is dangerous. Everyone running the same buggy client fails together, and the protocol charges them as if they had colluded.
Three practical mitigations exist today and are worth stating precisely, because they are frequently overstated:
- Switching clients reduces your own correlated-slashing exposure and the network’s. It is the only mitigation an individual operator fully controls.
- Distributed validator technology (DVT) splits a single validator key across multiple machines that must cooperate to sign. Configured across different clients, it also reduces single-client exposure — but DVT primarily addresses operator risk, not client risk, and only reduces client risk if the operators deliberately diversify.
- Slashing protection and doppelgänger detection prevent accidental double-signing. They do nothing about a consensus bug that makes an honest validator attest to the wrong chain.
Axis 2 — Execution clients: the numbers everyone quotes are more than a year old
The execution layer runs the EVM, holds state, and validates transactions. Its client distribution is separately measured from the consensus layer, because a validator pairs one execution client with one consensus client and the pairings are not correlated.
Here the problem is not two sources disagreeing. It is one source being wrong and everyone quoting it anyway. The figures circulating in 2026 as current execution client shares — commonly cited as roughly 43% Nethermind and 43% Geth — trace back to supermajority.info, whose own last-updated stamp is more than a year old. We are deliberately not reproducing those numbers as a current value, because they are not one. The maintained source for ethereum execution client diversity current data is execution-diversity.info, and that is where a reader should take a reading.
| Source | What it reports | Last updated | Usable in 2026? | Note |
|---|---|---|---|---|
| execution-diversity.info | Execution client distribution, maintained | Live at time of reading | Yes | Current reading not captured at time of writing — unverified. Read it directly |
| supermajority.info | Execution client distribution | Over one year stale as of 26 Jul 2026 | No | Source of the widely repeated ~43%/~43% pairing. Cited here as evidence of staleness, not as data |
| clientdiversity.org | Thresholds, rationale and switching guides | Maintained | Yes, for methodology | Best reference for why the 33%/66% lines exist |
| ethrex | New execution client | Roughly six months in production as of 26 Jul 2026 | Emerging | Share too small to affect thresholds; matters as evidence the client set is still growing |
Two structural points survive the data gap. First, execution-layer diversity has historically been worse than consensus-layer diversity, because Geth’s incumbency predates the merge by years and the migration cost for a large operator is real — resyncing state and revalidating an archive is days of work, not an afternoon. Second, the execution layer has a distinct failure signature: a consensus bug in an execution client causes affected nodes to compute a different state root and reject valid blocks, which under a supermajority client means the invalid state becomes canonical for most of the network.
The arrival of ethrex, roughly six months in production as of the July 2026 snapshot, matters less for its share — which is negligible — than for what it signals: the client set is not calcifying. Each additional independent implementation lowers the probability that any one bug is network-wide, provided operators actually adopt it. Client diversity is a demand-side problem, not a supply-side one. There have been credible minority execution clients for years, and the share numbers stayed lopsided anyway.
A concrete example shows how a stale dataset entrenches itself. The ~43%/~43% Geth-Nethermind pairing now repeated across 2026 commentary did not appear out of nowhere — supermajority.info was the standard reference for years, cited in conference talks and in earlier editions of pages like this one, before it quietly stopped updating at some point in 2025. No changelog announced the dashboard had gone dark; the numbers simply stopped moving, and because the last snapshot was plausible — two large clients near parity, roughly matching Geth’s long-standing dominance — nobody had an obvious reason to double-check it. That is precisely the failure mode that makes execution-client tracking harder than consensus-client tracking: the underlying software split changes slowly, but the monitoring layer sitting on top of it can go silently stale while looking exactly as healthy as it did the day before.
One exception is worth flagging so the caution above isn’t overread: a rough Geth-and-Nethermind duopoly, even with the exact decimals stale, is not obviously a wrong structural description — the migration-cost argument two paragraphs up has held for years, and nothing indicates a third established client closed meaningful share in 2025 or 2026 the way ethrex is now attempting to. The objection here is to citing a specific stale percentage as if it were a current reading, not to the general shape of two large incumbents and a long tail. Archive-node operators are a further exception to the “switching clients is straightforward” framing used elsewhere on this page: an archive node holding full historical state can take weeks to resync against a new client, which is why the largest infrastructure providers and block explorers — often the most exposed to a client-specific bug — are also frequently the slowest to diversify away from one.
Axis 3 — Staking concentration: how much of Ethereum does Lido and Coinbase control?
This axis is where most public argument happens and where most public argument is imprecise. The lido share of staked eth question has a real answer, but the answer means something different depending on what you think “Lido” is.
Lido is a protocol, not an operator. ETH deposited into Lido is delegated across a curated set of professional node operators, each running their own infrastructure with their own keys and their own client choices. The Lido DAO controls which operators are in the set and can add or remove them; it does not itself sign attestations. Coinbase, by contrast, is an operator and a custodian simultaneously — it holds customer ETH, runs the infrastructure, and signs with keys it controls. Two entities with similar reported shares therefore represent structurally different risks, and any measurement that treats them as equivalent is measuring the wrong thing.
| Entity | Share of staked ETH | As of | Structure | Operator count | Custody model |
|---|---|---|---|---|---|
| Lido | ≈mid-20s% on last published readings; current share unverified at time of writing | Unverified | Liquid staking protocol, DAO-governed | Curated set plus Simple DVT clusters; exact count per lido.fi/scorecard, last published Q4 2025 | Non-custodial to the protocol; keys held by individual node operators |
| Coinbase | Unverified at time of writing | Unverified | Centralized exchange and institutional staking provider | Single operator | Custodial — exchange holds and signs |
| Binance | Unverified at time of writing | Unverified | Centralized exchange | Single operator | Custodial |
| Other CEXs and institutional providers | Unverified at time of writing | Unverified | Mixed | Various | Mostly custodial |
| Solo and small-scale stakers | Unverified at time of writing | Unverified | Independent 32 ETH validators and small pools | Many thousands | Self-custody |
We are not filling those cells with numbers we did not read from a primary source. To take your own reading, use beaconcha.in for validator count and entity attribution, cross-check against a public Dune dashboard on staking entity share (record the dashboard ID and your query date), and read Lido’s own operator-level metrics from its scorecard, noting that the last published edition we are aware of is Q4 2025 — which is itself a data-freshness problem when the metric moves quarterly.
The concentration pattern here is not unique to staking. Ethereum’s stake distribution has the same long-tail shape as token ownership generally, where a handful of addresses hold a disproportionate slice — the same dynamic we documented when examining the concentration of tokens among large holders on other networks. What distinguishes staking is that the concentration converts directly into consensus weight rather than merely into market power.
The mechanical risk from ethereum staking centralization is bounded by the same thresholds as everything else. A single entity above 33% of stake can stall finality by going offline. Above 66%, it can reverse finality. But note what a large staking share does not give you: it does not let you steal user ETH under Lido’s design, it does not let you rewrite history below the finality threshold, and it does not let you unilaterally exclude transactions, because block content is decided by builders, not by whoever owns the stake — which is Axis 5.
Does Simple DVT actually decentralize a staking pool?
Partly, and it is worth being precise about which risk it retires. Simple DVT splits a validator key across a cluster of independent operators using threshold signatures, so no single member can sign alone and the validator survives any single member going offline. Roughly a year in production as of the July 2026 snapshot, it has been Lido’s main answer to the concentration critique.
What it genuinely fixes: single-operator failure and single-operator coercion. A cluster of independent parties in different jurisdictions cannot be compelled by one subpoena or taken down by one data-center outage. It also widens the operator set to smaller participants who could not meet a professional operator bar alone.
What it does not fix: protocol-level governance concentration. The DAO still decides who is in the set and under what terms. If you are measuring “how many independent parties would have to cooperate to move this stake”, DVT raises the number substantially. If you are measuring “how many governance decisions control this stake”, it does not change it at all. Both are legitimate questions; they have different answers, and the Nakamoto calculation below shows exactly how much that modelling choice swings the result.
Axis 4 — ETF custody: how concentrated is institutional ETH?
US spot ETH ETFs introduced a concentration vector that did not exist before 2024: large pools of ETH held by regulated issuers, almost all of whom name the same custodian. This is a genuine single point of failure, but it is a counterparty and legal single point of failure, not a consensus one — and the difference matters.
| Metric | Value | As of | Source | Risk threshold |
|---|---|---|---|---|
| Dominant named custodian across US spot ETH ETFs | Coinbase Custody Trust Company, named by the majority of issuers | Per each issuer’s current prospectus | Issuer prospectuses and registration statements | No consensus threshold; concentration is an operational and legal risk |
| Aggregate ETH held across US spot ETH ETFs | Not published as a single figure — must be summed from individual issuer disclosures | Per issuer reporting date | Issuer daily holdings pages and periodic filings | — |
| Share of ETF-held ETH that is staked | Unverified at time of writing — varies by issuer and by product terms | Unverified | Issuer prospectus supplements | Staked ETF ETH converts custody concentration into consensus weight |
| Custodian diversification | Some issuers name secondary or additional custodians; terms differ per product | Per prospectus | Issuer filings | — |
The critical variable is the third row. Unstaked ETF ETH is inert from a consensus perspective — it sits in cold storage, attests to nothing, and has no more effect on the chain than any other dormant balance. The moment an issuer stakes it, that same concentration becomes validator weight controlled by one custodian acting under one legal regime. Whether and how much ETF ETH is staked is therefore the single number to watch on this axis, and it is disclosed in prospectus supplements rather than in any dashboard. Readers tracking how these products evolved will find context in our coverage of institutional ETF custody developments.
Read the filings themselves rather than a summary. Custody arrangements, staking permissions and sub-custodian terms change by amendment, and secondary reporting lags those amendments by weeks.
Axis 5 — MEV and relays: who really builds Ethereum’s blocks?
Ethereum’s block production has been effectively outsourced since MEV-Boost’s arrival. The mechanism is proposer-builder separation in its current, off-protocol form: a validator selected to propose a block does not usually construct it. Instead it queries relays, receives sealed bids, signs the header of the highest bidder without seeing the contents, and the relay publishes the body. The mev boost relay market share ethereum question is therefore a question about who controls what actually goes into blocks.
The supply chain has three distinct layers, and conflating them produces bad analysis:
- Searchers find profitable transaction orderings and submit bundles.
- Builders assemble complete blocks from bundles and mempool transactions, competing on total value. This is where transaction inclusion is actually decided.
- Relays sit between builders and proposers, holding the block body until the proposer commits, so neither side can steal from the other. A relay is a trusted intermediary for escrow and data availability — it does not choose transactions.
| Layer | Entity type | Share of blocks | As of | Source | Failure mode if concentrated |
|---|---|---|---|---|---|
| Proposer path | Blocks delivered via MEV-Boost vs locally built | Majority relay-delivered; exact split unverified at time of writing | Unverified | relayscan.io | Local building is the fallback if relays fail — a low local share means low resilience |
| Relays | Flashbots, bloXroute, Agnostic, Ultra Sound, Titan and others | Per-relay shares unverified at time of writing | Unverified | relayscan.io, mevboost.pics | Relay outage degrades proposer revenue; relay filtering enables address-level censorship at the delivery layer |
| Builders | A small number of dominant builders | Per-builder shares unverified at time of writing | Unverified | mevboost.pics | This is the real chokepoint. Few builders serving most blocks means few parties decide inclusion |
Even without current percentages, the structural finding holds and has held for years: builder concentration is consistently tighter than relay concentration, because block building is a capital-intensive, latency-sensitive, winner-take-most business, while running a relay is comparatively commoditized. Coverage that reports relay share as the censorship metric is measuring the less concentrated layer.
The mev censorship risk is real but bounded in a specific way. A builder that excludes certain addresses does not remove them from Ethereum — it delays them. Any proposer building locally, or using a non-filtering relay, can include the transaction. The practical effect is higher latency and worse inclusion odds for filtered transactions, not permanent exclusion. That is a meaningful degradation of neutrality and a poor foundation for a settlement layer, but it is not censorship in the strong sense, and the distinction should not be blurred.
What ePBS changes — and what it does not
EIP-7732 proposes enshrined proposer-builder separation: moving the proposer-builder split from the off-protocol MEV-Boost arrangement into the consensus protocol itself, so the escrow function currently performed by trusted relays is enforced by the protocol. Anyone writing about eip-7732 epbs glamsterdam explained should check its current status directly in the official Ethereum Improvement Proposals repository and in All Core Devs notes, because inclusion in a hard fork is a decision that can and does change between calls. We have not re-verified the finalized Glamsterdam scope against those primary sources at time of writing, and readers should treat any scope claim they encounter — including inclusion of EIP-7732 — as unconfirmed until they read the EIP’s status field and the relevant meeting notes themselves.
Assuming it ships in the form proposed, what enshrined PBS fixes is the relay layer: it removes the trusted intermediary and with it relay outage risk, relay-level filtering and the operational fragility of a critical piece of infrastructure run as public goods by a handful of teams. What it does not fix is the layer that was more concentrated to begin with. ePBS does not make block building competitive. The economics that produce a small number of dominant builders — latency advantage, order flow relationships, capital for bidding — are untouched by moving the auction on-chain. Complementary approaches such as inclusion lists, which let proposers force specific transactions into blocks regardless of builder preference, target the censorship symptom directly and are a separate line of work.
Axis 6 — Can a normal person still run an Ethereum node?
This is the axis Ethereum passes most clearly, and the one most degraded by casual claims that node operation has become inaccessible. The honest position on cost to run an ethereum node 2026: it requires a deliberate hardware purchase and ongoing storage headroom, but it remains within consumer reach and does not require a data center.
Requirements as documented in the client repositories themselves — Geth and Nethermind on the execution side, Lighthouse and Teku on the consensus side, and the newer ethrex — cluster around a consistent profile:
- Storage is the binding constraint. A high-endurance NVMe SSD with substantial headroom above current chain size. SATA SSDs and any spinning disk are documented as insufficient for keeping up with head — this is about sustained random-read IOPS, not sequential throughput or raw capacity.
- RAM: comfortably in consumer desktop territory; the exact minimum differs per client and per sync mode, and archive configurations are an entirely different class of requirement.
- CPU: a modern multi-core desktop or mini-PC processor is adequate. This has not been a bottleneck for years.
- Bandwidth: a normal home broadband connection with an unmetered or generous data allowance. Peer-to-peer gossip is continuous and monthly volume is non-trivial.
- Sync time: snap sync brings an execution client to head in hours rather than the days a full historical sync takes; consensus clients use checkpoint sync from a trusted source to reach head in minutes. Both drastically lower the entry barrier and both are documented in the client repos.
The variable that determines whether this stays true is the gas limit. Raising it increases throughput and also increases state growth, bandwidth and the cost of staying synced — validators vote on it, which makes it a rare case of a decentralization-relevant parameter under continuous, direct operator control. Every increase is a deliberate trade of node accessibility for capacity.
The structural fix in progress is statelessness. Today, validating a block requires holding the full state. Under a stateless design, blocks carry cryptographic witnesses proving the state they touch, so a validating node can verify without storing everything. That would break the link between state growth and node cost entirely and is the single most important long-term change for this axis. It is also incomplete, and its timeline should be read from All Core Devs notes rather than assumed.
What is Ethereum’s Nakamoto coefficient in 2026?
The ethereum nakamoto coefficient is the minimum number of independent entities that must collude to compromise a chain — conventionally, the smallest set whose combined share crosses the critical consensus threshold. For Ethereum, the relevant threshold is 33% of staked ETH, because that is the point at which a coordinated set can prevent finality.
Two things must be said before any number appears. First, no third-party dashboard we checked publishes a Nakamoto coefficient for Ethereum — Chainspect, which publishes the metric for a range of other chains, does not have one for Ethereum. Second, the figure below is therefore our own calculation, and its value depends almost entirely on one modelling decision that we state up front rather than bury.
Entity-definition rule (state it before the arithmetic, or the result is unfalsifiable):
- An “entity” is a party that can independently decide whether its validators sign. Custody and legal control, not branding, determine the boundary.
- A centralized exchange or institutional provider that holds keys and runs infrastructure is one entity.
- A liquid staking protocol can be modelled two ways, and both are defensible: (A) aggregated — the protocol is one entity, on the grounds that its governance selects and can remove operators; or (B) decomposed — each node operator is a separate entity, on the grounds that each holds its own keys and signs independently. We compute both, because the choice changes the answer by more than an order of magnitude and no result is meaningful without disclosing which rule produced it.
- Solo stakers are individually below any threshold and are excluded from the accumulating set.
- Threshold: cumulative share > 33.0% of total staked ETH.
Worked example: calculating the staking Nakamoto coefficient step by step
Method — five steps you can reproduce:
- Pull the staking entity distribution from a public Dune dashboard or beaconcha.in and record the dashboard ID and your query date. That timestamp is part of the result.
- Apply the entity-definition rule above and merge any sub-entities that share custody.
- Sort entities by share of total staked ETH, descending.
- Accumulate row by row, keeping a running total.
- The coefficient is the row number at which the running total first exceeds 33%.
Model A — liquid staking protocol aggregated as one entity. The shares below are illustrative of the distribution shape on last widely reported readings and are not a verified current snapshot; substitute your own dated figures and rerun. The point of the exercise is the arithmetic and how sensitive it is, not these specific decimals.
| Rank | Entity | Type | Share of staked ETH (illustrative) | Running total | Crossed 33%? |
|---|---|---|---|---|---|
| 1 | Lido (aggregated) | Liquid staking protocol | ≈25% | ≈25% | No |
| 2 | Coinbase | Custodial exchange | ≈9% | ≈34% | Yes |
| 3 | Binance | Custodial exchange | ≈4% | ≈38% | — |
| 4 | Next largest provider | Institutional | ≈3% | ≈41% | — |
The running total crosses 33% at row 2. Nakamoto coefficient under Model A = 2. This result is robust to fairly large errors in the inputs: as long as the top entity is anywhere in the mid-20s and the second is mid-single-digits or higher, two entities clear the line. You would need the largest entity to fall below roughly 24% and the second and third to be small before the answer moved to 3.
Here is the same distribution as a share bar, drawn from the table above rather than copied from any dashboard — each block is roughly one percentage point of staked ETH:
33% threshold |
Lido (aggregated) █████████████████████████ | ≈25%
Coinbase █████████ ≈9% → cumulative ≈34% ✓ crosses
Binance ████ ≈4%
Next provider ███ ≈3%
^-- two entities clear the line
Model B — liquid staking protocol decomposed into its individual node operators. Now the same ≈25% is split across the curated operator set and the DVT clusters. Lido’s own scorecard is the source for the operator-level breakdown; note that the last published edition we are aware of is Q4 2025, so operator counts and per-operator shares from it carry that date.
The arithmetic changes completely. If ≈25% is spread across a curated set of professional operators plus DVT clusters, no individual operator holds more than roughly a percentage point or two of total staked ETH. The accumulation now looks like this:
| Rank | Entity | Share (illustrative) | Running total | Crossed 33%? |
|---|---|---|---|---|
| 1 | Coinbase | ≈9% | ≈9% | No |
| 2 | Binance | ≈4% | ≈13% | No |
| 3 | Next institutional provider | ≈3% | ≈16% | No |
| 4–n | Individual Lido node operators and remaining providers | ≈0.5–2% each | Accumulates slowly | Crosses only after many more rows |
With the remaining ≈17 percentage points made up of entities holding one to two points each, roughly ten to twenty additional rows are needed. Nakamoto coefficient under Model B lands in the region of 15–25 rather than 2 — an order-of-magnitude difference produced by a single definitional choice, with no change to the underlying chain.
What this actually tells you. The honest reading is that Ethereum’s staking Nakamoto coefficient is 2 if you believe liquid staking governance can direct its operators, and roughly ten times that if you believe operators act independently. Neither number is wrong; they answer different questions. Model A measures governance capture risk. Model B measures operational collusion risk. Anyone quoting a single Ethereum Nakamoto coefficient without stating which model they used is not giving you information — and that, more than the number itself, is why we published the rule before the arithmetic.
A concrete detail sharpens why the entity-definition rule matters beyond the headline arithmetic. Picture a single professional node operator that runs validators for Lido, for a smaller competing liquid-staking protocol, and for a few institutional clients directly, all from the same infrastructure and the same signing setup. Model B counts that operator once, inside Lido’s cluster — but if its work for other protocols isn’t tracked as the same entity, its true combined weight across pools is undercounted rather than overcounted. In other words, the decomposed model still assumes each protocol’s operator list is a closed set, when in practice some operators appear in more than one. That cross-protocol overlap is not published anywhere we could find, which means the ten-to-twenty figure under Model B should be read as a ceiling on the count of independent decision-makers, not a precise one — the true number could be lower, though it cannot be higher than what the decomposed model already produces.
One exception belongs in the same sentence as any figure quoted from this section: a coefficient built the same way for the consensus-client axis instead of the staking axis currently returns 1, not 2, because a single client already clears 50% on both public readings discussed under Axis 1. Reporting a staking Nakamoto coefficient of 2 — or of 15 to 25 under the decomposed model — while leaving that client-axis figure out of the same breath is how a technically accurate number ends up understating Ethereum’s most acute concentration risk. Any summary of “Ethereum’s Nakamoto coefficient” that doesn’t specify which axis it is describing should be treated as incomplete, not merely imprecise.
Two limitations to record. First, entity attribution on public dashboards is heuristic; validators are grouped by deposit address clustering and withdrawal-credential patterns, which misses relationships and occasionally invents them. Second, this coefficient covers stake only. A complete picture would need separate coefficients for client software, for builders and for relays — and on the client axis, given one client above 50%, that coefficient would be 1.
Is Ethereum more decentralized than Bitcoin, Solana or Cardano?
Cross-chain comparison is where blockchain decentralization ranking content usually goes wrong, because the chains do not share a threshold. Bitcoin’s consensus fails at 51% of hashrate; Ethereum’s finality fails at 33% of stake. A coefficient of 3 does not mean the same thing on both. Comparisons are only meaningful axis by axis.
- Against Bitcoin: Bitcoin’s concentration lives in mining pools, and its coefficient at the pool layer has often been low. The mitigating argument is that hashrate is rented — individual miners can redirect it to another pool, so pool share is less sticky than staked ETH. Ethereum’s counter-argument is that its validator set is far larger and its client set more diverse. Our overview of Bitcoin’s decentralization model covers the mining-pool structure in detail. On ethereum vs bitcoin decentralization, the honest verdict is that they are concentrated at different layers, and neither dominates across all six axes.
- Against Solana: the ethereum vs solana decentralization comparison turns on node cost and client diversity. Solana’s hardware requirements are materially higher, which structurally limits who can validate, and its client diversity has historically been narrower. Ethereum’s advantage here is real and is the direct product of the design choice to keep node requirements on consumer hardware.
- Against Cardano: Cardano’s stake pool model produces a large number of independently operated pools and a comparatively flat distribution, which scores well on a stake-based coefficient. Its execution client diversity is narrower. On ethereum vs cardano decentralization, Cardano tends to win on stake distribution and lose on implementation diversity.
There is no defensible answer to most decentralized blockchain 2026 as a single ranking. Any list that produces one has silently picked a weighting for the axes, and the weighting is doing all the work.
The governance axis: how centralized is the Ethereum Foundation?
Ethereum has no on-chain governance. Protocol changes move through the EIP process, are debated in All Core Devs calls, and take effect only when client teams implement them and node operators upgrade. The Ethereum Foundation funds research and development and employs people central to that process, but it cannot deploy a change — client teams write the code and operators decide whether to run it. That is a meaningful veto held by thousands of parties.
The concentration that does exist is one of influence and attention: a comparatively small group of researchers and core developers shapes which proposals get serious consideration, and Foundation funding weights that landscape. Measured as “who must agree for a change to ship”, ethereum foundation governance is distributed across client teams and operators. Measured as “who sets the agenda”, it is considerably narrower.
Where Ethereum’s decentralization is heading
Three changes would move the scorecard materially, and they run on independent timelines. Enshrined PBS would eliminate the trusted relay layer entirely, converting Axis 5’s relay row from a trust assumption into a protocol rule — while leaving builder concentration untouched. Statelessness would decouple node cost from state growth, protecting Axis 6 permanently against the gas-limit trade-off. Distributed validator technology at scale would keep raising the Model B coefficient on Axis 3 without requiring anyone to leave a staking pool.
None of these addresses Axis 1, which is the axis currently in breach. Client diversity has no protocol-level fix — it is a coordination problem solved one operator at a time, by individual operators choosing a minority client. It is also the only axis on this scorecard where a single reader’s decision measurably moves the number.
What to do now
- Check what client you are running, today. If you operate a validator, confirm your consensus and execution client versions and compare them against the current distributions at clientdiversity.org and execution-diversity.info. If you are on a client above 33%, you are carrying correlated-slashing risk you can eliminate.
- Take your own dated reading before you quote any figure from this page. Open Miga Labs/monitoreth.io and Rated.Network side by side, note both values and the date, and treat the gap between them as the measurement uncertainty.
- Stop quoting supermajority.info. Check its last-updated stamp yourself, then route to execution-diversity.info for any execution-layer claim.
- Reproduce the Nakamoto calculation with current inputs. Pull the staking distribution from beaconcha.in or a public Dune dashboard, record the dashboard ID and query date, and run both Model A and Model B. If your answer differs from ours, the disagreement will be in the entity-definition rule — which is the point.
- Read EIP-7732’s status field directly in the EIPs repository, plus the most recent All Core Devs notes, before repeating any claim about Glamsterdam scope. Fork inclusion changes between calls.
- If you hold ETH through an ETF, read the prospectus section on staking and custody — specifically whether the fund stakes, through whom, and which custodian holds the keys. That determines whether your exposure is inert or is consensus weight.
- Diary a re-check. Every figure here has a shelf life of weeks. Set a recurring reminder to re-read the six dashboards and update your own notes with fresh dates.
Frequently asked questions
Is Ethereum decentralized in 2026?
Partly. Ethereum passes on permissionless participation — anyone can run a node on consumer hardware and the validator set is large and globally distributed. It fails on consensus client diversity, where one client exceeds 50% of the validator set, and on block building, where a small number of builders assemble most blocks.
What is Ethereum’s Nakamoto coefficient?
It depends on one modelling choice, and no third-party dashboard we checked publishes a figure for Ethereum. Treating a liquid staking protocol as a single entity, our calculation gives 2 — two entities clear 33% of staked ETH. Decomposing that protocol into its individual node operators moves it into the region of 15–25. Both are correct; they answer different questions.
Does Ethereum have a supermajority client?
On the 26 July 2026 readings, yes — but the sources disagree on which. Miga Labs showed Lighthouse at 50.45% while Rated.Network showed Teku at 53.86%. The two use different methods (network crawling versus behavioral inference) and the ecosystem cannot currently adjudicate between them. Both readings breach the 33% safety threshold.
How much of Ethereum’s staked ETH does Lido control?
Lido has been the largest single staking entity, at roughly the mid-20s percent of staked ETH on last published readings; the current exact share is unverified at time of writing. Lido is a protocol, not an operator — the stake is delegated across independent node operators who hold their own keys, and the DAO selects that operator set.
How many validators does Ethereum have and who runs them?
The current validator count is unverified at time of writing and should be read from beaconcha.in. Structurally, the set is split between liquid staking protocols, custodial exchanges and institutional providers, and tens of thousands of solo stakers running 32 ETH validators on their own hardware.
Is Ethereum more decentralized than Bitcoin, Solana or Cardano?
Not as a single ranking. Ethereum leads Solana on node cost and accessibility, trails Cardano on stake distribution flatness, and differs from Bitcoin rather than beating it — Bitcoin concentrates in mining pools, Ethereum in staking entities and client software. Comparisons only hold axis by axis, because the chains have different security thresholds.
Why does client diversity matter for Ethereum’s security?
Because penalties scale with correlation. A bug in a client running under 33% of validators costs its own users a little stake. Above 33%, the same bug stalls finality network-wide and triggers the inactivity leak. Above 66%, it can finalize an invalid chain that other clients reject, splitting the network.
How much does it cost to run an Ethereum node in 2026?
It remains a consumer-hardware purchase, not a data-center expense. Client documentation points to a high-endurance NVMe SSD with headroom above current chain size as the binding requirement, plus desktop-class CPU and RAM and unmetered home broadband. Snap sync and checkpoint sync bring a new node to head in hours rather than days.
Sources and methodology
Last verified: 31 July 2026. Primary sources used or recommended for re-verification: the Ethereum consensus and execution layer specifications for the 33%, 50% and 66% thresholds; the Ethereum Improvement Proposals repository and All Core Devs notes for EIP-7732 status and Glamsterdam scope; clientdiversity.org for threshold rationale; execution-diversity.info for current execution client shares, with supermajority.info cited only as evidence of staleness; Miga Labs/monitoreth.io and Rated.Network for consensus client shares; beaconcha.in and public Dune dashboards for validator and staking distribution; the Lido scorecard for node-operator metrics, last published edition Q4 2025; relayscan.io and mevboost.pics for relay and builder shares; issuer prospectuses for ETF custody; and the Geth, Nethermind, Lighthouse, Teku and ethrex repositories for hardware and sync requirements.
Limitations, stated plainly. Consensus client shares are estimates from two incompatible methods and cannot currently be reconciled. Staking entity attribution is heuristic and can both miss and invent relationships. Several cells in the tables above are marked unverified at time of writing or not published because the live dashboards were not re-read for this revision — those are honest gaps, not estimates, and we have not filled them with plausible numbers. The Nakamoto coefficient is our own calculation under the disclosed entity-definition rule with illustrative inputs, published so it can be reproduced or contested; no third-party dashboard we checked publishes one for Ethereum. This article contains no price predictions, no price targets, no investment recommendations and no affiliate links. Lido, Coinbase, ETF issuers, relays and client teams appear here strictly as measurement subjects.
