Stellar (XLM) sustainability report

Stellar is present on the following networks: Stellar.

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.

Stellar is present on the following networks: Stellar.

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.

Stellar is present on the following networks: Stellar.

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.

Stellar is present on the following networks: Stellar.

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.

Stellar is present on the following networks: Stellar.

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.