USD1 (USD1) sustainability report

USD1 is present on the following networks: Aptos Coin, Binance Smart Chain, Ethereum, Plume, Solana, 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.

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

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

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

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

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

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

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

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

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

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

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.

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.

USD1 is present on the following networks: Aptos Coin, Binance Smart Chain, Ethereum, Plume, Solana, 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.

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

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

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

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

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

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

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

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

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

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

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.

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.

USD1 is present on the following networks: Aptos Coin, Binance Smart Chain, Ethereum, Plume, Solana, 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

USD1 is present on the following networks: Aptos Coin, Binance Smart Chain, Ethereum, Plume, Solana, 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

USD1 is present on the following networks: Aptos Coin, Binance Smart Chain, Ethereum, Plume, Solana, 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.

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

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

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

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

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

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

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

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

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

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

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

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

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