Uniswap (UNI) sustainability report

Uniswap is present on the following networks: Arbitrum, Avalanche, Binance Smart Chain, Ethereum, Harmony One, Huobi, Near Protocol, Optimism, Polygon, Gnosis Chain.

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.

Avalanche's Primary Network is not a single chain but three, each specialized and all validated by the same set of operators. The contract chain hosts smart-contract execution in an Ethereum-compatible environment and is where most applications and issued assets live. The exchange chain handles asset creation and transfers. The platform chain tracks the validator set, staking, and the registration of the sovereign networks that run alongside the Primary Network.

Agreement across all three comes from the Snow family of protocols, which reaches consensus through repeated randomized sampling rather than through the round-based voting of classical Byzantine fault tolerant designs. There is no leader gathering votes from the entire validator set. Instead each node repeatedly asks a small random sample of validators what they currently prefer, adopts whichever answer carries a sufficient majority of that sample, and accepts a decision once it has seen enough consecutive samples agree. Because a node queries a fixed-size sample rather than everyone, the messaging load per node barely grows as the validator set grows, which is what allows the set to be large without consensus becoming the constraint.

Snowman is the variant used for linearly ordered chains, and Snowman++ layers a proposer schedule over it: block-building windows are assigned to proposers in proportion to stake, with production opening more widely if a designated proposer fails to act, which limits contention without introducing a fixed committee. Sampling remains the voting mechanism throughout. An earlier design in which the exchange chain ordered transactions as a directed acyclic graph was retired in 2023 when that chain was linearized, and the whole Primary Network now runs on the same linear engine.

Acceptance is fast, typically under a second, and once a decision is accepted the protocol treats it as irreversible. Formally the guarantee is probabilistic: sampling parameters can drive the chance of two conflicting decisions both being accepted arbitrarily close to zero, but not to exactly zero, which is a different kind of statement from the deterministic finality a quorum-certificate protocol offers. Validators join the Primary Network by bonding the native asset for a chosen term, holders may delegate to them, and the protocol does not slash bonded principal.

BNB Smart Chain, the programmable chain of BNB Chain and formerly styled Binance Smart Chain, reaches agreement through Proof of Staked Authority, a design that borrows stake-weighted election from delegated proof of stake and rotating, permissioned block production from proof of authority. Bonded stake decides who may produce blocks rather than who wins any individual slot. The network keeps an active set of forty-five operators, ranked by the amount of the native asset bonded to them through self-delegation and through delegation from holders. The twenty-one highest-ranked form the cabinet tier and the next twenty-four are candidates, with everyone below inactive and producing nothing. Rankings are recomputed once a day, so membership of the set turns over on a daily cycle rather than per block.

Within each epoch a consensus group of twenty-one is drawn from the active set, weighted heavily toward the cabinet tier, and those operators take turns proposing in a fixed rotation. Turn length and epoch length are protocol parameters that have been retuned repeatedly as block intervals shortened: successive upgrades cut the interval from three seconds to 1.5, then to 0.75 in mid-2025, and to 0.45 seconds in January 2026. A separate voting layer sits above the rotation, in which validators sign attestations on recent blocks; once enough signatures accumulate a block is treated as final, giving deterministic finality in roughly a second. Should that voting layer stall, the chain falls back to confirmation by accumulated depth, which takes minutes rather than seconds.

Security rests on an honest supermajority of a deliberately small elected set, backed by on-chain penalty logic. A slashing contract watches for double signing, for contradictory attestations in the fast-finality vote, and for repeated failure to produce during an assigned turn. Consequences range from temporary jailing and lost rewards through to removal from the set and forfeiture of part of a validator's own bonded stake. The trade-off is deliberate: a compact, frequently re-elected validator set buys very short block intervals and cheap execution, at the cost of the broader operator base that larger validator sets provide.

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.

Block production on the Harmony network stopped on 10 September 2026, when its two remaining shards sealed their final blocks within minutes of each other, and the chain no longer reaches agreement on new transactions. What follows describes the mechanism as it ran until that point. Harmony combined a stake-weighted validator election with a Byzantine fault tolerant block protocol and a partitioned chain structure. The network began with four parallel shards and was later consolidated to two: shard 0, which also acted as the beacon chain, and shard 1. Each shard kept its own ledger and state database, so an operator elected to a shard stored and verified only that shard's portion of the whole.

Seats were allocated once per epoch, a period of roughly eighteen hours, through an election run on the beacon shard. Operators registered signing keys and committed stake behind them, but the weight a key carried was not simply the amount behind it. A key's counted weight was confined to a narrow band around the median commitment across all candidates, so stake far above the median was trimmed down to the upper bound of that band and stake below it was lifted to the lower bound. Keys were then ranked by the adjusted weight, the highest-ranked filled the available seats, and each was assigned to a shard by a deterministic function of the key itself. The intent was that accumulating stake beyond a point would yield no further influence over consensus.

Within a shard, blocks were produced by a leader and confirmed by the elected committee in a single round of voting. Votes used an aggregatable signature scheme, collapsing hundreds of individual signatures into one constant-size signature and keeping message volume linear in committee size. A block committed once signatures representing more than two thirds of the shard's voting power had been gathered, giving finality in roughly two seconds, and an unresponsive or faulty leader was replaced through a view change. Shard 1 anchored its blocks to the beacon shard through crosslinks, and value crossed between shards as receipts that the receiving shard checked against those anchors. A defect in that cross-shard receipt accounting was exploited in August 2026, allowing receipts to be credited more than once, and the chain was rolled back to an earlier checkpoint before the wind-down was agreed.

The Huobi ECO Chain, generally known as HECO, no longer operates. Its validators stopped producing blocks in January 2025 after the body that governed the chain resolved to wind it down, and the public nodes, block explorer and project site that supported it have since been withdrawn; the hostnames they used no longer resolve. What follows describes the mechanism as it last ran.

HECO was an Ethereum-compatible chain built from a fork of the predominant Ethereum client, and its consensus combined authority-based block sealing with an on-chain staking contract, a pairing its documentation called hybrid proof of stake. At most twenty-one accounts formed the active set at any moment. Membership was not granted administratively: a candidate locked the network's native asset in a validator contract, any account could add stake to a candidate, and the ranking by total stake decided who was in. The set was not recomputed continuously. Blocks were sealed in a fixed rotation and the chain advanced roughly every three seconds, with every two hundred blocks closing an epoch; only at an epoch boundary did the client consult the staking contract and install the new leading twenty-one.

Agreement worked differently from the two-thirds voting schemes used by Byzantine fault tolerant chains, and the distinction is material. A HECO block was valid because it had been sealed by the member of the current authority set whose turn it was, not because a supermajority had voted for it, so the chain could in principle fork and confirmation was probabilistic: a block became safe as successive blocks were built on top of it, not at the instant it was proposed. Settlement was quick in practice because the authority set was small, identifiable and rotated predictably, but the network did not provide the immediate, irreversible finality that a voting protocol delivers. Security rested on the assumption that a majority of those twenty-one sealers, economically committed through the stake locked behind them, would not collude. Separate contracts governed admission, proposals and the recording of misbehavior, which kept the rules of participation on the chain itself rather than in agreements between operators.

