Derive (DRV) sustainability report

Derive is present on the following networks: Arbitrum, Base, Ethereum, Hyperliquid, Optimism.

Arbitrum One does not run a consensus algorithm or a validator set of its own. It is an optimistic rollup: transactions are executed off Ethereum, while Ethereum holds the canonical record and provides final settlement. A sequencer accepts transactions, orders them on a first-come basis and executes them under the chain's state-transition rules, producing blocks roughly four times a second and giving users an immediate local confirmation. The ordered transactions are compressed and published to Ethereum in batches. Because that input data sits on the settlement layer, anyone running the node software can replay it and arrive at the same Layer 2 state without trusting the operator.

Agreement about what that state is happens on Ethereum. Validators post assertions — claims about the rollup's resulting state — to contracts on the settlement layer. Since early 2025 the chain has used a dispute protocol that made validation permissionless, so any party may post an assertion or challenge one rather than only an approved list of operators. Conflicting claims are resolved by an interactive process that narrows the disagreement down to a single step of execution, which Ethereum then adjudicates directly. The protocol is designed so that disputes conclude within a bounded period no matter how many adversaries join them, and so that a single honest participant is enough to defend the correct state. Once the challenge window has passed without a successful dispute, the assertion is confirmed and withdrawals that depend on it become executable through the canonical bridge.

Two qualifications matter for an accurate picture. Ordering is still performed by a single sequencer operated by the chain's development company, so transaction ordering is not decentralized today; censorship is bounded rather than impossible, because a user can submit a transaction to a queue contract on Ethereum and force its inclusion once a defined delay has elapsed. Separately, a security council retains powers over the contracts, which keeps the arrangement short of full trust-minimization. Security therefore rests on Ethereum's proof-of-stake consensus combined with the rollup's fraud-proof mechanism, not on a validator set belonging to the chain itself.

Base is a Layer 2 network that executes transactions away from the Ethereum chain and settles them on it. It runs no consensus protocol of its own and has no validator set of its own. Agreement about which Base transactions occurred, and in what order, is ultimately established by the data and the state commitments the network publishes to Ethereum, which are secured by Ethereum's proof-of-stake consensus.

Ordering and execution on the Layer 2 are carried out by a single sequencer, operated by the company that launched the network. It receives transactions, places them into blocks at a fixed cadence and returns a result to the user straight away; those blocks are then compressed and posted to Ethereum in batches, alongside commitments to the state they produce. Once a batch sits inside a finalized Ethereum block, the ordering it encodes is as hard to reverse as Ethereum itself. Users are not wholly dependent on the sequencer for access: a transaction can instead be submitted through a contract on Ethereum, and the rules by which the Layer 2 chain is derived oblige it to be included, which bounds how far the sequencer can censor.

Base is an optimistic rollup, built on the shared OP Stack codebase and part of the Superchain group of networks that use it. State commitments are accepted as correct unless disputed. Anyone may propose one and anyone may challenge one within a dispute window, by playing an interactive game on Ethereum that narrows the disagreement down to a single step of execution, which an Ethereum contract then settles by running that step itself. Both sides post bonds, so an untrue claim and a frivolous challenge are each expensive. Permissionless fault proofs have run on the main network since late 2024, and a multi-party security council with a supermajority threshold governs changes to the contracts; together these place the network at the intermediate tier of the rollup maturity scale commonly used to compare such systems. A withdrawal to Ethereum cannot complete until the dispute window for the relevant commitment has elapsed. Decentralizing the sequencer itself remains outstanding work.

Ethereum reaches agreement through proof of stake, adopted in September 2022 when the original mining-based chain was retired in favor of a validator-driven consensus layer. The protocol family is usually referred to as Gasper. A fork-choice rule named LMD-GHOST selects the head of the chain by following the branch carrying the greatest accumulated weight of validator votes, while a separate finality gadget, Casper FFG, periodically justifies and then finalizes checkpoints, so that reversing them would require destroying an enormous quantity of bonded value.

Time is divided into slots of twelve seconds, and thirty-two slots form an epoch. For each slot the protocol pseudo-randomly designates one active validator to assemble and publish a block, and assigns the rest to committees that vote on what they believe is the correct head and the correct checkpoints. Under healthy conditions a checkpoint becomes final two epochs after it is proposed, a little under thirteen minutes, after which everything beneath it is treated as settled.

Joining the validator set requires a deposit of no fewer than 32 units of the native asset. Since the protocol upgrade of May 2025 a single validator may hold a far larger balance, up to 2,048 units, and earn on the whole of it, which lets an operator running many minimum-sized validators consolidate them into fewer; the activation floor itself did not change. Entry and exit are rate-limited by a queue measured in staked weight rather than in validator headcount, which bounds how fast the composition of the set can turn over.

Security rests on voting power being bonded. A validator that signs contradictory messages can be proved to have done so and is penalized, and the size of that penalty scales with how much other stake was penalized at the same time, so a coordinated attack is punished far more severely than an isolated fault. Should the chain stop finalizing altogether, a separate mechanism gradually erodes the balances of validators that are not participating until the remainder again represents a large enough majority to finalize. Upgrades during 2024 and 2025 changed how large data payloads are distributed and sampled between nodes, without altering this underlying agreement process.

