Chainlink (LINK) sustainability report

Chainlink is present on the following networks: Arbitrum, Astar, Avalanche, Base, Berachain, Binance Smart Chain, Bittensor, Celo, Cronos, Ethereum, Fantom, Harmony One, Hedera Hbar, Huobi, Hyperliquid, Kaia, Linea, Near Protocol, Opbnb, Optimism, Osmosis, Plume, Polygon, Ronin, Sei, Solana, Sonic, Starknet, Gnosis Chain, Xdc Network, Zksync.

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.

Astar does not run a consensus mechanism of its own in the usual sense. It is a parachain in the Polkadot ecosystem, which means it produces blocks locally but borrows its security from the Polkadot relay chain rather than from a validator set it elects itself. Block authoring on Astar is the job of collators: a bounded set of operators, admitted and ranked by the stake bonded to them, who take turns authoring in a slot-based rotation. A collator gathers transactions, executes them against the current state, and emits a candidate block together with a proof of validity — a compact witness containing the state values the block touched and the hashes needed to verify them.

That candidate is then handed to the relay chain, where security actually resides. A group of relay chain validators re-executes the proof of validity, backs the candidate if it checks out, and erasure codes its data across the full validator set so that it remains recoverable. Additional validators subsequently self-select to re-check the candidate, and any disagreement escalates into a dispute settled by the entire set, with the losing side slashed. Finality comes from GRANDPA on the relay chain: an Astar block is irreversible once the relay chain has finalized the candidate that carries it, and not before. Collators therefore hold no power to finalize, censor without consequence, or rewrite history — their misbehavior is caught downstream. Access to the relay chain cores that run this pipeline is now scheduled through Polkadot's coretime market rather than held as a leased slot won at auction.

Two execution environments run side by side on the chain. One is a WebAssembly environment native to the underlying framework, the other an Ethereum-compatible environment that accepts standard EVM bytecode, and both settle into the same state and the same blocks. A separate validium deployment the network previously operated outside the Polkadot ecosystem was discontinued in March 2025 and no longer exists; descriptions of this network as spanning multiple settlement layers are out of date, and its footprint today is the parachain and its collators alone.

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.

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

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

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

Berachain splits consensus from execution across two processes that every node operator runs side by side. Execution is handled by an Ethereum-compatible client holding the state and running the virtual machine; consensus is handled by a client built around a modified CometBFT engine, and the two communicate over the same engine interface Ethereum node software already uses. The result is an Ethereum execution environment settling under a Byzantine-fault-tolerant proof-of-stake engine rather than Ethereum's attestation and checkpoint machinery.

Consensus advances in timed rounds. A proposer is designated at each height in proportion to bonded stake, and a block commits once operators representing more than two thirds of bonded weight have voted for it, which makes it final in that same block: there are no attestation committees, no epochs and no delayed finalization. Where a proposer fails to deliver, the round times out and another operator proposes at that height. Entry to the active set is governed by bonded stake in the network's native asset. An operator must bond at least two hundred and fifty thousand units, is capped at ten million, and must rank among the top sixty-nine by bonded amount, a ceiling set by governance. Voting power follows the bonded amount rounded down to a fixed granularity, and an operator leaves the set only by exiting voluntarily or by being displaced by a larger entrant.

Proof of Liquidity describes what happens to the block reward rather than how blocks are ordered. Each block issues a fixed quantity of the native asset in its wrapped form, of which only a small fixed portion goes to the proposing operator. The larger portion is routed by an on-chain allocation contract into reward vaults, contracts that pay out to participants who have deposited approved liquidity positions, and operators decide how their allocation is spread across the approved vaults. Consensus participation therefore determines where liquidity incentives land, which is the design's distinguishing feature.

That design changed substantially after launch. Until July 2026 emissions were paid in a second, non-transferable asset that also carried governance rights, and an operator's emissions scaled with how much of it had been delegated to them. A hard fork removed that asset from the mechanism: emissions are now fixed per block, no longer scale with delegation of a separate token, and the retired asset has no remaining role in reward allocation or governance, with outstanding balances converting when claimed.

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.

Two distinct mechanisms operate here and conflating them produces a misleading description. The first is an ordinary chain consensus: a proof-of-stake network built on a general-purpose blockchain framework, where holders nominate validators, block production runs as a randomized slot lottery and finality is reached by a separate voting process over chains rather than individual blocks. This is what orders transactions and secures the ledger, and it resembles other networks in the same framework family.

The second mechanism is what the network exists for and has no counterpart elsewhere. The network is divided into subnets, each an independent market for a particular kind of machine-produced output. Within a subnet, participants in a producing role submit work and participants in a validating role evaluate it, scoring each producer on a normalized scale. Those scores are submitted on-chain as weights and aggregated by a consensus algorithm that weights each evaluator's opinion by the stake behind it and produces a ranking reflecting the stake-weighted median view rather than any individual judgment. Rewards are then distributed according to that ranking. The design deliberately makes it unprofitable for an evaluator to score dishonestly, because rewards accrue to those whose assessments agree with the stake-weighted consensus, and an evaluator who deviates persistently earns progressively less.

A restructuring introduced per-subnet tokens and shifted the allocation of rewards between subnets from a governance-style vote toward a market mechanism driven by where participants commit capital, so subnets compete for emissions rather than receiving an administered share.

On penalties, precision matters. Participation as an evaluator requires meeting a stake threshold and ranking among the top holders by stake weight, and failing to maintain that standing removes the permit to participate, with associated bonds deleted. Deviating from consensus reduces what an evaluator earns. This text does not describe the protocol as slashing principal in the sense used by networks that confiscate a bond for equivocation; the documented mechanisms operate through reduced emissions and loss of participation rights.

Celo has not operated as a standalone Layer 1 since March 2025, when a governance-approved hard fork converted it into a Layer 2 network that settles on Ethereum. The current design is built on the OP Stack. Transaction ordering is the job of a sequencer, which assembles blocks at roughly one-second intervals and runs an execution environment equivalent to the Ethereum Virtual Machine, so contracts and tooling written for Ethereum behave identically here. One element of the former Layer 1 survives as a precompiled contract: the network's native asset can be moved either as the gas asset or through a standard fungible-token interface, without a wrapper.

Agreement on the canonical chain therefore no longer comes from a local committee of block-producing validators voting among themselves. Batched transaction data is published to an external data availability service, and only a short commitment to that data is recorded on Ethereum. Because the data itself lives off the settlement chain, the design is generally classified as an optimium rather than a full rollup, and it carries the extra assumption that the availability service will serve the data when it is asked for. State roots are proposed to contracts on Ethereum and become final only after a challenge window of about three and a half days, during which a permissioned group of challengers may dispute a proposal. A disputed proposal is resolved by generating a succinct cryptographic proof of the contested execution rather than by an interactive bisection game. A user who believes the sequencer is censoring them can force a transaction in through the Ethereum contracts, subject to a delay.

The elected operator set that once produced blocks still exists, but its function has changed: those operators now run public remote-procedure-call infrastructure serving reads and transaction submission, and election to the set remains an on-chain, stake-weighted process resolved once per epoch. Safety for funds leaving the network rests on Ethereum and the dispute process; ordering and liveness rest on a single sequencer; retrievability of transaction data rests on the external availability layer.

The identifier cronos refers to the Cronos EVM chain, the Ethereum-compatible layer 1 addressed as chain 25 by Ethereum tooling, and not to the other networks that share the Cronos name. It is distinct from the Cronos POS chain, a separate Cosmos SDK network on which the native asset is bonded and where governance sits, and from the zero-knowledge rollup variant that was introduced separately and is now being wound down. The EVM chain is standalone: it proposes and finalizes its own blocks, posts neither state roots nor validity proofs to Ethereum for settlement, and takes no security from the Cosmos Hub. Its links to other Cosmos SDK networks, the POS chain included, carry messages and assets over the Inter-Blockchain Communication protocol; they are not a security relationship.

Agreement is reached through CometBFT, the Byzantine-fault-tolerant engine used across Cosmos SDK chains, operated here in a proof of authority configuration. This is the network's most distinctive property and the one most often described incorrectly. Validator slots are not allocated by an open contest ranked on bonded stake. Operators are admitted by review, with the incumbent validators weighing a candidate's record of running highly available infrastructure, its ability to apply protocol upgrades promptly, and its commitment to the network. The active set is consequently a small, identified group of institutional operators rather than an open population, and while anyone may run a full node, running one confers no route into the set.

Block production follows the standard round structure for this engine. A proposer is selected for each height, and the remaining validators pre-vote and then pre-commit; a block gathering more than two thirds of voting power is committed and is final at that moment, with no confirmation depth to wait out and no reorganization of committed history. Safety holds while fewer than one third of the set acts adversarially, and the protocol tolerates that same fraction failing outright without halting. Demonstrable Byzantine behavior, such as signing two different blocks at one height, results in the offending operator being penalized and removed from the set.

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.

Fantom Opera settles on a transaction order through Lachesis, an asynchronous Byzantine fault tolerant protocol running over a proof of stake validator set. There is no proposer chosen for each round. Every validator gathers the transactions it has received into an event, points that event at the most recent events it has seen from its peers, signs it and gossips it onward. Those events pile up into a directed acyclic graph that each participant holds locally, and because the gossip eventually delivers the same events to everyone, the graph itself carries enough information to derive a single ordering without a further round of voting messages. Once an event has been seen, directly or through the references of later events, by validators holding more than two thirds of the bonded native asset, the protocol treats it as decided and the ordering routine converts that region of the graph into a numbered block.

The safety argument is the classical Byzantine one measured in stake rather than in machines: the derived order holds so long as validators controlling more than two thirds of the bonded amount follow the rules. Joining the validator set is open but capital gated. An operator registers through the chain's staking contract with a self bonded minimum, and other holders may delegate to that operator up to a fixed multiple of its own bond, which caps how much weight any one operator can accumulate. Confirmation is deterministic and typically arrives a second or two after an event is gossiped, so there is no confirmation depth to wait out and no reorganization of sealed blocks. Execution is an Ethereum compatible virtual machine, so ordering and execution are separate concerns.

The network is still live and still sealing blocks, but it is in a managed wind down. Development effort, liquidity and most operators have moved to a successor chain that inherits this consensus design, and a retirement date announced for mid 2026 was afterwards deferred. The mechanism above is the one still running, on a much reduced operator base.

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.

Hedera does not assemble transactions into a chain of blocks proposed by a leader. Its nodes instead build a shared directed acyclic graph of communication events. Whenever two nodes speak, the initiating node passes on everything it knows that the other does not, and each event it creates records the two prior events it builds upon, namely its own most recent one and the one it has just received. Because every event carries that ancestry, the graph is itself a verifiable record of who learned what and when, and it propagates across the network exponentially without any node needing to broadcast to all the others.

Ordering is then derived from the graph rather than negotiated through voting messages. Since each node holds the same ancestry information, each can compute what every other node would have voted at each stage of the protocol and arrive independently at the same answer. This virtual voting removes an entire round of network traffic, and it produces both an agreed order and an agreed timestamp for every transaction, the timestamp being derived from when the participating nodes first received it rather than chosen by whoever proposed a block. Once settled, the order is settled permanently: the protocol offers asynchronous Byzantine fault tolerance, meaning it stays safe without assuming any bound on message delivery times, provided less than a third of the voting weight is dishonest. Finality arrives within seconds, with no probabilistic confirmation window and no fork to resolve.

Voting weight is proportional to the quantity of the network's native asset staked to each node, but the right to operate a consensus node is not open. The set is permissioned, and the address book of consensus nodes is maintained by the council of organizations that governs the network, whose members operate those nodes and vote on protocol and treasury decisions. The published roadmap moves through a stage of permissioned third-party operators toward eventual open participation, and that transition remains incomplete: consensus node operation is still restricted to approved operators, while the mirror nodes that answer historical queries are already open to anyone who wishes to run one.

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.

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

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

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

The network identified here is now called Kaia. It was formed in August 2024 by merging Klaytn, the chain built by an affiliate of the South Korean internet company Kakao, with Finschia, the chain operated by the company behind the LINE messaging platform. Kaia continues the Klaytn codebase and ledger rather than starting a new chain: state, node infrastructure and governance arrangements carried across, the existing native asset was rebranded as KAIA, and Finschia holders converted into it at a set ratio. The Klaytn name is retired, and the governance bodies of both predecessor chains merged into a single council.

Kaia reaches agreement through an optimized variant of Istanbul Byzantine fault tolerance, itself descended from practical Byzantine fault tolerance, and it produces a block every second. Validators run consensus nodes and must lock at least five million units of the native asset per node. For every block a committee is drawn from the validator set by a verifiable random function seeded from the preceding block, so the round's participants cannot be anticipated, and one member is designated proposer. That member assembles the block and circulates it, the committee votes through the prepare and commit rounds the protocol inherits, and the block is written once more than two thirds of it has committed. Every council member has an equal chance of being drawn as proposer regardless of the stake it holds, a change made when the network stopped weighting proposer selection by the distribution of stake.

Because a supermajority commits before a block is written, finality is immediate and unconditional: there are no competing forks to resolve and no confirmation depth to wait out. The trade-off is that the protocol halts rather than diverges if more than a third of a committee becomes unavailable. Around the consensus layer sit an endpoint node network that serves applications and read traffic, and optional service chains that run independently and anchor back to the main chain. Governance is exercised partly through parameters recorded in block headers and voted on by validators, and partly through on-chain voting contracts for more complex decisions. Work is underway to separate the operational and decision-making roles the council currently combines, so that running a validator would depend on meeting a stake threshold and a measured performance standard rather than on council membership; that change is proceeding through the network's governance process and is not yet active.

Linea is a Layer 2 network that executes transactions away from the Ethereum chain and then proves their correctness to it. It has no consensus protocol of its own in the sense a base layer does, and no independent validator set standing behind user funds. What settles the question of what is true on Linea is a cryptographic proof, checked by a contract on Ethereum, showing that the state transition the network claims is precisely what its rules produce from the data it has published.

Three components do the work. A sequencer receives transactions, orders them and produces Layer 2 blocks, which gives users an immediate result. A coordinator drives the pipeline that turns those blocks into batches, requests proofs for them and submits the outcome to Ethereum. A prover generates the succinct zero-knowledge proofs themselves, and that is by a wide margin the most computationally demanding part of the system. During 2026 block production inside the sequencer was moved onto a Byzantine-fault-tolerant protocol of the kind used in permissioned enterprise networks, replacing an earlier proof-of-authority arrangement. The change is groundwork for spreading sequencing across several independent operators, but for now a single operator, the network's originator, produces every block.

Because the proof establishes validity mathematically, there is no dispute window and no requirement that a challenger be watching. Once the contract on Ethereum accepts a proof, the state it attests to is settled, subject only to Ethereum finalizing the block that contains the verification. That is the substantive difference from optimistic designs, where commitments are presumed correct and may be contested for a period afterwards. The network also publishes the full transaction data for each batch to Ethereum rather than only the differences in state, so anyone can rebuild the Layer 2 chain from settlement-layer data alone.

Execution aims to be indistinguishable from Ethereum's, and the remaining differences in gas accounting and state representation have been narrowed successively. Operationally the network remains centralized: sequencer and prover are each run by one party, contract upgrades are not yet constrained by a long user exit window, and independent assessments place it at the earliest tier of the common rollup maturity scale, with staking-based permissionless sequencing described as a later goal.

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.

opBNB is a Layer 2 network built with the OP Stack, and it does not run a consensus protocol of its own. Ordering is delegated to a single sequencer, which receives transactions, executes them against the current state, and emits blocks on a fixed cadence; a network upgrade activated in January 2026 halved that cadence to a quarter of a second. Because one party decides the ordering, there is no agreement to reach among competing block producers, and what a user sees immediately after submitting a transaction is a provisional commitment from that sequencer rather than settled history.

Settlement is anchored to BNB Smart Chain rather than to Ethereum, which sets this network apart from most other OP Stack deployments. A batching component compresses the run of Layer 2 transactions and publishes it to contracts on BNB Smart Chain, while a proposer publishes commitments to the resulting Layer 2 state. Once that published material is buried under enough blocks of the settlement chain, the Layer 2 history it encodes becomes as difficult to revise as the settlement chain's own history, so the durability of the ordering ultimately derives from the base chain and not from anything happening at this layer.

That base chain reaches agreement through a staked-authority scheme that blends delegated staking with authority-based block production. A ranked set of validators bonds the base chain's native asset, and a subset is drawn each epoch to take turns proposing blocks; holders who do not operate a node can bond to a validator and thereby influence which nodes enter the active set. Validators that sign conflicting blocks, vote maliciously, or stay offline for long stretches forfeit part of their bond.

The design is optimistic in the sense that published state commitments are accepted unless someone disproves them. The on-chain dispute machinery that would allow anyone to do so is not yet in operation on this network; it has remained a matter of engineering work rather than a live system. Until it runs, the correctness of published state rests on the permissioned proposer and on the parties able to upgrade the bridge contracts.

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.

Osmosis is a sovereign chain built with the Cosmos SDK, reaching agreement through CometBFT, the Byzantine fault tolerant engine that carried the name Tendermint Core until its rename in 2023. Blocks are committed in rounds: a validator from the active set proposes, the set votes in a prevote stage and then a precommit stage, and the block is finalized the moment precommits representing more than two thirds of bonded voting power are collected. Nothing is probabilistic about this, so a committed block cannot be reorganized away and no confirmation depth needs to be observed. The guarantee the engine provides is that honest validators never commit conflicting blocks while fewer than one third of bonded voting power misbehaves; past that point the chain halts instead of forking.

Validators are ranked by the stake bonded to them, self-bonded and delegated counted together, and the highest ranked fill a fixed number of active slots, which on this network is seventy, a deliberately tighter set than several of the chains it interoperates with. Delegation lets holders of the native asset assign their weight to an operator and share in that operator's rewards, and it carries the same downside the operator carries. Bonded stake takes a fortnight to unwind, roughly half the period used elsewhere in the ecosystem.

What sets this network apart from a general-purpose Cosmos chain is that its exchange lives inside the state machine rather than in contracts deployed on top of one. Pool creation, routing a swap across several pools, concentrated liquidity positions, and the accounting of trading fees are all protocol modules that validators execute as part of processing a block, so a trade is a consensus-level state transition carrying exactly the same finality as a transfer. The protocol also runs an arbitrage module of its own, which inspects a proposed block for price discrepancies its pools have opened and captures the correction for the protocol rather than leaving it to outside searchers. A number of recurring operations, issuance and reward distribution among them, are processed once per daily epoch instead of every block.

