Overview 

Summary

Following the development of the Cambridge Bitcoin Electricity Consumption Index (CBECI), the Cambridge Centre for Alternative Finance (CCAF) set out to extend its coverage beyond Bitcoin. The discourse surrounding the environmental externalities of blockchain networks has intensified, and Bitcoin – although responsible for a large share of the electricity use that is attributable to public-permissionless networks – is only one part of the picture. The Cambridge Blockchain Network Sustainability Index (CBNSI) was therefore introduced to expand the analytical perimeter. This document describes the methodology used to estimate Ethereum's electricity consumption under CBNSI.

The methodology presented here is the second iteration of our Ethereum estimation. Since the publication of the first version shortly after The Merge, the Ethereum protocol has undergone material updates that warrant a review. The March 2024 Dencun upgrade shipped blob-carrying transactions (EIP-4844), which changed the data-propagation and storage profile of full nodes by introducing short-lived blob sidecars on the consensus layer. The May 2025 Pectra upgrade raised the maximum effective validator balance to 2,048 ETH (EIP-7251), enabling validator consolidation on existing infrastructure, and doubled blob throughput (EIP-7691). In July 2025, execution clients implemented partial history expiry (EIP-4444), reducing the disk requirement for a full node by approximately 300–500 GB by pruning pre-Merge block bodies and receipts. Separately, a majority of validators now run an MEV-Boost sidecar that outsources block construction to an external marketplace; MEV-Boost draws a small additional marginal power not captured by the EL/CL wall-plug measurement and is therefore a minor source of downward bias in the present model. Independently, the analytical apparatus available to CBNSI has advanced: dedicated network crawlers and public datasets now allow a more granular reading of the network’s client and operator composition than was feasible in 2022. Empirical power-consumption tests have also been conducted, bracketed by two contemporary hardware profiles – a low-power consumer device and an enterprise-grade workstation – to capture the efficiency range of modern node operations.

Protocol context

Unlike Bitcoin, Ethereum transitioned from a proof-of-work (PoW) to a proof-of-stake (PoS) consensus mechanism in an event known as The Merge. The methodology outlined in this document pertains exclusively to Ethereum's PoS architecture post-Merge.

Ethereum is a public-permissionless blockchain network initially based on PoW. The possibility of shifting to PoS was discussed as early as 2014,¹ but the transition was only completed on 15 September 2022. Before The Merge, the Beacon Chain (the consensus layer) and the original Ethereum Mainnet (the execution layer) ran as two parallel blockchains. Post-Merge, the two client types were integrated. A functional Ethereum node now consists of both an execution-layer (EL) client and a consensus-layer (CL) client operating as a pair. The EL client is responsible for executing transactions and smart contracts, a process managed by the Ethereum Virtual Machine (EVM) – a sandboxed execution environment that runs code in a decentralised manner across the network. The CL client is responsible for reaching consensus on the head of the chain and distributing validator rewards.

To prevent malicious behaviour in PoW, network participants proposing blocks must produce an unforgeable proof of computational work. PoS, by contrast, requires participants to put financial resources at stake. Ethereum requires those who participate in proposing new blocks and providing attestations (validators) to pledge at least 32 ETH as collateral. Following the Pectra upgrade, the maximum effective balance was raised to 2,048 ETH per validator (EIP-7251), enabling consolidation of validation duties on a single validator client without reducing network security. The validator client is a lightweight piece of software that holds the signing keys; it relies upon a full node (the EL/CL client pair) to follow the chain and submit its messages to the network. A single full node can support the signing duties of many validator clients. If a validator behaves negligently or maliciously, the network imposes a financial penalty – known as slashing – that reduces the validator's staked balance.

This divergence from PoW has significant consequences for electricity-consumption estimation. The methodology used for PoW networks is a bottom-up techno-economic model in which hardware efficiency directly affects revenue; the same approach cannot be applied to PoS, because an operator's electricity cost does not influence staking rewards. A different method is therefore required to approximate the number of hardware units in use – specifically, the number of full EL/CL node pairs – and their technical specifications.