Hyperliquid is a proof-of-stake layer-one network running its own Byzantine fault tolerant consensus protocol, HyperBFT, implemented from scratch and derived from the HotStuff line of leader-based BFT designs. Consensus advances in rounds. A rotating leader proposes an ordered bundle of transactions, validators vote, and a round commits once signatures representing more than two-thirds of stake-weighted voting power have been gathered; voting is pipelined so that the vote confirming one round also advances the next. Ordering is therefore agreed before execution, and a committed round is final immediately rather than after a probabilistic waiting period. Safety holds provided that faulty or dishonest validators control less than a third of stake-weighted voting power.

What sets this network apart is what the agreed ordering is fed into. Two execution environments sit on the same consensus and the same validator set. The first, the native state machine, holds fully on-chain central limit order books together with margin, perpetual futures and spot balances, so order placement, cancellation, matching and liquidation are consensus operations of the chain itself rather than calls into a deployed contract. The second is an EVM environment added in 2025, which inherits ordering and finality from the same consensus and can read from and write to the native state. It uses two interleaved block types: small blocks produced roughly every second with a low gas ceiling, for ordinary transfers and trades, and much larger blocks produced about once a minute, for contract deployment and heavy batch work, so bulky transactions cannot delay time-sensitive ones.

Validators are selected by stake. An operator must self-delegate a minimum amount of the network's native asset to become active, and any holder may delegate to a validator to add to its weight. The active set and the stake behind it are fixed within staking epochs of a hundred thousand consensus rounds, roughly an hour and a half, and are recomputed between them. Validators police each other's liveness directly: a validator that does not answer consensus messages with acceptable latency or frequency can be voted into a jailed state by its peers, in which it stops producing blocks until it returns itself to service.

OP Mainnet operates no validator set and no consensus algorithm of its own. It is an optimistic rollup: blocks are produced away from Ethereum, but the canonical history and final settlement live on Ethereum. A sequencer accepts transactions, orders them and produces Layer 2 blocks on a two-second cadence, which is what gives users a fast confirmation. The ordered transaction data is compressed and published to Ethereum in batches, and every node derives the canonical chain by reading that data back from the settlement layer. Deriving the chain from Ethereum rather than from the sequencer's word is what makes the arrangement verifiable: anyone holding the published data can recompute the same state independently.

Correctness is enforced after the fact. Claims about the chain's output state are posted to a dispute-game contract on Ethereum, and since the fault-proof system was opened to the public in mid-2024 anyone may post such a claim or dispute one, with no allowlist involved. A challenge proceeds as a bisection game in which the two sides repeatedly narrow their disagreement until a single step of execution remains; that step is then executed inside a deterministic fault-proof machine on Ethereum, which settles the matter on-chain. Both sides lock bonds and the loser forfeits. A claim that survives a challenge window of roughly a week is treated as final for the purpose of withdrawing assets to Ethereum.

Two limits belong in any accurate description. Sequencing rests with a single operator, so ordering is centralized in practice; censorship is constrained rather than prevented, because a transaction can be deposited through a contract on Ethereum and must then be included in the chain. And a guardian role, alongside a security council, retains emergency powers, including pausing withdrawals and returning the dispute system to a permissioned mode should it fail — a deliberate safeguard that nonetheless keeps the chain short of full trust-minimization. Ultimate security comes from Ethereum's proof-of-stake consensus, whose validators finalize the data the rollup depends on.

Derive is present on the following networks: Arbitrum, Base, Ethereum, Hyperliquid, Optimism.

Fees on Arbitrum One are paid in the settlement layer's native asset and split into two economic components. The execution component prices computation and state access on Layer 2 through a base fee that a control loop raises and lowers with demand, in the style of Ethereum's own fee market. The data component covers the cost of publishing compressed batches to Ethereum. A transaction's share of that component is estimated from how many bytes it adds to a compressed batch, so how well its data compresses matters as much as its size, and the fixed cost of a posting is spread over everything in the batch rather than falling on one transaction. Since Ethereum opened a dedicated data space for rollups, batches are posted there and priced by that space's separate fee market. Both components are converted into a single unit, so a user sees one price rather than two.

Payments flow to several places. The party that posts batches is reimbursed from collected fees, with the data price adjusted over time so that reimbursement tracks what was actually spent. Remaining Layer 2 revenue accrues to protocol-controlled accounts — one covering baseline infrastructure, another collecting congestion revenue — which governance directs, rather than being burned. A portion of ordering rights is also sold: a sealed-bid auction awards a short-lived priority lane for a round lasting under a minute, and the proceeds go to an account that chain governance designates. Contracts compiled to WebAssembly run alongside EVM contracts and are metered on their own resource unit.

There is no staking, delegation, issuance or slashing at this layer. The equivalent penalty is a bond: participants that assert or challenge state must lock collateral, and a party that loses a dispute forfeits it, with part compensating the honest side, so an incorrect claim carries a direct cost. Beneath the rollup, Ethereum's own incentives apply to the data it posts — the base fee there is burned and the priority fee goes to the block proposer. There is no recurring storage rent; state is paid for when it is written.