Plume is an Ethereum Layer 2 built on the Arbitrum Nitro codebase and deployed through the Orbit framework, oriented toward tokenized real-world assets. Like other chains of that design it runs no consensus protocol among competing block producers. A single sequencer receives transactions, orders them, executes them against the current state, and emits blocks; users get a fast provisional commitment from that sequencer, and the ordering becomes final only once the corresponding data and state claims have been accepted on Ethereum, which is the settlement layer.

The arrangement for making transaction data retrievable changed after the public mainnet opened in mid-2025. The chain initially published its batch data to an external modular availability network, and during late 2025 moved to the committee-based scheme available in the Nitro stack, in which a designated group of parties signs certificates attesting that it holds a batch and will serve it on request. Only those certificates, rather than the full transaction data, are posted to Ethereum. The choice lowers what publishing costs, and it also means the guarantee that data can be retrieved rests on that committee honoring its attestation rather than on Ethereum alone; the stack retains a fallback in which data is posted directly to Ethereum when the committee does not sign.

Correctness of the state, as distinct from retrievability of the data, is enforced optimistically. A whitelisted party posts assertions about the chain's state to contracts on Ethereum, and those assertions can be contested on-chain during a confirmation window of roughly five and a half days. In early 2026 the chain adopted Arbitrum's newer dispute protocol, which replaces one-against-one interactive challenges with a design in which many parties can contest an assertion at once and the total delay a dispute can impose is bounded. The right to post assertions and to challenge them is currently held by a permissioned set, so the honest-party assumption presently rests on a small number of operators rather than on open participation.

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.

Ronin began as a sidechain built to carry the transaction volume of a single gaming application that the Ethereum main chain could not absorb cheaply. It launched in 2021 under an authority-based model in which a hand-picked group produced every block, and moved in April 2023 to a delegated staking model: twenty-two slots, twelve held by institutional operators confirmed through governance and ten open to any candidate that bonded enough of the native asset and attracted enough delegated stake to rank into the set. A 2024 change rotated the block-producing subset each epoch so that every member of the set, not only the largest, took turns producing and earning. Blocks arrived every three seconds and were treated as final once two-thirds of the set had signed.

That architecture no longer runs. In May 2026, following a vote of the operator set, the network hard-forked into a Layer 2 that settles on Ethereum and is built on the OP Stack. Block production passed from the rotating set to a single sequencer operated under contract. Batched transaction data goes to an external data availability service rather than onto Ethereum, with only commitments recorded on the settlement chain, which places the design in the optimium category rather than among rollups proper. State roots are proposed to Ethereum and remain open to dispute for a challenge window of several days. The proposer and challenger roles are currently permissioned, so the correctness of settled state depends on the honesty of designated parties, with a dispute game backed by validity proofs planned to remove that dependency. A user facing censorship can force a transaction in through the Ethereum contracts.

The bridge was rebuilt after the 2022 compromise, in which an attacker obtained enough validator signing keys to authorize withdrawals directly. The signer set was widened well beyond its original size and spread across independent organizations, approval thresholds were raised to a large supermajority, and daily withdrawal ceilings and anomaly monitoring were introduced. Asset transfers were later moved onto an external cross-chain messaging protocol and the original gateway deprecated; the canonical bridge contracts deployed during the Layer 2 migration do not yet hold the network's bridged liquidity.

The identifier sei-v2 refers to the release in which the Sei network gained an Ethereum-compatible execution layer on top of what had been a Cosmos SDK chain, which reached mainnet in 2024. The network has moved on considerably since then, and what follows describes how it operates now rather than at that release. Sei is a standalone layer 1: it proposes and finalizes its own blocks and settles to no other chain.

Consensus runs on Twin Turbo, a latency-tuned variant of the CometBFT protocol used across Cosmos SDK networks. Voting power is weighted by bonded stake. A single proposer is selected for each height and the remaining validators move through pre-vote and pre-commit rounds; a block committed by more than two thirds of voting power is final at that moment, with no confirmation depth and no reorganization of committed history, and safety holds while fewer than one third of voting power behaves adversarially. Two modifications give the mechanism its name. Proposals travel in compressed form, carrying references to transactions that receiving nodes already hold rather than the transaction bodies themselves, so each node rebuilds the block locally instead of receiving it whole. And validators start executing a proposal speculatively while the voting rounds are still running, discarding the work if the block is not committed, which lifts execution off the critical path. Blocks commit on a sub-second cadence.

Further changes belong in the current picture. A parallel execution client, running transactions concurrently under optimistic concurrency control and falling back to sequential execution where they conflict, together with a restructured state store, reached mainnet during 2026. A redesigned consensus layer in which every validator disseminates its own stream of transactions concurrently — separating data availability from ordering instead of funneling both through one proposer per height — has been specified and tested but was not yet active on mainnet. Separately, governance has approved retiring the chain's Cosmos-native surface, halting new CosmWasm contract deployments and disabling Inter-Blockchain Communication transfers in both directions during 2026.

Solana runs a proof-of-stake network in which the right to produce a block is allocated in proportion to the quantity of the native asset staked to each validator. What sets the design apart is that ordering is established before agreement is sought. A designated leader runs a sequential hash chain, each output feeding the next input, so the chain cannot be computed faster than a fixed number of steps and a transaction's position within it is evidence of when that transaction was received. This construction, called proof of history, spares validators from negotiating timestamps with one another and lets the rest of the protocol treat the order of events as already settled.

Leadership is not auctioned block by block. At the start of each epoch, which runs for roughly two days, a schedule is derived deterministically from the active stake distribution and assigns every short slot in the epoch to a named validator. Slots follow one another a few hundred milliseconds apart. The scheduled leader gathers transactions, executes them and streams the resulting block to the rest of the set in small fragments relayed through a tree structure rather than pushed to every peer at once. Receiving validators replay the block independently and publish votes for the fork they consider canonical.

Fork choice weights those votes by stake, and each vote commits a validator to its chosen fork for a period that doubles with every further confirmation, so abandoning a block grows steadily more costly. A block that a supermajority of stake has voted on is treated as confirmed within about a second, and it is locked in permanently once enough additional confirmations accumulate, which takes on the order of ten seconds. Safety rests on the assumption that participants acting dishonestly control less than a third of staked value. A revision of the voting layer, approved in a stake-weighted validator vote, is being activated on the main network in stages; it retains stake-weighted validation and the existing block distribution scheme while replacing the incremental lockout rule with direct voting that settles in one or two rounds.

Sonic is an independent layer one network that reaches agreement with Lachesis, a leaderless asynchronous Byzantine fault tolerant protocol operating over a proof of stake validator set. It inherits this design from the earlier chain whose community and token it succeeded, and it runs it on a rebuilt client. No validator is designated to propose for a given round. Each one bundles the transactions it has received into an event, references the latest events it has seen from its peers, signs the result and gossips it on, so every participant accumulates a directed acyclic graph of the same events. Ordering is then derived from the structure of that graph: once an event has been observed, directly or through the references of later events, by validators holding more than two thirds of the bonded native asset, it is settled, and the ordering procedure turns that portion of the graph into a sequential chain of blocks.

A 2025 revision of the consensus implementation restructured how these decisions are computed, running the elections that resolve successive positions in an overlapping fashion instead of one after another. The change did not alter the safety or finality properties; it cut the processing and memory a validator needs to seal an epoch, which lowers the hardware burden of participating. Execution is deliberately separated from consensus: an Ethereum compatible virtual machine tuned for fast contract execution sits behind a dedicated state storage layer, and the node software distinguishes validating nodes from archival ones that retain full history.

Finality is deterministic and typically reached about a second after submission, with no confirmation depth and no dispute window; agreement is reached by this network's own validators and is not deferred to, or settled on, any other chain. Bridges to other networks exist but sit outside consensus. Operators register through the staking contract with a substantial self bond, set high while the validator set was young and intended to fall over time, and delegated stake is capped at a fixed multiple of that self bond.

Starknet is a validity rollup that settles to Ethereum. Transactions are executed away from the settlement layer, and their correctness is established by a cryptographic proof rather than by a challenge period: a prover produces a succinct argument that a batch of transactions was executed according to the rules, a contract on Ethereum verifies that argument, and once verification succeeds the resulting state is final. There is no window during which a submitted state can be disputed, because an invalid state transition cannot be proven in the first place. The proof system relies on collision-resistant hash functions rather than elliptic-curve assumptions.

Ordering and execution are the responsibility of sequencers. A 2025 upgrade replaced the single sequencer with several running a Byzantine fault tolerant agreement among themselves at a majority threshold, which cut block times substantially and introduced pre-confirmations that give users a response well before a block closes. Those sequencer nodes remain operated by one organization, so the arrangement removes a single point of failure in the software sense without yet making participation open. Proving likewise remains centralized.

A staking system is being introduced in stages and is the route by which that changes. The first stage opened staking and delegation to anyone willing to run a full node; the second added attestation, which makes a validator's liveness and reliability publicly measurable; the stage now being rolled out has validators validate and vote on sequenced blocks, with a block finalized only once more than two-thirds of stake has voted for it; a final stage would hand validators responsibility for operating the network, with proof generation expected to remain the last centralized component. Published schedules for the later stages have moved, and the network should be described as partially decentralized: state validity is enforced by proofs verified on Ethereum and does not depend on trusting any operator, while liveness and transaction ordering still do. Data is published to the settlement layer, so the information needed to reconstruct state is available independently of the operators.

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.

The XDC Network runs a delegated proof-of-stake design known as XDPoS, currently in its second major version, which pairs stake-weighted election of block producers with a Byzantine fault tolerant agreement protocol derived from the HotStuff family. Block-producing nodes are called masternodes. Standing as a candidate requires locking a fixed amount of the native asset, currently ten million units, and candidates are ranked by the stake behind them, combining the operator's own deposit with the weight other holders direct to them. The ranking is recalculated at the start of each epoch, an epoch being a fixed run of nine hundred consecutive blocks, and the leading one hundred and eight candidates form the committee that produces blocks for that epoch. Candidates outside the committee remain staked and ready to step in, and nodes that only follow the chain and serve queries carry no stake requirement at all.

Within an epoch the committee takes turns proposing, and every block must gather a certificate signed by a supermajority of committee members before the chain advances past it. That certification is what supplies finality: once the required quorum has signed, the block cannot be reversed, provided fewer than a third of the committee is acting adversarially. Blocks are produced at roughly two-second intervals and a transaction is final within a few seconds of inclusion, rather than becoming progressively harder to reverse as further blocks accumulate. The protocol does not fork under normal operation.

The distinctive element is accountability. Consensus messages are recorded in a form that allows the network to attribute contradictory signatures to the specific masternode that produced them, using evidence already on the chain and querying comparatively few participants to establish it. This turns a detected safety violation into an identified and provable offense rather than an anonymous one, which is what makes the penalties described in the network's incentive rules enforceable against a named operator rather than against the committee collectively.

zkSync Era is a validity rollup on Ethereum — the family commonly called zero-knowledge rollups — and it runs neither a consensus algorithm nor a validator set of its own. A sequencer receives transactions, orders them and executes them against the chain's state, returning a confirmation within a second or two. Blocks are grouped into batches, and each batch passes through three stages on Ethereum: the resulting data is committed, a cryptographic proof that the batch executed correctly is submitted and checked by a verifier contract, and the state transition is then applied on the settlement layer.

What separates this design from an optimistic rollup is that correctness is established before the fact rather than assumed and disputed afterwards. Once a proof verifies on Ethereum, the batch is known to have followed the protocol's rules, so there is no fraud proof, no challenger role and no week-long challenge window standing between a withdrawal and settlement; the wait is instead however long producing and verifying a proof takes. Proving is carried out by dedicated proving infrastructure, not by ordinary users. Proofs are built recursively, with many small proofs aggregated into one, and the final proof is compact enough to verify cheaply on Ethereum. The proving stack has been replaced more than once as the technology matured; the current generation proves execution of the chain's state-transition program itself, which brings proving close to real time and removes the need to maintain a separate circuit description mirroring the same logic.

Data availability rests on Ethereum. The chain publishes compressed differences in state — what changed as a result of a batch, rather than every transaction in it — into the dedicated data space Ethereum provides for rollups, which is sufficient for an independent party to reconstruct the chain. Two limits apply here as they do across comparable networks: sequencing is performed by a single operator, and the contracts are upgradeable through a governance process with timelocks and an emergency path rather than being fixed.

Chainlink is present on the following networks: Arbitrum, Astar, Avalanche, Base, Berachain, Binance Smart Chain, Bittensor, Celo, Cronos, Ethereum, Fantom, Harmony One, Hedera Hbar, Huobi, Hyperliquid, Kaia, Linea, Near Protocol, Opbnb, Optimism, Osmosis, Plume, Polygon, Ronin, Sei, Solana, Sonic, Starknet, Gnosis Chain, Xdc Network, Zksync.

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.

A fixed quantity of the native asset is issued with each block and split between three destinations: the collators that author blocks, the on-chain treasury, and the pool that funds dApp Staking. Collator pay is a flat amount per block authored rather than a stake-weighted share, which removes any advantage to accumulating bond beyond the threshold for admission. Collators that fail to produce blocks across two consecutive sessions forfeit a small percentage of their bonded stake and are removed from the active set, so the penalty for unavailability is immediate and mild rather than catastrophic. Emission parameters, including the split between destinations and the ceiling on issuance, are governance-controlled and have been tightened more than once.

The network's distinctive mechanism is dApp Staking, which routes protocol issuance to application developers rather than only to infrastructure. Time is organized into periods, each opening with a voting subperiod in which all prior stakes are cleared and participants re-stake behind the applications they want funded. No rewards accrue during voting; issuance to stakers and developers begins in the build-and-earn subperiod that follows, which runs as a sequence of eras roughly a day long. Registered applications are sorted into tiers by the stake behind them, and the tiers offer a strictly limited number of reward-bearing slots, so applications compete for a capped set of positions rather than all drawing a diluted share. A staker earns in proportion to the amount staked, an application earns according to the tier and rank it reaches, and unfilled slots simply go unminted. Unstaking takes effect at once, but unlocking the underlying funds runs through a block-denominated delay before withdrawal.

Users pay a weight-based fee on the native environment and standard gas on the Ethereum-compatible one, both settled in the native asset. The large majority of each fee is burned and only a minority reaches the collator that included the transaction, so heavy usage removes supply rather than accruing it to operators. Cross-chain messages to other chains in the ecosystem carry their own execution fees, on-chain storage requires refundable deposits, and the chain bears the recurring cost of the coretime it buys to keep producing blocks.

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.

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

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

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

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

Each block on Berachain issues a fixed quantity of the network's native asset in wrapped form, divided along fixed lines rather than by any variable weighting. A small fixed portion is credited to the proposing operator, and the larger fixed portion goes to the distributor that feeds reward vaults. Because both rates are constant, an operator's emissions no longer scale with delegated balances of a separate token, as they did before the July 2026 fork. Annual issuance from these emissions runs at roughly five percent of supply and is a governance parameter.

The vaults are where the incentive structure becomes unusual. A protocol wanting emissions steered toward its own liquidity supplies incentive tokens of its own to a vault. The operator whose allocation directed emissions there takes a commission on those incentive tokens, and what remains is auctioned for the wrapped native asset, with the proceeds accruing to the staking vault whose share token ordinary stakers hold. Depositors of eligible liquidity positions therefore collect the block emissions, the protocols seeking that liquidity pay for it in their own assets, and stakers who simply bond the native asset receive the value realized from selling those incentives. Allocation is granted through agreements that require demonstrable on-chain usage, replacing the earlier arrangement in which allocation was bid for through delegation-weighted voting.

Additional holders can add stake to an operator directly through the deposit contract or indirectly through pooling contracts, subject to the per-operator ceiling. Enforcement at the consensus layer works chiefly through forfeiture and exclusion: an operator that fails to propose when designated earns nothing for that slot, an operator that stops participating ceases to earn altogether, and an operator displaced from the active set has its bonded stake returned to its withdrawal address and must generate fresh consensus keys before re-entering.

Users pay for execution in the native asset under an Ethereum-style fee market. Every block carries a base fee per unit of gas that the protocol raises when blocks run above their gas target and lowers when they run below, and that base fee is burned, permanently removing those units from circulation. A separate priority tip, set by the sender, goes to the block producer. Contract execution and storage are metered through the standard virtual-machine gas schedule, with no recurring rent charged against stored state.

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.

Emissions are issued per block and divided between three groups: the producers whose output was ranked highest by consensus, the evaluators who scored them, and the owner of the subnet in which the work took place. A producer ranked below the effective threshold earns nothing at all and eventually loses its registration, so the distribution is sharply concentrated rather than broadly shared, and the marginal participant is not merely underpaid but unpaid. Evaluators earn in proportion to stake and to the degree their assessments agreed with the consensus view.

Entering a subnet as a producer requires paying a registration cost that adjusts with demand for places, which prices access and limits indiscriminate registration. Holders who do not wish to operate infrastructure may commit stake to an evaluator and share in its earnings after a commission, in the manner of delegation elsewhere. Following the restructuring, committing stake to a particular subnet converts it into that subnet's own token, so the holder's return depends on that subnet's success rather than on the network as a whole, and capital flows between subnets are what determine how emissions are allocated across them. The issuance schedule includes periodic halvings that reduce the rate of new supply.

Transaction fees on the chain itself are modest and are not where the economics of participation lie. The dominant cost for a producer is not a protocol fee but the computing hardware required to generate output good enough to be ranked highly, and the dominant cost for an evaluator is the infrastructure needed to assess that output. This is the defining feature of the network's incentive structure: the protocol is a payment and scoring layer sitting on top of a large amount of off-chain computation, and the real competitive expenditure happens in hardware rather than in fees or bonded capital. Participants who cannot cover that hardware cost exit, in much the way unprofitable mining equipment is switched off elsewhere, though nothing is confiscated when they do.

Fees on this network are unusual in one respect: gas need not be paid in the native asset. A dedicated transaction type lets an account settle fees in any currency an on-chain allowlist admits, which in practice means several dollar-denominated stablecoins, so an account can transact holding none of the gas asset at all. The pricing itself follows the mechanism Ethereum introduced with EIP-1559. Each transaction carries an algorithmically determined base fee that rises and falls with demand for block space and an optional priority fee paid for earlier inclusion, with a floor under the base fee to deter spam and uncontrolled state growth. Because transaction data goes to a low-cost external availability layer rather than onto the settlement chain, the surcharge many Layer 2 networks pass on for settlement data is configured at zero here, and users are not billed separately for it. Smart contract execution is metered in gas and priced by the same components; there is no recurring rent on stored state.

