Tether (USDT) sustainability report

Tether is present on the following networks: Aptos Coin, Avalanche, Celo, Ethereum, Kava, Kaia, Near Protocol, Solana, Tezos, Toncoin, 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.

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

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

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

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.

Kava is a layer 1 network built with the Cosmos SDK that reaches agreement through CometBFT, the Byzantine-fault-tolerant engine previously released under the Tendermint Core name. The design is proof of stake: voting power is allocated in proportion to the quantity of the network's native asset bonded to each validator, either committed by the operator directly or delegated to it by other holders, and only the hundred highest-weighted operators sit in the active set that produces blocks at any given height.

What separates this network from a conventional single-environment chain is its co-chain arrangement. One validator set and one consensus process secure two execution environments that sit side by side: an Ethereum-compatible environment in which Solidity contracts run, and a Cosmos SDK environment whose state changes are typed module messages rather than contract bytecode and which speaks the Inter-Blockchain Communication protocol to other Cosmos networks. A translator component moves value and calls between the two. Because both environments advance inside the same block, they share a single transaction ordering and a single security budget, rather than being separate chains joined by a bridge.

Block production follows the round structure usual to this consensus family. A proposer is drawn for each height with a frequency weighted by bonded stake, and the remaining validators move through a pre-vote and then a pre-commit round. Once more than two thirds of voting power has pre-committed, the block is committed and treated as final at that moment; there is no confirmation depth to wait out and no reorganization of committed history while fewer than one third of voting power behaves adversarially. On the Ethereum-compatible side blocks arrive roughly every six seconds and are final at the first block. Accountability is economic: operators that sign conflicting blocks at the same height, or that miss too large a share of recent blocks, forfeit part of their bonded stake and are excluded from the active set until they are reinstated.

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

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

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

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

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

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

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

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.

Tezos runs a liquid proof-of-stake network on top of a classical Byzantine fault-tolerant agreement algorithm called Tenderbake, adapted from the Tendermint family. Validators, known on this network as bakers, are allocated the right to propose blocks and to attest them in proportion to their baking power, which is computed once per cycle from the funds they have frozen themselves, the funds other holders have frozen alongside them, and the balances merely delegated to them, with frozen funds weighted more heavily than delegated ones. Within a block's round a designated proposer publishes a candidate and a committee of attesters votes on it; agreement requires more than two thirds of the committee's weight. Finality is deterministic rather than probabilistic, arriving within a couple of blocks, and block intervals were shortened to six seconds by the amendment adopted in January 2026.

The liquid part of the design is delegation that does not move custody. A holder can point the weight of a balance at a baker without transferring the coins, without freezing them and without surrendering the ability to spend them; the baker gains voting weight but never control. A distinct and stronger commitment, staking, freezes funds alongside the baker's own and shares the baker's exposure to penalties, while plain delegation carries no such exposure. Bakers may accept external frozen stake up to a multiple of their own.

What most distinguishes the network is that it amends itself on chain. A proposed protocol change moves through five automatically scheduled voting periods, and if it carries it activates at the end of the last one without a hard fork, coordinated release or chain split; the code the network runs is replaced by the network itself. More than twenty amendments have taken this route. Recent ones reshaped consensus and its economics: the January 2025 amendment bounded issuance against a target staked ratio and raised the external stake limit, the May 2025 amendment shortened cycles to roughly a day and tied part of baker reward to data availability participation, the September 2025 amendment introduced aggregated attestation signatures, and the amendment active since June 2026 widened data availability bandwidth and made attestation lag dynamic.

TON is not a single chain but a hierarchy of them secured by one Byzantine fault tolerant proof-of-stake validator set. At the top sits the masterchain, which carries the protocol configuration, the current validator set and hash references to the latest state of everything beneath it. Below it are workchains, each able to define its own rules, of which one general-purpose chain is in operation. Each workchain is in turn divided into shardchains, and that division is dynamic: the count is always a power of two, a shardchain splits in two when its load grows and the halves merge back when it falls, and an account's address prefix decides which shard holds it at any moment. Describing this as a single-chain network would misstate it, as would treating the shards as independent chains, since the masterchain commits them all.