NEAR Protocol is a sharded proof-of-stake network. Rather than running independent chains alongside one another, it treats the whole system as a single logical chain whose every block is assembled from per-shard pieces called chunks, so one block header commits to the state of every shard at once. An account's address determines which shard holds it. The network launched with a single shard and has since grown to several; a 2026 protocol release made the split automatic, so a shard now divides at an epoch boundary once its state passes a configured size threshold, instead of waiting for a coordinated upgrade.

Participation is decided by a recurring auction over stake. An operator wanting to validate submits a staking proposal; at each epoch boundary the protocol sorts the proposals, derives a seat price from them, and assigns duties to those clearing it, with some accounts producing blocks, others producing the chunks of a particular shard, and the rest acting as chunk validators. Epochs last roughly half a day and assignments are reshuffled each time, so no operator holds a given shard indefinitely. Because the seat price floats with the total stake competing for entry, the threshold rises and falls with demand rather than being fixed in the protocol.

The design that most distinguishes this network is stateless validation, adopted in 2024. A chunk producer publishes, alongside its chunk, a compact witness carrying exactly the state that chunk touched together with proofs against the shard's state root. Chunk validators check the work from that witness alone, so they can verify a shard without storing it, and shards can be added without pushing hardware requirements steadily upward.

Blocks are produced under Doomslug, which allows the next block to be built once more than half of the stake has endorsed its predecessor, giving a fast practical guarantee that the chain will not reorganize. Full finality comes from a separate rule once two-thirds of the stake has endorsed, normally within a small number of blocks. Safety rests on more than two-thirds of staked value behaving honestly, and activity crossing shard boundaries travels as receipts routed asynchronously over subsequent blocks.

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.

Polygon PoS is an EVM-compatible proof-of-stake network that runs its own validator set and anchors itself to Ethereum by posting periodic checkpoints there. It should not be confused with the other chains that have carried the Polygon name: the zero-knowledge rollup operated under that brand was shut down in 2026, and chains built with Polygon's development kit are independent networks with their own validators. Polygon PoS executes transactions and holds its own transaction data, so it is a sidechain or commit-chain rather than a rollup inheriting Ethereum's execution and data-availability guarantees.

The architecture splits into two node layers that every validator runs together. The execution layer, derived from Go Ethereum, assembles transactions into blocks. The consensus layer coordinates the validator set, tracks staking and finalizes checkpoints; it was rebuilt in 2025 on the Cosmos SDK and CometBFT, which brought checkpoint-based finality down from a wait of one to two minutes to a matter of seconds and capped how deeply the chain may reorganize. At intervals the consensus layer gathers the blocks produced since the last checkpoint into a Merkle tree and submits the root to contracts on Ethereum, where it becomes the reference point for bridge withdrawals.

Staking itself lives on Ethereum. Validators bond the network's native asset, POL, which replaced MATIC in the migration that began in 2024 and now serves as both the staking asset and the gas asset, into contracts on Ethereum mainnet; holders delegate through share-based pools in the same contracts. The active set is capped, so entry requires displacing an incumbent by stake.

Block production changed materially with the Rio upgrade in late 2025. Rather than rotating producers by stake-weighted draw over short intervals, validators now vote, with voting power weighted by stake, to elect the producer or producers for a span. Because a single elected producer builds the span, competing chain tips largely disappear and reorganizations are eliminated. The same upgrade introduced witness-based verification, letting a validator check a block against a supplied witness instead of holding full state, which lowers the storage burden of participating.

Gnosis Chain is a proof of stake network with its own validator set and its own genesis, secured entirely by that validator set rather than by any other chain. It began as a proof of authority sidechain, and in December 2022 a separately bootstrapped consensus chain merged with the existing execution chain, replacing the authority set with staking. Since then the architecture mirrors Ethereum's: every participant runs two pieces of software, an execution client that processes transactions and maintains state, and a consensus client that votes on and orders the blocks. The same independent client implementations used on Ethereum are used here with adjusted parameters, which keeps the network from depending on a single codebase. It is not a rollup and not a layer two; the bridges connecting it to Ethereum move assets but carry no part of the ordering or validation of its blocks.

Time is divided into five second slots grouped into epochs of sixteen slots, giving an epoch of roughly eighty seconds. For each slot the protocol pseudorandomly assigns one validator to build a block and a committee of others to attest to what they see, with the assignment derived from an on chain randomness accumulator so that upcoming duties are hard to predict or target. The fork choice rule follows the branch carrying the greatest weight of recent attestations, and a separate finality mechanism operates on epoch boundaries: when a supermajority of the staked balance attests across two successive epochs, the earlier one is finalized and can no longer be reverted without the destruction of a large fraction of all stake.

The distinctive parameter is the size of a validator deposit, an order of magnitude smaller in relative terms than Ethereum's, which has produced an unusually large and widely distributed set of validating keys. A later upgrade allowed a single validator to hold a much larger effective balance, letting operators consolidate many keys into one. The network has also deployed an optional encrypted transaction pool, in which threshold cryptography keeps transaction contents hidden from the block builder until ordering is already fixed.

Uniswap is present on the following networks: Arbitrum, Avalanche, Binance Smart Chain, Ethereum, Harmony One, Huobi, Near Protocol, Optimism, Polygon, Gnosis Chain.

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.

Validators on the Primary Network are compensated out of protocol issuance under a capped supply schedule rather than out of user fees. An operator bonds a minimum amount of the native asset for a chosen staking term and is paid at the end of that term provided it met the uptime requirement. A validator's effective weight is capped relative to its own bonded stake, which limits how much delegated stake any single operator can concentrate. Holders who do not run infrastructure may delegate to a validator for a term and receive the reward net of the fee that validator charges.

The enforcement model is unusual in that bonded principal is not slashed. A validator that fails to meet the uptime threshold simply does not receive its reward for that period and gets its stake back, so the penalty is forfeited income rather than confiscated capital. The most recent protocol upgrade reworked these terms considerably: the minimum staking term was shortened from two weeks to two days, staking terms can now renew automatically with rewards compounded at a chosen ratio, the uptime threshold required to earn a reward was raised for newly started validations, and the average rate at which rewards are issued was reduced.

Sovereign networks running alongside the Primary Network are funded differently. Since the late-2024 upgrade that separated them, their validators no longer need to bond a large stake and validate the Primary Network as well; instead they pay a continuous fee to the platform chain that adjusts with the number of active such validators relative to a target, rising when the population exceeds it and easing when it falls short.

Users of the contract chain pay a base fee plus an optional tip, priced dynamically in the style of Ethereum's fee market. The distinguishing feature is that the fee is burned rather than paid to the block producer, so transaction activity reduces supply and offsets issuance instead of rewarding validators directly. The minimum base fee has been lowered by upgrade and is now a floor that validators adjust collectively rather than a hard-coded constant. The exchange and platform chains likewise price their operations dynamically, and those fees are burned as well. There is no storage rent.

