Stable (STABLE) sustainability report

Stable is present on the following networks: Binance Smart Chain, Hyperliquid.

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

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

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

Hyperliquid is a proof-of-stake layer-one network running its own Byzantine fault tolerant consensus protocol, HyperBFT, implemented from scratch and derived from the HotStuff line of leader-based BFT designs. Consensus advances in rounds. A rotating leader proposes an ordered bundle of transactions, validators vote, and a round commits once signatures representing more than two-thirds of stake-weighted voting power have been gathered; voting is pipelined so that the vote confirming one round also advances the next. Ordering is therefore agreed before execution, and a committed round is final immediately rather than after a probabilistic waiting period. Safety holds provided that faulty or dishonest validators control less than a third of stake-weighted voting power.

What sets this network apart is what the agreed ordering is fed into. Two execution environments sit on the same consensus and the same validator set. The first, the native state machine, holds fully on-chain central limit order books together with margin, perpetual futures and spot balances, so order placement, cancellation, matching and liquidation are consensus operations of the chain itself rather than calls into a deployed contract. The second is an EVM environment added in 2025, which inherits ordering and finality from the same consensus and can read from and write to the native state. It uses two interleaved block types: small blocks produced roughly every second with a low gas ceiling, for ordinary transfers and trades, and much larger blocks produced about once a minute, for contract deployment and heavy batch work, so bulky transactions cannot delay time-sensitive ones.

Validators are selected by stake. An operator must self-delegate a minimum amount of the network's native asset to become active, and any holder may delegate to a validator to add to its weight. The active set and the stake behind it are fixed within staking epochs of a hundred thousand consensus rounds, roughly an hour and a half, and are recomputed between them. Validators police each other's liveness directly: a validator that does not answer consensus messages with acceptable latency or frequency can be voted into a jailed state by its peers, in which it stops producing blocks until it returns itself to service.

Stable is present on the following networks: Binance Smart Chain, Hyperliquid.

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

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

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

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

Validators and their delegators are paid from a reserved pool of the native asset held for that purpose, not from the network's trading revenue. Rewards accrue continuously, are paid out daily and are automatically re-delegated, and the rate scales inversely with the square root of the total amount staked, so the yield falls as participation grows. A validator earns only for epochs in which it actually took part in consensus, and its delegators earn nothing while it is jailed. Validators set a commission on delegator rewards; raising one is constrained, since a commission may only be changed to a rate at or below a low ceiling, which prevents an operator from attracting delegation cheaply and then repricing it.

Delegated stake cannot be withdrawn quickly. A delegation is locked for a day before it can be undone, and moving stake back to a spendable balance then takes a further week in a withdrawal queue, which makes it impractical to assemble voting weight, attack consensus and exit. There is no automatic confiscation of stake in the protocol as it currently operates; the sanction for poor performance is jailing, which costs the validator and its delegators their rewards rather than their principal.

The fee model is the most distinctive part. Trading fees on the native order books are charged to takers and makers on a volume-tiered schedule, and execution fees on the EVM side are paid as gas. Almost none of this reaches validators. The great majority of protocol fee revenue is routed to an on-chain fund that continuously buys the native asset on the open market; the address holding it has no private key, so under current protocol rules those holdings cannot return to circulation. Alongside that, several streams are destroyed outright: spot trading fees denominated in the native asset, the base-token fees from token deployments that a deployer has not redirected, and both the base fee and, unusually, the priority fee on the EVM, since block producers do not collect them. Optional priority fees for faster order handling, introduced in 2026, are likewise burned. Token listings are allocated through descending-price auctions rather than sold at a fixed price.

Stable is present on the following networks: Binance Smart Chain, Hyperliquid.

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

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

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

The figure reported for this network is an estimate built from the machines that operate it, not a metered reading. It starts from the population of participating nodes and works upward from the draw attributable to each.

Establishing that population is more tractable here than on most networks, because the set of validators taking part in consensus is small, identified on-chain and recomputed at each staking epoch, so its size and membership can be read from publicly observable network data rather than inferred. Counting only that set would understate the total, however. The chain is also served by non-validating nodes that follow consensus, keep a copy of state and answer the queries that applications and market participants make of it, and by the infrastructure that distributes order book and market data. These are estimated from peer discovery and from publicly available operator information, collected by automated crawling.