Agreement is reached by two layered protocols. The lower layer, Catchain, gives a validator group a signed, hash-linked message graph with dependency information, so broadcasts are reliably delivered and any attempt to fork is detectable. A block consensus protocol runs on top of it to agree the next block. Validators are partitioned into groups, each assigned to a shard or to the masterchain for a term, and a group's agreement is safe as long as fewer than a third of its members behave maliciously.

Selection runs through an election contract on the masterchain rather than a continuous ranking. Candidates submit an application carrying their keys and a stake in the native asset; applications clearing a configured minimum are ordered by stake and the set is taken down to a configured maximum, with a cap limiting how much weight any single large stake can carry relative to the smallest accepted. Terms are fixed-length rounds, after which a fresh election seats a new set, and a departing validator's stake stays frozen for a further period so that misconduct discovered late can still be answered for. Contracts interact only by asynchronous messages, which is what allows work to cross shard boundaries as they split and merge.

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.

Tether is present on the following networks: Aptos Coin, Avalanche, Celo, Ethereum, Kava, Kaia, Near Protocol, Solana, Tezos, Toncoin, 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.

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

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

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

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

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

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

Validators and the holders who delegate to them are the paid participants. Fee revenue from each block is spread across the active set in proportion to voting power, with an additional share to the proposer, and each operator passes on what remains to its delegators after deducting a commission rate it sets and publishes. Delegation lets holders contribute stake weight without running infrastructure, and it carries the matching downside: stake delegated to a penalized operator is reduced alongside the operator's own.

The material change in how all this is funded is that the protocol no longer issues new units to pay for security. Emissions were switched off at the start of 2024, the last inflationary issuance having been minted in the final block of 2023, and the protocol retains no mechanism to create further supply — only to destroy it. Rewards consequently come from two places: transaction fees collected in the ordinary course, and distributions out of a community-controlled on-chain treasury whose balance was set aside rather than printed. Ecosystem incentive programs that were once paid from new issuance are funded the same way, with governance deciding allocations and deciding whether any surplus is retired or redeployed. The reward budget is therefore a finite and governed pool rather than an open-ended subsidy, and the security of the network rests on fee revenue over the long run.

Users pay for execution in gas, denominated in the network's native asset on both co-chains. Contract execution in the Ethereum-compatible environment is metered per operation on the familiar opcode schedule, so computation, storage writes and contract deployment cost in proportion to the work they impose on every node; module messages on the Cosmos side are metered on an equivalent gas basis. Validators enforce a minimum acceptable gas price, and transactions offering more than that floor are ordered ahead of those that do not. Penalties form the counterweight: a fraction of bonded stake is confiscated for equivocation, a smaller penalty and temporary exclusion from the set apply to sustained unavailability, and stake withdrawn from bonding stays exposed through an unbonding period before it becomes transferable.

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

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

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

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

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

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

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

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.

Rewards on Tezos are paid for proposing blocks, for attesting them and for participating in the data availability layer, with a share of baker reward conditional on that last duty. Issuance is adaptive rather than fixed: the rate at which new units of the native asset are created moves within bounds according to how much of the supply is frozen, rising when the frozen proportion falls below a target of roughly half and falling as it rises above, so the protocol leans against both under- and over-participation instead of paying a constant rate. Three roles share the proceeds. A baker runs the infrastructure and takes a fee on what it distributes. A staker freezes funds alongside a baker, earns the higher rate and accepts the baker's penalty exposure. A delegator lends only weight, keeps its funds liquid, earns less and bears no penalty exposure at all.

Penalties are real and are applied to frozen funds. Signing two different blocks at the same level and round, or attesting two conflicting proposals, is denounced by evidence included on chain, and the offending baker's frozen funds, together with the frozen funds of those staking with it, are cut at the end of the cycle. Double baking draws a fixed proportion. Double attesting draws an adaptive proportion that grows with the square of the share of the committee that equivocated together, so an isolated accident costs little while a coordinated attack can consume the entire frozen balance. A fraction of what is taken rewards whoever included the evidence and the remainder is destroyed, and a denounced baker is barred from baking and attesting for a period. A baker that simply goes quiet is deactivated rather than penalized, and must reactivate to resume.