BNB Smart Chain pays for its own security out of transaction fees rather than out of new issuance. The native asset carries no protocol-level block subsidy, so every reward reaching a validator or a delegator originates in gas paid by users. When a block is finalized the proposer's collected fees are routed into system contracts and split three ways. A governed fraction is sent to an unspendable address and permanently removed from supply, a slice accumulates in a reward vault used for network-wide purposes such as paying for fast-finality attestations, and the balance sits in the validator-set contract until it is distributed, on a daily cycle, to active validators and the holders who delegated to them.

Participation is staking-based. An operator must self-delegate a substantial amount of the native asset before it can be considered for the active set, and holders may bond additional stake to any validator to lift its ranking. Delegators receive their proportional share of whatever the validator earns, after the commission that validator sets for itself, and only the forty-five ranked operators earn at all: stake bonded to an inactive validator yields nothing. Unbonding is subject to a waiting period, so stake cannot be pulled out the instant misbehavior comes to light.

Penalties are graduated. Missing assigned turns or going offline for a sustained stretch triggers jailing, during which the validator produces nothing and earns nothing. Double signing and contradictory attestations in the finality vote are treated far more severely and can cost the validator a portion of its own bonded stake alongside ejection from the set.

Users face a conventional gas-metered fee model inherited from the Ethereum virtual machine. Each operation carries a gas cost, the sender chooses a gas price, and the total is charged in the native asset. There is no separate storage rent, so the cost of persisting state is bundled into execution gas, and deploying or calling a contract is priced purely by the computation and storage it consumes. The minimum acceptable gas price is a coordinated parameter that operators and infrastructure providers have revised downward several times, keeping ordinary transfers and contract calls inexpensive in absolute terms.

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.

No rewards accrue and no fees are payable on Harmony now that block production has ceased; the arrangements below are those that applied while the network ran. Two roles were paid. Operators ran the signing nodes and set a commission rate, and delegators assigned stake to an operator without running any infrastructure themselves. Each block minted an amount of the network's native asset, and that issuance was distributed across the elected keys in proportion to the adjusted stake weight used in the election, with each operator taking its commission before the remainder passed through to the delegators behind it. Because weight was capped near the median, stake piled onto an already large operator earned nothing extra, so the reward schedule itself carried most of the burden of discouraging concentration.

Two kinds of failure carried consequences. Signing two conflicting blocks at the same height was treated as an attack: a proportion of the stake behind the offending keys was confiscated from the operator and its delegators alike, a floor applied regardless of how small the offending voting share was, half of the confiscated amount was destroyed and half paid to whoever submitted the evidence, and the operator was barred from the network permanently. Falling short on availability was treated as neglect rather than attack. An operator whose keys signed fewer than two thirds of the blocks they were asked to sign over an epoch was marked inactive, dropped from the following election, and had to submit a transaction to put itself forward again.

Users paid for execution in the network's native asset, metered in gas in the manner familiar from Ethereum-compatible chains: a fixed charge for a plain transfer and a charge proportional to the computation and storage a contract call consumed, multiplied by a price the sender set. There was no congestion-responsive base fee, no separate priority auction, and no recurring charge for holding state on the chain. Transaction fees were destroyed rather than handed to the proposer, which offset part of the issuance and meant that heavier use diluted existing holdings less. A transfer between the two shards was paid for on the originating shard and completed once its receipt had been taken up on the receiving side.

Nothing is paid or charged on HECO today, since block production ended in January 2025; the arrangements below are those in force when it stopped. The economics were simple, and in one respect unusual: the protocol minted nothing. There was no block subsidy and no new issuance of the native asset to compensate the sealers. The entire reward available to the active set was the gas that users had already paid in the blocks it produced, collected and shared out in proportion to the stake standing behind each validator. Security was funded wholly by demand for block space, so a quiet chain paid its operators correspondingly little.

Participation had a low floor. A candidate registered by locking a small fixed quantity of the native asset, and any holder could add stake to any candidate without operating infrastructure, with no minimum on the delegated amount. Stake moved a candidate up the ranking, and a candidate that reached the leading twenty-one entered the active set at the next epoch boundary, so entry and exit were continuous rather than requiring a governance decision each time. Withdrawal was deliberately slow: after submitting an unstaking request a participant waited a fixed number of blocks, on the order of a few days, before the assets could be moved, keeping capital exposed long enough for misconduct to come to light.

Discipline was administered by a dedicated contract that counted failures to produce a block when due. The penalties escalated with that count rather than arriving in one step: past a first threshold the validator forfeited the rewards it had accumulated, and past a second it was removed from the active set. The principle is worth stating precisely, because it differs from the slashing designs common elsewhere: the locked stake itself was not confiscated, so an absent or unreliable validator lost its income and its seat but not its capital. Users paid for execution in the native asset, metered in gas exactly as on Ethereum, with a fixed charge for a plain transfer and a charge proportional to the computation and storage a contract call performed, multiplied by a price the sender chose. There was no congestion-responsive base fee, no burn, and no recurring charge for occupying state; the whole of every fee reached the validators.

The network issues a fixed proportion of the supply of its native asset each year, on the order of five percent, and divides it: roughly nine-tenths is paid to the validators of each epoch and the remaining tenth goes to a protocol treasury. Epoch rewards are proportional to the seats an account holds, and they are conditional on work actually performed. A validator that produces fewer than the required proportion of the blocks or chunks it was assigned earns nothing for that epoch and is removed from the set for the following one, with re-entry taking a further two epochs. Holders who do not want to operate infrastructure can delegate to a staking pool contract, which pools their stake behind an operator and passes back rewards net of that operator's commission.

Penalties deserve to be stated precisely. The protocol specifies a design under which stake could be confiscated for provable misbehavior, but that mechanism is not switched on. What actually operates is economic exclusion: forfeited rewards, ejection from the validator set, and the delay before an ejected account can return. Stake itself is not taken.

Execution is paid for in gas. Unlike an auction-priced fee market, the cost of each operation is fixed in protocol configuration, and the gas price moves only gradually in response to how full recent blocks have been, so costs stay predictable and do not spike sharply with congestion. Gas spent is destroyed rather than handed to validators, who are paid from issuance instead. Historically three-tenths of the gas burned by a contract call was credited to the account of the contract being called, a rebate meant to fund contract authors; network governance has voted to set that share to zero so the entire amount is burned.

State is charged for separately through storage staking. An account must keep an amount of the native asset locked in proportion to the bytes it occupies, in the region of one unit per hundred kilobytes, and the lock is released when the data is deleted, so there is no recurring rent. Access keys and meta-transactions additionally let one party cover another's gas.

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.

Validators on Polygon PoS are paid for two distinct jobs: producing and executing blocks on the chain itself, and signing the checkpoints submitted to Ethereum. Rewards are distributed per checkpoint, funded by protocol issuance of the native asset together with an allocation of transaction fees, and they are apportioned by stake and by how reliably each validator signed. Because the staking contracts sit on Ethereum, a validator's operating costs include Ethereum gas for checkpoint submission and for staking transactions, a meaningful expense that chain-local fee models do not capture.

