Wrapped Bitcoin (WBTC) sustainability report

Wrapped Bitcoin is present on the following networks: Aptos Coin, Avalanche, Base, Berachain, Binance Smart Chain, Ethereum, Hedera Hbar, Optimism, Osmosis, Sei, Solana, Sonic, Sui, Tron.

Aptos combines proof of stake with a Byzantine fault tolerant agreement protocol in the lineage of pipelined, leader-based designs. Validators hold voting power in proportion to the stake bonded to them, and a committee is fixed for the duration of an epoch, which lasts two hours; changes to the set take effect only at those boundaries. Within an epoch, a leader is chosen for each round to propose the next block, and the choice is weighted not only by stake but by recent performance, so an operator that repeatedly fails to get its proposals committed is proposed less often. Agreement is deterministic: once a quorum of voting power certifies a block, it is final and cannot be reorganized, in contrast to systems where confidence accumulates probabilistically.

Transaction data is disseminated separately from ordering. Validators batch incoming transactions and circulate them ahead of time, collecting proofs of availability, so a proposal need only reference batches that the rest of the committee already holds rather than carry the payload itself. This separation is what allows proposals to stay small and the agreement path to stay short. Successive protocol revisions have compressed that path further, cutting the number of network round trips needed to commit and allowing a leader to propose once per network delay instead of waiting out two, which has brought block intervals down to a few tens of milliseconds and finality comfortably below a second.

Execution is parallel and optimistic. Rather than requiring developers to declare in advance which state a transaction will touch, the engine speculatively executes transactions concurrently across processor cores, detects at runtime where one transaction read state another wrote, and re-executes only the affected transactions. Because the serial order fixed by agreement is used as the reference, the outcome is identical to sequential execution and every validator derives the same result. The network tolerates faulty or malicious behavior by up to one third of voting power.

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.

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.

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.

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.

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.

Sui runs a delegated proof-of-stake network whose validator committee is fixed for an epoch of roughly one day, with voting power proportional to the stake bonded to each member. Agreement uses a directed acyclic graph rather than a single chain of proposals: validators produce blocks each round that reference blocks from the previous round, and the resulting structure is read directly by every validator to work out which blocks are committed and in what order. Because the commit rule is evaluated over the graph itself, no separate round of explicit certification is needed, which removes network round trips from the critical path and brings commit latency down to a few hundred milliseconds. A more recent revision folded transaction validation into the same process and routes each submitted transaction through a single coordinating validator, cutting duplicated signature work.

The distinctive part of the design is that not every transaction has to pass through that machinery. State is modeled as discrete objects, each either owned by a single address, shared, or immutable, and a transaction declares the objects it will read and write before it executes. A transaction touching only objects owned by its sender cannot conflict with anything another party might submit, so it does not need a global ordering: a quorum of stake signing it by reliable broadcast is enough to settle it, and it finalizes on this fast path in roughly the time of two network round trips. Transactions that touch shared objects, which is what most decentralized finance activity involves, do require the graph-based protocol to sequence competing accesses, and carry slightly higher latency and cost as a result, rising further when many transactions contend for the same popular object.

Execution takes advantage of the same declarations: transactions whose object sets do not overlap run concurrently. The protocol remains safe provided faulty or malicious validators hold less than a third of voting power.

The TRON network reaches agreement through delegated proof of stake. Holders of the native asset lock it up, which yields voting weight, and use that weight to back candidates who have registered to produce blocks. Votes are counted afresh at the end of every six-hour cycle. The twenty-seven candidates ranked highest by votes become the super representatives that produce blocks for the cycle that follows; those ranked immediately below them form a standby tier of partners, which does not produce blocks but remains in the reward distribution and supplies replacements as the ranking shifts. Because the count repeats four times a day, the producing set is re-derived continuously rather than fixed for a term.