Users pay a transaction fee that scales with the size of the operation in bytes and the gas it consumes, and that fee goes to the block proposer. Storage is charged separately and permanently: allocating space in the ledger, originating a contract or creating a new account destroys an amount proportional to the bytes claimed rather than paying it to anyone. Smart contract execution is metered in gas against per-operation and per-block ceilings, and rollup and data availability operations carry their own costs.

Validators are paid from two sources. New units of the native asset are issued with each block, with a masterchain block carrying a larger subsidy than a block of the general-purpose workchain, and the subsidy for a shard is divided among the shardchains that result when it splits. On top of that, the fees collected during a validation round accumulate in the election contract. When a round closes and the frozen stakes are released, the contract distributes rewards in proportion to stake, so payment reaches a validator only after its term has ended and the window for complaints has passed. The minimum stake for a seat is high, so holders wanting to participate with less generally do so through nomination and staking pool contracts, which aggregate deposits behind an operator and return rewards after a commission.

Punishment is deliberate rather than automatic. There is no mechanism that confiscates stake the instant a fault occurs. Instead, a validator that failed to produce the blocks it was assigned can be reported by another validator, who constructs a proof of the omission, proposes a fine scaled to its severity and files it with the election contract; the validators of the current round then vote on the complaint, and if it is upheld the fine is deducted from the frozen stake of the accused. Most of what is taken is destroyed rather than redistributed.

Users pay several distinct fees rather than one. Storage is genuine rent: a contract accrues a charge for every second it occupies space, priced by the cells and bits it holds, settled whenever it is next touched, and a contract that exhausts its balance is frozen and eventually removed. Computation is metered in gas, forwarding fees pay for delivering messages between contracts and across shards with the charge split between the sending and receiving shards' validators, and further components cover inbound external messages and outbound actions. All of these prices are set in on-chain configuration parameters that validators change by vote, not by an auction among users, so costs are stable rather than demand-driven. Half of the fees collected are sent to an unspendable address and destroyed; validators keep the other half.

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.

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

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

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

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

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

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

The figure is built from the network's node population rather than from any metered reading taken across the network, which is the appropriate treatment for a stake-weighted Byzantine-fault-tolerant chain where the right to produce a block is not won by computational effort. The estimation approach used here begins by establishing how many machines take part. The active and standby validator set is enumerated from public chain state, and the wider population of full, archive and public endpoint nodes is approximated using network crawlers alongside publicly listed infrastructure. A representative hardware profile is then inferred from the specifications the client software states for running a node that can keep pace with the chain, and the electrical draw of machines matching that profile comes from laboratory measurement, recorded both under load and at rest. Aggregating that draw across the estimated population over the reporting period, with idle hours counted rather than assumed away, gives the network total.

The co-chain arrangement matters to this calculation. Since one validator set and one consensus process advance both the Ethereum-compatible and the Cosmos-side environments inside the same block, there is no second node population to add for the contract environment. Counting the validator and node set once captures both, and treating the two environments as though they were distinct networks would double the result.

Several limits should be read alongside the output. The node count and the hardware mix are inferences drawn from public observation and from stated software specifications, not readings taken from the machines themselves, and operators are under no obligation to disclose what they run. Where the evidence is thin, the assumptions chosen sit at the cautious end, so the result is likelier to overstate consumption than to understate it. Figures are restated as observation of the node population improves or as client specifications change. Where an asset is issued across more than one network, the portion attributed to each is derived from observed on-chain transfer volumes rather than divided evenly between them.

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

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

Two limitations apply throughout. This is a reconstruction from public records and stated software requirements rather than a metered reading of anyone's equipment, and operators in practice deploy machines that differ from the published specification in both directions. Where evidence is missing, the assumption chosen is the one producing the larger number, so the estimate is likelier to overstate the impact than understate it, and figures are revised as observation improves. The share of the network total attributed to an individual asset issued on the chain is set by that asset's observed on-chain transfer activity as a proportion of all activity on the network.

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

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

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

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

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