Delegation works through validator-specific share pools. A holder exchanges the native asset for shares in a chosen validator, and as rewards accrue the redemption value of each share rises, so returns appear as appreciation of the share rather than as separate payments. Validators take a commission before the remainder flows to their delegators. Stake withdrawn from a validator remains locked for a defined number of checkpoints before it can be moved out, while switching between validators carries no such delay.

The penalty structure is weighted toward lost income. The staking contracts define consequences for double-signing and for sustained unavailability, but in normal operation the dominant economic pressure on a validator is forfeited reward: missed checkpoint signatures and poor block-production uptime reduce what a validator and its delegators earn. The producer election introduced by the Rio upgrade also redistributes fee income, including value captured from transaction ordering, toward validators that are not currently producing, so that supporting the chain stays worthwhile for the rest of the set.

Users pay fees in the native asset under a base-fee-plus-tip model. The base fee moves with how full recent blocks have been and is routed to a burn path, while the optional tip goes to the producer. A 2026 protocol change made that base-fee destination configurable in order to fund a time-limited program that recycles fees for one narrow category of activity, with ordinary transactions continuing to follow the burn path. There is no storage rent, and contract deployment and execution are charged purely as metered gas on the resources they consume.

Validators are paid from two separate streams. Consensus duties — attesting to blocks, serving on the synchronization committee and proposing when selected — are rewarded in the staking asset, issued by the protocol and accruing to the withdrawal address the operator nominated when depositing. Execution duties pay in the network's gas asset: when a validator proposes, it receives the priority tips attached to the transactions it includes, together with any value it captures from how it orders them. The issuance rate is not fixed. It is a function of the total balance staked, so the reward for each validator falls as the active set grows, and the design targets a level of security rather than a headline yield.

The penalty structure is symmetric with the reward structure. A validator that misses an attestation, or attests to the wrong thing, loses roughly what it would have earned for getting it right, so ordinary downtime is a small recurring cost rather than a catastrophe. If the chain fails to finalize for an extended period, a progressively steeper drain applies to validators that are not attesting, shrinking their balances until the participating remainder regains a supermajority. Provable equivocation is punished far more severely: proposing two blocks for one slot, or casting votes that contradict each other, costs part of the balance immediately, forces exit from the validator set, and carries an additional penalty scaled to how many other validators were caught doing the same thing over the same period, so coordinated attacks are punished far harder than isolated mistakes. Exiting voluntarily is also rate limited by a queue.

Users pay in the gas asset, a stable value token minted on this chain when a dollar denominated stablecoin is locked in the native bridge on Ethereum, which makes transaction costs predictable in fiat terms. Each transaction carries a base component, priced algorithmically from recent block fullness and never paid to the proposer, and an optional tip that is. Contract execution is metered in gas, and stored data carries no recurring rent.

Uniswap is present on the following networks: Arbitrum, Avalanche, Binance Smart Chain, Ethereum, Harmony One, Huobi, Near Protocol, Optimism, Polygon, Gnosis Chain.

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.

Avalanche is a staked network, so its energy estimate is assembled from the machines that participate rather than from hardware economics driven by block rewards. One structural feature shapes the calculation: a single Primary Network validator runs one node that validates the contract chain, the exchange chain and the platform chain together. The three are therefore not summed as though they were three independent populations, which would count the same hardware three times; the footprint is modeled against one node population serving all of them.

The estimate combines three inputs. The validator set is read directly from the platform chain, which makes the consensus-participating population unusually well observed compared with networks where it has to be inferred. The surrounding population of non-validating full and archive nodes, run by applications, data services and trading venues, is approximated from peer-discovery crawls and public listings, which see only nodes that accept inbound connections and so tend to undercount. A representative hardware profile is then inferred from the published requirements for the node software, and the power draw of such a configuration is taken from measurement of comparable machines under sustained load and at idle, since a validator draws power continuously whether or not it is currently proposing.

The result carries qualifications that should be read as part of the figure rather than as footnotes to it. Node counts and hardware profiles are inferred from public observation and stated requirements, not metered at the socket. Where evidence is missing, the assumptions chosen are the ones more likely to overstate consumption than to understate it. Estimates are revised as crawler coverage and hardware information improve. Sovereign networks that maintain their own validator sets are accounted for separately from the Primary Network rather than folded into it. And where a share of the total is attributed to an individual asset issued on the chain, that share is derived from observed on-chain transfer volumes, which measures how heavily an asset is used rather than the energy it uniquely causes.

The energy figure for BNB Smart Chain is built upward from the node population rather than downward from operator revenue, which is the appropriate treatment for a staked network where block production is not a computational race. Nothing about the fee model or the value of the native asset determines how much hardware is deployed: the size of the validator set is fixed by protocol, and the wider population of non-validating nodes is driven by demand for chain access.

The estimate has three inputs. The first is the number of machines. The elected validator set is known from the chain itself, while the surrounding population of full and archive nodes is approximated from peer-discovery crawls, public node listings and network scans, all of which observe only nodes willing to accept inbound connections and therefore tend toward undercounting. The second input is a representative hardware profile per node, inferred from the client software's published requirements, which on this chain are demanding relative to slower networks of the same family, since sub-second block intervals and rapid state growth push operators toward high core counts, large memory and fast solid-state storage. The third is the electrical draw of such a machine, taken from measurement of comparable configurations on the bench, both under sustained load and at idle, because a validator idles between its assigned turns and that baseline draw is a real part of the total. Aggregating the per-machine figure across the estimated population, with an allowance for the overhead of the facilities housing it, gives the network total.

Several qualifications belong with the result. It is a modeled estimate resting on observed node counts and stated software requirements, not metered consumption at the socket. Where evidence is thin, the assumptions chosen lean toward overstating rather than understating consumption. Figures are revised as crawler coverage and hardware information improve. Finally, apportioning a share of the network total to any single asset issued on the chain is done from observed on-chain transfer volumes, which measures how heavily an asset is used rather than the energy it uniquely causes.

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 estimate is assembled from the machines that ran the network, not derived from anything the protocol itself reports. Because Harmony settled blocks through stake-weighted voting rather than mining, there is no hash rate to reason from and no computational race to model; what the network drew was determined by how many machines were kept powered and what each of them consumed. The first input is therefore a count of participants: the elected committees on each shard, the redundant nodes operators kept ready so as not to miss their turn, and the non-validating full nodes, archive nodes and public endpoints that wallets and applications depended on. That population is reconstructed from the chain's own staking and election records together with crawls that enumerate reachable peers, and neither source sees every machine.

The second input is a hardware profile. The client software published the processor class, memory and storage needed to keep pace with the chain, and a representative machine is inferred from those stated requirements rather than surveyed from the operators themselves. Power draw for that representative machine is taken from measurements made on comparable equipment under controlled conditions, covering idle as well as loaded operation, since a validating node consumes power continuously whether or not transactions are flowing. Total consumption is that per-device draw applied across the estimated machine count over the reporting period. The shard structure matters here: an operator elected on both shards had to run a node for each, so the machine count exceeded the operator count.