In keeping with the CBECI, this study incorporates a sensitivity analysis that demonstrates how power demand varies across hardware and software combinations. Because the precise network-wide power demand cannot be ascertained, a hypothetical range comprising three scenarios is employed. Two of these establish the upper and lower bounds of that range; enclosed within these bounds is a best-guess estimate that blends the two using a measured operator-type split. The assumptions underpinning each scenario are set out in the relevant sections below.

Representation

The dashboard on the index page displays the Ethereum network's estimated power demand and electricity consumption for all three scenarios (lower bound, upper bound and best-guess), and it is updated once a day.

The first figure reported refers to the network's total power demand. This measure corresponds to the electrical power the Ethereum network uses at any given moment and is expressed in kilowatts (kW). The second figure refers to the network's total electricity consumption, a metric corresponding to the total amount of electricity used over a given period. In this case, it is an annualised value expressed in gigawatt-hours (GWh) based on the assumption that the estimated power demand remains constant over an entire year.

Further, a seven-day moving average is applied downstream to the daily series of lower-bound, best-guess and upper-bound estimates (rather than to the model inputs) to smooth short-term fluctuations – chiefly crawler-sampling noise in the node count, typically on the order of ±2–5 % day-to-day – thereby rendering the series more suitable for comparison with other electricity-use series.

Model parameters

The CBNSI Ethereum model considers the parameters listed in Table 1. The following sections specify how each of these is estimated and the assumptions that are made. Subscripts: d indexes the day; c ∈ C indexes the consensus client; e ∈ E indexes the execution client; p = (c, e) ∈ P = C × E indexes the ordered pair; and t ∈ {1, 2} indexes the hardware profile.

Table 1: Ethereum model parameters

Estimating node count

The unit counted by N_d is the Beacon Node: a device running an execution-layer (EL) client and a consensus-layer (CL) client as a pair, optionally with one or more validator clients attached. This definition is deliberately node-centric rather than validator-centric. A validator client is a lightweight signing process that relies upon a beacon node to follow the chain and submit its messages; a beacon node, by contrast, can function without any validator client attached, and a single beacon node can support the signing duties of many validator clients simultaneously. The hardware footprint that drives electricity consumption therefore scales with the number of EL/CL node pairs in operation, not with the number of validators those nodes serve, which is why N_d is the appropriate measurand for this model – and why the model is neutral to validator-level changes such as the consolidation enabled by the Pectra upgrade (EIP-7251), targeting a reduction in validator count without compromising security.

The count itself is obtained from the Miga Labs discv5 crawler, which continuously traverses the Ethereum consensus-layer peer-discovery protocol and maintains a live view of the reachable population. The choice to crawl the consensus layer rather than the execution layer is dictated by protocol coverage: the CL is universally addressable through discv5, whereas the EL runs over a mix of discv4 and discv5 with coverage on neither protocol yet sufficient to support a live crawl (see the Execution-client distribution section and footnote 2). Because every full Ethereum node must pair an EL client with a CL client through the authenticated Engine API, the CL-discovered population serves as the canonical count of full node pairs.

Ethereum nodes locate one another through this discovery protocol and, once connected, exchange transactions, blocks and attestations over a custom messaging protocol that provides integrity and confidentiality guarantees. The Miga Labs crawler joins the discv5 network as a passive observer, recording metadata on each peer it reaches from the traffic exchanged. Because peers apply reputation mechanisms that penalise parties requesting information without reciprocating, the crawler advertises itself at genesis state to remain protocol-compliant – a configuration that lets it function as a census of the reachable topology without actively soliciting responses. The fields populated in the per-peer record are enumerated in Table 2; this record supports both the daily node-count series and the daily consensus-client share series that feed into Equation 1. The network-monitoring infrastructure was upgraded on 6 March 2023 to the second iteration of the Miga Labs crawler tooling, with accompanying improvements in data quality and consistency. The daily count series is continuous across that upgrade, though the pre-upgrade segment carries marginally higher observational noise and should be read with that caveat when the series is examined historically.

