VNX Swiss Franc (VCHF) sustainability report

VNX Swiss Franc is present on the following networks: Base, Celo, Ethereum, Internet Computer, Solana, Stellar, Tezos.

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

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

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

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.

The Internet Computer is not a single chain. It is a collection of subnets, each one a replicated state machine run by its own committee of node machines and each running its own instance of the consensus protocol over the messages routed to it. Smart contracts, called canisters, are assigned to a subnet; the protocol carries messages between subnets and runs consensus on every hop, so that many chains present themselves to an application as one.

Within a subnet, agreement proceeds in rounds. A shared random beacon, produced jointly by the subnet's replicas, assigns them a fresh ranking each round. The highest-ranked replica proposes a block, and lower-ranked replicas step in only if that proposal fails to appear in time, which keeps the common case to a single proposal per round. Replicas notarize a block they judge valid, a notarization requiring signature shares from more than a supermajority of the committee, and a notarized block is then finalized by a second threshold signature that a replica contributes only if it notarized no competing block in that round. Finality is cryptographic rather than probabilistic: a finalized block has no surviving rival and the state it produces is settled at once, typically within a second or two, so long as fewer than a third of the subnet's replicas are faulty. Safety does not rest on any assumption about how promptly messages arrive.

The binding element is chain-key cryptography. A subnet's replicas jointly hold a threshold key that exists nowhere in complete form; the shares are generated by a distributed protocol and re-shared whenever membership changes, so the subnet's public key stays constant while the machines behind it rotate. A client can verify a response against that single public key without replaying the chain, subnets can authenticate messages to one another, and canisters can hold and sign for assets on external chains. Membership is decided by governance rather than by open entry: a network-wide governance system, controlled by voters who have locked the native asset, admits node machines, composes them into subnets and deploys protocol upgrades to them.

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.

Stellar reaches agreement through the Stellar Consensus Protocol, an implementation of federated Byzantine agreement. It is neither proof of work nor proof of stake: nothing is mined, nothing is bonded, and holdings of the native asset confer no voting weight whatsoever. What decides influence is trust that each operator declares for itself. Every validating node publishes a quorum set naming the other nodes it is willing to rely on, together with thresholds over that set. Any subset of a node's quorum set that meets its threshold is a quorum slice, and a quorum is a group of nodes that contains a slice for each of its members. There is no global register of validators and no authority that admits or expels one; a node joins the system in practice only when enough existing operators choose to name it.

Safety rests on quorum intersection. If the quorum sets operators have chosen overlap sufficiently, no two quorums can commit conflicting values and the ledger cannot fork. If they overlap too little, the guarantee lapses, which makes configuration choices and the diversity of operators the real security parameter. The protocol is deliberately biased toward safety over liveness: when trust fails to intersect or too many nodes disagree, the network stops closing ledgers rather than producing divergent histories. Concentration is the corresponding risk, since a small number of widely trusted operators sit in most quorum sets.

A ledger closes in two phases. Nomination runs a federated vote until candidate values converge and are combined into a single composite value, and the ballot protocol then runs prepare and commit rounds until a value is externalized. Ledgers close every few seconds and an externalized ledger is final immediately. Operators run validators that either publish a full history archive or do not, and organizations expected to anchor the trust graph run several geographically separated archive-publishing nodes. Protocol versions are adopted by validator vote; recent ones added parallel smart contract execution, moved contract state into memory, and introduced a consensus-maintained mechanism for freezing specified ledger entries.

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.

VNX Swiss Franc is present on the following networks: Base, Celo, Ethereum, Internet Computer, Solana, Stellar, Tezos.

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

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

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

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

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.

The distinctive feature of this network's fee model is that the party making a request usually pays nothing. Computation and storage are charged to the smart contract rather than to its caller. Each canister holds a balance of cycles, a resource unit created by burning the network's native asset through a system contract at a rate pegged to an external basket-of-currencies reference, so the price of compute stays stable in real terms while the quantity of the asset consumed varies. That balance is drawn down continuously for the memory the canister occupies and again on every request that changes its state; a canister whose balance runs out is frozen and stops answering until it is topped up. Funding responsibility therefore sits with whoever operates an application, and an end user can interact with one without holding the asset, without a wallet and without approving anything. The exception is a direct transfer of the native asset on its ledger, which carries a small fixed charge that is destroyed rather than paid to anyone.