Base has no native protocol asset, no staking and no issuance. Nothing is minted to reward participation and there is no validator or delegation system on the Layer 2. Fees are denominated and paid in ether, the same asset used on the settlement layer.

What a user pays has two parts, and they behave quite differently. The first is the cost of executing the transaction on the Layer 2, metered in gas exactly as on Ethereum and priced by an equivalent algorithmic base fee that moves with how full recent Layer 2 blocks have been, plus an optional tip. Because Layer 2 block space is plentiful, this component is usually very small and fairly stable. The second is a charge for the cost of publishing that transaction's data to Ethereum. It is assessed per transaction from the compressed byte size of the transaction and the prevailing price of settlement-layer data space, and it is collected when the transaction is processed even though the actual posting happens later, in a batch shared with many others. This second component typically dominates the total and is why Layer 2 costs track conditions on Ethereum.

Since Ethereum opened a dedicated market for rollup data in 2024, the network posts its batches into that market rather than as ordinary transaction data. Those data fees are priced independently of execution and are destroyed rather than paid to anyone, which cut this component sharply. A December 2025 change on the settlement layer raised the available data capacity while introducing a floor that ties the minimum data price to ordinary execution costs, so the charge no longer falls to almost nothing whenever demand for data space is light.

Fees collected on the Layer 2 accrue to the entity operating the sequencer, funding the cost of running it and of settling to Ethereum, with a portion shared with the collective that stewards the shared codebase. The other economic mechanism at work is the dispute system: participants who propose or challenge a state commitment post bonds that are forfeited if they are shown to be wrong, which funds honest challenges and makes dishonest claims costly.

Payment inside the protocol flows to validators, the only participants the consensus layer compensates directly. A validator earns newly issued units of the network's native asset for voting promptly and correctly on the head of the chain and on the checkpoints being justified, for serving its turn in the committee that signs headers for light clients, and, when selected to propose, for the block itself. The proposer additionally keeps the priority portion of the fees in that block, together with whatever it receives from the separate market through which many proposers outsource block assembly. There is no delegation inside the consensus rules: stake is either operated directly or entrusted to an operator through arrangements that sit outside the protocol.

Users pay for execution in gas, metered per operation, with writes to persistent state priced far above arithmetic. Every transaction carries a base fee per unit of gas that the protocol sets algorithmically from how full recent blocks have been, and that amount is destroyed rather than paid to anyone, so sustained demand withdraws native asset from circulation. On top of it a user adds a voluntary tip, which goes to the proposer and governs how quickly the transaction is picked up. Data posted on behalf of Layer 2 networks is priced in a second, independent market whose fee is likewise destroyed; a December 2025 upgrade tied the floor of that market to ordinary execution costs so it cannot collapse to a negligible level, and capped the gas any one transaction may consume.

Penalties mirror the rewards. Failing to vote, or voting late or incorrectly, costs a validator roughly what correct behavior would have earned it. Provable equivocation is treated far more harshly: the offender is scheduled for ejection, forfeits part of its balance immediately, and later incurs an additional correlated penalty computed from how much other stake was penalized nearby in time. Prolonged absence while the chain is failing to finalize drains balances until finality can resume. Stakers may take out accumulated rewards without leaving the set, and since 2025 may also trigger a full exit from the execution layer rather than only from the consensus client.

Validators and their delegators are paid from a reserved pool of the native asset held for that purpose, not from the network's trading revenue. Rewards accrue continuously, are paid out daily and are automatically re-delegated, and the rate scales inversely with the square root of the total amount staked, so the yield falls as participation grows. A validator earns only for epochs in which it actually took part in consensus, and its delegators earn nothing while it is jailed. Validators set a commission on delegator rewards; raising one is constrained, since a commission may only be changed to a rate at or below a low ceiling, which prevents an operator from attracting delegation cheaply and then repricing it.

Delegated stake cannot be withdrawn quickly. A delegation is locked for a day before it can be undone, and moving stake back to a spendable balance then takes a further week in a withdrawal queue, which makes it impractical to assemble voting weight, attack consensus and exit. There is no automatic confiscation of stake in the protocol as it currently operates; the sanction for poor performance is jailing, which costs the validator and its delegators their rewards rather than their principal.

The fee model is the most distinctive part. Trading fees on the native order books are charged to takers and makers on a volume-tiered schedule, and execution fees on the EVM side are paid as gas. Almost none of this reaches validators. The great majority of protocol fee revenue is routed to an on-chain fund that continuously buys the native asset on the open market; the address holding it has no private key, so under current protocol rules those holdings cannot return to circulation. Alongside that, several streams are destroyed outright: spot trading fees denominated in the native asset, the base-token fees from token deployments that a deployer has not redirected, and both the base fee and, unusually, the priority fee on the EVM, since block producers do not collect them. Optional priority fees for faster order handling, introduced in 2026, are likewise burned. Token listings are allocated through descending-price auctions rather than sold at a fixed price.