Table 2: Peer data

Source: Cortes-Goicoechea & Bautista-Gomez (2020)

Two edge cases to the Beacon Node definition warrant brief comment. Validator-only processes without a co-located EL/CL pair are technically possible but remain uncommon: such a setup requires the operator to rely on a third-party beacon node, and therefore to accept slashing and liveness risks that experienced operators prefer to internalise. Their contribution to network-wide electricity consumption is accordingly expected to be a minor share of the measured Beacon Node population and is not separately modelled. Conversely, self-hosted deployments that share one execution client across several consensus clients over a trusted LAN, and multi-node households in which a solo staker operates a primary and a backup machine, produce small departures in the opposite direction; these residuals are addressed in the one-to-one Assumption box below.

Although the per-peer record is rich on software identity, it does not contain precise hardware specifications for the device actually running the node software. Converting the daily node count into an electricity-consumption estimate therefore requires an external source of representative hardware profiles; the choice of those profiles is taken up in the Selecting hardware section below.

Figure 1: Beacon Node count

Selecting hardware

The methods used to estimate the hardware employed in PoW and PoS consensus-based blockchain networks are fundamentally different. In PoW, the hardware used to secure the network will only be run if it is profitable, which allows for estimations based on electricity costs and mining profitability. However, this approach does not apply to PoS. Because PoS no longer requires the energy-intensive hash-rate competition of PoW, an operator's revenue does not depend on the computational power of the hardware deployed.

To address this distinction, a different method must be used. In a PoS environment, rational economic actors naturally select the hardware with the lowest power consumption that still fulfils the software requirements of the chosen client pair and performs reliably under sustained load. However, the actual composition of the network-wide hardware stock cannot be observed directly from crawler metadata (as noted in the Estimating node count section). The hardware distribution must therefore be approximated through assumptions about operator behaviour.

Our assumptions regarding hardware configurations and their electrical power are sourced from a measurement campaign by the Crypto Carbon Ratings Institute (CCRI, 2026). In this campaign, each of the twenty consensus/execution-client combinations was run on two contemporary hardware profiles and instrumented at the wall plug. These two profiles replace the six discrete hardware configurations used in the first iteration of the methodology; their purpose is to bracket the efficiency range of devices operating on the network.

• Node 1 (retail-grade) represents the low-power consumer hardware typically found in home-operator setups, characterised by low idle draw and moderate peak consumption under steady-state workloads.

• Node 2 (enterprise-grade) represents the server-class hardware typical of cloud and co-located deployments, serving as the platform upon which paid staking services, MEV builders, and exchange validators typically run.

The detailed specifications of each profile are provided in Appendix 1. The two-profile bracket acts as a centralising simplification: intermediate-tier deployments (such as small shared-VPS solo stakers or medium-grade co-located home labs) are projected onto the nearest profile through the ASN-based operator-type signal.

Importantly, each measurement in the CCRI (2026) campaign captures the total wall-plug power of the node under a representative workload, encompassing both the hardware baseline and the marginal draw attributable to the specific client combination. A single statistic P_p,t therefore suffices to characterise the power consumption of a full node running a given client combination on a specific profile. This total wall-plug measurement supersedes the idle and marginal power decomposition used previously; it contains the identical information without the need for technical attribution and serves as the preferred measurand because it is a direct observable rather than a counterfactual metric.

Operator-type split

To map the network onto the two established hardware profiles, it is necessary to determine the proportion of nodes running on retail-grade setups versus enterprise-grade setups. The operator-type share, denoted as r_d, represents the fraction of nodes operating from residential internet service provider (ISP) networks on any given day, d. The complementary institutional share, calculated as (1 - r_d), represents those operating from cloud or data-centre networks.