The second input is what a single machine draws. A representative hardware profile is inferred from the resources the node software states it requires, and per-device power is attributed from laboratory measurement of equipment matching that profile. Two features of this network push that profile upward relative to a general-purpose chain: consensus targets sub-second commitment, and the state machine continuously matches orders, so participants run high-specification servers in professionally operated facilities and keep them running constantly. Draw is therefore counted on a continuous basis, idle periods included, and multiplied across the estimated population.

The limitations should be stated plainly. The hardware mix is inferred from stated requirements rather than surveyed, and the count of supporting non-consensus infrastructure is the least observable part of the estimate. Because the consensus set is small, the total is sensitive to the per-machine assumption in a way that a large network's total is not: an error in the assumed profile is not diluted across thousands of nodes. Where evidence is thin, assumptions are chosen so that the impact is more likely to be overstated than understated, and figures are revised as observation improves.

Stable is present on the following networks: Binance Smart Chain, Hyperliquid.

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

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

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

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

The renewable share attributed to this network follows from where its machines are located, not from any statement about the electricity its operators choose to buy. Locations are established from publicly observable network data: the addresses validators and other nodes announce to their peers, information operators publish about the infrastructure they run, and the hosting providers and data-center address ranges those addresses belong to, gathered by automated crawling of the peer network.

The picture that emerges here has a particular shape. The consensus set is small and professionally operated, and its members run in commercial data centers chosen for network latency to one another rather than for cheap power, which tends to concentrate them in a handful of well-connected regions. That concentration cuts both ways for the estimate: fewer sites make placement easier to observe, but it also means the renewable share is sensitive to a small number of hosting decisions, and a single operator moving facility can shift the network figure noticeably. Where placement cannot be resolved at all, because a node sits behind a relay or the provider does not disclose the site, the geographic distribution of a structurally similar network is used instead, chosen for comparable incentives and comparable validation duties.

Each location is then matched to the grid serving it, and the renewable proportion of that grid's generation is applied, weighted by the share of estimated consumption sitting in each region. The result is a consumption-weighted renewable share that moves when operators relocate and when the underlying generation mixes change.

Energy intensity is reported alongside it and has a narrow meaning: the marginal energy associated with one further transaction. On this network the distinction matters, because consumption is almost entirely the fixed cost of keeping validators running at capacity, while throughput can vary greatly with trading activity. The marginal figure therefore falls as activity rises and should not be read as an average per transaction. Grid statistics come from Share of electricity generated by renewables, compiled by Our World in Data with major processing from Ember and from the Energy Institute's Statistical Review of World Energy.

Stable is present on the following networks: Binance Smart Chain, Hyperliquid.

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

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

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

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

Emissions are derived from the network's estimated electricity use combined with the carbon content of the grids supplying it. The energy total is first apportioned by location, using the same geographic picture assembled for the energy analysis: node addresses observed on the peer network, operator information published openly, and the hosting ranges those addresses resolve to. Where a node's placement cannot be resolved, the distribution of a structurally comparable network is used in its place, selected for similar incentives and similar validation duties rather than for similar scale.

Each portion of consumption is then multiplied by the carbon intensity of the grid serving that region, expressed as emissions per unit of electricity generated, and the parts are summed. The consequence is that hosting decisions drive the result as strongly as the amount of electricity drawn. That is pronounced here, because the consensus set is small and clustered in a few commercial facilities, so the figure reflects the generation mix of a handful of jurisdictions rather than a global average, and can move when one operator changes provider.

The reported figures distinguish two scopes. Scope 1 covers emissions from sources the operators control directly, such as fuel burned on site; for infrastructure of this kind that is effectively nil, since the machines are commodity servers drawing grid power in third-party facilities. Scope 2 covers the indirect emissions embodied in the electricity bought to run them and accounts for substantially the whole footprint. Emissions from manufacturing the hardware, and from constructing and cooling the buildings that house it, sit outside both scopes and are not counted.

GHG intensity is the marginal quantity: the emissions attributable to processing one additional transaction. As with energy, most of the total is a fixed cost that continues regardless of how busy the network is, so intensity falls as usage rises and is not an average. Carbon intensity values come from Carbon intensity of electricity generation, compiled by Our World in Data with major processing from Ember and from the Energy Institute's Statistical Review of World Energy, and made available under the CC BY 4.0 license.