Because this is a stake-based network with no computational race, the energy estimate is constructed from the machines that keep it running rather than from any model of mining economics. The relevant population is more varied than a single validator count suggests: bakers and the attesting infrastructure behind them, the accompanying nodes that serve and sample the data availability layer, the nodes operating smart rollups, and the ordinary full nodes that relay and validate without taking part in consensus. Their number is estimated from publicly observable network data, from peer crawling, and from on-chain records of which addresses hold baking rights, which makes the consensus-active portion of the population unusually well bounded even though the servers behind those addresses are not directly enumerable.

Hardware is inferred rather than surveyed. The published operating requirements for the node software, covering processor, memory, disk and bandwidth, indicate what a competent operator would deploy, and the electrical draw of machines of that class is taken from controlled bench measurement at load and at rest rather than from nameplate figures. The annual total is the aggregate across the estimated population including idle draw, since a baking node consumes power continuously regardless of how often it is called on. Where a token issued on this network is being reported rather than the network itself, a portion of the network total is attributed to it using observed on-chain transfer volumes.

Two caveats are specific to this network. Its capabilities are extended by on-chain amendment, and successive amendments have changed cycle length, block interval, attestation duties and data availability bandwidth; each of those alters what a node must store, verify and transmit, so a hardware profile inferred before an amendment can understate requirements after it. Separately, a baker may run several machines for redundancy and signing separation, which a public count of endpoints will not reveal. More broadly, the population and hardware mix are estimates from public observation, not metered readings; where evidence is thin the assumption chosen is the one more likely to overstate consumption than understate it; and figures are restated as observation improves.

The figure reported for this network is an estimate constructed from the machines that run it, not a metered reading. It begins with the population of participating nodes and works upward from the power each is expected to draw.

Establishing that population takes account of the network's structure. The validator set is elected on-chain for fixed terms and its size and membership can therefore be read directly from publicly observable network data at any point in a round, but validators are only part of the picture. They are partitioned into groups covering the masterchain and each shardchain, and the number of shardchains changes as load causes them to split and merge, so the work carried per machine is not constant across a reporting period. Beyond consensus, the network depends on nodes that keep full or partial history and on the query-serving infrastructure that applications rely on; those are estimated from peer discovery, published operator information and automated crawling, since they are not enumerated on-chain.

The second input is per-machine draw. A representative hardware profile is inferred from the resources the node software states it needs, covering processor, memory, disk and bandwidth, and power consumption is attributed from laboratory measurement of equipment matching that profile. The minimum stake for a seat is substantial and terms are contested, so validator infrastructure is assumed to be server-grade and continuously online; draw is counted on that basis, idle time included, and multiplied across the estimated population.

The limits are worth stating plainly. Both the count and the hardware mix are inferences from public observation and from stated requirements rather than from surveys or meters. The supporting non-consensus infrastructure is the least observable component, and the shifting shard count adds variability that a snapshot does not capture. Where evidence is missing, assumptions are chosen so that the impact is more likely to be overstated than understated, and the estimate is revised as observation of the network improves and as its topology changes.

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.

Tether is present on the following networks: Aptos Coin, Avalanche, Celo, Ethereum, Kava, Kaia, Near Protocol, Solana, Tezos, Toncoin, 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 derived geographically rather than measured at the socket. The first step is to locate the machines doing the work: the sequencing and proposing infrastructure, the full nodes and public endpoint servers, and the operators of the external data availability layer the network depends on. Locations are inferred from publicly observable network data, principally the addresses peers advertise and the hosting providers and regions those addresses resolve to. Coverage is never complete; operators sitting behind relays or content delivery networks cannot always be placed. Where a meaningful part of the population cannot be located directly, the geographic distribution of a network whose operator profile and hosting economics resemble this one is used as a stand-in, on the reasoning that similar incentives produce similar siting decisions.

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

