EURØP (EUROP) sustainability report

EURØP is present on the following networks: Avalanche, Ethereum, Polygon, Solana, Ripple.

Avalanche's Primary Network is not a single chain but three, each specialized and all validated by the same set of operators. The contract chain hosts smart-contract execution in an Ethereum-compatible environment and is where most applications and issued assets live. The exchange chain handles asset creation and transfers. The platform chain tracks the validator set, staking, and the registration of the sovereign networks that run alongside the Primary Network.

Agreement across all three comes from the Snow family of protocols, which reaches consensus through repeated randomized sampling rather than through the round-based voting of classical Byzantine fault tolerant designs. There is no leader gathering votes from the entire validator set. Instead each node repeatedly asks a small random sample of validators what they currently prefer, adopts whichever answer carries a sufficient majority of that sample, and accepts a decision once it has seen enough consecutive samples agree. Because a node queries a fixed-size sample rather than everyone, the messaging load per node barely grows as the validator set grows, which is what allows the set to be large without consensus becoming the constraint.

Snowman is the variant used for linearly ordered chains, and Snowman++ layers a proposer schedule over it: block-building windows are assigned to proposers in proportion to stake, with production opening more widely if a designated proposer fails to act, which limits contention without introducing a fixed committee. Sampling remains the voting mechanism throughout. An earlier design in which the exchange chain ordered transactions as a directed acyclic graph was retired in 2023 when that chain was linearized, and the whole Primary Network now runs on the same linear engine.

Acceptance is fast, typically under a second, and once a decision is accepted the protocol treats it as irreversible. Formally the guarantee is probabilistic: sampling parameters can drive the chance of two conflicting decisions both being accepted arbitrarily close to zero, but not to exactly zero, which is a different kind of statement from the deterministic finality a quorum-certificate protocol offers. Validators join the Primary Network by bonding the native asset for a chosen term, holders may delegate to them, and the protocol does not slash bonded principal.

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.

Polygon PoS is an EVM-compatible proof-of-stake network that runs its own validator set and anchors itself to Ethereum by posting periodic checkpoints there. It should not be confused with the other chains that have carried the Polygon name: the zero-knowledge rollup operated under that brand was shut down in 2026, and chains built with Polygon's development kit are independent networks with their own validators. Polygon PoS executes transactions and holds its own transaction data, so it is a sidechain or commit-chain rather than a rollup inheriting Ethereum's execution and data-availability guarantees.

The architecture splits into two node layers that every validator runs together. The execution layer, derived from Go Ethereum, assembles transactions into blocks. The consensus layer coordinates the validator set, tracks staking and finalizes checkpoints; it was rebuilt in 2025 on the Cosmos SDK and CometBFT, which brought checkpoint-based finality down from a wait of one to two minutes to a matter of seconds and capped how deeply the chain may reorganize. At intervals the consensus layer gathers the blocks produced since the last checkpoint into a Merkle tree and submits the root to contracts on Ethereum, where it becomes the reference point for bridge withdrawals.

Staking itself lives on Ethereum. Validators bond the network's native asset, POL, which replaced MATIC in the migration that began in 2024 and now serves as both the staking asset and the gas asset, into contracts on Ethereum mainnet; holders delegate through share-based pools in the same contracts. The active set is capped, so entry requires displacing an incumbent by stake.

Block production changed materially with the Rio upgrade in late 2025. Rather than rotating producers by stake-weighted draw over short intervals, validators now vote, with voting power weighted by stake, to elect the producer or producers for a span. Because a single elected producer builds the span, competing chain tips largely disappear and reorganizations are eliminated. The same upgrade introduced witness-based verification, letting a validator check a block against a supplied witness instead of holding full state, which lowers the storage burden of participating.

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 XRP Ledger reaches agreement through a trust-based Byzantine agreement procedure rather than through mining or staking. Every server running the ledger software keeps a configured roster of validators whose votes it will listen to, known as its unique node list, and it discards proposals from anyone outside that roster. The security assumption is not that participants have put capital at risk but that the operators named on a given roster are independent enough that they will not fail, or collude, in the same way at the same time. Most operators adopt one of the default rosters curated and published by the XRP Ledger Foundation and by Ripple, although any server is free to compose its own.