This split is inferred daily using an Autonomous System Number (ASN) analysis of discovered node IP addresses, conducted by Miga Labs. By mapping the IP addresses of the reachable node population to their corresponding ASNs, the network can be segmented by hosting environment. An ASN classified as a residential ISP contributes to the residential share r_d; an ASN categorised as a cloud provider or data-centre operator contributes to the complementary institutional share.

Figure 2. Residential-versus-institutional operator-type split.

Client distribution

Having established the physical hardware profiles and their network distribution, the next logical step is to determine the software running on these devices. As the CCRI (2026) empirical power measurements demonstrate, the electrical power drawn by a full node varies depending on the specific combination of consensus and execution clients it runs. Therefore, to calculate network-wide electricity demand accurately, it is essential to define the market share of these client pairs to apply the correct power footprint.

While the Ethereum ecosystem supports a long tail of experimental and niche client software, their aggregate market share is trivial. The methodology therefore strictly isolates the dominant clients (categorised in Table 3) that secure the vast majority of the network. Emerging clients with minor but growing shares, such as Grandine on the consensus layer and Reth on the execution layer, do not yet possess empirical CCRI power measurements. Consequently, they are not tracked as independent parameters; rather, the mathematical gap they create is absorbed via a renormalisation step (detailed in Equation 2) to ensure the final calculation scales to 100% of the active network.

Table 3: Consensus (Set C) and execution (Set E) clients considered in the model

Consensus-client distribution

The market share of each consensus-layer client s_c,d is observed dynamically on a daily basis from the identical Miga Labs discv5 crawl used to establish the node count. Consensus clients actively broadcast rich identity metadata through Ethereum Node Record (ENR) attributes. This enables the passive classification of every discovered node, allowing for a highly accurate, live daily distribution of Set C clients.

Figure 3: Consensus client distribution

Execution-client distribution

Conversely, a live crawl equivalent to the consensus-layer discv5 crawl is not yet feasible on the execution layer. Execution clients predominantly use the older discv4 peer-discovery protocol, in which client identification requires active handshakes rather than passive observation. Consequently, the share of each execution-layer client s_e,d is currently derived from a periodically refreshed snapshot provided by manually maintained community aggregators (such as Supermajority.info). Table 4 illustrates a recent snapshot. As execution clients progressively migrate towards the discv5 protocol, live dynamic monitoring will eventually yield a sufficiently representative, unbiased sample. Transitioning to this automated approach is actively planned as a future enhancement to the methodology.

Table 4: Execution-client distribution

Source: Supermajority.info (accessed 20 April 2026)

Deriving client pairs

With the marginal distributions of the consensus and execution clients established, they must be combined to estimate the frequency of each specific client pair. Table 5 enumerates the twenty possible combinations.

Table 5: Enumeration of the twenty consensus/execution client combinations

Assuming independence between the two layers, the unadjusted share of each pair on day d is approximated as:

Because the total sum of these combined pairs falls slightly below unity – owing to the emerging clients (Grandine and Reth) that are not yet captured in Sets C and E – the pair shares are subsequently renormalised. This ensures the analysed population correctly scales to 100% of the active node weight:

Calculating electricity demand

Combining the daily node count, the client pair distributions, the empirical power measurements, and the operator-type split provides the necessary variables to calculate the network's total power demand and subsequent electricity consumption. To account for the unobservable hardware composition of the network, the model generates three scenario estimates: a lower bound, an upper bound, and a best-guess estimate that blends the two extremes based on the observed residential-versus-institutional split.

Constructing the lower-bound estimate

Under the lower-bound scenario, the entire active node population is assumed to run exclusively on Node 1 (retail-grade) hardware. Furthermore, no data-centre overhead (Power Usage Effectiveness, or PUE) is applied. This establishes the absolute minimum power footprint mathematically plausible for the observed network.