Block production follows a fixed rotation among the twenty-seven, with one slot every three seconds. A producer that misses its slot is skipped and the schedule continues. A block is treated as settled once more than two-thirds of the producing set has built on it, so settlement follows from producers confirming one another's work rather than from a separate voting protocol, and takes on the order of a minute in normal conditions. Smart contracts execute in a virtual machine built for compatibility with Ethereum tooling, under the same producing set.

The security argument rests on an honest supermajority within a small, elected and publicly identified group. Entry is open in the sense that anyone may register as a candidate, subject to a deposit that is destroyed on registration, but a candidate only produces blocks by accumulating votes. The same twenty-seven form the committee that governs the chain's adjustable parameters: proposals to change values such as resource pricing, reward sizes and protocol feature switches are voted on by the producers, and a proposal passes on the support of a supermajority of them. A substantial part of what users experience as the cost of using the network is therefore a governance variable rather than a fixed property of the protocol.

Wrapped Bitcoin is present on the following networks: Aptos Coin, Avalanche, Base, Berachain, Binance Smart Chain, Ethereum, Hedera Hbar, Optimism, Osmosis, Sei, Solana, Sonic, Sui, Tron.

Validators are paid from newly issued units of the native asset at a rate set by on-chain governance, and the payment is conditioned on output rather than mere presence. The reward for an epoch scales with the stake bonded to a validator multiplied by the proportion of its block proposals that were actually committed, so an operator that is offline, slow, or frequently skipped earns proportionally less. Rewards are added to the staked balance at each epoch boundary and compound from there. Holders who do not run hardware delegate into a validator's staking pool and receive their share after the operator's commission; stake locks and unlocks on epoch boundaries rather than on demand.

Penalties are exclusionary rather than confiscatory. The protocol does not currently implement slashing: there is no mechanism that destroys a validator's bonded stake for double-signing or for prolonged inactivity. What an underperforming operator loses is reward, through the proposal-success term, and eventually its place, since a validator whose stake falls below the minimum required to remain in the active set is moved to inactive status at an epoch transition, and governance can remove a validator directly. Delegators exert the remaining pressure by moving stake elsewhere.

Users pay for transactions in gas units priced in a small subunit of the native asset. The charge separates two things. Execution and input-output gas covers computation and propagation, and its unit price floats with congestion, which is also how transactions are prioritized: validators select from the pending pool by offered gas unit price, banded into discrete tiers rather than compared continuously, so raising a bid within a tier changes nothing. Storage is billed separately and at a price fixed in the native asset rather than in gas units, so the cost of occupying state does not swing with congestion, and the charge is refunded when the storage is released, meaning a transaction that frees more state than it creates can settle as a net credit. Under the fee parameters governance currently sets, collected gas is burned in full rather than routed to the proposing validator.

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.

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.

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.

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.

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.

Stake is bonded by wrapping the native asset in a stake object delegated to a validator's pool; the holder keeps custody of that object and the pool's exchange rate appreciates as rewards accrue, so redeeming it later returns principal plus accumulated reward net of the validator's commission. Rewards are settled at epoch boundaries and come from the computation fees collected during the epoch together with issuance intended to support the validator set in the network's early years. Stake counts toward rewards only for epochs it was active throughout.

Penalties bite on reward, not on principal. Validators grade each other over the epoch, and if holders of more than two thirds of voting power report a given validator for poor operation, that validator's rewards for the epoch are reduced or removed entirely, and the holders who delegated to it forfeit their reward for that epoch as well. The bonded principal itself is not destroyed. A validator whose stake falls below the threshold for committee membership simply leaves the committee. The same reward multiplier enforces the fee market: at the start of each epoch validators submit the lowest price at which they will process transactions, the reference price for the epoch is the stake-weighted two-thirds percentile of those quotes, and validators that quote a low price and then honor it are rewarded relative to those that do not.