Agreement proceeds in short rounds. A server accepts incoming transactions into an open set, closes that set, then exchanges proposals with the validators it trusts, repeatedly adjusting its own proposal to converge on the transactions its trusted peers also hold. When roughly eighty percent of the trusted validators support the same set, each server applies those transactions in a deterministic canonical order to the previous state and publishes a signed hash of the result. Agreement on that hash marks the ledger version as validated, and validation is final: there is no probabilistic confirmation period and no reorganization of settled history. A new ledger version closes every few seconds.

The design deliberately favors halting over divergence. If the proportion of faulty, unreachable or dishonest validators on a roster rises past what the threshold tolerates but falls short of overwhelming it, the affected servers stop advancing rather than splitting into competing histories. A companion mechanism tracks validators that have fallen silent and temporarily discounts them from the quorum calculation, so that ordinary outages do not stall progress. The validator operators named on a roster also carry the network's governance: protocol changes activate only after sustained on-chain support from that same set, and the same votes set network-wide parameters such as the base transaction cost and the minimum balance an account must hold.

EURØP is present on the following networks: Avalanche, Ethereum, Polygon, Solana, Ripple.

Validators on the Primary Network are compensated out of protocol issuance under a capped supply schedule rather than out of user fees. An operator bonds a minimum amount of the native asset for a chosen staking term and is paid at the end of that term provided it met the uptime requirement. A validator's effective weight is capped relative to its own bonded stake, which limits how much delegated stake any single operator can concentrate. Holders who do not run infrastructure may delegate to a validator for a term and receive the reward net of the fee that validator charges.

The enforcement model is unusual in that bonded principal is not slashed. A validator that fails to meet the uptime threshold simply does not receive its reward for that period and gets its stake back, so the penalty is forfeited income rather than confiscated capital. The most recent protocol upgrade reworked these terms considerably: the minimum staking term was shortened from two weeks to two days, staking terms can now renew automatically with rewards compounded at a chosen ratio, the uptime threshold required to earn a reward was raised for newly started validations, and the average rate at which rewards are issued was reduced.

Sovereign networks running alongside the Primary Network are funded differently. Since the late-2024 upgrade that separated them, their validators no longer need to bond a large stake and validate the Primary Network as well; instead they pay a continuous fee to the platform chain that adjusts with the number of active such validators relative to a target, rising when the population exceeds it and easing when it falls short.

Users of the contract chain pay a base fee plus an optional tip, priced dynamically in the style of Ethereum's fee market. The distinguishing feature is that the fee is burned rather than paid to the block producer, so transaction activity reduces supply and offsets issuance instead of rewarding validators directly. The minimum base fee has been lowered by upgrade and is now a floor that validators adjust collectively rather than a hard-coded constant. The exchange and platform chains likewise price their operations dynamically, and those fees are burned as well. There is no storage rent.

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

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

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

Validators on Polygon PoS are paid for two distinct jobs: producing and executing blocks on the chain itself, and signing the checkpoints submitted to Ethereum. Rewards are distributed per checkpoint, funded by protocol issuance of the native asset together with an allocation of transaction fees, and they are apportioned by stake and by how reliably each validator signed. Because the staking contracts sit on Ethereum, a validator's operating costs include Ethereum gas for checkpoint submission and for staking transactions, a meaningful expense that chain-local fee models do not capture.

Delegation works through validator-specific share pools. A holder exchanges the native asset for shares in a chosen validator, and as rewards accrue the redemption value of each share rises, so returns appear as appreciation of the share rather than as separate payments. Validators take a commission before the remainder flows to their delegators. Stake withdrawn from a validator remains locked for a defined number of checkpoints before it can be moved out, while switching between validators carries no such delay.