The aggregate instantaneous power demand on day d is calculated as:

The resulting value D_low,d yields the total network power demand in watts. For reporting on the dashboard, this figure is divided by 10³ to convert to kilowatts (kW) or by 10⁹ to express it in gigawatts (GW).

To determine the annualised electricity consumption, this daily power demand is multiplied by the number of hours in a year. The calculation utilises 365.25 days⁴ to accurately incorporate the effect of leap years over time1

The power demand (D) of the Ethereum network for the lower bound on a given day is calculated using Equation 4. This estimate assumes that the hardware configuration of all discovered nodes is consistent with configuration 4 (shown in Appendix 1).

Constructing the upper-bound estimate

The upper-bound scenario is designed to model the highest mathematically plausible power footprint for the observed network. To establish this absolute ceiling, the entire active node population is assumed to run exclusively on Node 2 (enterprise-grade) hardware hosted within a commercial data-centre environment.

Unlike residential setups, operating enterprise hardware at scale introduces facility-level energy overheads. To account for this, a Power Usage Effectiveness (PUE) multiplier is applied to the calculation. PUE is a standard industry metric expressed as the ratio of total facility electricity to the electricity consumed purely by the IT equipment. Incorporating this multiplier captures the additional power drawn by essential auxiliary systems, including intensive cooling, power-conversion, and distribution losses.

The aggregate instantaneous power demand on day d under this scenario is calculated as:

As with the lower-bound scenario, this daily power demand is annualised by multiplying it by the number of hours in a year:

Constructing the best-guess estimate 

The best-guess estimate represents the most pragmatic perspective on Ethereum's actual power footprint. It calculates a realistic daily aggregate by blending the two extreme bounds using the operator-type split (r_d).

Under this scenario, the network is segmented based on the hosting environment inferred from the Autonomous System Number (ASN) analysis. Nodes identified as residential operators are mapped to the most efficient consumer-grade hardware (Node 1) without any facility overhead. Conversely, nodes identified as institutional operators are mapped to enterprise-grade hardware (Node 2) and have the commercial data-centre PUE overhead applied.

The aggregate instantaneous power demand on day d under this blended scenario is calculated as:

Finally, this blended daily power demand is annualised by multiplying it by the number of hours in a year:

The best-guess estimate is the primary figure most appropriate for year-on-year comparison, and for placing Ethereum's electricity consumption alongside that of other industries and infrastructure. The lower and upper bounds are continuously reported alongside the best-guess on the index dashboard to transparently expose the scale of hardware and deployment heterogeneity that the model explicitly acknowledges.

Discussion

Limitations of the model

While theoretical models strive for absolute accuracy, they are inherently imperfect representations of reality. They rely on reasoned assumptions to bridge gaps where direct observation is technically impossible. To provide full transparency and to set an agenda for future methodological refinements, the primary limitations of the current model are detailed below.

Approximating the hardware distribution. The physical hardware specifications of each individual node cannot be observed directly through the network. Consequently, the model relies on the Autonomous System Number (ASN) as a proxy signal to classify the operator type. While this is a highly effective heuristic for distinguishing a home-based retail setup from a commercial data-centre deployment, it is not an infallible census. Residual misclassifications inevitably occur – for instance, when residential operators tunnel their connection through a cloud Virtual Private Network (VPN), or when small-scale operators lease bare-metal servers from hosting providers. Rather than attempting speculative per-node corrections, the model absorbs this grey area within the broad, two-profile hardware bracket.

Execution-client distribution delays. At present, the market share of the execution-layer clients is refreshed via periodic manual snapshots rather than a live, daily automated feed. This is because a live network crawl is not yet technically sound on the execution layer, owing to its reliance on the older 'discv4' peer-discovery protocol. Broader adoption of the modern 'discv5' protocol across the execution layer will eventually make a direct, passive crawl possible, which will restore daily granularity to this metric in a future update.