Two limitations are inherent to this approach. It is a reconstruction from public observation and stated software requirements, not a metered reading of anyone's equipment, and real operators run machines that depart from the published specification in both directions. Where the evidence runs out, the assumption selected is the one that produces the larger number, so the result is likelier to overstate the impact than to understate it, and estimates are revised as observation improves. The portion of the network total attributed to an individual asset issued on the chain is set by that asset's observed on-chain transfer activity as a proportion of all activity. The chain's status is the overriding caveat: with block production stopped and the supporting infrastructure being retired, consumption attributable to continuing operation falls away, and any quantity reported relates to the period in which the network was live.

Consumption is built up from the machines that ran the chain rather than read off any protocol metric. HECO settled blocks by rotating a small authority set, not by mining, so there is no computational race to model and no work rate to convert into hardware; what the network drew was decided by how many servers were kept powered and what each consumed while idle, which for this design was most of the time. The first input is a machine count. The active set was capped at twenty-one, but the relevant population was larger: candidates outside the active set who stayed ready to enter at an epoch boundary, the redundant nodes operators kept so as not to miss their turn, and the non-validating full nodes, archive nodes and public endpoints that wallets and applications relied on. Those are reconstructed from the chain's own staking records and from crawls of reachable peers, and neither source was ever complete.

The second input is what such a machine draws. The client published the specifications required to keep pace with the chain, and because it derived from an Ethereum client those specifications pointed at ordinary server hardware rather than anything purpose-built. A representative configuration is inferred from them, and its power draw is taken from measurements on comparable equipment made under controlled conditions, covering idle as well as loaded operation. The total is that draw applied across the estimated machine count for the period in question.

The honest description of the result is a reconstruction rather than a measurement. No operator's hardware was metered; the machine count rests on what a crawler could see and the hardware profile on what the software asked for rather than on what operators actually bought. Where evidence ran out, the more conservative assumption was taken, meaning the one yielding a larger figure, so the result errs toward overstatement. The share of the network total attributed to an individual asset issued on the chain is set by that asset's observed on-chain transfer activity relative to all activity. The decisive caveat is the chain's status: with block production ended and the supporting infrastructure withdrawn, there is no ongoing consumption to estimate, and any quantity reported describes the period when the network was still running.

The figure reported for this network is an estimate assembled from the infrastructure that runs it, not a metered reading. It works upward from the population of machines taking part, and from what each of those machines can be expected to draw.

The first input is the size and composition of that population. It is estimated from publicly observable network data, including peer discovery, the published validator set and its per-epoch duty assignments, and open directories of operators, gathered by automated collection of the same information. For a sharded network this matters more than a headline count, because duties are divided between block producers, the producers of each shard's chunks, and the chunk validators that verify them; the estimate has to cover all of those roles rather than only the accounts holding seats. Machines that take no part in consensus but that the network needs in order to be usable, such as archival nodes and query-serving infrastructure, are included as well.

The second input is consumption per machine. A representative hardware profile is inferred from the resources the client software states it requires, covering processor cores, memory, disk and bandwidth, and power draw is attributed from laboratory measurement of devices matching that profile. Draw is counted continuously, including the large idle component, since a validator has to stay online whether or not it currently holds an assignment. Multiplying the per-device figure across the estimated population produces the network total.

The limits should be read plainly. Both the population and the hardware mix are inferences drawn from public observation and from stated software requirements; operators are not surveyed and meters are not read. Where the evidence runs out, the assumption chosen is the one that makes the impact look larger rather than smaller, so the resulting figure is more likely to overstate than understate. Stateless validation also changes the profile over time, since verifying a shard no longer requires storing it, and the estimate is revised as observation of the network improves and as the shard count changes.

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.

Polygon PoS is a staked network, so its consumption is modeled from the machines that run it rather than from mining economics. Two components are added together. The first is the chain's own infrastructure: every validator operates a paired execution and consensus process, which in practice means a heavier machine than a single-process chain of comparable throughput would need, plus the wider population of full and archive nodes serving applications and data consumers. The second is a share of Ethereum's consumption, because the checkpoint and staking transactions that give Polygon PoS its anchor are executed by Ethereum's validators; that share is apportioned by the gas those transactions consume as a fraction of total Ethereum gas.

For the chain's own component, the node count is estimated from peer-discovery crawls, public node listings and the validator set recorded on chain, with the understanding that crawls see only nodes willing to accept connections. A representative hardware profile is inferred from the published requirements for running both node processes, and the electrical draw of such a configuration is taken from measurement of comparable machines, at load and at idle, since a validator's hardware draws power continuously regardless of whether it is currently producing. Aggregating across the estimated population, with an allowance for the overhead of the facilities housing it, gives the chain-local total.

The usual qualifications apply and matter here. The node population and the hardware behind it are inferred from public observation and stated software requirements, not metered. Where evidence is incomplete, the assumptions used err toward a higher figure rather than a lower one. The estimate is revised as observation improves. The gas-based apportionment of Ethereum's consumption is a convention rather than a physical measurement, since Ethereum's validators would run whether or not the checkpoints were posted. And where a share of the network total is attributed to an individual asset issued on the chain, that attribution is made from observed on-chain transfer volumes, which reflects how heavily an asset is used rather than the energy it uniquely causes.

The reported consumption is an estimate constructed from the machines running the network, not a measured quantity. The first step is to size the physical node population, using network crawlers, peer discovery traffic and information operators publish themselves. One feature of this network makes that step unusually error prone and worth stating plainly: because the deposit required for a single validator is small, the number of validating keys is very large, and a single physical machine can run hundreds of them behind one consensus client. Counting keys would therefore overstate the hardware enormously. The estimate counts machines, and treats the key count as evidence about participation rather than about equipment.

The second step is to characterize those machines. Every participant runs an execution client and a consensus client, usually on the same host, and the hardware profile is inferred from the processor, memory and storage specifications those clients publish as their requirements, mapped onto server and workstation configurations that satisfy them. Power draw for such configurations comes from laboratory measurement taken both under load and at rest. The period total aggregates that draw across the estimated set, idle time included, since a synchronized node consumes power whether or not it is presently doing anything.

The result carries the limits of its inputs. Node counts and hardware profiles are inferred from public observation and stated requirements rather than from an inventory, and this network's mix spans everything from rented cloud instances to small machines run at home, which have quite different efficiency characteristics. Where evidence is thin the assumptions chosen are the ones more likely to overstate the footprint than to understate it, and figures are revised as the observed picture sharpens. Client efficiency and hardware requirements also change across protocol upgrades, so estimates from different periods are not strictly comparable.

Uniswap is present on the following networks: Arbitrum, Avalanche, Binance Smart Chain, Ethereum, Harmony One, Huobi, Near Protocol, Optimism, Polygon, Gnosis Chain.

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.