Transactions are paid for in the settlement layer's native asset, and the amount splits in two. The execution component prices computation and state access on Layer 2 through a base fee that adjusts with demand plus an optional priority fee, and it is small because the work happens away from Ethereum. The data component covers publishing the transaction's data to Ethereum so the chain can be reconstructed, and it usually dominates. Since Ethereum introduced a dedicated data space for rollups, batches are posted there instead of as ordinary call data, and the pricing function reads both Ethereum's ordinary base fee and the separate fee for that data space — each relayed onto Layer 2 by a system contract every block — scaled by two parameters the chain operator can tune. What a transaction pays is proportional to its compressed size, estimated with a compression function, so the cost of a posting is apportioned across the transactions in the batch rather than charged to whichever one happens to trigger it.

There is no staking, delegation or reward issuance at this layer, and consequently no slashing. The sequencer's incentive is the margin between the fees it collects and what it spends publishing data to Ethereum, which gives it a direct reason to batch efficiently. Net of those costs, the surplus from this chain is directed to the collective treasury that funds protocol development and public-goods programs, and other chains built on the same software contribute a defined share of their own revenue on the same basis. Participants in the proof system are paid differently: bonds locked in a dispute are forfeited by the losing side to the winner, so challenging an incorrect claim is rewarded while posting one is expensive.

Deploying and calling smart contracts is charged on the resources consumed, on the same basis as on Ethereum, and there is no recurring storage rent — state is paid for when it is written. Underneath, the data the chain posts is subject to Ethereum's own rules, where the base fee is burned and the priority fee goes to the block proposer.

Derive is present on the following networks: Arbitrum, Base, Ethereum, Hyperliquid, Optimism.

The consumption attributed to Arbitrum One has two parts, and they are estimated in different ways. The first is the chain's own infrastructure: the machines running the sequencer and the batch-posting process, the validators that track state assertions and would take part in a dispute, and the broader population of full, archive and RPC nodes that other participants operate. The second is the share of Ethereum's consumption that belongs to the rollup, because settlement and data availability happen there. Ethereum's validators do work on the rollup's behalf whenever a batch is posted, and a proportion of their consumption is apportioned to the chain according to how much of the settlement layer's capacity those postings occupy. Ethereum publishes its own account of how that figure is arrived at (Ethereum energy consumption).

Since nothing here is mined, the first part is estimated by counting machines rather than by modeling operator profitability. The size of the node population is approximated from network crawlers, peer discovery and publicly listed endpoints. A representative hardware specification is inferred from what the client software states it needs to stay in sync — processor class, memory, fast storage and bandwidth — and the electricity that specification draws is taken from controlled measurement of equivalent machines, both under load and idling. The total is the aggregate across the estimated population including idle draw, because nodes run continuously whether or not blocks are full. Dispute participation is episodic and contributes little in normal operation. A fraction of the network total is then attributed to an individual asset in proportion to observed on-chain activity involving it.

These are estimates rather than meter readings, and the limits should be read as part of the figure. Node counts are lower bounds, because machines behind private networks cannot be discovered. The hardware mix is inferred from stated software requirements rather than surveyed from operators. Where the evidence runs out, the assumption chosen is the one more likely to overstate consumption than to understate it, and figures are revised as observation improves.

The estimate for this network has two components, and they are constructed differently.

The first is the network's own infrastructure. This is a small and largely identifiable set of machines rather than a large permissionless population: the sequencer that orders and executes transactions, the batching service that compresses and submits data to the settlement layer, the service that publishes state commitments, and the replica and archive nodes that third parties operate to serve applications and to independently check what the sequencer produced. The number of independent replicas is estimated from crawlers of the Layer 2 peer-to-peer network and from public information about node operators and infrastructure providers. Hardware profiles are inferred from the published requirements of the node software, which for a high-throughput rollup are materially heavier than for an ordinary chain, and per-device power draw comes from measurement on representative equipment under controlled laboratory conditions, counting idle draw as well as load. The fault-proof machinery adds little in normal operation, since the interactive dispute game runs only when a commitment is actually challenged rather than continuously.

The second component is the share of the settlement layer's consumption that this network causes. That layer is Ethereum, whose own consumption is estimated from its validator population using the node-level method described for that network. A portion is attributed here in proportion to what this network occupies there, principally the data space its batches consume, alongside the gas used by its commitment and dispute contracts. Because the settlement layer's consumption is driven by a continuously running validator set rather than by throughput, this attributed share is modest next to the Layer 2's own footprint, but it is included so that settlement is not treated as free.

Both components are estimates built on public observation and stated software requirements, not metered readings. The replica population is the least observable part and the largest source of uncertainty. Where evidence is thin, the assumptions used are those more likely to overstate impact than understate it, and figures are revised as observation improves. The settlement layer publishes its own account of its energy profile at Ethereum energy consumption.

The figure reported for this network is assembled machine by machine, treating the computers that run the protocol as the thing that draws electricity. The starting point is an estimate of how many independent nodes are operating, built from crawlers that walk the peer-to-peer layer and record every peer they can reach, supplemented by public listings of infrastructure and staking providers and by the protocol's own visible record of how much stake is active and how it is spread across operators.