Fee revenue accrues to the sequencer, and a protocol contract routes a configured share onward, destroying part of it and allocating the rest to beneficiaries that governance nominates, among them a fund that purchases carbon offsets. The allocation is a governance parameter rather than a fixed constant.

A separate reward stream runs each epoch, an epoch being a period of at least a day whose processing is triggered by an on-chain call rather than emitted by a special block. A treasury contract releases the native asset to four groups: the operators running public endpoint infrastructure, the holders whose locked stake voted for the elected groups, a community fund, and the carbon offsetting fund. An operator's share is scaled by a score reflecting the service it actually provides, and the group it belongs to takes a commission before passing the remainder to its voters. Penalties changed with the architecture: the automatic slashers for downtime and double-signing were retired along with local block production, while a governance-controlled slashing path remains, and an operator that stops serving without deregistering sees its score, and eventually its rewards and those of its voters, fall to nothing.

Because the validator set is admitted by review rather than won with bonded stake, this chain runs no open delegation market and pays no inflationary block reward to a public staking population. Its validators are compensated out of transaction fees, and their incentive to behave correctly is reputational and contractual as much as economic: an operator that misbehaves or fails to stay available loses a seat it cannot simply buy back. Public staking of the native asset happens instead on the separate Cronos POS chain, where an open validator set capped at a hundred active operators is ranked by bonded stake, earns newly issued units alongside a share of fees, and passes rewards to delegators net of a commission each operator sets, with the remainder of the fee take routed to a community pool. That chain confiscates stake for equivocation and for sustained unavailability, and holds withdrawn stake through an unbonding period.

Users of the EVM chain pay in gas, denominated in the network's native asset. The fee market follows the structure popularized by Ethereum's EIP-1559: every block carries a base fee that rises when recent blocks have run above their gas target and falls when they have run below it, and a transaction may attach a priority fee on top to compete for earlier inclusion. The important divergence concerns where that revenue goes. This network burns none of the base fee; the base and priority components alike are collected by the validator producing the block. Fee pressure here redistributes value rather than retiring supply, which is the opposite of the effect the same fee structure has on Ethereum.

Execution costs follow the Ethereum gas schedule, so contract deployment, computation and writes to persistent storage are priced by the work they impose on every node, and a transaction that exhausts its gas limit still pays for what it consumed before failing. There is no recurring storage rent and no rent exemption to maintain: state paid for once persists without further charge, placing the cost of state growth on the writer at the moment of writing rather than spreading it over time.

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.

Compensation on this network changed materially when its successor chain launched. Newly issued native asset that previously paid validators for sealing blocks was redirected to the successor, so ongoing issuance to operators here has been wound down to nothing and what an operator earns now comes from the transactions it helps order. A portion of every fee collected in a period is destroyed rather than paid out, and the remainder is shared among validators when the period closes, weighted by the stake behind each one and by whether it stayed available and responsive. That distribution is handled by an upgradeable staking contract rather than hard coded into the client, so the split can be changed by governance without a coordinated fork.

Holders who do not operate infrastructure participate by delegating to an operator. Delegated amounts count toward the operator's weight in consensus and in the fee split, and the delegator receives the corresponding share of what the operator earns, less a commission the operator retains. Delegation can be left liquid or committed for a fixed term, with longer commitments historically earning a larger share, and withdrawing a bond or a delegation takes effect only after a waiting period, which prevents stake from leaving immediately after misbehavior.

Penalties operate on the bond. An operator that signs conflicting events for the same position is flagged by the protocol as having broken the rules, is removed from the active set and forfeits its bonded amount; balances delegated to that operator can be reduced along with it, which is why the choice of operator is a real decision for a delegator rather than a formality. Simple unavailability is not punished by confiscation, but an absent operator earns nothing for the period.

Users pay for computation and storage through gas metering in the native asset, with the price per unit set by demand for block space. Contract calls cost in proportion to the work they cause, ordinary transfers cost a fixed minimum, and there is no recurring rent charged for data already stored.

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.

Costs on Hedera are quoted in United States dollars and settled in the network's native asset. Each operation type carries a price in a fee schedule the network publishes, and when a transaction is handled the nodes convert that dollar price into a quantity of the native asset at an exchange rate they agree on. The practical effect is that the cost of an operation holds roughly constant in purchasing-power terms while the quantity of the asset charged moves inversely to its market rate, which is the property enterprise users were intended to be able to budget against. Pricing is per operation rather than metered through a gas auction, so there is no bidding contest for inclusion; a recent revision simplified how the components of a price are computed without altering the dollar denomination or the conversion step. Reading data back out of the network through the archival query nodes carries no charge at all.

A charge splits by purpose. One portion compensates the network as a whole for reaching consensus on the transaction, one goes to the particular node that accepted and submitted it, and one covers the specific service invoked, whether that is persisting a file, executing contract bytecode, creating an account or a token, or submitting a message to a topic. Collected charges accumulate in network accounts, part of which funds the pool from which node payments are made.

Consensus node operators receive a daily payment when they have genuinely taken part in consensus over the period, measured by their contribution to the rounds the protocol produces rather than by how many transactions they happened to route. An operator whose node was inactive receives nothing for that day, and an operator may also decline the payment outright. Holders of the native asset may stake to a node, which raises that node's voting weight and earns them a share of a reward pool whose maximum rate is a governance-set parameter. Staking of this kind does not lock the asset, which stays transferable throughout, and the protocol does not confiscate staked balances: the consequence for a node that fails to participate is forfeiture of its reward, not loss of a bond.

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.

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

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

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

Each block mints an amount of the native asset, and that issuance plus the transaction fees the block collected is divided along ratios set by governance. Half goes to validators and the community, a quarter to an ecosystem fund, and a quarter to an infrastructure and operations fund. The validator half splits again. A smaller part rewards contribution, allocated by measured on-chain activity rather than paid automatically to the block's proposer; the larger part is a staking reward shared among council members in proportion to the stake each has locked above the five-million minimum, so the qualifying threshold itself earns nothing and only the excess is compensated. Delegation is supported through staking contracts that let holders assign stake to a validator and receive a transferable claim in return.

Users pay a base fee per unit of gas that the protocol sets itself. It rises when the preceding block consumed more gas than a target and falls when it consumed less, moving by a bounded amount each block and held between upper and lower limits that governance controls, so the price tracks congestion without running away. The network long had no tip mechanism and ordered transactions by arrival; a later upgrade introduced an optional priority fee, so a transaction's effective price is now the base fee plus any tip, capped at the maximum the sender agreed to pay. A distinctive feature is fee delegation: specific transaction types let a second account sign for and pay the fee, so an application can carry that cost without the user holding the native asset. Much of what is collected is destroyed rather than paid out: fees are burned up to the size of the proposer's minted reward, and only the excess reaches the proposer.

Penalties are mild, and worth stating precisely because this design is often assumed to include something it does not. There is no slashing: a validator that performs poorly or behaves badly does not have its locked stake confiscated. What exists is a performance ranking tracking whether a node meets its obligations; a validator falling short is excluded from consensus and moved to an inactive state, losing rewards and its place rather than its capital. Unlocking staked assets is subject to a waiting period of about a week. Stricter measures including confiscation have been discussed alongside the move toward open validator participation, but are not part of the protocol today.

Fees on Linea are paid in ether, the asset used on the settlement layer; no separate asset needs to be held in order to transact. The network runs no staking system, issues no rewards to a validator set and has no delegation inside its protocol, because it has no permissionless set of block producers to pay.

A user's fee has two parts in substance even where it is quoted as a single number. The first covers executing the transaction on the Layer 2, metered in gas on the same schedule Ethereum uses and priced by an algorithmic base fee plus a tip. The second covers what the network must spend on Ethereum, which for a validity rollup is of two kinds: publishing the batch's compressed transaction data, and paying for the on-chain verification of the proof that covers it. Verification is a fixed cost per submission and is spread across every transaction in the batch, so the fuller the batch the less each transaction bears. Data publication has used Ethereum's dedicated data market since 2024, priced separately from ordinary execution and destroyed rather than paid out, and compression improvements on the Layer 2 side reduce how much of that space a batch needs.

Fee revenue first pays the cost of running the sequencer, coordinator and prover and of settling to Ethereum. What remains after those costs is destroyed rather than kept: approximately one fifth as ether, which removes supply on the settlement layer, and the remainder used to acquire and destroy the network's own asset on Ethereum. This arrangement has been in force since late 2025 and ties the economics of both assets to how heavily the network is actually used rather than to a fixed schedule.

Penalties in the usual sense do not exist here, because no participant posts a bond that misbehavior could forfeit. Correctness is not encouraged economically but enforced cryptographically: an operator cannot finalize an invalid state, because no proof of one can be produced. What that leaves exposed is liveness and transaction ordering rather than validity, and it is those risks that the move toward multiple independent sequencers and provers is meant to address.

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.

Fees are denominated in the native asset of BNB Smart Chain, and what a user pays divides into two parts. The first covers computation and state access on the Layer 2 itself, priced by a base fee that drifts up and down with how full recent blocks have been, plus a small required tip. The floor under that base fee is only a few units of the asset's smallest denomination and the per-block gas ceiling is generous, so under ordinary load the execution component is close to negligible. The second part recovers what the network spends publishing compressed transaction data to the settlement chain. It is charged in proportion to the bytes a given transaction contributes, and it is normally the larger of the two.

That publishing cost fell sharply once the settlement chain gained a separate class of transaction for carrying bulk data, priced in its own fee market and discarded after a retention period. Routing batches through that channel instead of through ordinary contract input data cut what the network spends to make its history retrievable, and the saving is passed through to the per-transaction data charge.

Fees collected at this layer accumulate in on-chain vaults and fund the operators posting data and state commitments downstream; any surplus is retained by the network's operator rather than distributed, because there is no validator set at this layer to reward and no block subsidy is issued here. Staking, delegation, and penalties all sit on the settlement chain instead. Validators there bond the native asset, receive the bulk of each block's fees when they propose, pass a share to those who have bonded to them after retaining a commission, and lose part of their bond for signing conflicting blocks, voting maliciously, or remaining unavailable.

Deploying and calling smart contracts is priced by the same two-part formula. Deployment is the more expensive operation, because contract bytecode is bulky and therefore costly to publish downstream, not because execution itself is charged differently.

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.

Three groups are paid on this network, and the balance between them has shifted markedly. New units of the native asset are minted on a daily cadence along a schedule that steps down by a third every seven hundred and thirty days, and governance decides how each day's issuance is split. Liquidity provision was once the largest claim on that issuance; it has since been removed from the split entirely, on the argument that trading revenue rather than subsidy now sustains the pools. The staking share has been cut back as well, with most of each day's issuance now directed into the community fund alongside a fixed development allocation. Bonded stake is increasingly compensated from revenue instead: transaction fees collected in the native asset accrue to stakers, and fees paid in other accepted denominations are converted first.

That revenue comes from trading. Every swap pays a spread factor to the providers of liquidity in each pool it touches, and separately a taker fee to the protocol, set by default at a tenth of a percent and overridden route by route by a delegated fee committee that prices heavily traded pairs down and thin ones up. Taker fees collected in the native asset are split so that the larger part is destroyed and the remainder is paid to stakers. Taker fees collected in other assets are divided between the community fund and a buyback that acquires the native asset before splitting it the same way, which ties the rate of destruction directly to trading volume. Liquidity providers may bond their positions for additional incentives, and a superfluid arrangement lets the portion of a bonded position represented by the native asset be delegated to a validator at the same time, so one unit of capital both secures consensus and backs a pool.

Ordinary transactions pay gas at a base price that climbs when blocks fill and falls back when they empty, resting on a governance-set minimum, a mechanism intended to price out spam rather than to raise revenue; fees may be paid in a whitelisted set of denominations, not only the native one. Validators must charge at least five percent commission. Signing two conflicting blocks costs a validator and its delegators a share of bonded stake and permanent exclusion from the set, while missing too many blocks results in jailing rather than confiscation.

Block production at this layer is not contested, so there is no staking for the right to propose, no delegation to block producers, and no issuance of new units as a block subsidy. What the network's incentive design has to fund instead is the operator that sequences transactions, the parties that post batches and availability certificates, and the parties willing to watch the chain's published assertions and contest a wrong one.

Fees are paid in the network's own native asset rather than in ether, which is unusual among chains built on this stack and required changes to the bridge and dispute contracts so they escrow and account for a token instead of the settlement chain's currency. A user's fee has two parts. One prices computation and state access on the Layer 2, using a base fee that rises as blocks fill and falls when they empty, so congestion is rationed by price rather than by queueing. The other recovers what the network spends posting batch data and availability certificates to Ethereum, charged in proportion to the bytes a transaction contributes; because certificates rather than full transaction data go to Ethereum, this component is markedly smaller than it would be for a chain publishing everything to the settlement layer. Collected fees accumulate in on-chain accounts that the chain's owner directs toward the operators posting downstream and toward network upkeep.

Penalties are attached to the dispute game rather than to block production. A party posting an assertion about the chain's state must lock a bond, and so must a party challenging one; whoever loses the dispute forfeits that bond to a designated recipient. Misconduct is therefore punished economically at the point where it matters, which is the claim about state that the settlement contracts will act upon, and there is no separate slashing mechanism operating against a validator set, since this layer does not have one.

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.

Fees are paid in the network's native asset, which was kept as the gas asset through the Layer 2 migration. A transaction carries an algorithmically set base fee that tracks demand for block space and an optional priority fee buying earlier inclusion. Smart contract execution is metered in gas and priced by the same components, and stored state attracts no recurring rent beyond the gas cost of writing it. Behind the fee a user sees lie two costs the network bears itself: publishing batched transaction data to the external availability service, and submitting state roots and commitments to the settlement chain. These are met from network revenue rather than itemized to the user, and sequencer revenue net of them accrues to a protocol treasury.

The incentive model changed with the migration, and it changed direction. Under the sidechain, operators earned newly issued native asset and a share of fees for producing and validating blocks, while holders who delegated to an operator received a proportional share of that operator's rewards after commission. Bonded stake was exposed to slashing for signing conflicting blocks and to lesser penalties for downtime, so the choice of operator carried real risk for a delegator. Duty on the bridge was compensated separately from a dedicated allocation.

Since block production is now a sequencer's responsibility, rewards for passively bonded stake are being wound down and the issuance that funded them redirected to the treasury. In their place the protocol pays applications rather than infrastructure. Contracts register to be measured, and rewards are allocated according to observed on-chain contribution: principally the gas an application generates, the value it holds and the user activity it brings. Governance, formerly exercised through the institutional subset of the operator set, is moving toward voting weighted by holdings of the native asset over treasury allocation and protocol decisions. Operators retain roles in governance and in administering delegated stake, but payment for simply occupying a validator slot is not the model the network is built on going forward.

Validators and their delegators are the paid participants. Voting power derives from bonded stake, and holders who do not run infrastructure may delegate to an operator and share in its rewards net of a commission the operator sets. Stake taken out of bonding is locked for twenty-one days before it becomes transferable and earns nothing across that window; stake moved directly from one operator to another skips the wait, though the receiving operator is then barred from passing it on again for the same period, and an account may keep only a limited number of such moves open at once. Reward flow comes from transaction fees and from scheduled releases of units set aside at genesis rather than from open-ended issuance.

The penalty design departs from the Cosmos SDK default and is easily misstated. Bonded stake is not confiscated. A validator that goes offline or misbehaves is jailed — removed from the active set and cut off from rewards — but neither its own stake nor its delegators' stake is reduced. Security therefore rests on exclusion from future revenue and on the operational standing of the set rather than on a direct economic forfeit. The redesigned consensus layer under development would introduce a punishable offense for signing conflicting proposals at the same height, which would change this position once it is active.

Users pay in gas, denominated in the network's native asset. Ethereum's typed fee transactions are accepted, but no portion of the fee is burned: base and priority components alike accrue to validators and flow through to their delegators, so activity redistributes value rather than retiring supply. A minimum acceptable gas price is a governance parameter rather than a constant fixed in the client. Execution follows the Ethereum gas schedule with deliberate divergences, most notably a substantially higher charge for writing to persistent storage, which is itself an on-chain parameter and can be retuned by governance without a chain upgrade. There is no recurring storage rent: state paid for when it is written persists without further charge.

Two streams of payment reach validators. The protocol issues new units of the native asset on a defined schedule and distributes them at the close of every epoch to validators and to the stake delegated to them, in proportion both to that stake and to the voting credits the validator actually accrued over the epoch; an operator that missed its slots or stopped voting accrues fewer credits and receives a correspondingly smaller share. Holders who do not wish to run hardware delegate through a stake account to an operator of their choice, retain control of that account, and receive the reward net of whatever commission the operator has set. Delegated stake becomes active and inactive only at epoch boundaries, so capital committed to securing the network cannot be pulled out on demand.

Users pay a fixed base fee for every signature a transaction carries. Half of that amount is destroyed and half is paid to the validator that produced the block. A transaction may attach an optional priority fee, quoted per unit of requested compute, which under a protocol change adopted in 2025 goes in full to the block producer; this is the mechanism that rations capacity when demand exceeds what a slot can hold. Program execution is metered in compute units against a per-transaction ceiling, so the cost of a contract call tracks the work it requests rather than a flat tariff.

Storage is charged once, not continuously. An account has to hold a minimum balance scaled to the number of bytes it occupies in order to be exempt from rent, and that balance is a refundable deposit rather than a fee: closing the account returns it. Recurring rent collection has been switched off at the protocol level and rent-paying accounts can no longer be created, so ongoing storage charges do not form part of the fee model as it now stands.

Staked assets are not confiscated by the protocol. No implemented mechanism automatically destroys a validator's stake for equivocation or for being offline; the cost of downtime is forgone reward set against operating expense, including the fees an operator pays to submit its own votes. A scheme to record provable duplicate-block violations on chain, as groundwork for any future economic penalty, is still at proposal stage and would not itself remove stake.