Payment flows to the parties providing hardware. Independent node providers operate machines of a specified standard in data centers and are compensated in newly issued units of the native asset. Their entitlement is denominated in an external unit of account and converted at a trailing average rate when issued, so compensation tracks real operating cost rather than the asset's market movements. The rate per machine varies with hardware generation, with the country the machine sits in, and with how many machines the same provider already runs, the last of these deliberately reducing the marginal payment so that ownership does not concentrate. Payment is conditioned on work performed: a machine's share is scaled by how reliably it produced the blocks its turn called for, subject to a floor below which the scaling does not fall, and a machine held in reserve outside any subnet is paid at the average performance of its provider's active machines.

Separately, holders of the native asset may lock it in the governance system to vote on proposals, from protocol upgrades to network topology, and receive newly issued units for voting. Rather than a confiscable bond, the lever on a node provider is the reward itself, which underperformance reduces.

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.

Stellar pays nobody for running the network. There are no block rewards, no staking rewards and no protocol-level payment to validators of any kind, and the inflation mechanism that once distributed new units of the native asset was switched off by validator vote in 2019 and has not been replaced. Transaction fees are not routed to whichever node closed the ledger; they accumulate in a network-wide fee pool that is not redistributed to anyone. The incentive to operate a validator is therefore indirect and institutional: the businesses that run them, payment providers, asset issuers, custodians and infrastructure operators, depend on the ledger continuing to close and on its trust graph remaining diverse, so they carry the cost themselves. The consequence is that participation is sustained by who chooses to show up rather than by a yield, which concentrates responsibility on a comparatively small set of organizations.

Fees are charged per operation rather than per transaction, so a transaction bundling several operations pays a multiple of the per-operation rate. The network minimum is one hundred stroops, a hundred-thousandth of a unit of the native asset, and validators can vote to change that floor. When more operations are submitted than a ledger can hold, surge pricing turns inclusion into an auction: a submitter states the maximum it will pay per operation, competing transactions are ranked, and those included are charged the lowest amount that would still have secured a place rather than the maximum bid, with the rest of the offered fee not taken.

Ledger space is rationed by reserves rather than rent. An account must hold a minimum balance of two base reserves, and each subentry it adds, a trustline for an issued asset, an offer on the order book, an extra signer or a data entry, raises that minimum by a further reserve. Reserved balance is locked rather than destroyed and is released when the subentry is removed, and one account can sponsor another's reserves. Smart contracts, added to the network in 2024, are priced separately: a resource fee meters processor instructions, ledger reads and writes and bandwidth, part of it refunded for resources not consumed, and contract state carries a time-to-live that must be extended by paying rent or the entry is archived and must be restored before use.

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.

VNX Swiss Franc is present on the following networks: Base, Celo, Ethereum, Internet Computer, Solana, Stellar, Tezos.

The estimate for this network has two components, and they are constructed differently.

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

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

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

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.

Energy use on the Internet Computer is estimated from the machines that run it rather than read from a meter. The approach establishes how many node machines are operating, infers the hardware behind them, attaches a measured power draw to that hardware and aggregates over the reporting period. Because nothing in the protocol ties electricity spent to reward earned in the way mining does, the profitability modeling used for proof-of-work networks has no counterpart here and is not used.

Two features make the population more directly observable than on an open network. Node machines are admitted by governance and recorded in an on-chain registry, so they can be counted rather than approximated from crawler sweeps, and the registry associates each machine with a provider and a data center location rather than only an address. What that does not give is the internal configuration: the hardware specification is a published standard for the machine class, and the estimate takes processor, memory and storage counts from that specification together with laboratory measurement of comparable equipment. The architecture also affects the shape of the answer. Each subnet replicates the same computation across its whole committee, so consumption scales with the number of machines and subnets rather than with how much work users generate, and machines admitted to the registry but not currently assigned to a subnet still draw power. Idle and standby draw is therefore counted, and the boundary between machines inside and outside subnets has to be stated rather than assumed.