A representative hardware profile is then inferred for those machines. The client software publishes what it requires in processor, memory and disk terms, and operators have little reason to provision far beyond that, so the profile is derived from those stated requirements rather than from a survey of individual operators. Power draw for the resulting device classes comes from measurement on representative equipment under controlled laboratory conditions, capturing both the load validating places on a machine and the draw of a machine that is powered on but momentarily idle, which for a network of this kind accounts for a large share of the total. Multiplying measured per-device draw across the estimated population over the reporting period yields the network figure. Where a disclosure concerns one of the many assets issued on this network rather than the network itself, a portion of the network total is assigned to it in proportion to observed on-chain transfer volumes.

The limits deserve stating plainly. The node count records what is reachable, not a census, and machines behind restrictive network configurations are missed. The hardware profile is a reasoned inference from published software requirements, not a record of what any particular operator bought. Nothing here is metered at the wall. Where the evidence runs out, the assumptions chosen are those that push the estimate upward rather than downward, so the result is more likely to overstate consumption than to understate it, and it is revised as observation improves. The network's own account of its energy profile is published at Ethereum energy consumption.

The figure reported for this network is an estimate built from the machines that operate it, not a metered reading. It starts from the population of participating nodes and works upward from the draw attributable to each.

Establishing that population is more tractable here than on most networks, because the set of validators taking part in consensus is small, identified on-chain and recomputed at each staking epoch, so its size and membership can be read from publicly observable network data rather than inferred. Counting only that set would understate the total, however. The chain is also served by non-validating nodes that follow consensus, keep a copy of state and answer the queries that applications and market participants make of it, and by the infrastructure that distributes order book and market data. These are estimated from peer discovery and from publicly available operator information, collected by automated crawling.

The second input is what a single machine draws. A representative hardware profile is inferred from the resources the node software states it requires, and per-device power is attributed from laboratory measurement of equipment matching that profile. Two features of this network push that profile upward relative to a general-purpose chain: consensus targets sub-second commitment, and the state machine continuously matches orders, so participants run high-specification servers in professionally operated facilities and keep them running constantly. Draw is therefore counted on a continuous basis, idle periods included, and multiplied across the estimated population.

The limitations should be stated plainly. The hardware mix is inferred from stated requirements rather than surveyed, and the count of supporting non-consensus infrastructure is the least observable part of the estimate. Because the consensus set is small, the total is sensitive to the per-machine assumption in a way that a large network's total is not: an error in the assumed profile is not diluted across thousands of nodes. Where evidence is thin, assumptions are chosen so that the impact is more likely to be overstated than understated, and figures are revised as observation improves.

Two distinct things are being estimated, and conflating them is the usual source of error. The first is the electricity drawn by the chain's own infrastructure: the sequencer, the process that publishes batches, the challenger software that watches state claims and would contest an invalid one, and the population of nodes that other participants run, each of which pairs a consensus client deriving the chain from Ethereum with an execution client replaying it. The second is the portion of Ethereum's own consumption that belongs to the rollup, since every batch it posts occupies capacity that the settlement layer's validators pay to provide. That portion is apportioned by how much of Ethereum's resources the chain's postings take up. Ethereum publishes its own description of how its consumption is estimated (Ethereum energy consumption).

Nothing in this design is mined, so the chain's own side is estimated at the level of individual machines rather than through the economics of hardware competition. The node population is approximated from crawlers, peer discovery and publicly advertised endpoints. A representative machine specification is inferred from what the client software states it requires to keep pace with the chain, and the power that specification draws is taken from controlled measurement of comparable hardware, recorded both under load and at rest. The network total is the aggregate across the estimated population, including idle draw, since these machines run continuously. From that total, a fraction is assigned to an individual asset according to observed on-chain activity involving it.

The honest caveats belong with the number. The node count is a floor rather than a census, because machines behind private networks are not visible to a crawler. The hardware profile comes from stated requirements, not from a survey of what operators actually bought. And where evidence is thin, the assumption taken is the one that produces the larger figure rather than the smaller one. Estimates are revised as observation of the network improves.

Derive is present on the following networks: Arbitrum, Base, Ethereum, Hyperliquid, Optimism.

The renewable share is derived geographically, starting from where the machines that keep the chain running actually sit: the servers hosting the sequencer and the batch poster, the validators that participate in the dispute protocol, and the wider population of full and archive nodes. Their locations are inferred from publicly observable network information — the addresses reachable peers announce, hosting and autonomous-system registries, and public node listings — which yields a country-level distribution rather than a precise address for any individual machine. Much of this infrastructure is hosted with commercial cloud and colocation providers, so the region a provider operates a facility in stands in where a single host cannot be placed more precisely. Where the chain's own distribution is too sparse to observe with confidence, the pattern seen on networks of similar shape — alike in how participants are paid and in the class of hardware they run — fills the gap.

The same exercise is applied to the settlement layer, because the portion of Ethereum's consumption attributed to the rollup carries the geographic profile of Ethereum's validator set rather than that of the rollup's own machines. The two distributions are combined, weighted by how much estimated consumption each accounts for.