Validators are paid for sealing epochs and for the transactions they order. For the network's early years the reward pool is not fresh issuance but a carried forward allocation redirected from the predecessor chain, which the staking contract pays out per sealed epoch; the target rate is tied to how much of the supply is bonded, falling as more is staked and rising as less is, so the yield tracks the security actually being purchased rather than a fixed schedule. Rewards accumulate in the contract and are claimed rather than credited automatically.

Holders who do not run infrastructure delegate to an operator. Delegation adds to the operator's consensus weight and to its reward entitlement, and the delegator receives the corresponding share less a commission the operator keeps. Each operator can accept only a fixed multiple of its own self bond in delegations, which limits how much weight a single operator can gather. Unbonding a delegation is not immediate: withdrawals enter a waiting period of about two weeks before the balance is released, so stake cannot be pulled out ahead of a penalty.

Penalties act on the bond. An operator found to have acted maliciously, for instance by signing conflicting events, has its stake reduced by the staking contract, and the delegations behind it are reduced in proportion, which is paid out of what delegators receive when they withdraw. Persistent unavailability is not confiscatory but earns nothing for the periods missed.

The fee a user pays is gas metered in the native asset, priced by demand for block space, with contract calls charged in proportion to the work they cause and no recurring charge for data already stored. What happens to that fee is unusual. Applications may register their contracts to receive a share of the fees their own usage generates, which can reach the large majority of the fee, with a further share going to validators and the balance destroyed. The proportions are governance controlled and have been revised since launch, and the accounting attributes gas consumed in nested calls so that shares cannot be double counted.

Users pay a single fee that covers three distinct costs, and understanding the split explains why this network's economics differ from those of a standalone chain. The first is execution: contracts are metered in computational steps and in calls to specialized built-in operations, and the submitter pays for the resources their transaction consumes. The second is the cost of publishing data to the settlement layer so that anyone can reconstruct the rollup's state, which is passed through at whatever the settlement layer charges for the dedicated data space it makes available, and which therefore moves with conditions on a network this one does not control. The third is the cost of producing and verifying the validity proof.

That third component behaves in a way with no equivalent on a monolithic chain. A proof covers a whole batch, and the cost of generating it and having it verified is amortized across every transaction inside that batch, so the per-transaction share falls as the batch fills. Periods of heavy use are therefore cheaper per transaction than quiet ones, which inverts the usual relationship between congestion and cost for this part of the fee. Fees may be paid in the network's native asset or in ether.

On the incentive side, validators lock the native asset and delegators may assign their holdings to a validator without running infrastructure, sharing in rewards after the validator's commission. Rewards are funded by protocol issuance. Eligibility is conditioned on performance: attestation makes it observable whether a validator is doing the work, and a validator that fails to attest does not earn for that period. The published design penalizes absence by withholding rewards, and this text does not assert any confiscatory penalty on locked principal, as the parameters governing that are still being settled alongside the remaining decentralization stages. Sequencer and prover operation is currently funded by the operating organization rather than by an open market in those roles.

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.

Block production on the XDC Network is paid from a fixed issuance released at the close of each epoch and divided among the masternodes that were active in the committee for that epoch. The large majority of each share goes to the node operator and the remainder to a network treasury. Because the stake requirement for standing as a candidate is a fixed figure rather than a bid, posting more than the required amount does not increase the reward a node earns; what extra weight buys is a better position in the ranking and therefore a better chance of holding a committee seat. Holders who do not run infrastructure themselves can direct their weight to a candidate and receive a portion of what that candidate earns, which is the route by which participation extends beyond the operators.

Penalties are built around exclusion rather than confiscation. A masternode that signs no block across a complete epoch is marked as failing and is barred from producing blocks for several subsequent epochs, though it may continue verifying the work of others, and it earns nothing while the exclusion runs. Persistent underperformance removes a node from the active list altogether, at which point the committee proceeds with fewer members rather than waiting, and a standing candidate can take the vacant place. The design treats an outage as an operational failure to be priced in lost reward rather than a wrong to be punished by seizing the deposit; the deposit is exposed where misbehavior is demonstrably deliberate and the consensus record proves it.

The fee model changed materially with the network upgrade activated in January 2026, which brought the chain into line with the fee market used on comparable execution environments. Each block now carries a base charge per unit of gas that the protocol adjusts up or down according to how full recent blocks have been, and that base charge is destroyed rather than paid to the producer. A sender may add an optional tip, which does go to the producing masternode and determines priority when demand is heavy. Before this change every unit of the fee went to the producer at a fixed floor price, which has been raised in steps over the network's life. Fees remain low in absolute terms and are calculated from the computation and storage a transaction consumes.

Fees on zkSync Era are denominated in the settlement layer's native asset and cover three costs rather than two. The first is executing the transaction on Layer 2. The second is publishing data to Ethereum: because the chain posts compressed state differences instead of full transaction data, a transaction's share of that cost turns on how many storage slots it touches and whether others in the same batch touch the same ones — repeated writes to one slot within a batch collapse into a single published change, so activity concentrated on the same state costs less than its raw size implies. The third is proving. Generating a validity proof consumes real computation on specialized hardware, and verifying it on Ethereum costs a fixed amount per batch however many transactions that batch contains, so both are spread across the batch and both reward filling batches fully.

The incentive structure follows from that. The operator running the sequencer and the proving infrastructure is paid out of collected fees and is out of pocket if those fees fail to cover data publication and proof verification, which ties its revenue to keeping batches full and published data compact. There is no staking, delegation, issuance or slashing at this layer, because the chain does not select block producers economically and so has no stake to penalize. What protects users instead is the proof itself — an invalid state transition simply cannot be verified on Ethereum — together with a queue on the settlement layer that gives users a route around a sequencer unwilling to include them.

Two further features shape what users actually pay. Account abstraction is part of the protocol rather than bolted on, so a contract can sponsor another account's fees or accept payment in a different asset while settlement still happens in the native one. And there is no recurring storage rent: state is paid for when it is written, through the data component of the fee, rather than carried as an ongoing charge against whoever wrote it.

Chainlink is present on the following networks: Arbitrum, Astar, Avalanche, Base, Berachain, Binance Smart Chain, Bittensor, Celo, Cronos, Ethereum, Fantom, Harmony One, Hedera Hbar, Huobi, Hyperliquid, Kaia, Linea, Near Protocol, Opbnb, Optimism, Osmosis, Plume, Polygon, Ronin, Sei, Solana, Sonic, Starknet, Gnosis Chain, Xdc Network, Zksync.

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

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

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

The estimate is constructed from the individual machines that run the network, because a chain of this kind has no mining hardware whose economics could be modeled instead. Two distinct populations draw power. The first is the network's own infrastructure: the collators that author blocks, plus the archive and full nodes that serve queries and keep history available. The second is the relay chain validator set, which performs the re-execution, availability and approval work that actually secures the chain. Both have to be counted, and the second only partly.

Population size is established by combining sources. Collator and validator registrations are visible in on-chain state and can be read exactly. The wider node population is less tractable and is approximated from network crawlers and publicly reachable peer data, with an upward adjustment for nodes behind network address translation or otherwise not announcing themselves. Hardware for each class is inferred from the reference specification the client software publishes for operators — the processor class, memory and disk type needed to keep up with the chain — since operators in practice provision close to that specification. Per-device power figures come from controlled bench measurement covering both idle and loaded states, and the total is the aggregate across the estimated population over the reporting period, idle draw included.

Because security is shared, only a portion of relay chain consumption belongs here. That portion is apportioned by the relay chain resources this network actually consumes relative to all chains sharing the same validator set, and it is added to the chain's own infrastructure figure. The apportionment is a modeling choice: the relay chain would run at close to the same power whether or not this particular chain were connected, so the share assigned reflects responsibility for the resource rather than electricity that would otherwise be saved.

The limits are worth stating plainly. Node counts, hardware mix and utilization are estimates from public observation and stated requirements, not meter readings, and the shared-security apportionment adds a second layer of modeling on top. Where evidence is missing, the higher assumption is taken, so the figure is more likely too high than too low, and it is 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 estimate for this network has two components, and they are constructed differently.

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

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

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

Berachain reaches agreement through bonded proof of stake, so the estimation approach applied here builds upward from the machines that run the network rather than from any model of mining hardware economics. The starting point is the size of the node population. Consensus operators can be enumerated from chain state; the surrounding population of full nodes, archive nodes, indexers and public endpoints cannot, and is approximated from crawling the peer-to-peer topology, from advertised endpoints and from operator directories, held as a range rather than a single number.

The chain's node architecture shapes the hardware profile in a specific way. A participant does not run one program but two: a consensus client and an execution client, operating as separate processes on the same host and exchanging work over the engine interface. The representative machine is therefore sized from the combined published requirements of both clients rather than from either alone, which raises the assumed processor, memory and storage specification above what a single-process chain would imply. Reward vaults and the allocation contracts that feed them are ordinary contract state executed by the same clients, so they add computational load but no separate infrastructure to count.

Power draw for each profile comes from laboratory measurement of comparable equipment under load and at rest. Idle draw is included deliberately, because machines of this kind are provisioned for peak demand and left running continuously, and that resting consumption forms much of the annual total. Multiplying profiles by the estimated population and by hours of operation yields the network figure, with an allowance added for hosting overhead. Where a figure is needed for one asset rather than the whole network, a share of the network total is attributed to it according to observed on-chain activity, and an asset present on several networks has its shares summed.

The honest qualifications are these. Node counts derive from public observation and will miss machines that stay unadvertised; a single hardware profile stands in for a varied and partly virtualized population; and none of this is metered measurement. Where evidence is absent the assumption taken is the one that raises the estimate, and figures are revised as observation improves.

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 covers the infrastructure that runs the chain itself, and the boundary matters more here than for most networks, so it is stated first. The chain is a proof-of-stake network of the ordinary kind, and its validator and full-node population is estimated in the ordinary way: node counts drawn from public listings and network crawlers, representative hardware inferred from the published requirements for running the software, and measured power draw for machines of that description applied across the population with idle draw weighted heavily.

What the boundary leaves out is larger than what it contains. The work this network pays for is machine learning inference and training carried out by participants in the producing role, and that work runs on graphics processing hardware whose power draw is an order of magnitude above that of a validator node and which is loaded continuously rather than intermittently, because a participant who stops computing falls in the ranking and stops earning. That consumption is real and it is not in the reported figure.

It is excluded because it cannot presently be estimated to a standard that would justify publishing it. Registered participants per subnet are readable on-chain, which bounds the count, but the hardware behind each registration is not disclosed, and it varies enormously between subnets because the computational demands of the different kinds of output being produced are not comparable. An estimate built by assuming a configuration and multiplying it across registrations would carry an error range wide enough to make the result misleading in either direction.

One consequence deserves stating. Rewards accrue only to participants ranked above a threshold, so there is a standing incentive to deploy as much capable hardware as expected earnings justify, which makes the network's true consumption respond to reward value in a manner closer to proof of work than to a conventional stake-based chain. The reported figure, resting on a validator population that does not move in that way, is stable while the quantity it omits is not. It should be read as a floor for this network rather than as a total, and it will be restated as the compute population becomes observable.

The energy figure for this network is assembled from the layers its operation actually spans, because it no longer runs a consensus of its own. The first layer is the infrastructure the network operates directly: the sequencer that orders and executes transactions, the software that batches transaction data and submits it to the external availability service, the component that proposes state roots to the settlement chain, and the population of full nodes and public endpoint servers that serve reads and relay user transactions. The size of that population is estimated from public network information, from crawlers that walk the peer-to-peer layer, and from the operator set recorded on chain. A representative machine specification is inferred from the published requirements for running the client software, and a power draw is attached to that specification from laboratory measurement of comparable equipment, counting idle consumption as well as consumption under load.

The second layer is the share of Ethereum's consumption attributable to what this network posts there. Ethereum is the settlement chain, so the commitments, state-root proposals and any dispute traffic submitted to it occupy a slice of that chain's validator capacity, and that slice is apportioned according to the footprint those submissions take up. Because the bulk of transaction data is sent to a separate availability layer instead, the operator set of that layer is treated as a third component and estimated on the same per-node basis. Dispute resolution depends on generating succinct cryptographic proofs, and proof generation is itself a compute cost, so it is counted where it arises rather than assumed away.

The limits of this are worth stating plainly. Node counts and hardware mixes are inferences drawn from observable network behavior and from stated software requirements, not metered readings taken from the machines. Where evidence is thin, the assumption chosen is the one more likely to overstate consumption than understate it. Figures are revised as observation improves, and the architecture described here is itself recent, so earlier periods rest on a different operating model.

Consumption is estimated from the machines that run the network, which is the appropriate model for a Byzantine-fault-tolerant chain where producing a block costs no more energy than taking part in the protocol already requires. The starting point is the node population, and this network is unusual in one helpful respect: the set of block-producing validators is permissioned and therefore directly enumerable from chain state and public operator disclosures, which removes one of the larger uncertainties that affects open networks. Around that core sit the full nodes, archive nodes and public endpoint infrastructure anyone may operate, and that wider population is approximated using network crawlers and publicly available listings.

A representative hardware profile is inferred from the specifications the client software states for running a node that can keep pace with the chain, and the power draw of machines matching that profile is taken from laboratory measurement, capturing loaded and idle operation alike. The network total is the aggregate of that draw across the estimated population over the reporting period.

Two boundary decisions shape the result and are worth stating plainly. First, the estimate covers this chain's own infrastructure only. Its blocks are proposed, voted on and finalized by its own validator set, so no share of another network's consumption is attributed to it — not a settlement layer, since none is used, and not a hub or relay chain, since the links to other Cosmos SDK networks carry messages rather than security. Second, where an asset is issued on several networks, the portion attributed to each is derived from observed on-chain transfer volumes rather than divided evenly.

The customary caveats apply. Node counts outside the validator set, and the hardware mix throughout, are inferences from public observation and stated software specifications rather than readings taken from the machines, and operators need not disclose their configurations. Where evidence is missing the assumptions adopted sit at the cautious end and are likelier to overstate consumption than understate it, and figures are restated as observation improves or as the client's specifications change.

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

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

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

The figure reported for this network is an estimate assembled from the machines that run it, not a metered reading taken at the wall. The starting point is the size and composition of the node population. Validating and non validating nodes are counted using network crawlers, peer discovery traffic and information operators publish themselves, and that count is the unit of consumption, because in an asynchronous Byzantine fault tolerant design the work of taking part is ordinary server work: receiving gossip, checking signatures, executing transactions and holding state. There is no competitive computation to model and no hash rate to convert into equipment.

A representative hardware profile is then inferred from what the client software asks for. The processor, memory and storage specifications published as the requirements for running a node are mapped onto commercially available server configurations that meet them, and the electrical draw of those configurations is taken from laboratory measurement of the equipment both under load and at rest. The network total is the aggregate of that draw across the estimated node set for the length of the reporting period, idle time included, since a synchronized node that happens to be handling nothing still consumes power.

Two qualifications matter when reading the result. The node count and the hardware mix are inferences drawn from public observation and from stated software requirements, so neither is exact; where the evidence is thin the assumptions chosen are the ones more likely to overstate consumption than to understate it, and the figures are restated as observation improves. The second qualification is particular to this network. Because development, liquidity and the majority of operators have moved to its successor chain, the operator base is contracting and its composition shifts faster than a periodic estimate can follow, so a figure produced for one reporting period should not be read as a stable rate that will carry into the next one.

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.

The energy figure for Hedera is built up from the machines that run the network rather than read from a meter. The method establishes how many nodes are operating, infers what hardware sits behind each of them, attaches a measured power draw to that hardware and aggregates across the node set for the reporting period. Nothing in this network's design ties electricity expenditure to reward, so the profitability reasoning used to model proof-of-work mining fleets has no counterpart here and is not applied.

The node count is unusually well constrained. Consensus node operation is permissioned and the roster of operators forms part of the network's own published address book, so the population performing consensus can be enumerated directly rather than approximated from crawler observations of an open peer-to-peer network. That removes the single largest source of error in this family of estimates. What remains uncertain is the configuration behind each entry: operators publish little about their individual deployments, and one address book entry may in practice be a redundant cluster rather than a single machine. The hardware assumption is therefore taken from the specification the node software is documented to require, covering processor class, memory, storage and network capacity, and per-device consumption comes from laboratory measurement of comparable equipment. Consumption is counted continuously, including the idle draw of machines that must remain available whether or not transactions arrive, and the separate population of archival query nodes is treated explicitly rather than left ambiguous.

The result remains an estimate. Hardware profiles, utilization and the treatment of redundancy are inferred rather than observed, and where evidence is thin the assumption chosen is the one that raises the figure rather than lowers it, so the published number should be read as a conservative ceiling and is revised as observation improves.

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 built from the machines that operate it, not a metered reading. It starts from the population of participating nodes and works upward from the draw attributable to each.

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

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

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

Consumption is assembled from the machines that run the network, because a Byzantine fault tolerant protocol offers nothing else to measure: blocks are committed by voting rather than by computation, so there is no work rate to convert into hardware and the question reduces to how many servers are running and what each draws. Kaia is unusual in how well the first of those is known. The validator set is bounded, its members are identified institutions, and the roster together with the stake behind each entry is recorded on the chain itself, so the count of consensus nodes is close to exact rather than inferred. The uncertainty sits in the layer around them: the endpoint nodes that serve applications and read traffic, archive nodes retaining full history, the redundancy each operator maintains behind a single consensus identity, and the separately operated service chains that anchor to the main chain. Those are estimated from peer crawls and public infrastructure listings, and they are not fully observable.

Hardware comes from the specifications the client publishes for each node role, which are demanding relative to many networks: one-second blocks and a high throughput ceiling call for server-class processors, substantial memory and fast storage. A representative machine is inferred for each role, and its power draw is taken from measurements on comparable equipment under controlled conditions, covering idle as well as loaded operation. Idle draw dominates the result, because a consensus node holds the same configuration ready whether the chain is busy or quiet and the fixed block interval means it performs the same duties either way. The total is that per-device draw applied across the estimated machine count for the reporting period.

Two limitations apply throughout. This is a reconstruction from public records and stated software requirements rather than a metered reading of anyone's equipment, and operators in practice deploy machines that differ from the published specification in both directions. Where evidence is missing, the assumption chosen is the one producing the larger number, so the estimate is likelier to overstate the impact than understate it, and figures are revised as observation improves. 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 as a proportion of all activity on the network.

The estimate for this network is assembled from two components: the machines the network runs itself, and the share of the settlement layer's consumption that its activity causes.