Establishing a renewable share for Avalanche is first a question of geography, because the same hardware draws very different electricity depending on which grid it sits on. The validator set is enumerated from the platform chain, and the network addresses behind those validators, together with the wider set of nodes seen through peer discovery and public network observation, are resolved to hosting providers, autonomous systems and countries. That yields an approximate map of where node capacity is concentrated. Where the mapping is too incomplete to support a result, the observed distribution of a network with comparable staking economics is used in its place.

The map is then joined to national electricity statistics. Each country's share of generation from renewable sources is taken from Share of electricity generated by renewables, compiled and processed by Our World in Data from Ember's yearly electricity datasets and the Energy Institute's Statistical Review of World Energy. Weighting country-level shares by the estimated node capacity located in each gives one renewable percentage for the network as a whole.

Energy intensity is a marginal measure rather than an average: the additional electricity associated with one further transaction being processed. Because validators run continuously and blocks are produced on a schedule regardless of how full they are, the marginal figure is considerably lower than the annual total divided by transaction count, and the two answer different questions.

Several limits constrain what the renewable percentage can mean. Hosting location reveals a grid but not a contract, so operators procuring renewable electricity on a carbon-heavy grid are not distinguished from those that are not. Cloud regions and proxied connections can place a node's apparent location away from its actual hardware. Annual national averages flatten the hourly and seasonal movement in generation mix. And validator infrastructure is concentrated in a relatively small number of hosting markets, so the result is sensitive to how a handful of large operators are located.

The renewable share reported for BNB Smart Chain follows from where its machines physically run, so the method begins with locating them. Node addresses visible through peer discovery and public network observation are resolved to hosting providers, autonomous systems and countries, producing an approximate geographic distribution of the validator and full-node population. Where that observation is too sparse to stand on its own, the distribution of a network with a comparable staking design and operator economics is substituted, on the reasoning that similar incentives attract similar operators into similar hosting markets.

That distribution is then matched against national electricity statistics. Each country's share of generation coming from renewable sources is taken from Share of electricity generated by renewables, compiled and processed by Our World in Data from Ember's yearly electricity datasets and the Energy Institute's Statistical Review of World Energy. Weighting those country-level shares by the portion of estimated node capacity sitting in each gives a single renewable percentage for the network.

Energy intensity is a separate quantity and is defined marginally: the additional electricity associated with one further transaction being processed, rather than the annual total divided by the transaction count. On a chain that produces blocks on a fixed schedule whether or not they are full, the marginal figure is far smaller than a simple average would suggest, and the two should not be used interchangeably.

Three limits are worth stating plainly. An observed hosting location identifies a grid but not a procurement arrangement, so an operator buying renewable power on a carbon-heavy grid is indistinguishable from one that is not. Cloud and proxy infrastructure can place a node's apparent location away from the hardware actually running it. And national annual averages smooth over the hourly and seasonal variation in generation mix that a continuously running machine actually draws from.

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 is not something the protocol records, so it is inferred from where the machines stood. Reachable nodes advertise network addresses, and those addresses are resolved to a country through public address-allocation registries. What comes out is a distribution of the node population across jurisdictions rather than a list of sites, and it is imperfect in predictable ways: addresses can be proxied, they can belong to hosting providers registered in one country while the equipment sits in another, and a machine behind a firewall may not be visible to a crawler at all.

Where too little of a population can be placed this way to be credible, the geographic profile of a different network stands in. The substitute is chosen because its participants face a comparable cost structure and a comparable reason to run a node, on the reasoning that similar incentives draw operators to similar places. Harmony's elected set was small, and a small set placed only partially is exactly where such a substitution does real work, so it is a genuine source of uncertainty rather than a formality.

Each jurisdiction in the distribution is then matched to published statistics on how its electricity is generated, and the renewable proportion for the network is the share-weighted average across those jurisdictions. Those statistics are 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. The figures are annual and national, so they cannot capture an individual facility's supply arrangements or the hour of day at which load actually fell.

Energy intensity, as the term is used here, is a marginal rather than an average quantity: the additional electricity needed to carry one more transaction. On a network that settles by scheduled voting, almost the whole of the draw is fixed, because committees sign at a set interval whether the block is full or empty. The true marginal cost of one further transaction is accordingly close to nothing, and the intensity figure is better read as total consumption spread over observed throughput. It serves to compare networks of different designs on a common basis; it does not measure what any single transaction caused. Since the chain stopped producing blocks, no fresh node observation is possible and the distribution can only be drawn from what was recorded while it operated.

The renewable share is not a property the protocol records, so it is inferred from where the machines stood. Reachable nodes advertise network addresses, and those addresses are resolved to a country using public address-allocation registries, producing a distribution of the node population across jurisdictions rather than a list of physical sites. The method is imperfect in known ways: addresses can be proxied, they can belong to hosting providers registered in one country while the equipment sits in another, and machines behind firewalls never appear to a crawler.

Two features of this network compound that uncertainty. The authority set was capped at twenty-one and much of the surrounding infrastructure was operated by a small number of parties, so a handful of unplaceable nodes could shift the distribution materially, in a way that would not happen on a network with thousands of independent operators. More decisively, the chain has stopped: its nodes and endpoints are gone, so no fresh observation is possible and the geographic picture can only be drawn from what was recorded while it ran. Where a population cannot be placed with enough confidence, the geographic profile of a structurally similar network is substituted, chosen because its participants face a comparable cost structure and a comparable reason to run a node, on the reasoning that like incentives put operators in like places.

Each jurisdiction in the resulting distribution is matched to published statistics on how its electricity is generated, and the renewable proportion for the network is the share-weighted average across them. Those statistics come 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. They are annual national figures, so they cannot reflect an individual facility's supply arrangements or the hour at which load fell.

Energy intensity here is a marginal quantity, the additional electricity required to carry one further transaction. On a chain that sealed blocks on a fixed schedule, nearly all of the draw was fixed and independent of how full the blocks were, so the genuine marginal cost of one more transaction was close to zero. The reported intensity is better understood as total consumption spread over observed throughput, a way of putting networks of different designs on a common footing rather than a measurement of any single transaction's effect.

The renewable share attributed to this network is derived from where its machines sit, not from any claim about the electricity the network chooses to buy. The first step is to place the node population geographically. Locations are inferred from publicly observable network data, including the addresses peers announce to one another, information operators publish about themselves, and the hosting providers and data-center ranges those addresses resolve to, all gathered by automated crawling of the peer network. Sharded duty assignment does not complicate this step, since what matters is where a machine physically sits rather than which shard it happens to serve in a given epoch.

Coverage is never complete. Some operators sit behind relays or cloud infrastructure that hides the physical site, and others publish nothing at all. Where a network's own geographic spread cannot be observed in sufficient detail, the distribution observed for a structurally similar network is used in its place, chosen because its participants face comparable incentives and carry comparable consensus duties, and can therefore be expected to cluster in broadly the same regions.