The result is an estimate. Machine counts and locations are read from public records, but utilization, power supply efficiency and the overhead of the facilities housing the machines are inferred rather than measured, and facility overhead in particular can be a material share of the total for rack-mounted equipment in data centers. Where evidence is missing, the assumptions chosen raise the figure rather than lower it, so the published number reads as a conservative ceiling and is revised as observation improves.

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 estimate is built up from the machines that operate the network, which suits a design where consensus is reached by exchanging votes rather than by expending computation, and where no participant gains anything by adding hardware. The population to be counted is comparatively small and unusually legible: validators name each other in published quorum sets, and operators are expected to publish organizational and node information at well-known locations, so the consensus-relevant set can largely be enumerated from the network's own configuration instead of being inferred statistically. Around that core sit watcher nodes that follow the ledger without voting, and the object storage that serves history archives for nodes catching up.

Hardware is inferred from the stated operating requirements of the core software, which specify processor, memory, disk and bandwidth, and the power draw of machines meeting those specifications is taken from controlled bench measurement at load and at rest rather than from vendor ratings. Consumption is aggregated across the estimated population with idle draw included, because a validator runs continuously whether or not the network is busy. A share of the network total is attributed to a particular asset issued on the ledger, when one is being reported rather than the network itself, using observed on-chain transfer volumes.

Several caveats apply. The enumeration captures validating nodes well but non-validating infrastructure poorly, and history archives are served from object storage whose energy use belongs to a storage provider and is difficult to apportion; archive bandwidth is the largest and most variable element of an operator's cost, and it is estimated rather than observed. Nodes are overwhelmingly cloud-hosted, so a logical node cannot reliably be mapped to a physical machine, and protocol changes that raise in-memory state requirements or enable parallel execution alter the hardware profile an operator must provision. The population and hardware mix are estimates assembled from public observation and published requirements, not metered readings; where evidence is missing the assumption chosen is the one more likely to overstate consumption than understate it; and figures are revised as observation improves.

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.

VNX Swiss Franc is present on the following networks: Base, Celo, Ethereum, Internet Computer, Solana, Stellar, Tezos.

The renewable share reported for this network is a weighted average of the electricity mixes of the grids its infrastructure draws on, assembled in two steps: establish where the machines are, then attach regional generation statistics to those places.

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

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

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

The renewable share reported for 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 reported for the Internet Computer follows from locating the hardware. Node machines are recorded in an on-chain registry that names the provider and the data center behind each one, so a large part of the geographic picture is available from the network's own records rather than inferred from network traffic. Advertised network addresses, public network data and registry records fill in the remainder, and where part of the population still cannot be placed, the geographic distribution of a structurally similar network, meaning one whose participation rules and operating incentives resemble this one, stands in for the missing portion.

Located capacity is then matched to the electricity mix of the grid that serves it. National generation statistics give the proportion of electricity produced from renewable sources in each country, and weighting those proportions by the consumption estimated to sit in each country yields the renewable share for the network as a whole. The construction has known limits. It describes the grids the machines sit on rather than any electricity an operator has contracted for on its own account, and because the payment schedule for providers varies by country, the geographic spread of the machines can shift for reasons that have nothing to do with energy, carrying the renewable share with it.

Energy intensity is reported alongside the share and is narrower than an average. It is a marginal quantity: the additional electricity attributable to one further transaction, with the installed infrastructure held constant. On this network the distinction matters more than usual, because capacity is provisioned as whole machines and whole subnets that run continuously regardless of demand, so the marginal value is small, the average value is driven by how much of the provisioned capacity is being used, and the two can move in opposite directions between reporting periods. The grid statistics behind these calculations are taken from Share of electricity generated by renewables, compiled and processed by Our World in Data from Ember and from the Energy Institute's Statistical Review of World Energy.

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

Establishing a renewable share means first establishing where the hardware draws its power. This network is comparatively favorable to that exercise, because validators are named in one another's published quorum sets and operators are expected to publish identifying information about themselves and their nodes, so the organizations behind much of the infrastructure and the regions they operate in can be read from public sources rather than guessed. Advertised network addresses, autonomous system registrations and hosting-provider allocations resolve the remainder to a country or region. Since almost all of this infrastructure is cloud-hosted, the facility's location is what determines the grid supplying it, and hosting location is used in preference to the operator's home jurisdiction.

Gaps remain. Non-validating nodes are not systematically observable, an organization running several separated nodes may not disclose all of their locations, and archive storage may sit in a different region from the validator that publishes to it. Where the geographic spread cannot be established from public data, the distribution seen on a network with a comparable operating profile is substituted, selected for similar participation requirements and similar hosting behavior rather than for any resemblance in how consensus is reached. That substitution is the main source of uncertainty in the renewable figure.