Country weights are then matched against published statistics on how much of each country's electricity comes from renewable sources, drawn from Share of electricity generated by renewables, compiled by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy. The result is a consumption-weighted average across the estimated footprint. It is not a statement about what any operator has contracted for: power purchase agreements, on-site generation and renewable certificates are invisible in network data and are not assumed.

Energy intensity is expressed marginally, as the additional electricity associated with one more transaction on top of the infrastructure already running. Because the cost of operating a node is largely fixed and barely responds to how full a block is, that marginal figure is small and moves inversely with throughput, which is why it should not be read as a per-transaction share of the total.

The renewable share reported for this network is a weighted average of the electricity mixes of the grids its infrastructure draws on, assembled in two steps: establish where the machines are, then attach regional generation statistics to those places.

Locating them is easier for some parts of the network than others. The sequencing, batching and commitment services run in identifiable data center regions, and the hosting regions an operator uses are publicly observable. The wider population of replica and archive nodes is inferred as it would be for any peer-to-peer network, from the addresses peers advertise so that others can reach them, collected by crawlers and supplemented by public directories of infrastructure providers. Resolving a single address to a country is unreliable, but in aggregate these resolutions describe a distribution well enough to weight against. Where the observable sample is too thin, the geographic spread of a structurally comparable network is used in its place, chosen because its operators face similar hosting economics rather than because it runs similar software. The same exercise is carried out for the settlement layer, because part of the figure reported here is an attributed share of Ethereum's consumption, and Ethereum's validator population is spread quite differently from a rollup's concentrated operator infrastructure. The two distributions are weighted by their respective contributions to consumption and combined.

Each location is then matched to published statistics on how electricity is generated in that country or region, and the renewable proportion is the consumption-weighted share falling in regions supplied by renewable generation. Grid averages are used throughout, because the actual supply arrangements of individual hosting facilities are not observable; a facility on a dedicated renewable supply and one drawing ordinary grid power in the same country are treated alike.

Energy intensity is a marginal figure rather than an average: the additional electricity attributable to one further transaction on the network as it currently runs. Because most of the infrastructure runs continuously whether or not it is busy, that marginal quantity is much smaller than dividing total consumption by the transaction count would suggest. The generation statistics come from Share of electricity generated by renewables, compiled by Our World in Data from Ember's electricity datasets and the Energy Institute's Statistical Review of World Energy.

The renewable share reported here is a weighted average of grid mixes rather than a record of what any operator actually buys. It is produced in two steps: establish where the infrastructure sits, then attach regional electricity statistics to those places.

Location is inferred from what the network exposes publicly. Nodes advertise network addresses in order to be reachable by peers, and those addresses resolve to a country accurately enough to describe an aggregate distribution, even though any single resolution may be wrong. Crawlers of the peer-to-peer layer and public directories of hosting and staking infrastructure supply the input. Where the observable sample is too thin or too skewed to stand for the whole population, the geographic spread of a structurally similar network is substituted, chosen because its participants face comparable hardware costs and comparable pressures over where to site machines, on the reasoning that operators respond to the same commercial forces even where the software differs.

Each location is then matched to published statistics on how electricity in that country or region is generated. The renewable proportion for the network is the consumption-weighted share falling in regions where generation is renewable. Grid averages are used because the alternative, knowing each operator's actual supply contract, is not observable; an operator on a dedicated renewable supply and one drawing ordinary grid power in the same country are treated alike.

Energy intensity is reported on a different basis from total consumption. It is a marginal quantity: the additional electricity attributable to processing one further transaction on the network as it currently runs. For a network whose consumption is driven by a validator set that operates continuously regardless of how busy the chain is, that marginal figure is small, and it is not the total divided by the transaction count. The generation statistics are drawn from Share of electricity generated by renewables, compiled by Our World in Data from Ember's electricity datasets and the Energy Institute's Statistical Review of World Energy.

The renewable share attributed to this network follows from where its machines are located, not from any statement about the electricity its operators choose to buy. Locations are established from publicly observable network data: the addresses validators and other nodes announce to their peers, information operators publish about the infrastructure they run, and the hosting providers and data-center address ranges those addresses belong to, gathered by automated crawling of the peer network.

The picture that emerges here has a particular shape. The consensus set is small and professionally operated, and its members run in commercial data centers chosen for network latency to one another rather than for cheap power, which tends to concentrate them in a handful of well-connected regions. That concentration cuts both ways for the estimate: fewer sites make placement easier to observe, but it also means the renewable share is sensitive to a small number of hosting decisions, and a single operator moving facility can shift the network figure noticeably. Where placement cannot be resolved at all, because a node sits behind a relay or the provider does not disclose the site, the geographic distribution of a structurally similar network is used instead, chosen for comparable incentives and comparable validation duties.

Each location is then matched to the grid serving it, and the renewable proportion of that grid's generation is applied, weighted by the share of estimated consumption sitting in each region. The result is a consumption-weighted renewable share that moves when operators relocate and when the underlying generation mixes change.