The first component is unusual among Layer 2 designs because proving dominates it. The sequencer, the coordinator and the replica and archive nodes that third parties operate are conventional server workloads, sized from the published requirements of the node software and assigned power figures measured on representative equipment under controlled laboratory conditions, with idle draw counted alongside load. The prover is a different matter. Producing a succinct proof that a whole batch of transactions executed correctly is an intensive computation, run on large multi-core machines and accelerators, and it is performed for every batch the network settles rather than only when something is contested. That makes proving a recurring, throughput-linked energy cost with no counterpart in an optimistic design, and it is modeled as a distinct workload whose draw scales with the volume of transactions proved rather than with elapsed time alone. Efficiency gains in the proving software reduce this component directly, which is one reason the figure moves between reporting periods.

The second component is the settlement layer, which is Ethereum. Its consumption is estimated from its validator population using the node-level method described for that network, and a share is attributed here in proportion to what this network occupies there: the data space its batches consume and the gas its verification and settlement contracts use.

All of this rests on estimation rather than metering. The number and specification of proving machines are inferred from the operator's published architecture and from what the proving workload demands, not read from a meter, and the replica node population is observed through crawlers and public listings and is necessarily incomplete. Where the evidence does not settle a question, the assumption chosen is the one that raises the estimate rather than lowers it, so the result is more likely to overstate than understate, and it is corrected as observation improves. The settlement layer's own account of its energy profile is published at Ethereum energy consumption.

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.

The estimate is built up from the machines that actually run the network rather than from any protocol-level abstraction, and it has two distinct components because this is a Layer 2.

The first component is the infrastructure operated for the Layer 2 itself: the sequencer, which orders and executes incoming transactions; the components that compress history and publish it downstream; the component responsible for state commitments; and the replica and archive machines that outside parties keep running to answer queries and follow the chain for themselves. The size of that population is approached by counting what can be observed, through network crawlers, reachable peers, published endpoints, and operator disclosures. A representative machine specification is then inferred from the requirements the client software states for each of those roles, power draw for such specifications is taken from measurement of comparable hardware under load and at rest, and summing across the estimated population gives the total. Idle draw is included rather than assumed away, since these machines consume power continuously and not only while a transaction is being processed.

The second component is whatever portion of the settlement layer's consumption is properly charged to this network. Because settlement and data publication happen on BNB Smart Chain and not on Ethereum, it is that chain's validator infrastructure whose consumption is partly allocated here, in proportion to the data and state commitments this network posts there relative to the settlement chain's total load. Observed on-chain activity data is used to size that proportion. The result is a proportional attribution, not a measurement of energy caused at the margin.

Several limits belong next to any resulting figure. The node population and the hardware behind it are inferred from public observation and from stated software requirements, so machines that are unreachable or unannounced go uncounted and the real mix is more varied than a single representative specification suggests. Where evidence is thin, the assumptions chosen lean toward the higher end, so the outcome is likelier to overstate the impact than to understate it. Figures are revised as observation improves and as the network's architecture 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.

The reported consumption for this network is a modeled estimate rather than a measurement taken from a meter, and it is built from the machines that keep the chain running. The first task is to size that machine population. It comprises the seventy validators in the active set, the bonded candidates waiting outside it, and the full, archive, and indexing nodes that serve the trading interfaces, routing services, and relayers connecting this chain to its neighbors. The count is approximated from peer discovery on the public network, from what operators publish about their own deployments, and from the chain's own on-chain register of who is bonded.

Each machine is then represented by a hardware profile. The client software publishes the processor, memory, disk, and bandwidth a node needs to stay in sync, and a machine meeting those requirements stands in for the node. This chain sits at the demanding end of the range for its family, because validators execute swap routing, concentrated liquidity accounting, and the protocol's own arbitrage checks inside block processing rather than delegating them to a contract layer, and because several recurring tasks are batched into a daily epoch that produces a pronounced load spike. Electrical draw for the representative machine comes from controlled measurement of comparable equipment across its load range, idle draw included, since nodes are powered continuously. Draw multiplied by population over the reporting period gives the network total, from which a per-asset share is apportioned using observed on-chain activity.

Two caveats matter. The population and the hardware mix are inferred from public observation and stated software requirements, not from operator disclosure, and where evidence is missing the assumption chosen raises rather than lowers the estimate, so the figure is likelier to overstate than understate. Second, a correction: earlier assessments attributed to this network a share of another chain's consumption on the grounds that the other chain contributed to its security. That is not how this network is secured. It has its own validator set, its own bonded stake, and its own penalties, and the estimate here covers only the machines that run it. Figures are restated as observation improves.

The estimate is assembled from the machines that run the network rather than from a protocol abstraction, and it has two parts because this is a Layer 2.

The first part is the network's own infrastructure: the sequencer, which orders and executes what users submit; the components that batch and post data; the party that publishes state assertions to Ethereum and any parties standing ready to contest them; the servers run by the committee that holds batch data and serves it on request; and the full and archive machines that outside parties keep running to answer queries and track the chain for themselves. That population is sized from what can be observed, through network crawlers, reachable peers, published endpoints, and operator disclosures. A representative machine specification is inferred from the requirements the client software states for each role, per-device power draw is taken from measurement of comparable hardware under load and at rest, and summing over the estimated population produces the total, with idle draw included, since these machines consume power continuously rather than only while transactions arrive. This is not a validity rollup, so no proof generation runs continuously; the dispute machinery consumes meaningfully only while a challenge is actually being worked through.

The second part is the share of Ethereum attributable to this network, covering the validator infrastructure that carries the certificates and state assertions posted there. It is allocated in proportion to what this chain posts relative to Ethereum's total load, sized from observed on-chain activity data. That is a proportional attribution rather than a measurement of energy caused at the margin.

The caveats belong with the figure. Node counts and hardware profiles are inferred from public observation and stated software requirements, so unreachable or unannounced machines go uncounted and the real mix of hardware is more varied than one representative specification implies. Where evidence is missing, assumptions are chosen toward the higher end, making the result likelier to overstate the impact than to understate it. Estimates are revised as observation improves and as the chain's own architecture changes, which for this network it has since launch.

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.

This network settles on another chain, so its estimate has more than one part. The first is the infrastructure it runs itself: the sequencer that orders and executes transactions, the batching software that submits transaction data to the external availability service, the component that proposes state roots to the settlement chain, and the population of full nodes, archive nodes and public endpoint servers that hold state and serve applications. That population is estimated from crawlers walking the peer-to-peer layer, from public node directories, and from what the protocol records on chain. A representative machine profile is inferred from the stated requirements for running the client software, and a power figure attached to it from laboratory measurement of equivalent hardware, counting the idle floor as well as draw under load.

The second part is the share of Ethereum's consumption attributable to what this network posts there. Ethereum is the settlement chain, so commitments, state-root proposals and any dispute traffic occupy a slice of its validator capacity, apportioned by the footprint those submissions take up. The bulk of transaction data goes instead to a separate availability layer, whose operator set is treated as a third component and estimated on the same per-node basis. Where disputes are resolved by generating cryptographic proofs, that proof generation is itself a compute cost and is counted where it occurs.

One caveat is specific to this network and material. Its architecture changed during 2026, from an independent sidechain secured by its own validator set to a Layer 2 settling on Ethereum. A reporting period that spans that change necessarily blends two different models, the earlier one counting a bonded validator set producing blocks locally and the later one counting sequencing infrastructure plus an allocated share of another chain. The generic limits apply as well: node counts and hardware mixes are inferences from public observation and stated software requirements rather than metered readings, conservative assumptions are preferred where evidence is missing, and figures are revised as the picture improves.

The estimate is constructed from the machines that run the network rather than from a metered reading, which is the correct treatment for a stake-weighted Byzantine-fault-tolerant chain where block production is not a contest of computational work. The first step is sizing the node population: the validator set is enumerated from public chain state, and the surrounding population of full, archive and public endpoint nodes is approximated using network crawlers together with publicly listed infrastructure. A representative hardware profile is then inferred from the specifications the client software states for a node able to keep pace with the chain, which on this network are demanding by the standards of the family, since sub-second block cadence and parallel execution push more work onto each machine. Per-device power draw comes from laboratory measurement taken under load and at rest, and the network total is that draw aggregated across the estimated population over the reporting period, idle hours included.

Two features of the network's current shape bear on the boundary. The consolidation onto a single Ethereum-style execution surface removes the question of whether a second environment should be counted separately; there is one node population and it is counted once. And because the chain finalizes its own blocks rather than posting to a settlement layer, no share of another network's consumption is attributed to it.

The limits are worth stating. Node counts and the hardware mix are inferences from public observation and from stated software specifications, not measurements taken from the machines, and operators are not obliged to publish their configurations. A network in the middle of a staged architectural change is a moving target, so the hardware profile in particular is revisited as client releases alter what a node must do. Where evidence is missing the assumptions adopted sit at the cautious end, making the result likelier to overstate consumption than understate it. Where an asset is issued on more than one network, the share attributed to each is derived from observed on-chain transfer volumes.

The figure reported for this network is assembled from the machines that run it rather than inferred from any single aggregate quantity. The starting point is a count of active nodes, put together from network crawlers, publicly reachable cluster and gossip information, and data operators choose to publish. That population is then divided by role, because a validator taking part in voting, a machine that only replays the ledger, and the infrastructure that answers application requests do not draw comparable amounts of power.

Each role is matched to a representative hardware profile derived from the resources the client software is documented to need. Requirements here are heavy by the standards of proof-of-stake systems, running to many processor cores, large memory and fast solid-state storage, and the profiles reflect that rather than assuming commodity equipment. Electrical draw per profile is taken from controlled bench measurement of equivalent devices, capturing both the load imposed by processing and the draw of a machine that is powered up but idle, since a node consumes electricity continuously whether or not it is producing a block. Multiplying profiles by the estimated population across the hours of the reporting period gives consumption for the network as a whole. Where a figure is attributed to one asset issued on the network rather than to the network itself, the share is taken from observed on-chain transfer activity for that asset.

The output is an estimate and should be read as one. The node count rests on what is visible from outside, and operators are under no obligation to be visible; the hardware mix is inferred from stated requirements rather than surveyed; and facility overheads such as cooling and power conversion are approximated rather than metered. Where the evidence does not settle a question, the assumption adopted is the one more likely to overstate consumption than understate it, and figures are restated as observation improves or as protocol changes alter the work a node must perform. The network's own climate reporting is published at Solana Climate Dashboard.

The reported consumption is a modeled figure rather than a metered one, built from the population of machines that keep the network running. That population is estimated from network crawlers, peer discovery traffic and operator information published in public sources. Counting nodes is the right unit for this consensus family: in a stake weighted asynchronous Byzantine fault tolerant design, participating means receiving gossip, verifying signatures, executing transactions and maintaining state, which is conventional server work. Nothing in the protocol rewards spending more electricity than the next participant, so there is no mining hardware to infer and no hash rate to translate into equipment.

Hardware is inferred from what the client software requires. Published processor, memory and storage specifications are matched to commercially available server configurations capable of meeting them, and the power draw of those configurations is taken from laboratory measurement under load and at rest. This network's node software distinguishes validating nodes from archival nodes that retain the full history, and the two have appreciably different storage and memory footprints, so the estimated mix between them affects the result. The network total aggregates the modeled draw across the estimated set for the reporting period, including idle time, since a node that is synchronized but momentarily idle still consumes power.

The limits of the method should be read alongside the number. Both the node count and the hardware mix are inferences from public observation and from stated requirements, not an inventory, and operators running on shared or virtualized infrastructure are not distinguishable from those on dedicated machines. Where evidence is missing the assumptions used are the ones more likely to overstate consumption than to understate it, and estimates are revised as observation improves. A further complication here is that consensus and client efficiency have changed since launch, so a figure computed for an earlier period reflects a heavier per node profile than the software now demands.

A rollup's energy accounting has two parts, and reporting only one of them would misstate the result. The first part is the infrastructure this network runs itself: the sequencer nodes that order and execute transactions, the full nodes that follow and serve the chain, and the proving infrastructure. Proving deserves separate treatment because it is unlike anything in a conventional validator set. Generating a succinct proof of a batch is a heavy, sustained computation run on specialized hardware in a small number of facilities, and it recurs for every batch, so it is a continuous load rather than an occasional one. Because that work is concentrated in few locations operated by one organization rather than spread across an anonymous population, the count of machines involved is a far smaller and better-characterized number than a node crawl would produce, though the specification of that hardware is not publicly detailed and has to be approximated from the class of equipment such workloads require.

The second part is the share of the settlement layer attributable to this network. Ethereum's own consumption is estimated from its validator population, and a portion is assigned here in proportion to the settlement resources this network consumes — the data space it occupies and the verification it triggers — measured against the total those resources represent. The settlement layer publishes its own account of its energy profile at ethereum.org.

Where data availability sits matters to the boundary and is stated rather than assumed: this network publishes its data to the settlement layer, so the storage and bandwidth burden of keeping that data retrievable falls inside the settlement share rather than on a separate network. The usual caveats apply and are sharper here. The operator-run portion is not independently observable, so its estimate rests on the class of hardware such work requires rather than on a measured inventory. Where evidence is thin, conservative assumptions are used that are more likely to overstate than understate, and figures are revised as the network's operation opens up and more of it becomes externally measurable.

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.

Consumption for this network is derived from the machines that run it. The network settles its own transactions and does not depend on another chain for ordering or data availability, so the estimate covers its own infrastructure alone. Three tiers of machine are relevant and are treated separately. Block-producing masternodes are directly enumerable, since candidacy and committee membership are recorded on the chain and the committee size is fixed by protocol. Candidates holding stake outside the active committee run equivalent infrastructure and are counted on the same basis, because a node that must be ready to take a seat must be running continuously. Non-staking machines that follow the chain and serve queries are estimated from network crawling and publicly listed infrastructure, since they are not registered anywhere on-chain.

Hardware for each tier is inferred from what the client software is documented to require, and the requirements for a producing node are materially higher than for an ordinary follower, which is why the tiers are modelled separately rather than averaged. Power draw for equipment matching each profile is taken from controlled bench measurement rather than from manufacturer ratings, and the draw of a machine that is powered up without an active workload is counted, since a staked node runs whether or not its turn to propose has come around. The per-machine figures multiplied across each estimated population over the reporting period give the annual total. Because influence here comes from a fixed stake rather than from computation, nothing in the design rewards deploying more processing power than the client needs.

The honest limits are these. Only the producing and candidate tiers are counted from an authoritative on-chain record; the follower population is an estimate from what is visible on the public network, and machines behind private infrastructure are not observable. Hardware is inferred from stated requirements, so operators running heavier equipment are not captured individually. Where evidence is incomplete, the assumption chosen produces the larger number rather than the smaller, and figures are revised as observation improves.

The estimate combines two sources of consumption. One is the chain's own infrastructure, which has a component most rollups lack: alongside the sequencer, the process that publishes data to Ethereum, and the full and archive nodes that applications and infrastructure providers run, there is a proving fleet. Generating validity proofs is genuine computation on servers with high core counts and accelerator hardware, run continuously as batches arrive, and it is a material line in the total rather than a rounding error. The other source is the share of Ethereum's consumption attributable to the rollup, since every batch commitment and every proof verification consumes capacity that the settlement layer's validators pay to provide; that share is apportioned by how much of Ethereum's resources those postings occupy. Ethereum publishes its own account of how its consumption is estimated (Ethereum energy consumption).

Because nothing is mined, the chain's own side is assessed machine by machine. The node population is approximated from crawlers, peer discovery and published endpoints. Representative hardware is inferred from what the client software states it needs, and for the proving side from what the proving implementation documents as its requirements, which are considerably heavier. Power draw for each profile comes from controlled measurement of equivalent equipment under load and at idle, and the network total aggregates across the estimated population including idle draw. A fraction of that total is then attributed to an individual asset according to observed on-chain activity involving it.

The caveats are the substance of the method, not a disclaimer attached to it. Node counts are floors, since machines on private networks cannot be discovered. Proving capacity is particularly hard to observe from outside, because it is operated privately rather than announced to peers, so its size is inferred from proof cadence and stated hardware requirements. Where evidence is missing, assumptions are chosen that are more likely to overstate consumption than understate it, and figures are revised as observation improves.

Chainlink is present on the following networks: Arbitrum, Astar, Avalanche, Base, Berachain, Binance Smart Chain, Bittensor, Celo, Cronos, Ethereum, Fantom, Harmony One, Hedera Hbar, Huobi, Hyperliquid, Kaia, Linea, Near Protocol, Opbnb, Optimism, Osmosis, Plume, Polygon, Ronin, Sei, Solana, Sonic, Starknet, Gnosis Chain, Xdc Network, Zksync.

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.

Working out the renewable share begins with geography, because the electricity a node consumes comes from whatever grid serves the building it sits in. Node locations are inferred from publicly observable network data — advertised peer addresses, routing information, and the hosting providers those addresses belong to — and the result is aggregated to country level. Finer resolution is not attempted: it would imply a precision the inputs cannot support and would surface operator detail that serves no purpose in the estimate. Because this network shares its security, the exercise is run twice, once over its own collator and node population and once over the relay chain validator set whose consumption is partly attributed to it.

Not every node can be placed. For the portion that cannot, the observed distribution of a structurally similar network is used as a stand-in — similar meaning a comparable reward and participation design, on the reasoning that networks recruiting operators on similar terms end up with operators in similar places. The substitution covers only the unplaced remainder.

Country weights are then matched to national generation mixes to produce a renewable share for the electricity consumed. The generation data comes from Share of electricity generated by renewables, compiled by Ember and the Energy Institute's Statistical Review of World Energy and processed by Our World in Data. These are annual national averages, so they describe the grid an operator draws from rather than any particular supply agreement, and seasonal or intraday swings within a country are averaged out of the picture.

Energy intensity is a separate quantity: the marginal energy cost of one more transaction, meaning the additional consumption caused by adding a transaction to the load already being carried. It is not total consumption divided by transaction count. On infrastructure that draws power continuously whether busy or idle, those two numbers differ substantially, and the marginal figure moves with throughput even across periods when the underlying hardware population has not changed.

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 this network is a weighted average of the electricity mixes of the grids its infrastructure draws on, assembled in two steps: establish where the machines are, then attach regional generation statistics to those places.

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

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

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