Users pay two components. Computation is metered in units placed into coarse buckets, so similar transactions cost the same and developers are not pushed into micro-optimization, and the bucket is priced at the epoch's reference rate. Storage is charged per byte at a price fixed by governance rather than set by congestion, and the amount paid is routed into a storage fund instead of to the validators of the day. Deleting data returns almost all of the storage charge as a rebate, so a transaction that frees more state than it occupies can settle at a net credit. The storage fund is the unusual element: it is counted alongside user stake when rewards are computed, most of the return it earns is paid to whichever validators are currently storing historical data, the remainder is reinvested, and its principal is never paid out, so it cannot be drained by the validators it compensates.

Producers on TRON are paid from two streams of newly issued units. A fixed amount is awarded for each block to the representative that produced it, and a larger per-block amount is divided among the wider set of elected and standby representatives in proportion to the votes each received. Each representative publishes the proportion of its receipts that it passes back to those who voted for it, so what a participant earns depends on which representative is backed. Registering as a candidate requires a deposit that is destroyed rather than held, which discourages frivolous entry. There is no slashing: a representative that produces poorly is not deprived of locked funds but loses votes, and with them its place in the producing set and its share of both streams.

Users do not pay a per-transaction price in the usual sense. The protocol meters two resources. Bandwidth covers the byte size of a transaction and energy covers computation performed by the virtual machine. Each has a fixed network-wide daily ceiling, and locking up the native asset entitles an account to a share of that ceiling proportional to its share of everything locked for the same resource, so an allowance changes as others lock and unlock even when the account itself does nothing. Every account also receives a small free bandwidth allowance that regenerates daily. Under the staking arrangement introduced in 2023 and generally known as the second version, locking up is separated from resource assignment: resources obtained by locking can be delegated to other addresses and reclaimed without unlocking, which is what makes third-party resource provision practical. Recovering the locked balance itself requires a waiting period of fourteen days.

When an account attempts an operation without sufficient resources, the protocol burns the native asset at unit prices set by governance, one per byte of bandwidth and one per unit of energy, both of which have been revised upward in recent parameter changes. That burn is destroyed rather than paid to producers, so what users spend and what producers earn are separate flows. A further mechanism adjusts cost by contract rather than by congestion: a contract whose energy consumption passes a threshold within a cycle carries a multiplier on its energy cost in following cycles, decaying once consumption falls back, so calling a heavily used contract can cost several times what the same computation costs elsewhere.

Wrapped Bitcoin is present on the following networks: Aptos Coin, Avalanche, Base, Berachain, Binance Smart Chain, Ethereum, Hedera Hbar, Optimism, Osmosis, Sei, Solana, Sonic, Sui, Tron.

Consumption is built up from the population of machines that operate the network. The first input is a count of those machines, split into the validators that take part in agreement, the fullnodes that operators run beside them to distribute state, and the public fullnodes that serve reads to applications. One part of this population is unusually well observed: the active validator set is recorded on chain and reconstituted at every epoch transition, so its size is known rather than estimated. The wider fullnode population is not, and is inferred from network crawlers and publicly reachable peer information.

Each class of machine is matched to a hardware profile taken from the resources the node software is documented to require. Because the execution engine is built to occupy many processor cores at once, validator profiles assume multi-core server equipment with substantial memory and fast persistent storage rather than a modest configuration. Power draw for a profile comes from bench measurement of equivalent hardware, recorded both under load and at rest, with idle draw included because a node is expected to stay available continuously. Aggregating draw across the estimated population over the hours in the reporting period yields consumption for the network. Where a portion of that total is attributed to an individual asset issued on the network, the share is based on that asset's observed proportion of on-chain transfer activity.

Several qualifications apply. The fullnode population is inferred rather than counted; hardware is deduced from documented requirements rather than reported by the operators themselves; and facility overheads for cooling and power conversion are approximated using typical data-center factors instead of being metered at each site. Where the available evidence leaves a question open, the assumption taken is the one that tends to produce the higher consumption figure, so the disclosure is not made flattering by accident. Estimates are revised as observation improves and after protocol changes that alter the work a node has to do.

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 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 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.

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 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.