Energy intensity is reported alongside it and has a narrow meaning: the marginal energy associated with one further transaction. On this network the distinction matters, because consumption is almost entirely the fixed cost of keeping validators running at capacity, while throughput can vary greatly with trading activity. The marginal figure therefore falls as activity rises and should not be read as an average per transaction. Grid statistics come from Share of electricity generated by renewables, compiled by Our World in Data with major processing from Ember and from the Energy Institute's Statistical Review of World Energy.

Establishing a renewable share begins with location rather than with energy. The infrastructure in question is the sequencing and batch-publishing servers, the challenger nodes that watch the dispute system, and the wider set of full and archive nodes run by applications, bridges and infrastructure providers. Where those machines sit is inferred from publicly observable network information — announced peer addresses resolved against hosting and autonomous-system registries, and public listings of node operators — which supports a country-level picture rather than a precise location for any one machine. Because much of this runs on rented cloud capacity, the region a provider states for a facility is used in place of a finer-grained address. Where the chain's own sample is too thin to support a distribution, the pattern observed on networks built along similar lines, with comparable participant roles and hardware classes, substitutes for the missing portion.

The settlement layer is handled separately and then combined. The share of Ethereum's consumption attributed to the rollup takes on the geographic profile of Ethereum's validator population, which is distributed differently from the rollup's own servers, so the two distributions are weighted by their respective contributions to estimated consumption before being merged.

Those country weights are applied to published figures for the renewable proportion of each country's electricity generation, taken from Share of electricity generated by renewables, compiled by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy. What comes out is a consumption-weighted average across the inferred footprint, reflecting the grids the infrastructure most likely draws on. It does not capture procurement: renewable supply contracts, certificates and behind-the-meter generation cannot be seen in network data and are not credited.

Energy intensity here means a marginal quantity — the extra electricity associated with one further transaction, given the infrastructure already running. Node and sequencer power draw barely varies with how full a block is, so this marginal figure is small and falls as throughput rises. It is not the network total divided by the transaction count, and the two should not be compared.

Derive is present on the following networks: Arbitrum, Base, Ethereum, Hyperliquid, Optimism.

Emissions are derived from the energy estimate rather than measured at the source. The geographic distribution built for the renewable calculation — sequencer and batch-posting infrastructure, dispute-protocol validators, full nodes, and the share of Ethereum's validator set attributed to settlement — is reused, and each country's slice of estimated electricity is multiplied by the average carbon intensity of that country's grid. Grid figures are drawn from Carbon intensity of electricity generation, compiled by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy and made available under a Creative Commons BY 4.0 license. Regional totals are summed to give a network figure, and a fraction of that figure is attributed to an individual asset in proportion to observed on-chain activity.

The two scopes are treated separately. Scope 1 covers combustion that the operators themselves control — on-site generators, fuel burned directly on their premises. For a chain whose infrastructure sits in commercial data centers this is ordinarily zero or negligible, and it is reported as such unless direct fuel use is known. Scope 2 is the substantive figure: the emissions embodied in the grid electricity that infrastructure draws. It is computed on a location basis, using the average intensity of the grid a machine draws from, rather than on a market basis reflecting supply contracts or certificates, because supplier-level information cannot be observed from the network. Emissions embodied in manufacturing the hardware or building the facilities that house it fall outside this boundary.

Greenhouse gas intensity is stated marginally, as the additional emissions associated with one more transaction. Two limits are worth stating plainly. Grid intensity statistics are annual national averages, so they miss the hourly and sub-national variation any specific facility experiences, and a data center on a dedicated low-carbon supply will be represented by its country's average. And the figure inherits every uncertainty in the energy and location estimates beneath it; where those rest on assumption, the assumption chosen is the one more likely to overstate the result.

Emissions are not measured directly. They are derived by attaching a carbon intensity to each unit of electricity the network is estimated to consume, across both parts of its footprint: the machines the network operates itself, and the share of the settlement layer's consumption attributed to the data and commitments it posts there.

The geographic step repeats the one used for the renewable share. The hosting regions of the sequencing and batching infrastructure are publicly observable; the wider set of replica and archive nodes is located from the addresses peers advertise, collected by crawlers and public directories. Where observation is too sparse to characterize the population, the spread of a structurally comparable network is used in its place. The settlement layer's validator population is located separately, because it is distributed quite differently, and the two are weighted by how much consumption each accounts for. Each region is then assigned a carbon intensity, the average greenhouse gas released per unit of electricity generated on that grid, expressed in carbon dioxide equivalent so that methane and the other gases are counted on a common basis. Estimated consumption in a region multiplied by that region's intensity, summed across regions, gives the total.

Two scopes are distinguished. Scope 1 covers emissions from sources the operators of the infrastructure control directly, such as fuel burned on site in a generator. For infrastructure that consists of ordinary servers in commercial data centers drawing from public grids, there is generally nothing in that category, and it is reported as such rather than left out. Scope 2 covers the indirect emissions embodied in the purchased electricity, and is where essentially the whole footprint sits. Emissions from manufacturing and transporting the hardware fall outside this boundary.

Greenhouse gas intensity follows the marginal logic used for energy intensity: the additional emissions attributable to one further transaction, not an average spread across all of them. It inherits the uncertainty of both the consumption estimate and the grid averages. Carbon intensities are taken from Carbon intensity of electricity generation, compiled by Our World in Data from Ember's electricity datasets and the Energy Institute's Statistical Review of World Energy, and made available under the CC BY 4.0 license.