The penalty structure is weighted toward lost income. The staking contracts define consequences for double-signing and for sustained unavailability, but in normal operation the dominant economic pressure on a validator is forfeited reward: missed checkpoint signatures and poor block-production uptime reduce what a validator and its delegators earn. The producer election introduced by the Rio upgrade also redistributes fee income, including value captured from transaction ordering, toward validators that are not currently producing, so that supporting the chain stays worthwhile for the rest of the set.

Users pay fees in the native asset under a base-fee-plus-tip model. The base fee moves with how full recent blocks have been and is routed to a burn path, while the optional tip goes to the producer. A 2026 protocol change made that base-fee destination configurable in order to fund a time-limited program that recycles fees for one narrow category of activity, with ordinary transactions continuing to follow the burn path. There is no storage rent, and contract deployment and execution are charged purely as metered gas on the resources they consume.

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.

No participant on the XRP Ledger receives a protocol payment for taking part in consensus. There is no block subsidy, no issuance of new units of the network's native asset, and no share of user charges routed to validators. Operators therefore run their servers entirely at their own cost, and their motivation is indirect: payment businesses, custodians, exchanges, universities and foundations that depend on the ledger settling correctly have a direct interest in its continued correctness, and running a validator gives them a voice in the parameter and amendment votes that shape it. Because nothing is bonded, there is correspondingly no slashing and no jailing. A validator that misbehaves is simply dropped from the rosters that reference it, and one that goes quiet is temporarily excluded from quorum accounting until it returns.

Users pay a transaction cost that nobody collects. The amount a transaction specifies is destroyed when that transaction is applied, permanently removing those units from circulation. The purpose is defensive rather than remunerative: because the cost falls on the sender and enriches no one, flooding the network with junk submissions is expensive and pointless. The minimum is set by a vote of the trusted validator set rather than by an auction, and it is kept deliberately small, but an individual server raises the price it is willing to accept as its own queue lengthens, so that under congestion the cheapest submissions wait while higher-paying ones proceed.

The second cost is not a charge but a lock. Each account must hold a minimum balance simply to exist, and that minimum rises for every additional object the account owns in the ledger state, such as offers, trust lines, escrows and issued token balances. This reserved amount is neither burned nor transferred; it stays the account's own property and becomes spendable again once the objects are removed. Its function is to make unbounded growth of stored state costly to the parties causing it, and its level is set by the same validator vote that fixes the base transaction cost.

EURØP is present on the following networks: Avalanche, Ethereum, Polygon, Solana, Ripple.

Avalanche is a staked network, so its energy estimate is assembled from the machines that participate rather than from hardware economics driven by block rewards. One structural feature shapes the calculation: a single Primary Network validator runs one node that validates the contract chain, the exchange chain and the platform chain together. The three are therefore not summed as though they were three independent populations, which would count the same hardware three times; the footprint is modeled against one node population serving all of them.

The estimate combines three inputs. The validator set is read directly from the platform chain, which makes the consensus-participating population unusually well observed compared with networks where it has to be inferred. The surrounding population of non-validating full and archive nodes, run by applications, data services and trading venues, is approximated from peer-discovery crawls and public listings, which see only nodes that accept inbound connections and so tend to undercount. A representative hardware profile is then inferred from the published requirements for the node software, and the power draw of such a configuration is taken from measurement of comparable machines under sustained load and at idle, since a validator draws power continuously whether or not it is currently proposing.

The result carries qualifications that should be read as part of the figure rather than as footnotes to it. Node counts and hardware profiles are inferred from public observation and stated requirements, not metered at the socket. Where evidence is missing, the assumptions chosen are the ones more likely to overstate consumption than to understate it. Estimates are revised as crawler coverage and hardware information improve. Sovereign networks that maintain their own validator sets are accounted for separately from the Primary Network rather than folded into it. And where a share of the total is attributed to an individual asset issued on the chain, that share is derived from observed on-chain transfer volumes, which measures how heavily an asset is used rather than the energy it uniquely causes.

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