The estimate starts from the machines that operate the network and works upward. Its first input is the population of nodes, separated into the validators that form the committee, which is recorded on chain and therefore countable rather than guessed, and the far larger and less visible set of full nodes that replicate state, index it and serve application traffic. The size of that second group is inferred from network crawlers and publicly reachable peer information, and is the main source of uncertainty in the count.

Each group is matched to a hardware profile derived from the resources the node software is documented to need. Validators here are expected to execute transactions in parallel across cores and to maintain the object store and its indexes, so their profiles assume multi-core server hardware with generous memory and fast solid-state storage rather than modest equipment. Power draw for each profile is taken from bench measurement of comparable devices under load and at rest, and idle draw is counted, because a node is expected to remain available continuously whether or not transactions are arriving. Multiplying draw by the estimated population across the hours of the period gives consumption for the network. Where a share of that total is attributed to an individual asset issued on the network, that share is based on the asset's observed proportion of on-chain transfer activity.

The limits of the method should be read alongside the result. Node counts outside the committee rest on what is observable from the public network, and operators need not be observable; hardware is inferred from documented requirements rather than collected from operators; and the overhead of cooling and power conversion in hosting facilities is approximated from typical factors rather than metered. Where the evidence does not resolve a question, the assumption chosen is the one that tends to raise rather than lower the reported figure, and estimates are revised as observation improves and as protocol changes alter what a node must do.

The consumption figure reported for this network is estimated from the machines that operate it. A delegated proof-of-stake chain does not expend energy as part of reaching agreement, so there is no work-based quantity to model as there is for mining networks; what consumes electricity is a population of continuously running servers, and estimating that population is the whole of the exercise.

The estimation approach used here starts from the participants the chain itself identifies. Registered producer candidates are visible on chain, as is their ranking, which separates the twenty-seven producing during a cycle from the standby tier and the wider candidate list. Around that core sits a larger population of full nodes, relay nodes and the query-serving infrastructure that applications and wallets depend on, which is estimated from publicly available network data and from scanning for reachable endpoints. A representative machine is then inferred for each part of the population, taking the published operating requirements of the node software as the primary input. Those requirements are demanding relative to many networks, reflecting a three-second block interval, a high sustained transaction rate and a large accumulated state that nodes must keep available. Electrical draw for machines of that class is taken from controlled bench measurement rather than from specification sheets, and includes the draw of a machine that is powered and connected but idle, which for always-on infrastructure is a large part of the annual figure. The total is the sum across the estimated population.

Where a figure is needed for one asset issued on the chain rather than for the chain as a whole, a share of the network total is attributed to it in proportion to observed on-chain activity involving that asset. This matters on a network carrying a high volume of token transfers relative to its other traffic.

The limits are inherent to the method. Node counts and hardware profiles are inferred from public observation and stated requirements, not metered; operators commonly run hardware above the published minimum; and endpoints that do not respond to scanning are not counted. Where evidence is thin, assumptions are chosen to be more likely to overstate impact than to understate it, and figures are revised as observation improves.

Wrapped Bitcoin is present on the following networks: Aptos Coin, Avalanche, Base, Berachain, Binance Smart Chain, Ethereum, Hedera Hbar, Optimism, Osmosis, Sei, Solana, Sonic, Sui, Tron.

Establishing where the network's electricity comes from begins with establishing where its machines are. Node addresses observable through crawlers and public peer information are resolved to a country or region, giving partial geographic coverage; it is only partial, because operators frequently sit behind hosting providers whose announced location need not match the facility actually running the hardware. Where the spread cannot be pinned down directly, the observed distribution of a structurally similar network is used in its place, selected because its staking economics and agreement protocol place comparable demands on operators and so tend to draw them toward comparable hosting markets.