Measuring power under variable network load. The wall-plug power measurements provided by the CCRI (2026) campaign were conducted under highly controlled, representative workloads to establish a reliable baseline. However, real-world node hardware must respond to exogenous network activity, meaning power draw fluctuates during periods of extreme network congestion. While the testing windows were extended to smooth out transient spikes, the resulting figures represent a steady-state average rather than a forecast of every possible stressed operating state.

Power Usage Effectiveness (PUE) generalisation. The model applies a single, highly optimised PUE multiplier (1.09) to all institutional operators. PUE is not a universal constant; it varies significantly depending on a facility's age, geographic location, and cooling technology. By anchoring this figure to the trailing-twelve-month average of a leading hyperscaler (Google Cloud), the model deliberately generalises across a wide spectrum of facility efficiencies. Because non-hyperscaler commercial hosting typically operates at a less efficient PUE (approximately 1.15 to 1.35), adopting the 1.09 value places the best-guess estimate at the most optimistic end.

Client-software evolution. The power measurements in this methodology were conducted on specific versions of the execution and consensus clients. Because these software clients are under active, continuous development, future updates and patches may alter their computational efficiency and resource consumption materially. The model represents a static snapshot of the software landscape at the time of testing and will require periodic recalibration.

Undiscoverable nodes on the network layer. The aggregate node count relies strictly on what the MigaLabs crawler can publicly discover. Nodes that operate behind strict corporate firewalls, employ certain Network Address Translation (NAT) configurations, or are explicitly configured to hide from the peer-discovery protocol remain entirely invisible to the crawler.

Independence of client-share choices. The mathematical model treats an operator's choice of consensus client and execution client as strictly independent variables. In reality, large institutional staking operators tend to converge on a small number of preferred client combinations. While this means certain software pairings occur more frequently than pure probability suggests, the variance in power draw across the twenty tested pairs is narrow enough that the resulting bias on the final gigawatt-hour estimate is negligible.

We are committed to publishing studies that present a picture as close to reality as possible. Nevertheless, we acknowledge that, especially in this emerging area of research, we often have to rely on numerous assumptions. While we are confident that the proposed estimates represent a fair range of Ethereum's electricity use, this methodology will be refined and adjusted over time as new and more granular data becomes available. That being said, we will record any alterations in the change log.

For suggestions on improving the index, please contact us through our website.

How do our estimates compare to others?

There have been a few attempts to estimate Ethereum's post-Merge electricity consumption (Table 7). Some of these estimates are updated daily, while others represent a snapshot at a specific time. Since The Merge is a recent event, there is limited research on post-Merge electricity consumption, and different approaches often lead to varying results. Therefore, it is essential to consider the publication date and methodology when comparing estimates from other studies.

All comparisons are based on estimated annualised electricity consumption to make comparing estimates more convenient.

Table 7: Overview of previous studies

Appendix 1 – Hardware profiles

The two hardware profiles used in the CCRI (2026) measurement campaign are summarised below. Both were purchased in 2025 and were selected to span the efficiency range of node operators on the network: Node 1 represents a modern home-staking or Dappnode-style setup, while Node 2 represents a robust enterprise or institutional staking setup. Each profile fulfils the hardware requirements of all in-scope Ethereum consensus and execution clients.

Table A1. Hardware profiles used in the measurement campaign.

Appendix 2 – Node 1 (retail-grade) power consumption

The table below reports the wall-plug power-draw statistics for each of the twenty consensus/execution-client combinations measured on Node 1. Values are total power (i.e. P_p,1) in watts. PUE is not applied at the appendix level; it enters the model at the network level through Equations 5 and 7. The full distribution across the 24-hour stable measurement window – post-sync steady state, with the syncing phase excluded – is summarised by the minimum, first quartile, median, arithmetic mean, third quartile and maximum.

Table A2. Power consumption (W) on Node 1 – retail-grade hardware.

Source: Crypto Carbon Ratings Institute (2026)