Polygon PoS is a staked network, so its consumption is modeled from the machines that run it rather than from mining economics. Two components are added together. The first is the chain's own infrastructure: every validator operates a paired execution and consensus process, which in practice means a heavier machine than a single-process chain of comparable throughput would need, plus the wider population of full and archive nodes serving applications and data consumers. The second is a share of Ethereum's consumption, because the checkpoint and staking transactions that give Polygon PoS its anchor are executed by Ethereum's validators; that share is apportioned by the gas those transactions consume as a fraction of total Ethereum gas.

For the chain's own component, the node count is estimated from peer-discovery crawls, public node listings and the validator set recorded on chain, with the understanding that crawls see only nodes willing to accept connections. A representative hardware profile is inferred from the published requirements for running both node processes, and the electrical draw of such a configuration is taken from measurement of comparable machines, at load and at idle, since a validator's hardware draws power continuously regardless of whether it is currently producing. Aggregating across the estimated population, with an allowance for the overhead of the facilities housing it, gives the chain-local total.

The usual qualifications apply and matter here. The node population and the hardware behind it are inferred from public observation and stated software requirements, not metered. Where evidence is incomplete, the assumptions used err toward a higher figure rather than a lower one. The estimate is revised as observation improves. The gas-based apportionment of Ethereum's consumption is a convention rather than a physical measurement, since Ethereum's validators would run whether or not the checkpoints were posted. And where a share of the network total is attributed to an individual asset issued on the chain, that attribution is made from observed on-chain transfer volumes, which reflects how heavily an asset is used rather than the energy it uniquely causes.

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.

Energy use on the XRP Ledger is estimated from the machines that run it rather than read from a meter. The unit of analysis is the server: the approach counts how many are operating, decides what kind of hardware each is likely to be, attributes a power draw to that hardware and sums the result across the reporting period. Because this network has no mining, no hash race and no relationship between electricity spent and reward earned, the miner-economics reasoning used for proof-of-work networks has no counterpart here and is not applied.

The population count comes first. Servers that take part in consensus identify themselves publicly, announce their validation keys on the network and appear in openly maintained validator registries alongside the curated rosters that reference them, so the consensus-participating set is more directly observable than on a network where anonymous nodes join and leave at will. That visibility narrows the largest uncertainty in this family of estimates without eliminating it, since servers that merely follow the ledger without validating are harder to enumerate, and a single published identity may sit in front of several physical machines. The hardware assumption is drawn from the published system requirements for the ledger software, which state the processor class, memory, storage and bandwidth a server needs to keep pace with the network; per-device consumption is taken from laboratory measurement of representative equipment rather than from operator self-reporting. Idle draw is included, because a server consumes power continuously whether or not transactions are flowing through it.

These figures are estimates and should be read as such. The machine count, the hardware mix and the utilization level are inferred from public observation and from stated software requirements, not measured at the socket. Where the evidence is incomplete, the assumptions selected are those that push the result upward rather than downward, so the published number is better understood as a cautious ceiling than as a precise reading, and it is restated as observation improves. Attributing a share of the network total to an individual asset issued on the ledger uses observed on-chain transfer activity as the apportionment key.

EURØP is present on the following networks: Avalanche, Ethereum, Polygon, Solana, Ripple.

Establishing a renewable share for Avalanche is first a question of geography, because the same hardware draws very different electricity depending on which grid it sits on. The validator set is enumerated from the platform chain, and the network addresses behind those validators, together with the wider set of nodes seen through peer discovery and public network observation, are resolved to hosting providers, autonomous systems and countries. That yields an approximate map of where node capacity is concentrated. Where the mapping is too incomplete to support a result, the observed distribution of a network with comparable staking economics is used in its place.

The map is then joined to national electricity statistics. Each country's share of generation from renewable sources is taken from Share of electricity generated by renewables, compiled and processed by Our World in Data from Ember's yearly electricity datasets and the Energy Institute's Statistical Review of World Energy. Weighting country-level shares by the estimated node capacity located in each gives one renewable percentage for the network as a whole.