Energy intensity carries a specific meaning here. It is the marginal energy attributable to one additional transaction, obtained by dividing estimated consumption over a reporting period by the transactions confirmed in that period. It is not a physical measurement of any individual transaction, and on infrastructure that draws power largely independently of how busy it is, the number is best read as an allocation of shared overhead: it falls as activity rises without any machine using less electricity. Regional generation data is drawn from Share of electricity generated by renewables, compiled by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy.

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

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

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

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

The renewable share is derived geographically. Node locations are inferred from publicly observable network data — the addresses peers advertise, the hosting ranges those addresses fall within, and operator disclosures that are already public — and each located node is assigned to the electricity grid of the region it sits in. Aggregating those assignments produces a weighted picture of which grids the network's infrastructure actually draws on, which is the input the renewable calculation needs.

Coverage is never complete. A meaningful share of nodes sits behind hosting arrangements or privacy configurations that reveal nothing dependable about physical location. The co-chain arrangement does not complicate this, because the same machines serve both execution environments and so are located once. Where a network's own geographic spread cannot be observed to a usable standard, the spread of a structurally similar network is substituted as a stand-in — one chosen for a comparable validator economy, a comparable cost of entry for node operators, and therefore a comparable hosting pattern. That substitution is a source of uncertainty in its own right and is applied only to the portion that cannot be resolved directly.

Grid assignments are then matched against published statistics on how electricity is generated in each region, yielding the proportion of the network's electricity that comes from renewable generation. Those statistics are 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.

Energy intensity is a separate quantity and should not be read as a per-transaction bill. It is defined at the margin: the additional electricity drawn as a consequence of one further transaction being processed, given the infrastructure already running. On a network of this kind, where validators run continuously and commit blocks on a fixed cadence whether or not demand is present, that marginal quantity is small next to the standing consumption, and it moves inversely with throughput — the busier the network, the lower the intensity attributed to each transaction.

The renewable share is not recorded by the protocol, so it is inferred from where the machines stand. Reachable nodes advertise network addresses, and those addresses are resolved to a country through public address-allocation registries, yielding a distribution of the node population across jurisdictions rather than a list of physical sites. The method has known weaknesses: addresses can be proxied, they can belong to hosting providers registered in one country while the equipment sits in another, and machines behind firewalls never present themselves to a crawler.

This network is better placed than most for the first step. Its validators are named institutions that publish their participation, and several concentrate in particular countries, so a substantial part of the consensus layer can be located with more confidence than a purely address-based inference would give. The endpoint and service-chain layers are a different matter, being operated by a wider and less visible set of parties. Where a portion of a population cannot be placed with enough confidence, the geographic profile of a structurally similar network is substituted, selected because its participants face a comparable cost structure and a comparable reason to run a node, on the reasoning that like incentives put operators in like places.

Each jurisdiction in the resulting distribution is matched to published statistics on how its electricity is generated, and the renewable proportion for the network is the share-weighted average across those jurisdictions. The generation statistics come from Share of electricity generated by renewables, compiled by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy. These are annual national figures, so they cannot represent an individual data center's supply arrangements or the hour of day at which the load actually fell.

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

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

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

Those locations are then matched to regional electricity statistics. Each machine is associated with the grid serving its location, and the renewable proportion of that grid's generation is applied, weighted by the share of estimated consumption sitting in each region. The result is a consumption-weighted renewable share for the network as a whole, which moves both when operators relocate and when the underlying grids change from year to year.

Energy intensity is reported alongside it and means something narrow: the marginal energy associated with processing one further transaction. Because most of this network's consumption is the fixed cost of keeping validators online rather than anything proportional to throughput, that marginal figure falls as activity rises, and it should not be read as an average cost per transaction. Grid statistics come from Share of electricity generated by renewables, compiled by Our World in Data with major processing from Ember and from the Energy Institute's Statistical Review of World Energy.

The renewable share is derived 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 share follows from where the hardware sits, so the first task is placing it. Locations are inferred from publicly observable network information: the addresses nodes advertise to peers, the autonomous systems and hosting providers those addresses belong to, and what operators publish about themselves. Many bakers are publicly identified services that state where they operate, which helps, but the address of a node still identifies a facility rather than an owner, and it is the facility that draws current from a grid, so hosting location takes precedence over any nationality attributed to the operator.