Those locations are then matched to regional electricity statistics. Each machine is associated with the grid serving its location, 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 for the network as a whole, which moves both when operators relocate and when the underlying grids change from year to year.

Energy intensity is reported alongside it and means something narrow: the marginal energy associated with processing one further transaction. Because most of this network's consumption is the fixed cost of keeping validators online rather than anything proportional to throughput, that marginal figure falls as activity rises, and it should not be read as an average cost 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.

The renewable share attributed to Polygon PoS depends on where its infrastructure physically sits, so the method begins with geolocation. Nodes visible through peer discovery and public network observation are resolved to hosting providers, autonomous systems and countries, giving an approximate map of where validator and full-node capacity is concentrated. Coverage is never complete; where it is too thin to be relied on, the geographic distribution of a network with a similar staking design and operator economics is used as a proxy. The same exercise applies to the portion of Ethereum's footprint brought in through checkpointing, using Ethereum's own observed node distribution.

Those locations are then matched to national electricity statistics. Each country's share of generation from renewable sources comes from Share of electricity generated by renewables, compiled and processed by Our World in Data from Ember's yearly electricity datasets and the Energy Institute's Statistical Review of World Energy. Weighting the country-level shares by the estimated node capacity in each produces a single renewable figure for the network.

Energy intensity is reported as a marginal quantity: the extra electricity associated with processing one more transaction, not the annual total divided by the number of transactions. On a chain whose validators run continuously and produce blocks on a schedule, that marginal figure is much smaller than a simple average would suggest, and the two are not interchangeable.

The limitations are inherent to the approach. An observed hosting location identifies a grid, not a power purchase agreement, so an operator sourcing renewable electricity on a carbon-heavy grid is invisible to the method. Cloud hosting and proxying can misplace a node relative to the hardware actually running it. Annual national averages cannot capture the hourly and seasonal swings in generation mix that continuously running machines draw from. And the borrowed share of Ethereum's footprint carries whatever geographic error is present in Ethereum's own distribution.

The renewable proportion is inferred from where the network's machines appear to sit and from how the electricity in those places is generated. Locations are approximated from publicly observable network data: the addresses seen during peer discovery and in crawler output, resolved to country or region rather than to a street. This network is a relatively favorable case for that method, because its low participation threshold has drawn in a wide and internationally dispersed set of operators, many of them running a single machine rather than renting capacity in a handful of large data centers. It remains an approximation. Operators behind hosting providers, relays or privacy services are attributed to the wrong place or not observed at all, and where the picture is too incomplete to support a distribution the geographic spread of a structurally comparable network is used to fill the gap.

The resulting distribution is weighted against published electricity statistics. For each region, the proportion of generation coming from renewable sources is taken from Share of electricity generated by renewables, compiled by Our World in Data from Ember and from the Energy Institute's Statistical Review of World Energy, and applied to the consumption assigned to that region. Summing across regions produces a weighted renewable share for the network. The assumption behind it is that every node draws from its local grid at that grid's average mix, which neither credits an operator on a certified renewable supply contract nor penalizes one on a dirtier local supply, since neither arrangement is visible in network data.

Energy intensity is reported as the marginal energy associated with one further transaction rather than as a period total divided by a transaction count. On a network whose nodes draw essentially the same power across a wide range of block fullness, the incremental figure describes the actual cost of additional usage, while an average would move with how busy the chain happened to be.

Uniswap is present on the following networks: Arbitrum, Avalanche, Binance Smart Chain, Ethereum, Harmony One, Huobi, Near Protocol, Optimism, Polygon, Gnosis Chain.

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.

The emissions estimate for Avalanche reuses the geographic work behind the renewable share and substitutes carbon factors for renewable percentages. The validator set enumerated from the platform chain, together with the nodes observed through peer discovery and public network data, is resolved to countries; where that resolution is too sparse, the distribution of a network with comparable staking economics stands in. Each country is then paired with the carbon intensity of its electricity, taken from Carbon intensity of electricity generation, processed by Our World in Data from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy and published under a CC BY 4.0 license. The estimated electricity in each region, multiplied by that region's grams of carbon dioxide equivalent per kilowatt-hour and summed across regions, gives the annual emissions figure.

Reporting separates two scopes. Scope 1 covers emissions from sources the operators control directly, such as fuel burned on site for power or heat; for a population of servers hosted in rented facility space this is generally negligible and is reported accordingly. Scope 2 covers the indirect emissions embodied in the electricity those machines buy from their grids, which is where effectively the entire footprint of a staked network falls. Hardware manufacture and end-of-life disposal lie outside the boundary of this accounting.

Greenhouse-gas intensity follows the same marginal logic used for energy: the incremental emissions associated with one more transaction, not the annual total divided by throughput.

Uncertainty accumulates across the two steps. Whatever error exists in the electricity estimate passes straight through into emissions, and the geographic step adds its own, since national grid intensities span more than an order of magnitude and shifting a large operator from one country to another visibly moves the answer. Annual averages also conceal the hourly variation in grid intensity that continuously running machines are exposed to in full.

Emissions for BNB Smart Chain are derived from the same geographic picture used for the energy mix, then converted using regional carbon factors. Node locations are approximated from peer-discovery data, public network observation and hosting attribution, and where coverage is insufficient the distribution of a structurally similar staked network stands in. Each location carries the carbon intensity of its national grid, drawn from Carbon intensity of electricity generation, processed by Our World in Data from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy and published under a CC BY 4.0 license. Multiplying the electricity attributed to each region by that region's grams of carbon dioxide equivalent per kilowatt-hour, and summing across regions, gives the annual emissions figure.

The split between scopes matters for interpretation. Scope 1 covers emissions from sources the network's operators control directly, such as on-site fuel combustion, which for a population of general-purpose servers in rented facility space is generally negligible and is reported as such. Scope 2 covers the indirect emissions embodied in the electricity those machines purchase from the grid, and that is where effectively the whole footprint sits. Emissions upstream of operation, in the manufacture and eventual disposal of the hardware, fall outside this accounting boundary.

Greenhouse-gas intensity mirrors the energy definition: the incremental emissions associated with one additional transaction, not the annual total divided by throughput.

Uncertainty in the emissions figure compounds the uncertainty in the two inputs behind it. Any error in the estimated electricity total propagates directly into the result, and the geographic attribution adds error of its own, since grid carbon intensity varies by more than an order of magnitude between countries and a misplaced share of node capacity moves the answer substantially. Annual national averages also mask the hourly variation in grid intensity to which a machine running around the clock is fully exposed.

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 same node distribution that underpins the renewable share, with a different coefficient applied to it. Once the node population has been apportioned across jurisdictions, the electricity attributed to each jurisdiction is multiplied by the average carbon intensity of that grid, meaning the greenhouse gases released per unit of electricity generated there, and the network total is the sum across jurisdictions.