The renewable share reported for Berachain is inferred rather than measured, by establishing where the network's machines are and then reading the electricity statistics of those places. The inputs are publicly observable: nodes advertise addresses so that peers can reach them, those addresses resolve to hosting providers and regions, and crawling the peer-to-peer layer repeatedly yields a country-level picture of the network. Regions disclosed by operators, and the known siting of the hosting facilities they use, tighten that picture further.

Because a participant runs a consensus client and an execution client on the same host, the two are treated as one physical location for this purpose; the architecture adds to the consumption attributed to a site without spreading it across additional ones. Where the geographic distribution still cannot be resolved with confidence, the observed spread of a structurally similar network is used instead, similar meaning that it rewards participation comparably and demands comparable hardware, so its operators weigh the same considerations when choosing where to host. That substitution approximates, and it is the largest single contributor to uncertainty in the published share.

Locations are then matched against public statistics on how electricity is generated in each country or region, weighted by the consumption attributed to each, and aggregated into the proportion of the network's electricity that comes from renewable sources. The figure is a grid average: it describes what the regional system delivered, not a supply contract held by any particular operator.

Energy intensity is a different measure and should not be confused with the total. It expresses the marginal energy cost of one further transaction, the additional consumption the network incurs by processing one more transaction on top of what it already handles. Since these machines run continuously whether blocks are full or nearly empty, that marginal quantity is small and shrinks as throughput increases.

Electricity generation statistics are drawn 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.

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 derived from the same boundary as the consumption figure, and therefore from the chain's own validator and full-node infrastructure rather than from the computing population the network pays for. That infrastructure is distributed in the manner typical of proof-of-stake networks and is located through network observation, hosting provider address ranges and what operators choose to disclose. Each location is matched to published statistics on how electricity is generated in that region, and the renewable share is the average across regions weighted by the consumption attributed to each.

The exclusion described in the methodology section shapes this figure as much as it shapes the consumption one, and in a way that is not neutral. Concentrations of graphics processing hardware are sited according to electricity price, available grid capacity, cooling conditions and the availability of suitable premises, which is a different set of considerations from those governing where someone runs a validator. A renewable share computed across the computing population would therefore not be expected to match the one reported here, and there is no basis at present for saying in which direction it would differ. The figure describes the grid mix behind the chain's own infrastructure and should not be read as characterizing the network's activity as a whole.

Two limits apply that are common to this kind of estimate. Grid statistics are annual and regional, so seasonal and daily variation is invisible and a regional average stands in for a specific facility. Contractual renewable purchases are not counted, since what is described is the physical grid mix rather than a procurement arrangement.

Energy intensity per transaction should be read with unusual care. It is period consumption within this boundary divided by transactions settled, so it is an accounting average across the chain's infrastructure and not the energy that an additional transaction causes. Source data is processed by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy: Share of electricity generated by renewables.

The renewable share reported for this network is derived geographically rather than measured at the socket. The first step is to locate the machines doing the work: the sequencing and proposing infrastructure, the full nodes and public endpoint servers, and the operators of the external data availability layer the network depends on. Locations are inferred from publicly observable network data, principally the addresses peers advertise and the hosting providers and regions those addresses resolve to. Coverage is never complete; operators sitting behind relays or content delivery networks cannot always be placed. Where a meaningful part of the population cannot be located directly, the geographic distribution of a network whose operator profile and hosting economics resemble this one is used as a stand-in, on the reasoning that similar incentives produce similar siting decisions.

Once a distribution of locations exists, each is matched to statistics for the electricity grid serving it, and the reported renewable share is the consumption-weighted average across those regional shares. The same procedure is applied to the portion of the settlement chain's operator base carrying this network's activity, so the figure reflects settlement as well as the network's own infrastructure. Regional generation mixes shift seasonally and from year to year, so the result moves with the underlying statistics even in periods when nothing about the network has changed.

Energy intensity carries a specific meaning here. It is the marginal energy attributable to one additional transaction, obtained by dividing estimated consumption over a reporting period by the transactions confirmed in that period. It is not a physical measurement of any individual transaction, and on infrastructure that draws power largely independently of how busy it is, the number is best read as an allocation of shared overhead: it falls as activity rises without any machine using less electricity. Regional generation data is 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 renewable share follows from where the network's machines physically sit. Node locations are inferred from publicly observable network data — the addresses peers advertise, the hosting ranges those addresses belong to, and operator disclosures already in the public domain — and each located node is assigned to the electricity grid serving its region. Those assignments are aggregated into a weighted view of the grids the infrastructure draws on, which is what the renewable calculation consumes.

This network's permissioned validator set helps here. Its block producers are a small number of named institutional operators whose hosting arrangements are comparatively well documented, so the portion of the estimate that matters most for the result rests on firmer ground than it would on a network with an anonymous and freely entered validator population. The surrounding unpermissioned nodes are a different matter: many sit behind hosting or privacy configurations that give no dependable indication of location. For the portion that cannot be resolved directly, the geographic spread of a structurally similar network is used as a stand-in, chosen for a comparable operator profile and a comparable cost of entry, and that substitution is itself a source of uncertainty.

Grid assignments are matched against published statistics on how electricity is generated region by region to yield the proportion drawn from renewable generation. 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.

Energy intensity is a distinct measure and does not represent a per-transaction share of the total. It is defined at the margin: the additional electricity drawn because one further transaction is processed, given infrastructure that is already running. Validators on this network commit blocks on a fixed cadence whether or not there is demand to fill them, so the marginal quantity is small beside the standing consumption and declines as throughput rises.

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 reported here is not measured at any node; it is inferred from where the machines appear to be and from what the electricity in those places is generated by. Placement is reconstructed from what the network exposes in public: the addresses observed while peering and in crawler records, resolved only as far as a country or a region, never to a particular building. Coverage is never complete. Operators sit behind hosting providers, relays and privacy services, and on a network whose operator base is shrinking the observable sample thins further, so where a distribution cannot be observed with confidence the geographic spread of a structurally similar network, one with a comparable operating model and a comparable cost of participation, stands in for the missing part.

That distribution is then weighted against regional electricity statistics. The share of generation from renewable sources in each region where nodes are placed is taken from published national and regional figures, drawn here 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. Combining the two gives a weighted renewable proportion for the estimated consumption of the network as a whole, on the working assumption that each machine takes its power from the surrounding grid at that grid's ordinary generation mix. That is an approximation, and it cuts both ways: an operator buying certified clean power is invisible to it, as is one on an unusually carbon heavy local supply.

Energy intensity is reported on a different basis from the total. It expresses the marginal energy associated with one additional transaction rather than an average obtained by dividing annual consumption by annual transaction count. The distinction matters most on a lightly used network, where the equipment continues to draw power whether or not anyone transacts, and where a falling transaction count would otherwise inflate a simple average without any change in the physical energy being consumed.

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 reported for Hedera begins with locating the machines. Consensus nodes are operated by named organizations listed in the network's published address book, and several of those operators disclose the regions or facilities in which they run, so a substantial part of the geographic picture is available directly rather than inferred. The remainder is resolved by the usual means: advertised network addresses are mapped to countries using publicly available network data, registry records and crawling of the peer-to-peer layer. Where some of the population still cannot be placed, the geographic distribution of a structurally similar network, meaning one whose participation rules and operating incentives resemble this one, stands in for the missing portion.

Located capacity is then matched to the electricity mix of the grid serving it. National generation statistics supply the proportion of electricity produced from renewable sources in each country, and weighting those proportions by the consumption estimated to sit in each country produces the renewable share for the network overall. Two limits follow from that construction. The share describes the grids on which the infrastructure happens to sit rather than any generation an operator has contracted for on its own account, and because the node set is small and concentrated in relatively few countries, the result is more sensitive to a single operator relocating or a single country's grid changing than it would be on a network of thousands of scattered machines.

Energy intensity is reported alongside the share and is a narrower quantity than an average. It is marginal: the additional electricity attributable to one further transaction, with the infrastructure held constant. On a network whose nodes run continuously irrespective of load, that marginal value is small and highly sensitive to the transaction count used as the denominator, so it can shift between reporting periods for reasons that have nothing to do with hardware. The grid statistics behind these calculations are taken from Share of electricity generated by renewables, compiled and processed by Our World in Data from Ember and from the Energy Institute's Statistical Review of World Energy.

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

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

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

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

The renewable share is not recorded by the protocol, so it is inferred from where the machines stand. Reachable nodes advertise network addresses, and those addresses are resolved to a country through public address-allocation registries, yielding a distribution of the node population across jurisdictions rather than a list of physical sites. The method has known weaknesses: 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 present themselves to a crawler.

This network is better placed than most for the first step. Its validators are named institutions that publish their participation, and several concentrate in particular countries, so a substantial part of the consensus layer can be located with more confidence than a purely address-based inference would give. The endpoint and service-chain layers are a different matter, being operated by a wider and less visible set of parties. Where a portion of a population cannot be placed with enough confidence, the geographic profile of a structurally similar network is substituted, selected 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 those jurisdictions. The generation 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. These are annual national figures, so they cannot represent an individual data center's supply arrangements or the hour of day at which the load actually fell.

Energy intensity as used here is a marginal quantity: the additional electricity needed to carry one further transaction. On a network that commits blocks at a fixed one-second interval, essentially the whole of the draw is fixed and independent of how full those blocks are, which means the genuine marginal cost of one more transaction is close to nothing. The reported intensity is therefore better understood as total consumption spread over observed throughput. It allows networks of different designs to be compared on a common basis; it does not measure what any particular transaction caused.

Most of the electricity behind this network is drawn by proof generation, and proof generation does not happen everywhere. It runs on clusters of high-core-count machines and accelerators in a handful of sites, which gives the geographic weighting an unusual shape: a small number of grids carry most of the weight, and the renewable figure shifts noticeably if the proving fleet is enlarged, retired or moved to a different hosting region. A network of many small scattered nodes averages such changes away. This one does not.

Establishing locations therefore starts with those sites. Hosting regions chosen for the proving fleet, and for the sequencing and coordination services running alongside it, are visible in the operator's published technical material and in the routing of the endpoints it exposes. Independent replica and archive operators form a second, dimmer tier, counted through peer crawling and through directories of infrastructure providers, with a country attached to each by looking up which allocation an announced address falls under. That lookup misfires often enough on any single machine that only the aggregate shape is trusted. A third tier lies outside the network altogether, since part of what is reported here is a slice of the settlement layer, whose validators occupy a far wider spread of grids; that spread is characterized separately and blended in at the weight the slice carries. When a tier resists observation, a stand-in profile is borrowed from a network whose operators choose hosting on comparable commercial grounds.

Generation statistics do the rest. Every country in the weighted distribution carries a published figure for the fraction of its electricity produced from renewable sources, and the network's renewable share is that fraction averaged over the consumption weights. It is a statement about grids rather than about procurement: a proving site buying wind power directly and a neighboring rack on default tariff are indistinguishable under this treatment, and an annual national series cannot describe the hour at which a load actually fell.

Energy intensity means the additional electricity one further transaction brings, with the deployed hardware held as it is. Here that quantity is not close to nothing, because every extra transaction enlarges the work a prover must perform. Generation figures come from Share of electricity generated by renewables, a series Our World in Data maintains from Ember's electricity data and from the Energy Institute's Statistical Review of World Energy.

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.

The renewable share is derived from where the hardware sits, not from any claim the network makes about its own power supply. The first step is to place the machines: the nodes serving this Layer 2, and separately the validator infrastructure of the settlement chain whose consumption is partly allocated to it. Locations are inferred from publicly observable network data, including announced addresses resolved to a country, address ranges belonging to hosting and cloud providers, and operator disclosures where any exist. Coverage is never complete, and for a Layer 2 whose node population is small and partly operated by one organization the observable sample can be thin. Where a chain's geographic spread cannot be read directly, the distribution of a network of similar design and similar operator economics is substituted for it, on the reasoning that comparable infrastructure tends to be hosted in comparable places.

Once locations are assigned, each is matched to statistics for the electricity grid serving it, and the resulting country weights produce a single renewable proportion for the network as a whole. Those grid statistics are annual national series published by Our World in Data and processed from Ember's electricity data together with the Energy Institute's Statistical Review of World Energy: Share of electricity generated by renewables.

Intensity in this section means energy rather than emissions, and it is expressed at the margin: the additional electricity associated with one further transaction being processed here and carried through to settlement. It is not the total divided by the transaction count, because most of what these machines draw is fixed and would be drawn whether or not the next transaction arrived. For a Layer 2 the marginal figure is dominated by the downstream cost of making a transaction's data retrievable on the settlement chain rather than by executing it, so it moves with how densely transactions are packed into published batches.

Two caveats carry through. Grid statistics are national annual averages rather than the mix actually supplied to a given facility at a given hour, and an operator's contractual purchase of renewable electricity does not show up in them.

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.

Because electricity is generated differently from one grid to the next, the renewable share reported for this network depends on establishing where its machines are. Locations are inferred from publicly observable network data: the addresses validators and other nodes advertise to their peers, the hosting ranges into which those addresses fall, and whatever operators choose to publish about their own infrastructure. The output is a distribution of the node population over countries and regions, never a precise site for a given machine. Where the distribution cannot be established with confidence, the observed distribution of a network with a comparable consensus design and comparable rewards is substituted, on the assumption that similar economics lead operators to similar places.

Every region in that distribution is then paired with published statistics on the composition of its electricity generation, and the network's estimated consumption is weighted across the regions to yield the proportion met from renewable sources. The generation statistics are taken from Share of electricity generated by renewables, compiled by Our World in Data with major processing from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy.

Energy intensity is reported as a marginal quantity and should not be read as consumption divided by transaction count. It answers a narrower question: how much additional energy the network draws when one further transaction is included in a block. That distinction is particularly sharp here. Validators run continuously and commit blocks on a fixed cadence whether or not there is trading to process, so nearly all of the draw is a standing cost, and the incremental cost of one more swap, which is executed by the same validator process as any other message, is very small by comparison.

The method's weakest link is geolocation. An address identifies a hosting provider rather than a customer, machines behind large commercial cloud regions are assigned to the advertised region rather than to a physical building, and the grid statistics are averages over a country or region that ignore any supply arrangement an individual facility has made. Where a stand-in distribution has been used, its representativeness remains an assumption.

Three kinds of machine sit behind the renewable figure, each located by different means. The sequencer and the components that batch and post are run by a few identified operators whose hosting regions are largely public record. The committee servers holding this chain's transaction data are likewise a known, named set rather than an anonymous crowd, which turns their placement into a question of disclosure rather than inference, unlike a design that buys availability from an external network whose own node population must also be characterized. The one genuinely open population is the full and archive nodes outside parties run, placed the ordinary way: announced addresses resolved to the country holding the allocation, and blocks belonging to hosting providers identified as such.

Beyond the chain's own machines sits its share of Ethereum, whose validators occupy a quite different set of countries. That spread is characterized on its own terms and blended in at the weight the allocated share carries. Where any part of a population resists placement, and on a chain of this age the observable sample is small, the geographic profile of a network built along similar lines, whose operators face similar hosting costs, is substituted for the missing part.

The weights that emerge are matched to national generation statistics, and the renewable share is the consumption-weighted proportion of electricity produced from renewable sources across the countries involved. The figure describes grids, not procurement: an operator contracted for wind or solar supply looks identical to one on ordinary tariff in the same country, and an annual national series cannot say what was generating in the hour a given load actually fell.

Energy intensity is the marginal quantity: the extra electricity one further transaction brings once it has been executed, committed to the committee and carried through to settlement. It is not the total divided by a transaction count, since nearly all of this infrastructure draws power whether or not the next transaction arrives. Keeping data with a committee rather than posting it in full to the settlement layer holds that quantity down, and denser batches hold it down further. The generation statistics are Share of electricity generated by renewables, maintained by Our World in Data from Ember's electricity data together with the Energy Institute's Statistical Review of World Energy.

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 share is derived from where the network's machines are, not from meters on them. Locating them means covering several distinct populations: the sequencing and proposing infrastructure the network operates, the full nodes and public endpoint servers that hold state and serve applications, the operator set of the external data availability layer, and the portion of the settlement chain's validator base carrying this network's activity. Locations are inferred from publicly observable network data, chiefly the addresses peers advertise and the hosting providers and regions to which those addresses resolve. Coverage is partial by nature; machines behind relays or content delivery networks cannot be placed.

Where a significant share of a population cannot be located directly, the geographic distribution of a network with a comparable operator profile and comparable hosting economics is used as a proxy, on the reasoning that similar incentives produce similar siting. The migration from an independent chain to a Layer 2 shifted the weighting between these populations considerably, moving a substantial part of the footprint from a locally operated validator set onto shared settlement infrastructure whose distribution is observed separately.

Each location is then matched to statistics for the electricity grid serving it, and the reported renewable share is the consumption-weighted average across those regional shares. Regional mixes move seasonally and year to year, so the figure shifts with the underlying statistics even when nothing about the network changes.

Energy intensity means something specific here: the marginal energy attributable to one additional transaction, obtained by dividing estimated consumption over a reporting period by the transactions confirmed in that period. It is an allocation of shared overhead, not a physical property of a single transaction, and on a network whose infrastructure draws power largely independently of load it falls as activity rises without any machine using less electricity. Regional generation data is 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 renewable share is derived from where the network's machines are. Node locations are inferred from publicly observable network data — the addresses peers advertise, the hosting ranges those addresses sit in, and operator disclosures already public — and each located node is assigned to the electricity grid serving its region. Aggregating those assignments gives a weighted view of which grids supply the infrastructure, which is the input the renewable calculation requires.

Resolution is partial in practice. A substantial share of nodes runs in hosting arrangements that identify a provider rather than a site, or behind configurations that disclose nothing dependable at all. The demanding hardware profile this network expects tends to concentrate operators in commercial data centers rather than residential connections, which sharpens regional attribution somewhat but also means a handful of large hosting regions can dominate the weighted result. Where a network's own geographic spread cannot be observed to a usable standard, the spread of a structurally similar network is used as a stand-in — one selected for a comparable validator economy and a comparable cost of entry for operators — and that substitution is a source of uncertainty applied only to the unresolved portion.

Grid assignments are matched against published statistics on how electricity is generated region by region, producing the proportion of the network's electricity drawn from renewable generation. 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.

Energy intensity is a separate measure from total consumption and is not the total divided by a transaction count. It is marginal: the extra electricity drawn because one more transaction is processed on infrastructure that is already running. Validators here commit blocks on a fixed sub-second cadence whether or not transactions are waiting, so the marginal quantity is small relative to the standing draw and falls further as throughput increases.