The picture is inevitably partial. Signing infrastructure is commonly kept off the public network behind a remote signer, redundant machines are not separately visible, and nodes that accept no inbound connections cannot be observed at all. Where the geographic spread cannot be pinned down from the network's own data, the distribution observed on a network with a comparable operating profile stands in for it, selected for similar participation requirements, similar operator incentives and similar hosting behavior. That substitution is the largest single source of uncertainty in the renewable figure and a reason it is less firm than the consumption estimate beneath it.

Locations are then weighted by the consumption attributed to them and matched against regional electricity statistics, so each part of the network's draw inherits the generation mix of its supplying grid. The renewable proportion reported is that consumption-weighted average, which is not the same as the proportion of nodes situated in countries with clean grids. The underlying statistics are annual averages and carry no hourly resolution, so time-of-day variation in the mix is invisible to the method.

Energy intensity is expressed at the margin: the extra electricity associated with one additional transaction at the network's current node population and throughput. Since these nodes run continuously and their draw hardly varies with how busy the chain is, that marginal quantity is small and shrinks as throughput grows, a consequence of how the measure is defined rather than a change in the machines. Regional generation mix is drawn from Share of electricity generated by renewables, compiled by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy.

The renewable share attributed to this network is derived from where its machines physically sit, not from any claim about the electricity its operators procure. Placement is inferred from publicly observable network data: the addresses nodes announce to their peers, information operators publish about themselves, and the hosting providers and data-center address ranges those addresses belong to, gathered by automated crawling of the peer network.

Two features of this network shape that exercise. The validator set turns over at the end of each election round, so the population being located is not the same from one term to the next and has to be observed repeatedly rather than fixed once. And because validators are grouped across a masterchain and a shifting number of shardchains, the geographic weighting reflects where machines are rather than which chain a given machine happened to serve. Coverage is still incomplete, since some operators sit behind relays or cloud infrastructure that conceals the underlying site. Where the observed spread is too thin to rely on, the distribution of a structurally similar network is substituted, chosen because its participants face comparable incentives and carry comparable duties and can be expected to cluster in broadly the same regions.

Each located machine is then matched to the grid that serves it, and the renewable proportion of that grid's generation is applied, weighted by the share of estimated consumption in each region. The outcome is a consumption-weighted renewable share for the network, which changes when operators move and when national generation mixes change from year to year.

Energy intensity is reported alongside it with a narrow meaning: the marginal energy associated with one further transaction. Because almost all of the consumption is the fixed cost of keeping elected validators online, rather than anything that scales with throughput, this marginal figure falls as activity rises and should not be read as an average cost per transaction. Grid statistics come from Share of electricity generated by renewables, compiled by Our World in Data with major processing from Ember and from the Energy Institute's Statistical Review of World Energy.

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

Tether is present on the following networks: Aptos Coin, Avalanche, Celo, Ethereum, Kava, Kaia, Near Protocol, Solana, Tezos, Toncoin, 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 derived from the same geographic picture used for the energy figures, with carbon intensity substituted for renewable share. Machine locations are inferred from publicly observable network data covering the sequencing and proposing infrastructure, the full node and public endpoint population, the operators of the external data availability layer, and the portion of the settlement chain's operator base that carries this network's traffic. Where part of that population cannot be placed directly, the distribution of a structurally comparable network is used in its stead, and the resulting uncertainty is carried into the estimate rather than hidden in it.

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

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

Greenhouse gas intensity is the marginal emission attributable to one additional transaction, obtained by allocating the total across the transactions confirmed in the same period. Like its energy counterpart it is an allocation of shared overhead rather than a property of any single transaction, and it moves when grid factors move or when the composition and location of the infrastructure change, not only when network behavior does. Grid carbon intensity values come from Carbon intensity of electricity generation, compiled by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy and made available under the Creative Commons Attribution 4.0 license.

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

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

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

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