Each located node is then assigned the generation mix of the grid supplying it. Those regional mixes are taken 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 proportion by the consumption estimated to sit there produces a figure for the network overall. The figure describes the grids the infrastructure physically draws on rather than any contractual arrangement: renewable purchase agreements held by individual operators are not reflected, since they cannot be observed from outside the network.

Energy intensity is a separate quantity and is narrower than dividing total consumption by transaction count. It expresses the additional energy associated with processing one further transaction. The distinction carries weight for a network of this design, where validators run continuously at a broadly constant power level and parallel execution absorbs additional transactions using capacity that is already switched on, so the marginal figure is small while the standing consumption of the validator set is not. Both numbers move with two independent inputs: the size, role mix and location of the node population, and the grid statistics for the years covered, which are themselves restated as national energy reporting is revised.

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 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 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.

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.

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.

Working out the renewable share means first working out where the machines sit. Addresses visible through network crawlers and public peer information are resolved to a country or region, which gives incomplete coverage: many nodes sit behind hosting providers or relays, and the announced location of an address need not match the facility housing the hardware. Where the geographic spread cannot be observed directly, the distribution of a structurally similar network is substituted, chosen because its staking economics and agreement protocol impose comparable operating demands and so tend to concentrate operators in comparable hosting markets.

Located nodes are then assigned the generation mix of the grid that supplies them, using 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 proportion by the consumption estimated to sit in that region produces a share for the network as a whole. That share describes the physical grids the infrastructure draws from, not contractual sourcing: an operator holding renewable supply agreements is treated the same as any other operator on the same grid, because such arrangements are not visible from outside the network.

Energy intensity is reported as a separate quantity and means the additional energy associated with handling one further transaction, not the annual total divided by the number of transactions. The distinction is material for this network, where the committee runs continuously at a broadly constant power level and much of the traffic settles over a path that adds little incremental work, so the marginal figure is small while the standing consumption of the node population is not. Both the renewable share and the intensity respond to two separate inputs: the size, mix and placement of the node population, and the grid statistics for the years covered, which are themselves restated as national energy reporting is revised.

The renewable proportion reported for this network follows from where its machines run. Locations are inferred from publicly observable network data: the addresses of reachable nodes are resolved to hosting providers and regions, and the on-chain registry of producer candidates helps place the most important part of the population, since candidates campaign for votes publicly and many disclose who operates them and where. The producing set is small and identifiable, which makes the part of the network that matters most for block production easier to locate than the broader population of supporting and query-serving nodes.

Where the geographic spread of that broader population cannot be established from observation, the distribution of a network with a comparable validator selection and reward design is used as a substitute. This substitution is the main source of uncertainty in the reported share and should be read as such.

Each location is then matched to published statistics on how electricity is generated on the grid serving it, and the individual shares are weighted by the electricity attributed to the machines in that location to give a network-level proportion. The underlying statistics describe the average generation mix on a regional grid across a reporting year. They do not capture variation within a day or a season, nor any renewable supply contracted privately by an individual operator, which is not observable from the chain.

Energy intensity is stated as a marginal figure: the additional electricity associated with processing one more transaction, rather than annual consumption divided by transaction count. On a network whose servers run continuously and which sustains a high transaction volume, that marginal quantity is very small, and it is sensitive to the throughput assumed in deriving it.

The generation statistics are taken 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.

Wrapped Bitcoin is present on the following networks: Aptos Coin, Avalanche, Base, Berachain, Binance Smart Chain, Ethereum, Hedera Hbar, Optimism, Osmosis, Sei, Solana, Sonic, Sui, Tron.

The emissions calculation reuses the geographic picture built for energy sources and applies a different body of grid statistics to it. Node addresses visible through crawlers and public peer information are resolved to regions; where that resolution is incomplete, the distribution of a structurally comparable network is substituted, chosen because its incentive design and agreement protocol impose similar operating requirements and therefore a similar hosting footprint.