The renewable share is derived geographically. Node locations are inferred from what the network exposes about itself: addresses observable through crawlers and public cluster information, resolved to a country or region. Coverage is never complete, because operators may sit behind hosting providers or relays that obscure where the hardware physically sits. Where the geographic spread of this network cannot be observed directly, the distribution of a structurally similar network stands in as a proxy, chosen because its validator economics and agreement protocol place comparable demands on operators and therefore tend to attract them to comparable locations.

Each located node is then assigned the generation mix of the grid that serves it. Those regional mixes come from Share of electricity generated by renewables, compiled by Our World in Data from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy. Weighting each region's renewable share by the estimated consumption sitting in that region produces a network-wide proportion. The result describes the grids the infrastructure draws from, not contractual purchases: an operator buying renewable certificates is not treated differently from a neighbor on the same grid, because that distinction cannot be observed from outside.

Energy intensity is reported separately and means something narrower than total consumption divided by transaction count. It is the marginal quantity of energy associated with processing one further transaction. That distinction matters for a network of this type, where validators run continuously at close to constant power regardless of how full the blocks are, so the incremental energy attached to an additional transaction is small while the standing consumption of the validator set is not. Both the renewable share and the intensity figure therefore move with two separate things: the composition and location of the node population, and the grid statistics for the years covered, which are themselves restated as national reporting is revised.

The renewable proportion attached to this network is inferred rather than measured. It starts from where the machines appear to be: node locations are approximated from publicly observable network data, chiefly the addresses seen during peer discovery and in crawler output, resolved to country or regional level and not to individual facilities. That view is partial by construction. Many operators sit behind hosting providers or relays, cloud regions do not always correspond to the jurisdiction of the account holder, and a comparatively young validator set concentrated in a few data center regions can shift quickly. Where the distribution cannot be observed with enough confidence, the geographic spread of a structurally comparable network, one with a similar participation model and similar hardware demands, is substituted for the unobserved part.

Those locations are then weighted against published electricity statistics. The share of generation coming from renewable sources in each region 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 attributed to that region. Summing across regions gives a weighted renewable share for the network. The underlying assumption is that a node draws from its local grid at the average mix for that grid; operators with dedicated renewable supply contracts or on site generation are not separately credited, because that arrangement is not visible in network data.

Energy intensity is expressed as the marginal energy associated with one additional transaction, not as annual consumption divided by annual transactions. The distinction is significant for a high throughput network whose equipment draws much the same power whether blocks are full or nearly empty: the incremental cost of ordering one more transaction is small and largely independent of how busy the chain happens to be, and a simple average would move with usage rather than with anything physical.

Two populations have to be located separately, and they are known with very different confidence. The proving and sequencing infrastructure is operated by a single organization from a small number of facilities, so rather than inferring a geographic distribution from network observation, the estimate rests on the far smaller question of which jurisdictions that organization operates in. That is a narrower uncertainty than a distributed validator set presents, and it means a single siting decision moves this network's renewable share in a way that no individual operator could move a chain with thousands of independent nodes.

The settlement layer share carries the geographic distribution of the settlement layer's own validator population, which is estimated from network observation and is far more dispersed. The renewable proportion reported here is therefore a blend: the operator-run infrastructure weighted by its own consumption and located where that organization runs it, combined with a share of the settlement layer weighted by the settlement resources this network consumes and located according to that network's validator distribution. Each location is matched to published statistics for its regional grid.

The limitations are specific. Hosting arrangements can place equipment in a jurisdiction other than the operator's own, and commercial facilities do not generally publish their supply mix, so the grid average is used in place of the actual supply of a particular building. Grid statistics are annual, which smooths over seasonal and daily variation. Contractual renewable purchases are not counted, since this describes the physical grid mix rather than a procurement position.

Energy intensity per transaction is period consumption divided by transactions settled, and for this network the quotient falls meaningfully as usage rises, more so than on a monolithic chain. Proving and settlement costs are largely per-batch rather than per-transaction, so filling batches spreads a near-fixed cost across more transactions. The figure describes an average across the period rather than the energy one additional transaction causes. Source data is processed by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy: Share of electricity generated by renewables.

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.

The renewable share is worked out by establishing where the network's machines are and what the local grids there are made of. Addresses observed on the public network are resolved to a country or region using routing records and publicly published hosting information, producing a distribution of the estimated machine population across jurisdictions. Operators of block-producing nodes are expected to run in commercial facilities with a documented service level, which tends to concentrate them in identifiable hosting locations and makes this part of the distribution more tractable than it would otherwise be. Where machines cannot be placed, because they sit behind private networking or return nothing useful, the geographic pattern seen on chains built along similar lines is substituted, on the reasoning that operators facing comparable participation requirements tend to choose comparable places to host.

Each portion of the distribution is weighted by the energy it is estimated to consume and matched to published statistics for the generating mix of the corresponding grid. What results is the share of the network's electricity that came from renewable generation, understood as a property of the grids supplying its infrastructure, averaged across the reporting period and weighted by consumption. It carries no implication that any operator has contracted for renewable supply, and it excludes both generation on site and certificates acquired separately from the electricity.

Energy intensity is calculated on a marginal basis rather than an average one. It is the additional energy associated with one further transaction being processed, not the annual total divided by the transaction count. On a network whose committee runs continuously and produces blocks on a fixed cadence regardless of how full they are, that marginal quantity is small, and it moves with how heavily the network is used even where total consumption is stable.

Generating mix data is 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. Coverage gaps and reporting lags in that data set flow through into the result, and locating the machines remains the largest source of uncertainty.

Working out a renewable share is a question of geography before it is a question of energy. The relevant infrastructure is the sequencing and data-publishing servers, the proving fleet, and the full and archive nodes operated by applications, bridges and infrastructure providers. Locations are inferred from what the network exposes publicly — peer addresses resolved against hosting and autonomous-system registries, and published operator endpoints — giving a country-level distribution rather than a fixed address for any one machine. Since much of this capacity is rented from cloud and colocation providers, the region a provider assigns to a facility stands in where nothing finer is available. The proving fleet is the hardest part to place, because it is run privately and does not announce itself to peers; where it cannot be located directly, the distribution of comparable computation-heavy infrastructure is used in its place. The same substitution applies more generally: where the chain's own sample is too thin, the pattern seen on networks of similar design fills the gap.

The settlement layer is treated on its own terms. The portion of Ethereum's consumption attributed to the rollup follows the geography of Ethereum's validator population, not of the rollup's servers, so the two distributions are weighted by their shares of estimated consumption and then combined.

Those country weights are applied to published figures for the renewable proportion of national 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. The output is a consumption-weighted average across the inferred footprint. Procurement is outside what this can see: renewable supply contracts, certificates and on-site generation leave no trace in network data and are not credited.

Energy intensity is a marginal measure — the additional electricity associated with one further transaction on top of infrastructure that is already running. Sequencing and node power draw barely move with block occupancy, and proving cost is amortized across a batch, so the marginal figure is small and declines as batches fill.

Chainlink is present on the following networks: Arbitrum, Astar, Avalanche, Base, Berachain, Binance Smart Chain, Bittensor, Celo, Cronos, Ethereum, Fantom, Harmony One, Hedera Hbar, Huobi, Hyperliquid, Kaia, Linea, Near Protocol, Opbnb, Optimism, Osmosis, Plume, Polygon, Ronin, Sei, Solana, Sonic, Starknet, Gnosis Chain, Xdc Network, Zksync.

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 reuses the energy figure and the geographic picture behind it, swapping generation mix for grid carbon intensity. Node locations are inferred from publicly observable network data and grouped by country, across both this network's own collator and node population and the share of relay chain validator infrastructure attributed to it. Where nodes cannot be placed, the distribution of a structurally similar network fills the gap for that remainder. Each country weight then carries the average carbon intensity of that country's electricity generation, and applying the weighted intensity to the energy estimate yields the emissions total.

Two scopes are reported separately. Scope 1 is emissions from sources the operators control directly — fuel burned on site, refrigerant leakage, on-premises generators — and for this network it is effectively zero, since the infrastructure consists of servers in facilities the operators do not own and nothing under their control combusts anything. Scope 2 is the indirect emissions embodied in the electricity bought to run that infrastructure, and it constitutes essentially the entire figure. Upstream emissions from manufacturing and transporting the hardware, and from building the facilities that house it, fall outside both and are excluded.

Carbon intensity values come from Carbon intensity of electricity generation, compiled by Ember and the Energy Institute's Statistical Review of World Energy with substantial processing by Our World in Data, and released under a CC BY 4.0 license. The values are location-based annual averages describing a national grid, which means an operator purchasing contracted renewable power is not distinguished from one buying ordinary grid supply in the same country.

GHG intensity is the marginal emission attributable to one additional transaction, calculated on the same marginal basis as the energy intensity figure. Its uncertainty accumulates from every input underneath it — the node population, the hardware profile, the shared-security apportionment, the inferred locations and the national averages — so it is best read as an indication of magnitude rather than a precise per-transaction quantity.

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

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

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

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

Greenhouse-gas figures for Berachain follow from the energy estimate by way of the carbon intensity of the electricity the network consumes; they are not observed directly. The geographic distribution assembled for the energy assessment is reused without change: the consumption attributed to each country or region is multiplied by that region's average emissions per unit of electricity generated, and the products are summed across regions. Since grid intensity varies by more than an order of magnitude from one system to another, the assumed geography bears on the result as heavily as the quantity of electricity does.

Two scopes are kept apart. Scope 1 captures emissions from sources the network's operators directly control, in practice fuel combusted on site, chiefly in standby generation. For infrastructure of this kind the quantity is negligible and is generally treated as zero, since the machines sit in facilities that purchase grid electricity rather than generating their own. Scope 2 captures the indirect emissions embodied in that purchased electricity, and effectively the entire reported figure falls there. Emissions arising from manufacturing the hardware, from constructing the facilities that house it, or from the wider activities of the organizations that operate it fall outside both scopes and are excluded.

Greenhouse-gas intensity is defined marginally, in the same way as its energy counterpart: the emission attributable to settling one additional transaction, rather than an annual total divided by a count of transactions. Treating it as an average would misdescribe a network whose infrastructure consumes power continuously regardless of how much it is asked to do.

Uncertainty accumulates at each step. Grid intensity values are annual averages that cannot reflect the hours in which power was actually drawn. Low-carbon supply arrangements held contractually by an individual operator are invisible to a grid-average method. And where a comparable network substituted for locations that could not be established, that approximation passes through into the emissions estimate untouched.

Carbon intensity statistics are 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.

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 by applying a grid carbon intensity to each location in the distribution described for the renewable share, and summing across the chain's validator and full-node infrastructure. The boundary is therefore the same one used throughout: operational electricity for the machines that run the chain, and not the graphics processing hardware that performs the work the network pays for. Hardware manufacture is excluded as well, in common with figures of this kind.

Scope 1 covers emissions from sources under the operators' direct control, principally on-site combustion such as backup generation. Across commercial hosting this is a negligible contributor and is reported as such rather than modeled in detail. Scope 2 covers emissions embodied in purchased electricity and constitutes effectively the whole of the reported footprint.

The structural point raised in the methodology section has a direct consequence here. Because rewards flow only to participants ranked above a consensus threshold, and ranking depends on computational output, an increase in the value of rewards draws in additional hardware and raises the network's real emissions with it. That relationship between reward value and emissions is characteristic of proof-of-work networks and is unusual in a network whose consensus is stake-based. It does not appear in the reported figure, because the population it acts on sits outside the boundary. Readers comparing this network against others on the reported number are comparing validator infrastructure against validator infrastructure, which is a narrower comparison than the number alone suggests.

Greenhouse gas intensity per transaction is period emissions within this boundary divided by transactions settled, and carries the same caveat as the energy intensity: it is an accounting ratio rather than a marginal figure. Figures are restated each period, and the omission described here will be closed if the hardware behind subnet registrations becomes observable. Carbon intensity data is processed by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy, and is made available under a Creative Commons BY 4.0 license: Carbon intensity of electricity generation.

Emissions are derived from the same geographic picture used for the energy figures, with carbon intensity substituted for renewable share. Machine locations are inferred from publicly observable network data covering the sequencing and proposing infrastructure, the full node and public endpoint population, the operators of the external data availability layer, and the portion of the settlement chain's operator base that carries this network's traffic. Where part of that population cannot be placed directly, the distribution of a structurally comparable network is used in its stead, and the resulting uncertainty is carried into the estimate rather than hidden in it.

Each location is then matched to the carbon intensity of the electricity supplied by the grid serving it, expressed in grams of carbon dioxide equivalent per kilowatt-hour, and the electricity estimated for that location is multiplied by the corresponding factor. Summing across locations produces the total for the network.

What results is overwhelmingly a scope 2 figure: the indirect emissions embodied in electricity purchased from a grid. Scope 1 covers emissions from sources the operators control directly, such as fuel burned on site; for infrastructure of this kind, which is general-purpose server hardware drawing grid power in commercial data centers, scope 1 is normally negligible and is reported as such unless something specific indicates otherwise. Emissions embodied in manufacturing, shipping and disposing of that hardware fall outside this boundary and are not included.

Greenhouse gas intensity is the marginal emission attributable to one additional transaction, obtained by allocating the total across the transactions confirmed in the same period. Like its energy counterpart it is an allocation of shared overhead rather than a property of any single transaction, and it moves when grid factors move or when the composition and location of the infrastructure change, not only when network behavior does. Grid carbon intensity values 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 made available under the Creative Commons Attribution 4.0 license.

Emissions rest on the same geographic groundwork as the energy figures, with a different coefficient applied at the end. Once the node population has been located and assigned to regional grids, each assignment is paired with the carbon intensity of electricity generation in that region — the mass of carbon dioxide equivalent released per unit of electricity delivered — and estimated consumption is apportioned across regions and converted. Because regional carbon intensities differ by an order of magnitude or more, where the machines sit influences the emissions result at least as much as how much electricity they draw.

Scope 1 and scope 2 are separated. Scope 1 captures emissions from sources the operators control directly, such as fuel combusted on site for backup power, and is negligible or zero for a network of this design, whose validators run commodity servers on purchased electricity. Scope 2 captures the indirect emissions embodied in that purchased electricity and makes up effectively the entire figure. The comparatively well-documented hosting of the permissioned block-producing set narrows the uncertainty on the part of the estimate that carries the most weight; for nodes whose location cannot be pinned down, the regional profile of a structurally comparable network stands in, and that approximation propagates into the emissions result as it does into the energy one.

Carbon intensity coefficients 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.

Greenhouse gas intensity is defined in the same marginal terms as energy intensity: the additional emissions attributable to processing one further transaction, not the network's total emissions divided by the number of transactions it carried. Since the machines run continuously irrespective of load, that marginal quantity stays modest and falls as utilization increases. Figures are revised when regional statistics are updated or when observation of the node population improves, and any assumption taken under uncertainty is set so as to favor the higher estimate.

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 estimated electricity consumption of the network and the carbon content of the electricity that supplies it, not from any direct measurement of exhaust. The chain of reasoning begins with the same inferred geography used for the energy assessment: node locations are approximated from publicly observable network data, resolved to regional level, and where the observation is too sparse to support a distribution, the spread of a network with a comparable operating model is used in its place.

Each region is then matched to a carbon intensity for its electricity supply, expressed as emissions per unit of electricity generated, using 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 that region, and summing, gives the network total.

The result is almost entirely indirect. Scope one covers emissions released by sources the operators themselves control, which for a network of this kind means essentially nothing: there is no combustion in running a node, and on site generation, where it exists at all, is not separately observable, so this component is reported at or near zero. Scope two covers the emissions embodied in the electricity purchased to run the machines, and that is where the network's footprint sits. Because the estimate is grid average by region, it does not credit an operator who buys certified renewable supply, nor does it charge an operator whose actual supply is dirtier than the regional figure suggests.

Greenhouse gas intensity is stated on a marginal basis, as the additional emissions associated with one further transaction, for the same reason that energy intensity is. On a network in wind down, where activity can fall while the infrastructure keeps running, an average computed from a shrinking transaction count would move sharply without anything physical having changed.

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 attributed to Hedera use the same geographic picture as the energy analysis, applied to a different statistic. Once the consensus nodes have been resolved to countries, partly from the operator identities published in the network's address book and partly from advertised network addresses mapped through public network data and registry records, each location is matched to the average carbon intensity of electricity generation on that grid, expressed as greenhouse gas emitted per unit of electricity produced. Multiplying the electricity estimated to be consumed in each country by that country's intensity, then summing, produces the emissions total. Where part of the population cannot be located, the distribution of a structurally similar network substitutes for the missing portion.

The reporting distinguishes two categories. Scope 1 covers emissions from sources the operators of the network infrastructure directly control, such as fuel burned on their own premises. For a network of this kind these are negligible or absent, because the nodes consume purchased electricity and combust nothing themselves, and a reported value of zero should be understood in that sense rather than as a gap in the data. Scope 2 covers the indirect emissions embodied in the purchased electricity, and accounts for essentially the whole figure. The calculation applies average grid intensities at country level, so it reflects a national generation mix rather than any contractual arrangement, on-site generation or certificate purchase an individual operator may have made, and it does not net off offsets purchased outside the electricity system.

Greenhouse gas intensity is the marginal counterpart to the total: the additional emissions attributable to one further transaction, with the infrastructure held constant. It carries forward every limitation of the inputs beneath it, including an inferred hardware profile, uncertainty about redundancy behind each address book entry, country-level rather than site-level grid data, and a transaction count that varies independently of the infrastructure. Where evidence is thin, the assumptions chosen raise the result rather than lower it. Carbon intensity data is taken from Carbon intensity of electricity generation, compiled and processed by Our World in Data from Ember and from 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. 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 are derived from the network's estimated electricity use combined with the carbon content of the grids supplying it. The energy total is first apportioned by location, using the same geographic picture assembled for the energy analysis: node addresses observed on the peer network, operator information published openly, and the hosting ranges those addresses resolve to. Where a node's placement cannot be resolved, the distribution of a structurally comparable network is used in its place, selected for similar incentives and similar validation duties rather than for similar scale.

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

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

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

This chain's consensus layer is a council whose members are known by name and whose participation is public record, unlike an open network of whoever turns up. That changes the calculation at its most uncertain point. How many consensus machines exist, and where they stand, need not be answered by inference alone: council membership yields an enumerable population, and its institutions publish enough to tie much of the consensus hardware to particular countries. What stays inferential is the endpoint tier and the independent service chains, whose operators are numerous and rarely announce themselves.