Emissions are derived from the same geographic work that supports the energy figures, applied against a different coefficient. Once the node population has been located and assigned to regional grids, each assignment is matched to the carbon intensity of electricity generation in that region — the mass of carbon dioxide equivalent released per unit of electricity delivered — and the network's estimated consumption is apportioned across those regions and converted. Regional variation is wide enough that two networks consuming identical amounts of electricity can differ substantially in emissions, which is why locating the infrastructure carries as much weight in the result as sizing its draw.

The two scopes are treated differently. Scope 1 covers emissions from sources the operators control directly, such as fuel burned on site for backup generation, and for a network of this design it is negligible or zero, since validators run commodity servers on purchased electricity rather than any combustion process of their own. Scope 2 covers the indirect emissions embodied in that purchased electricity and accounts for effectively the whole of the result. Where a node's location cannot be established with confidence, the regional profile of a structurally comparable network stands in for it, and that substitution 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 mirrors the definition used for energy intensity: the additional emissions attributable to one further transaction beyond those already being processed, rather than total emissions divided by a transaction count. Because the infrastructure runs continuously regardless of load, that marginal quantity is modest and falls as utilization rises. Results are restated when regional grid statistics are updated or when better observation of the node population becomes available, and the direction of any assumption made under uncertainty favors the higher estimate.

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

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

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

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

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

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

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

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

Emissions 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 figures are calculated, not metered. Each geographically attributed slice of the network's estimated electricity use is multiplied by the carbon intensity of the grid serving that location, using the same placement of nodes that supports the generation-mix analysis: advertised addresses and hosting registrations locate consumption, a structurally comparable network fills the gaps where placement cannot be established, and the result is a consumption-weighted distribution across grids rather than a tally of nodes by country.

Reading the result depends on understanding the scope split. Scope 1 captures emissions from sources the infrastructure operators control directly, essentially fuel combusted on site in backup generation. Bakers, rollup operators and data availability nodes run on general-purpose servers in commercial data centers and offices rather than on dedicated industrial equipment, so direct combustion attributable to the network is negligible and the scope 1 figure is reported as effectively nil. Scope 2 captures the indirect emissions embodied in the electricity those servers purchase and accounts for practically the whole footprint. It is derived on a location basis from average grid intensity, not on a market basis, because renewable energy certificates or power purchase agreements held by individual operators leave no trace in network data and cannot be verified from outside.

The boundary excludes emissions embodied in manufacturing and eventually disposing of the hardware, and it excludes the electricity used by wallets, indexers, explorers and applications built on the chain, which are counted against those services rather than the network. Carbon intensities are annual averages, so seasonal and daily variation in a grid's mix is not represented, and every uncertainty in locating nodes carries straight through into the emissions result.

Greenhouse gas intensity is stated as a marginal figure, the additional emissions attributable to one further transaction at the present node population and throughput; because the consumption behind it is close to fixed, that figure falls as activity rises and should not be read as an efficiency measurement. Carbon intensity values 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 CC BY 4.0 license.

Emissions are derived by combining the network's estimated electricity use with the carbon content of the grids that supply it. The energy total is first apportioned geographically, using the same picture built for the energy analysis: node addresses observed on the peer network, operator information published openly, and the hosting ranges those addresses resolve to. Because the validator set is re-elected at the end of each round, that apportionment is rebuilt over the reporting period rather than taken from a single observation. Where placement cannot be resolved, the distribution of a structurally comparable network is used instead, selected for similar incentives and similar validation duties rather than for similar size.

Each portion of consumption is then multiplied by the carbon intensity of the grid serving its region, expressed as emissions per unit of electricity generated, and the parts are summed. The result therefore depends as much on where operators host as on how much electricity the network draws, and it shifts year to year as national generation mixes change and as the elected set turns over.

Two scopes are reported separately. Scope 1 covers emissions from sources the operators control directly, such as fuel burned on site; for infrastructure of this kind it is effectively nil, because the machines are commodity servers drawing grid power in facilities run by third parties. Scope 2 covers the indirect emissions embodied in the electricity purchased to run that infrastructure, and it accounts for essentially the entire footprint. Emissions from manufacturing the hardware and from building and cooling the facilities housing it fall outside both scopes and are not included.

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

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.