Each region is paired with the carbon intensity of its electricity, drawn 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 published under the CC BY 4.0 licence. Multiplying the electricity estimated to be drawn in each region by that region's intensity, then summing across regions, gives the emissions attributable to operating the network over the period.

Two scopes are distinguished. Scope 1 captures emissions from sources under the direct control of those running the infrastructure, such as fuel combusted on site. For a network whose nodes are servers in third-party facilities, this is normally nil or immaterial, and a zero entry records the absence of such sources rather than a gap in the data. Scope 2 captures the indirect emissions embodied in the electricity those machines buy, and accounts for effectively the entire footprint reported here.

Greenhouse gas intensity mirrors its energy equivalent in being marginal rather than average: it is the emission associated with one additional transaction, not an annual total divided by throughput. Because validators consume power at a fairly steady rate irrespective of how full their blocks are, that marginal figure stays small and should not be read as a per-transaction apportionment of the network's whole footprint. Both the absolute emissions and the intensity are sensitive to the underlying grid data, which is updated as national energy statistics are revised, and to any protocol change that alters the hardware a validator needs.

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 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 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.

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.

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 are derived by taking the geographic picture assembled for energy sourcing and applying carbon statistics to it instead of generation-mix statistics. Node addresses observable through crawlers and public peer information are resolved to regions, and where that resolution is incomplete the distribution of a structurally comparable network stands in, chosen because its incentive structure and agreement protocol create similar operating requirements and therefore a similar hosting pattern.

Every region is then paired with the carbon intensity of the electricity generated there, 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 published under the CC BY 4.0 licence. The electricity estimated to be consumed in each region is multiplied by that region's intensity and the products are summed to give the emissions attributable to operating the network over the reporting period.

The disclosure keeps two scopes apart. Scope 1 covers emissions from sources directly controlled by those running the infrastructure, for instance fuel burned on site. For a network whose nodes are servers in third-party data centers this is normally nil or immaterial, and a zero figure records the absence of such sources rather than missing data. Scope 2 covers the indirect emissions carried in the electricity those machines purchase, and accounts for substantially the whole footprint reported for this network.

Greenhouse gas intensity is marginal in the same sense as its energy counterpart: it is the emission associated with one additional transaction rather than an average produced by dividing an annual total by throughput. Because the committee draws power at a fairly steady rate regardless of how busy the network is, that marginal figure stays small and should not be treated as each transaction's share of the network's overall footprint. Both the absolute emissions and the intensity shift with the grid data underneath them, which is revised as national energy statistics are updated, and with any protocol change that alters the hardware a node requires.

Emissions attributed to this network are derived from the geographic picture built for its energy mix, applied to a different statistic. Once the machines have been placed in regions, the electricity attributed to each region is multiplied by the carbon intensity of generation on the grid serving it, expressed as emissions per unit of electricity delivered, and the results are summed across regions. Where node geography cannot be observed directly, the distribution of a structurally comparable network stands in, and that assumption propagates into the emissions figure exactly as it does into the renewable share.

The figures separate two categories. Scope 1 covers emissions from sources the operators of the network's infrastructure control directly, such as fuel burned on site; for servers hosted in commercial facilities drawing from public grids, this is ordinarily nil or close to it, with any backup generation contributing negligibly over a reporting year. Scope 2 covers the indirect emissions embodied in the purchased electricity that powers those servers, and represents effectively the whole footprint of a network of this design. The allocation is made from grid electricity drawn and is not adjusted for offsets, attribute certificates or supply agreements held by individual operators, since none of those are visible from the chain.

Greenhouse gas intensity is reported on a marginal basis, as the emissions associated with one additional transaction rather than an average obtained by dividing an annual total. Because the infrastructure draws power whether or not transactions arrive, this marginal quantity is small, and it moves with the throughput assumed at least as much as with anything the protocol does differently from one period to the next.

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