The arithmetic laid over that population is ordinary. Electricity estimated for each country is multiplied by a published figure for the greenhouse gas its generation releases per unit produced, reported in carbon dioxide equivalent, and the country results are added. Because council membership leans heavily toward a small number of East Asian jurisdictions, the answer is governed by the generating mix of those particular grids, and it would move substantially if a large member relocated its racks or one of those grids changed its generating fleet. The quantity reported therefore tracks national electricity policy at least as closely as it tracks anything the protocol does.

Two scopes are reported. The first covers what operators burn themselves. Consensus and endpoint machines are ordinary servers drawing from a socket, and the standby plant behind a hosting facility runs only during outages, so the category is empty and is shown as empty rather than dropped. The second covers emissions embodied in the electricity those machines buy, which is where the entire figure sits. Grid averages serve rather than any supplier-specific number, since a member's power purchase arrangements are neither visible from outside nor verifiable; the effect errs toward a higher answer. Hardware manufacture and disposal fall outside the boundary altogether.

Per-transaction emissions intensity is marginal in principle and constrained in practice. Blocks arrive on a fixed one-second cadence whether or not anyone transacts, so emissions barely respond to one extra transfer; the published figure is better read as the total spread over observed throughput, useful for setting networks side by side and not a claim about what a single transaction released. Coefficients come from Carbon intensity of electricity generation, assembled by Our World in Data from Ember and from the Energy Institute's Statistical Review of World Energy and issued under the Creative Commons Attribution 4.0 license.

Where the boundary falls is not obvious here. Two pools of electricity are in scope: the machines the network runs for itself, chiefly the proving cluster together with sequencing, coordination and the replica and archive servers third parties keep; and a slice of the settlement layer, sized by how much of Ethereum's capacity the posted batches and proof verifications occupy. Fabricating the accelerators and constructing the halls that house them lie outside.

Within the boundary nothing is metered for carbon. A coefficient is applied instead: for each country in which consumption has been placed, published statistics give the average greenhouse gas released per unit of electricity generated there, expressed in carbon dioxide equivalent. Estimated electricity is multiplied through and the products added. What makes the calculation distinctive is how lopsided the weights are. Proving concentrates the bulk of the draw into a few hosting sites, so the coefficient of one or two grids governs the answer, and a decision to prove somewhere else would move reported emissions further than most protocol changes could. Those sites are placed from the operator's public technical material; replica nodes by resolving announced addresses to countries, with a borrowed profile from a commercially comparable network covering whatever will not resolve. Settlement-layer validators are placed on their own terms and folded in at the weight their slice carries.

Scope 1 would capture combustion under the operators' own control, an on-site generator being the plain case. In leased facilities full of general-purpose servers there is normally none, and the zero that appears is a finding rather than a gap. Scope 2 is the indirect burden riding on purchased electricity, and effectively the whole figure sits there. National average coefficients mean a site on a specific low-carbon contract scores no differently from a neighbor on default supply.

Greenhouse gas intensity per transaction is marginal rather than averaged: what one additional transaction adds, with the installed fleet unchanged. On this network that increment is real rather than nominal, since one more transaction is one more transaction to prove. It inherits the uncertainty of both the consumption estimate and the grid coefficients. Those coefficients are taken from Carbon intensity of electricity generation, a series Our World in Data builds from Ember's electricity data and from the Energy Institute's Statistical Review of World Energy and releases under the CC BY 4.0 license.

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.

Emissions follow the same path as the renewable share, with a different coefficient applied at the end. Node and validator locations are inferred from publicly observable network data, and where a chain's geographic spread cannot be read directly the distribution of a structurally similar network is substituted for it. Each location is matched to the carbon intensity of electricity generated on the grid serving it, expressed as grams of carbon dioxide equivalent per kilowatt-hour, and the weighted result is applied both to the consumption estimated for this network's own infrastructure and to its attributable share of the settlement chain on BNB Smart Chain.

The two scopes are kept apart. Scope 1 means emissions released by equipment the infrastructure's operators control outright, fuel combusted on site being the usual example; for machines racked in commercial data centers there is normally nothing of the kind, and a zero is stated rather than modeled. Scope 2 is the indirect burden carried in the electricity those machines buy and draw, and that is where effectively the whole footprint sits. Emissions from manufacturing the hardware, constructing the facilities, or running the networks between them fall outside both scopes and are not counted here.

Greenhouse gas intensity is a marginal figure: the additional emissions associated with one further transaction, obtained by applying the same carbon intensities to the marginal energy described in the preceding section. Like that energy figure, it is not the total divided by a transaction count.

The carbon intensity coefficients are annual national series published by Our World in Data and processed from Ember's electricity data together with the Energy Institute's Statistical Review of World Energy: Carbon intensity of electricity generation. That dataset is made available under the Creative Commons Attribution 4.0 license.

The limits are those of the inputs. National annual averages do not capture an hourly generation mix or a particular facility's supply contract, location inference remains incomplete, and the division between this network's own infrastructure and its share of the settlement chain rests on an attribution rule rather than on metering.

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 figures are constructed from the energy estimate and the geographic estimate together. The distribution of nodes across regions is inferred from publicly observable network data, with the distribution of a structurally comparable network standing in where direct observation is insufficient. Each region's share of estimated consumption is then multiplied by the emissions released per unit of electricity generated on that region's grid, and the results are summed to give the network total.

Carbon intensity values are taken from Carbon intensity of electricity generation, compiled by Our World in Data with major processing from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy, and published under the Creative Commons CC BY 4.0 license.

The distinction between the two reported scopes is worth spelling out. Scope 1 captures emissions from sources the infrastructure's operators control directly, essentially combustion happening on their own premises. Validators and supporting nodes for this network are conventional servers housed in data centers and supplied from public grids, so there is ordinarily nothing of that kind to record and the scope 1 figure is reported at or close to zero rather than omitted. Scope 2 captures the emissions embodied in the purchased electricity that those machines consume, and in practice the entire footprint falls under it. Greenhouse gas intensity mirrors energy intensity in construction: it expresses the emissions attributable to one additional transaction at the margin, not an average obtained by dividing a total by a count.

Every uncertainty already present in the consumption and location estimates propagates into these figures, and the intensity data introduces another. Published grid intensities are annual averages across a region; they cannot reflect the hours at which a node's consumption actually falls, nor any generation a particular operator has contracted for directly. Where the evidence is thin, the conservative assumption is preferred, meaning the reported emissions are more likely to sit above the true value than below it, and every figure is revised as the underlying observation improves.

Where the perimeter falls decides much of this figure, and here it sits unusually. Transaction data is not handed to an outside availability network with its own node set but held by a committee known to the chain, so those servers stand inside the perimeter and are counted directly rather than through a share of somebody else's total. Outside it but still attributable is the settlement layer, Ethereum, which receives only certificates and state assertions; a portion of its consumption is allocated here in proportion to what those postings occupy. Each pool needs a location before it can take a coefficient.

Locations come from what the public network reveals: announced endpoints resolved to countries, address blocks registered to hosting operators, and operator disclosures. Coverage is partial, and on a chain this young the observable sample is small, so a network of similar construction and hosting economics supplies a stand-in profile for the remainder. Each country in the resulting weights carries a published figure for greenhouse gas released per unit of electricity generated, in carbon dioxide equivalent. Applying those figures to the electricity estimated in each country and to the allocated settlement share, then adding, gives the total.

Reporting splits direct from indirect. Direct emissions arise from plant the operators own and run, an on-site generator being the plainest case; for equipment in leased commercial facilities there is none, so a zero is entered as a conclusion rather than a placeholder. Indirect emissions are those already contained in the grid electricity the machines draw, and they carry the entire result. Manufacturing the hardware and constructing the buildings fall outside.

Per-transaction intensity is stated at the margin, applying these coefficients to the marginal electricity described alongside the renewable share. Because data goes to a committee rather than to the settlement layer in full, that quantity is smaller than a design posting everything to Ethereum would produce, and it falls further as batches fill. The residual uncertainties are inherited: national annual coefficients cannot represent an hour's generation or a facility's supply, placement is incomplete, and the split between the chain's own machines and its settlement slice follows a rule rather than a meter. The coefficients are published by Our World in Data, processed from Ember's electricity data and the Energy Institute's Statistical Review of World Energy: Carbon intensity of electricity generation. The dataset is available under the Creative Commons Attribution 4.0 license.

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 are built on the geographic picture assembled for the energy figures, with grid carbon intensity replacing renewable share. Locations are inferred for each population that contributes: the sequencing and proposing infrastructure, the full node and public endpoint tier, the operators of the external data availability layer, and the part of the settlement chain's validator base carrying this network's activity. The inference rests on publicly observable network data, and where a population cannot be placed directly the distribution of a structurally comparable network stands in for it, with the resulting uncertainty carried into the estimate rather than concealed.

Each location is matched to the carbon intensity of the electricity on the grid serving it, expressed in grams of carbon dioxide equivalent per kilowatt-hour. The electricity estimated for that location is multiplied by the corresponding factor, and the products are summed across locations to give the network total.

What this produces is a scope 2 figure: the indirect emissions embodied in electricity bought from a grid. Scope 1 covers emissions from sources an operator controls directly, such as fuel burned on site; for a network running on general-purpose servers in commercial data centers, scope 1 is normally negligible and is reported as such unless something specific suggests otherwise. Emissions embodied in manufacturing and disposing of the hardware fall outside this boundary and are not counted, so the figure is an operational rather than a life-cycle measure.

Greenhouse gas intensity is the marginal emission attributable to one additional transaction, obtained by allocating the total across transactions confirmed in the same period. It distributes shared overhead rather than describing any individual transaction, and it moves with grid factors and hosting decisions independently of network activity. The 2026 change in architecture also reweighted which populations dominate the total, which matters for comparing periods. Grid carbon intensity values 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 the Creative Commons Attribution 4.0 license.

Emissions build on the same geographic work as the energy figures, with a different coefficient applied at the last step. Once nodes have been located and assigned to regional grids, each assignment is paired with the carbon intensity of electricity generation in that region — the mass of carbon dioxide equivalent released per unit of electricity delivered — and estimated consumption is apportioned across regions and converted. Regional carbon intensities vary by an order of magnitude or more, so where the machines sit shapes the emissions result at least as strongly as how much electricity they consume.

The scopes are kept apart. Scope 1 covers emissions from sources the operators control directly, such as fuel burned on site for backup generation; for a network whose validators run commodity servers on purchased electricity it is negligible or zero. Scope 2 covers the indirect emissions embodied in that purchased electricity and accounts for effectively the whole result. Concentration of operators in commercial hosting regions means a comparatively small number of regional coefficients carry most of the weight, so a revision to any one of them moves the total noticeably. Where a node's location cannot be established, the regional profile of a structurally comparable network stands in, and that approximation carries into the emissions result exactly as it does into the energy one.

Carbon intensity coefficients 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.

Greenhouse gas intensity follows the marginal definition used for energy intensity: the additional emissions attributable to one further transaction beyond those already processed, rather than total emissions divided by transaction count. Because the machines run continuously regardless of demand, that marginal quantity is modest and declines as utilization rises. Results are restated as regional statistics are refreshed and as observation of the node population improves, with assumptions taken under uncertainty set to favor the higher estimate.

Emissions are derived from the same geographic picture used for energy sources, applied to a different set of grid statistics. Node locations are inferred from addresses observable through crawlers and public cluster information and resolved to a region; where direct observation falls short, the geographic distribution of a structurally comparable network is substituted, selected on the basis that its incentive design and agreement protocol impose similar operating demands.

Each region is then paired with a carbon intensity for its electricity, taken from Carbon intensity of electricity generation, compiled 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 the CC BY 4.0 licence. Multiplying the electricity estimated to be consumed in a region by that region's carbon intensity, and summing across regions, gives the emissions attributable to running the network.

The disclosure separates two scopes. Scope 1 covers emissions from sources the operators of the infrastructure control directly, such as fuel burned on site; for a network of this kind, whose nodes are ordinary servers in rented facilities, this is normally nil or immaterial, and a zero figure reflects the absence of such sources rather than an omission. Scope 2 covers the indirect emissions embodied in the electricity those machines purchase, and is where essentially the whole footprint of this network falls.

Greenhouse gas intensity follows the same marginal logic as its energy counterpart: it expresses the emissions associated with one additional transaction rather than an average obtained by dividing an annual total by throughput. Because validators consume electricity at a fairly steady rate whether or not blocks are full, the marginal figure is small and is not a proxy for the footprint of the network as a whole. Both the absolute emissions and the intensity figure are sensitive to the grid statistics underlying them, which are revised as national energy reporting is updated.

Emissions are derived, not observed. The estimate combines the modeled electricity consumption of the network with the carbon content of the electricity supplying the regions where its machines appear to run. Those regions come from the same inference used for the energy assessment: addresses seen in peer discovery and crawler output, resolved regionally, with the distribution of a structurally comparable network standing in wherever direct observation is too thin to rely on.

Each region is assigned a carbon intensity for its electricity, measured as emissions per unit generated, taken 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 published under the Creative Commons Attribution 4.0 license. Multiplying each region's intensity by the consumption attributed to it, then summing, produces the network figure.

The split between the two reported scopes follows from how the network operates. Scope one counts emissions from sources the operators control directly, which for server infrastructure means combustion on the operator's own premises; nothing in running a node produces this, and any backup generation is neither material nor observable, so the figure is reported at or close to zero. Scope two counts the emissions embedded in the purchased electricity that runs the machines, and effectively the whole footprint sits there. Because regional grid averages are used, an operator buying certified clean supply is not credited for it, and one drawing from a dirtier local mix than its region's average is not charged for it either.

Greenhouse gas intensity is reported as the marginal emissions attributable to one further transaction, mirroring the treatment of energy intensity. For a network built for high throughput this is the more honest presentation: the infrastructure emits at much the same rate whether it is processing a few transactions or many, so dividing a period total by a transaction count would produce a figure that swings with activity rather than with the emissions actually caused.

Emissions follow from the consumption estimate by applying a carbon intensity to the electricity drawn at each location, and the two-part structure of the consumption estimate carries straight through. The operator-run sequencing and proving infrastructure is assigned the carbon intensity of the grids serving the facilities it runs in. The attributed share of the settlement layer is assigned the intensity implied by that layer's own validator distribution. Summing the two gives the total, and the boundary is operational electricity: neither the manufacture of proving hardware nor the construction of the facilities housing it is included.

Scope 1 covers emissions from sources the operators directly control, which for infrastructure hosted in commercial facilities means occasional backup generation and little else. It is a negligible contributor here and is reported as such rather than modeled in detail. Scope 2 covers emissions embodied in purchased electricity and accounts for effectively the entire footprint, on both the operator-run side and the attributed settlement share.

Greenhouse gas intensity per transaction is period emissions divided by transactions settled in the period. It inherits the batching property described for energy intensity, falling as batches fill, and it also inherits the uncertainty of every step behind it: an error in the assumed proving hardware propagates into consumption and from there into emissions, while the settlement share depends on both that layer's own estimate and the attribution rule used to divide it. Grid carbon intensities are annual averages that conceal substantial variation across a day and a year, and a network whose infrastructure sits in few locations is more exposed to that variation than one spread across many grids, because there is less averaging to smooth it out. Figures are restated each period as the network's operation becomes more openly observable and as grid data is updated. Carbon intensity data is processed by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy, and is made available under a Creative Commons BY 4.0 license: Carbon intensity of electricity generation.

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.

Emissions are calculated rather than measured, by applying the carbon properties of the electricity the network's machines consume. The jurisdictional distribution used for the energy mix is reused here: the consumption assigned to each location is multiplied by the published figure for greenhouse gases released per unit of electricity generated on that grid, and the products are added across the distribution. Totals are stated in carbon dioxide equivalent so that gases other than carbon dioxide are captured on a warming-equivalent basis.

The two scopes describe different sources and are kept apart deliberately. Scope 1 covers what the operators release from things they own or control, such as fuel burned on site, standby generators and refrigerant losses. For this network it is ordinarily nil or close to it, because the operators run computing equipment in commercial facilities they generally do not own and burn no fuel of their own in producing or verifying blocks. Scope 2 covers what was released elsewhere to generate the electricity that equipment draws, and that is where effectively the whole footprint sits. What it takes to manufacture the hardware or build the facilities falls outside the boundary drawn here.

Greenhouse gas intensity is reported per transaction on the same marginal basis as energy intensity: the further emissions attributable to processing one additional transaction rather than an annual average spread across throughput. Because the committee produces blocks on a fixed cadence whether the network is busy or idle, that marginal quantity is small and changes with usage more than with the underlying infrastructure.

Carbon intensity values 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 published under the Creative Commons Attribution 4.0 license. Those values are annual national averages, so variation within a country and over shorter periods is not represented, and any error in locating the machines carries straight through into the emissions result.

Emissions are derived from the energy estimate rather than measured. The geographic breakdown used for the renewable share — sequencing and data-publishing servers, the proving fleet, full nodes, and the portion of Ethereum's validator population attributed to settlement — is reused, and each country's share of estimated electricity is multiplied by the average carbon intensity of that country's grid. Those 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 a Creative Commons BY 4.0 license. Country-level results are summed into a network total, and a fraction of that total is attributed to an individual asset in proportion to observed on-chain activity.

The scopes are separated deliberately. Scope 1 covers emissions from sources the operators directly control, meaning fuel burned on their own premises. Infrastructure hosted in commercial data centers normally has nothing material here, and it is reported as zero or negligible rather than inflated by guesswork. Scope 2 is where the figure sits: the indirect emissions embodied in the electricity purchased to run sequencing, proving and node hardware. It is calculated on a location basis, applying the average intensity of the grid serving each region, since a market-based figure would require supply contracts and certificates that are not observable from network data. Emissions embodied in manufacturing the hardware — which for accelerator-heavy proving equipment is not trivial — and in constructing the facilities that host it fall outside this boundary and are not included.

Greenhouse gas intensity is expressed as the marginal emissions of one more transaction, mirroring the treatment of energy intensity. Three limits should be read with the figure: national annual averages conceal hourly and regional variation in real grids; every uncertainty in the energy and location estimates carries through; and where assumptions must be chosen, the more conservative one is taken, so the result is better understood as an upper bound than as a precise quantity.