Emissions are derived from the consumption estimate rather than measured, by attaching a carbon intensity to each unit of electricity the network is estimated to draw and summing across the network.

The geographic step repeats the one used for the renewable share. Node locations are inferred from publicly observable network data, principally the addresses peers advertise so that others can connect to them, gathered by crawlers and supplemented by public information about where staking and hosting infrastructure is operated. Where that observation is too sparse to characterize the whole population, the distribution of a comparable network stands in for it, selected because its participants face similar operating economics rather than because its software resembles this one. Each region is assigned a carbon intensity, meaning the average greenhouse gas released per unit of electricity generated on that grid, expressed in carbon dioxide equivalent so that methane and the other gases are counted on a common basis. Estimated consumption in a region multiplied by that region's intensity, summed across regions, gives the network total.

The reporting separates two scopes. Scope 1 covers emissions from sources the operators of the infrastructure control directly, such as fuel burned on site in a generator. For a network of this kind, whose participants overwhelmingly run ordinary servers connected to a public grid, there is generally nothing in that category, and it is reported as such rather than left out. Scope 2 covers the indirect emissions embodied in the electricity purchased to run that infrastructure, and that is where essentially the whole footprint sits. Emissions further up the supply chain, such as those from manufacturing and shipping the hardware, fall outside this boundary.

Greenhouse gas intensity follows the same marginal logic as energy intensity: it expresses the additional emissions attributable to one further transaction rather than an average spread across all of them. Because it inherits both the consumption estimate and the grid averages, its uncertainty combines theirs. Carbon intensities are taken from Carbon intensity of electricity generation, compiled by Our World in Data from Ember's electricity datasets and the Energy Institute's Statistical Review of World Energy, and made available under the CC BY 4.0 license.

Emissions are derived from the network's estimated electricity use combined with the carbon content of the grids supplying it. The energy total is first apportioned by location, using the same geographic picture assembled for the energy analysis: node addresses observed on the peer network, operator information published openly, and the hosting ranges those addresses resolve to. Where a node's placement cannot be resolved, the distribution of a structurally comparable network is used in its place, selected for similar incentives and similar validation duties rather than for similar scale.

Each portion of consumption is then multiplied by the carbon intensity of the grid serving that region, expressed as emissions per unit of electricity generated, and the parts are summed. The consequence is that hosting decisions drive the result as strongly as the amount of electricity drawn. That is pronounced here, because the consensus set is small and clustered in a few commercial facilities, so the figure reflects the generation mix of a handful of jurisdictions rather than a global average, and can move when one operator changes provider.

The reported figures distinguish two scopes. Scope 1 covers emissions from sources the operators control directly, such as fuel burned on site; for infrastructure of this kind that is effectively nil, since the machines are commodity servers drawing grid power in third-party facilities. Scope 2 covers the indirect emissions embodied in the electricity bought to run them and accounts for substantially the whole footprint. Emissions from manufacturing the hardware, and from constructing and cooling the buildings that house it, sit outside both scopes and are not counted.

GHG intensity is the marginal quantity: the emissions attributable to processing one additional transaction. As with energy, most of the total is a fixed cost that continues regardless of how busy the network is, so intensity falls as usage rises and is not an average. Carbon intensity values come from Carbon intensity of electricity generation, compiled by Our World in Data with major processing from Ember and from the Energy Institute's Statistical Review of World Energy, and made available under the CC BY 4.0 license.

The emissions figures are computed from the energy estimate, not observed directly. The geographic breakdown assembled for the renewable share — sequencing and batch-publishing servers, challenger and full nodes, and the slice of Ethereum's validator population attributed to settlement — is carried over, and each country's portion of estimated electricity is multiplied by that country's average grid carbon intensity. The intensity figures come from Carbon intensity of electricity generation, compiled by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy and released under a Creative Commons BY 4.0 license. Country results are summed into a network total, from which a share is attributed to an individual asset in line with observed on-chain activity.

Scope 1 and scope 2 describe different things and are reported separately. Scope 1 is direct combustion under the operators' own control — fuel burned on site, standby generation. For infrastructure hosted in commercial data centers there is normally nothing material to report here, and it is stated as zero or negligible rather than estimated upward. Scope 2 carries the weight: it is the indirect emissions embodied in purchased electricity. The calculation is location-based, applying the average intensity of the grid serving each region, because a market-based calculation would need supplier contracts and certificates that are not observable from outside. Embodied emissions from manufacturing servers or constructing the facilities they occupy are not in scope.

Greenhouse gas intensity is reported as the marginal emissions of one additional transaction, consistent with how energy intensity is treated. The main uncertainties should be read alongside the number. National annual averages smooth away the hourly swings and regional differences a real facility experiences. Every assumption in the underlying energy and location estimates propagates through to the emissions figure. And where a choice between plausible assumptions has to be made, the one producing the higher result is preferred, so these figures are better understood as a conservative ceiling than as a precise measurement.