Locations are weighted by the consumption attributed to each and matched against regional electricity statistics, so every portion of the network's draw inherits the generation mix of its supplying grid, and the renewable proportion is the consumption-weighted average of those mixes. It is not a count of how many nodes sit in countries with clean grids, and because the statistics are annual averages the method has no visibility into variation across hours or seasons.

Energy intensity is reported at the margin, as the additional electricity associated with one further transaction given the current node population and the throughput being carried. With nodes running continuously and drawing much the same power whether the ledger is full or nearly empty, that marginal quantity is small and declines as throughput grows, which reflects the definition of the measure rather than any change in the equipment. Regional generation mix comes from Share of electricity generated by renewables, compiled by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy.

The renewable share follows from where the 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.

VNX Swiss Franc is present on the following networks: Base, Celo, Ethereum, Internet Computer, Solana, Stellar, Tezos.

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

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

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

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

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.

Location evidence here is stronger than for any comparable network, because the network keeps the record itself. Every machine admitted to serve is entered in an on-chain registry naming the provider responsible for it and the data center in which it stands. Emissions accounting therefore opens not with a crawl but with a read: the registry supplies a machine census with facility-level placement, and only the gaps around it, an ambiguous country or capacity added between registry updates, need the ordinary treatment of resolving announced addresses or borrowing the profile of a network with similar operating economics.

That precision meets a coarser instrument at the next step. The coefficient applied to each unit of electricity is a national average for greenhouse gas released per unit generated, stated in carbon dioxide equivalent, so a facility identified by name is still scored by the mix of the whole country around it. Estimated consumption per country multiplied by that country's coefficient, then summed, yields the total. Two features of this network make the country weights unstable. Capacity is provisioned as whole machines organized into replicated subnets that run continuously, so emissions follow the installed base rather than demand; and what providers are paid differs by region, which means machines migrate for commercial reasons and carry the emissions weighting with them.

The scopes divide as they usually do for server infrastructure. Direct emissions, meaning combustion under the operators' own control, are nil for racks in commercial halls on a public grid, and that nil is a determination rather than an unfilled field. Indirect emissions carried in the purchased electricity account for everything else, and therefore for the figure as a whole. Building the machines and the halls lies beyond this boundary.

Emissions intensity per transaction is defined at the margin, as what one additional message costs with the machine base unchanged. On a network sized by provisioned capacity rather than by load, that marginal quantity stays small while the average quantity moves with utilization, so the two can point in opposite directions from one reporting period to the next and should not be conflated. Coefficients come from Carbon intensity of electricity generation, prepared by Our World in Data from Ember and from the Energy Institute's Statistical Review of World Energy and published 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 are derived from the consumption estimate rather than measured directly. Each geographically attributed portion of the network's electricity use is multiplied by the carbon intensity of the grid supplying that location, using the same placement of infrastructure that underpins the generation-mix analysis: published operator and node information together with advertised addresses and hosting registrations locate most of the consumption, a structurally comparable network stands in where placement cannot be determined, and the outcome is a consumption-weighted distribution across grids rather than a count of nodes per country.

The scope split shapes how the numbers should be interpreted. Scope 1 covers emissions from sources the operators control directly, which for this kind of infrastructure means fuel burned on site, essentially backup generation. Validators and archive servers are general-purpose machines in commercial data centers rather than dedicated industrial plant, so direct combustion attributable to the network is negligible and the scope 1 figure is reported as effectively nil. Scope 2 covers the indirect emissions embodied in the electricity purchased to run that equipment and represents virtually the entire footprint. It is calculated on a location basis from average grid intensity rather than on a market basis, because renewable energy certificates and power purchase agreements procured by individual operators or by their cloud providers cannot be verified from public network data and are therefore not credited.

What falls outside the boundary should be explicit. Emissions embodied in manufacturing, transporting and retiring the hardware are excluded, as is the electricity consumed by wallets, anchors, explorers and applications that use the ledger, which belongs to those services. Grid carbon intensities are annual averages, so variation within a year is not represented, and uncertainty in locating the infrastructure propagates directly into the emissions estimate.

Greenhouse gas intensity is expressed as a marginal quantity, the additional emissions attributable to one further transaction at the present node population and throughput. Because the consumption behind it barely responds to load, that quantity falls as activity rises and is not 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 made available under the CC BY 4.0 license.

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.