XRP (XRP) sustainability report

XRP Ledger is present on the following networks: Ripple.

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.

XRP Ledger is present on the following networks: Ripple.

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.

XRP Ledger is present on the following networks: Ripple.

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.

XRP Ledger is present on the following networks: Ripple.

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.

XRP Ledger is present on the following networks: Ripple.

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.