Energy intensity is a marginal measure rather than an average: the additional electricity associated with one further transaction being processed. Because validators run continuously and blocks are produced on a schedule regardless of how full they are, the marginal figure is considerably lower than the annual total divided by transaction count, and the two answer different questions.

Several limits constrain what the renewable percentage can mean. Hosting location reveals a grid but not a contract, so operators procuring renewable electricity on a carbon-heavy grid are not distinguished from those that are not. Cloud regions and proxied connections can place a node's apparent location away from its actual hardware. Annual national averages flatten the hourly and seasonal movement in generation mix. And validator infrastructure is concentrated in a relatively small number of hosting markets, so the result is sensitive to how a handful of large operators are located.

The renewable share reported 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 attributed to Polygon PoS depends on where its infrastructure physically sits, so the method begins with geolocation. Nodes visible through peer discovery and public network observation are resolved to hosting providers, autonomous systems and countries, giving an approximate map of where validator and full-node capacity is concentrated. Coverage is never complete; where it is too thin to be relied on, the geographic distribution of a network with a similar staking design and operator economics is used as a proxy. The same exercise applies to the portion of Ethereum's footprint brought in through checkpointing, using Ethereum's own observed node distribution.

Those locations are then matched to national electricity statistics. Each country's share of generation from renewable sources comes from Share of electricity generated by renewables, compiled and processed by Our World in Data from Ember's yearly electricity datasets and the Energy Institute's Statistical Review of World Energy. Weighting the country-level shares by the estimated node capacity in each produces a single renewable figure for the network.

Energy intensity is reported as a marginal quantity: the extra electricity associated with processing one more transaction, not the annual total divided by the number of transactions. On a chain whose validators run continuously and produce blocks on a schedule, that marginal figure is much smaller than a simple average would suggest, and the two are not interchangeable.

The limitations are inherent to the approach. An observed hosting location identifies a grid, not a power purchase agreement, so an operator sourcing renewable electricity on a carbon-heavy grid is invisible to the method. Cloud hosting and proxying can misplace a node relative to the hardware actually running it. Annual national averages cannot capture the hourly and seasonal swings in generation mix that continuously running machines draw from. And the borrowed share of Ethereum's footprint carries whatever geographic error is present in Ethereum's own distribution.

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

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

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

The renewable share reported for the XRP Ledger is derived geographically. The first task is to place the machines: addresses advertised by servers participating in the network are resolved to countries using publicly available network data, registry records and crawling of the peer-to-peer layer. Because consensus participants on this ledger are named and listed rather than anonymous, and because a substantial number are operated by identifiable institutions that disclose where they run, the location picture is firmer than it would be for a population of unidentified nodes. Where part of the population still cannot be placed, the geographic spread of a structurally similar network, meaning one whose participation rules and operating incentives resemble this one, stands in for the missing portion rather than assuming unplaced machines sit alongside the located ones.

Each located machine 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 share consequently tracks the composition of the grids the servers happen to occupy at least as much as anything the protocol itself does. It is a statement about where the infrastructure is located, not a claim that operators have procured particular generation on their own account.

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

EURØP is present on the following networks: Avalanche, Ethereum, Polygon, Solana, Ripple.

The emissions estimate for Avalanche reuses the geographic work behind the renewable share and substitutes carbon factors for renewable percentages. The validator set enumerated from the platform chain, together with the nodes observed through peer discovery and public network data, is resolved to countries; where that resolution is too sparse, the distribution of a network with comparable staking economics stands in. Each country is then paired with the carbon intensity of its electricity, taken from Carbon intensity of electricity generation, processed by Our World in Data from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy and published under a CC BY 4.0 license. The estimated electricity in each region, multiplied by that region's grams of carbon dioxide equivalent per kilowatt-hour and summed across regions, gives the annual emissions figure.