The reporting boundary separates two scopes. Scope 1 covers emissions from sources the operators control directly, which for a network of this kind is effectively nothing: consensus and endpoint nodes are general-purpose servers that burn no fuel on site, and standby generation at hosting facilities does not run in normal operation. Scope 2 covers the indirect emissions embodied in the electricity those machines purchase, and it accounts for essentially the entire result. A location-based convention is applied, using the average intensity of the grid each node draws from, because contractual instruments such as renewable supply certificates are not observable per node and cannot be verified from outside the operator. Emissions embodied in manufacturing, shipping and disposing of the hardware fall outside this boundary and are not counted.

Carbon 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 published under the Creative Commons Attribution 4.0 license. These are annual national averages, so they smooth over the hourly and sub-national variation that in reality determines what a given machine's electricity caused.

Greenhouse gas intensity per transaction follows the same marginal logic as its energy counterpart and inherits the same qualification. The network's emissions were driven by how many machines were kept running, not by how many transactions crossed them, so dividing the total by throughput produces a comparison aid rather than a causal statement about any one transfer. Uncertainty in the node count and in the geographic distribution propagates directly into the emissions figure, and where a substitute distribution has stood in for locations that could not be observed, the result is only as sound as that substitution. Because the chain no longer produces blocks, emissions attributable to its operation end as the remaining infrastructure is decommissioned, and reported quantities describe the period in which it ran.

Emissions are derived from the same node distribution that underpins the renewable share, with a different coefficient applied. Once the node population has been apportioned across jurisdictions, the electricity attributed to each is multiplied by the average carbon intensity of that grid, meaning the greenhouse gases released per unit of electricity generated there, and the network total is the sum of those products.

The reporting boundary distinguishes two scopes. Scope 1 covers emissions from sources the operators controlled directly, which for a network of this kind was effectively nil: the sealing and endpoint nodes were general-purpose servers burning no fuel on site, and standby generation at hosting facilities does not run in normal operation. Scope 2 covers the indirect emissions embodied in the electricity those machines purchased, and it accounts for virtually the whole figure. A location-based convention is used, applying the average intensity of the grid each node drew from, because contractual instruments such as renewable supply certificates cannot be observed per node or verified from outside the operator. Emissions embodied in manufacturing, transporting and disposing of the hardware sit outside this boundary.

Carbon intensity figures are taken 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 published under the Creative Commons Attribution 4.0 license. They are annual national averages and therefore smooth over the hourly and sub-national variation that in reality determines what a particular machine's electricity caused.

Greenhouse gas intensity per transaction follows the same marginal logic as its energy counterpart, with the same qualification attached. Emissions were driven by how many servers were kept running rather than by how many transactions passed through them, so dividing the total by throughput yields a comparison aid rather than a causal claim about any individual transfer. Uncertainty in the machine count and in the geographic distribution carries straight through into the emissions result, and where a substitute distribution has stood in for locations that could not be observed, the figure is only as reliable as that substitution. Because the chain has ceased operating and its infrastructure has been withdrawn, no emissions arise from its continued operation, and any quantity reported relates to the period when blocks were still being produced.

Emissions for this network are derived from its electricity use and from the carbon content of the grids supplying it. The estimated energy total is first broken down by location, using the same geographic picture built for the energy analysis: node addresses observed on the peer network, operator information published openly, and the hosting ranges those addresses belong to. Where the observed spread is too sparse to rely on, the distribution of a structurally comparable network is substituted, selected for similar incentives and similar validation duties rather than similar size.

Each block of consumption is then multiplied by the carbon intensity of the grid serving it, expressed as emissions per unit of electricity generated in that region, and the results are summed. This means the outcome is driven as much by where operators choose to host as by how much electricity the network draws, and it changes year to year as national generation mixes shift.

The reported figures separate two scopes. Scope 1 covers emissions from sources the network's operators control directly, such as on-site fuel combustion; for a network of this kind that is effectively nil, since the infrastructure is commodity servers drawing grid power in third-party facilities. Scope 2 covers the indirect emissions embodied in the electricity purchased to run that infrastructure, and it accounts for essentially the whole footprint. Emissions embodied in manufacturing the hardware, and in building and cooling the facilities that house it, fall outside both and are not included.

GHG intensity is the marginal figure, the emissions attributable to one additional transaction. As with energy, the bulk of the total is a fixed cost that continues regardless of throughput, so intensity falls as usage grows 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.

Emissions attributed to Polygon PoS rest on the same geographic work as the renewable share, with regional carbon factors applied in place of renewable percentages. Validator and full-node locations are approximated from peer discovery, public network observation and hosting attribution, and a comparable network's distribution stands in wherever direct observation is too sparse. The share of Ethereum's footprint brought in through checkpointing is located the same way, against Ethereum's own node distribution. Each location is paired with the carbon intensity of its national grid, taken from Carbon intensity of electricity generation, processed by Our World in Data from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy, and made available under a CC BY 4.0 license. Multiplying regional electricity by regional grams of carbon dioxide equivalent per kilowatt-hour, then summing, yields the annual total.

Scope matters to how the result should be read. Scope 1 captures emissions from sources under the direct control of the network's operators, such as fuel burned on site, which for servers in rented facility space is generally negligible and reported as such. Scope 2 captures the indirect emissions embodied in purchased electricity, and that is where essentially the entire footprint falls. Manufacture and disposal of the hardware sit outside the boundary of this accounting.

Greenhouse-gas intensity is defined marginally, as the incremental emissions associated with one additional transaction rather than the annual total spread across throughput.

The error bars on the emissions figure inherit those on the electricity estimate and add to them. Grid carbon intensity differs by more than an order of magnitude between countries, so a misallocated share of node capacity shifts the result considerably, and annual national averages hide the hourly swings in intensity that machines running around the clock experience in full.

Emissions figures are derived from the estimated electricity consumption of the network combined with the carbon content of the supply in the places where its machines run. The geographic starting point is the same as for the energy assessment: node locations approximated from addresses seen in peer discovery and crawler output, resolved to region, with the distribution of a structurally comparable network substituted wherever direct observation is too sparse to be relied upon.

Each region is then assigned a carbon intensity for its electricity, in emissions per unit generated, drawn from Carbon intensity of electricity generation, compiled by Our World in Data from Ember and from the Energy Institute's Statistical Review of World Energy and made available under the Creative Commons Attribution 4.0 license. Applying each region's intensity to the consumption attributed to it and summing across regions gives the network total for the period.

The division between reported scopes follows from what running this network involves. Scope one covers emissions from sources the operators control directly, which would mean combustion on their own premises; validating produces none, and standby generation is neither material nor observable at this level, so the figure is reported at or close to zero. Scope two covers the emissions embodied in the electricity bought to run the machines, and effectively the entire footprint falls there. Because regional averages are used, the estimate is insensitive to the individual supply contracts of particular operators, which is a known limitation rather than a claim about them. It is also worth noting that the residential share of this network's operators is supplied at the household rather than the industrial tariff mix, though both are represented in the same regional average.

Greenhouse gas intensity is expressed as the marginal emissions attributable to one additional transaction, consistent with the treatment of energy intensity, because the infrastructure emits at much the same rate irrespective of how full the blocks it is producing happen to be.