Reporting separates two scopes. Scope 1 covers emissions from sources the operators control directly, such as fuel burned on site for power or heat; for a population of servers hosted in rented facility space this is generally negligible and is reported accordingly. Scope 2 covers the indirect emissions embodied in the electricity those machines buy from their grids, which is where effectively the entire footprint of a staked network falls. Hardware manufacture and end-of-life disposal lie outside the boundary of this accounting.

Greenhouse-gas intensity follows the same marginal logic used for energy: the incremental emissions associated with one more transaction, not the annual total divided by throughput.

Uncertainty accumulates across the two steps. Whatever error exists in the electricity estimate passes straight through into emissions, and the geographic step adds its own, since national grid intensities span more than an order of magnitude and shifting a large operator from one country to another visibly moves the answer. Annual averages also conceal the hourly variation in grid intensity that continuously running machines are exposed to in full.

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

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

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

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

Emissions attributed to Polygon PoS rest on the same geographic work as the renewable share, with regional carbon factors applied in place of renewable percentages. Validator and full-node locations are approximated from peer discovery, public network observation and hosting attribution, and a comparable network's distribution stands in wherever direct observation is too sparse. The share of Ethereum's footprint brought in through checkpointing is located the same way, against Ethereum's own node distribution. Each location is paired with the carbon intensity of its national grid, taken from Carbon intensity of electricity generation, processed by Our World in Data from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy, and made available under a CC BY 4.0 license. Multiplying regional electricity by regional grams of carbon dioxide equivalent per kilowatt-hour, then summing, yields the annual total.

Scope matters to how the result should be read. Scope 1 captures emissions from sources under the direct control of the network's operators, such as fuel burned on site, which for servers in rented facility space is generally negligible and reported as such. Scope 2 captures the indirect emissions embodied in purchased electricity, and that is where essentially the entire footprint falls. Manufacture and disposal of the hardware sit outside the boundary of this accounting.

Greenhouse-gas intensity is defined marginally, as the incremental emissions associated with one additional transaction rather than the annual total spread across throughput.

The error bars on the emissions figure inherit those on the electricity estimate and add to them. Grid carbon intensity differs by more than an order of magnitude between countries, so a misallocated share of node capacity shifts the result considerably, and annual national averages hide the hourly swings in intensity that machines running around the clock experience in full.

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

The input population for this ledger does not have to be discovered. Validators declare themselves and appear in signed lists that server operators subscribe to, so the machines carrying consensus can be read off those lists rather than pieced together from whatever a crawler reaches, and many entries are institutions that state publicly where they operate. The wider population of servers that track the ledger, answer application traffic or retain history without voting is not enumerated that way and must be observed conventionally, by resolving announced addresses to the country holding the allocation. Where part of that outer population will not resolve, a network with comparable participation rules and comparable reasons to run a server lends its profile to the gap.

Emissions then follow from arithmetic over that map. Each country is assigned a published average for greenhouse gas released per unit of electricity generated within it, expressed in carbon dioxide equivalent, and the electricity estimated to be drawn there is multiplied through. Adding across countries gives the figure. Nothing here observes an emission; it converts an electricity estimate with a national coefficient, and is no better than either.

Of the two scopes reported, only one carries weight. Direct emissions from plant the operators run themselves fall in the first, fuel burned on their own premises being the standard case. Servers in commercial facilities burn nothing, so the first is reported at zero, and that zero means the category is genuinely empty rather than unexamined. The second, covering emissions already embodied in the electricity bought to run those servers, holds the whole result. It uses the average mix of a country's grid, which is why an operator contracted for low-carbon supply earns no credit here, and one on a coal-heavy grid no relief from offsets bought elsewhere.

The per-transaction figure is marginal: what one more transaction adds while the server population stays as it is. Because these machines run around the clock at a cadence consensus sets rather than demand, that increment is slight, and the reported number swings with its throughput denominator more than with anything physical. Intensity coefficients are taken from Carbon intensity of electricity generation, a dataset Our World in Data prepares from Ember and from the Energy Institute's Statistical Review of World Energy and distributes under the CC BY 4.0 license.