Blockasset (BLOCK) sustainability report

Blockasset is present on the following networks: Binance Smart Chain, Chiliz, Solana.

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.

Chiliz Chain is a Layer 1 network built for sports and entertainment applications. The chain running today is not the original one. The first Chiliz chain, derived from an Ethereum client and operated under a fixed authority model, was superseded by a new chain whose genesis block was produced in February 2023 and whose public mainnet opened in May 2023. The current client is a fork of the BNB Chain software, and the replacement brought a move from purely authority-based block production to a staked form of it.

Consensus is Proof of Staked Authority, a model in which the right to produce blocks is limited to a known set but distributed within that set by bonded stake. Block production is restricted to a small active group, currently eleven producers, selected from a wider register of candidates; admission to the register is gated rather than open, so the operator population is deliberately identifiable and accountable. Candidates are ranked by the native asset bonded to them, their own stake together with stake delegated by holders, and the highest-ranked occupy the producing slots. That set is recalculated at epoch boundaries, an epoch being 28,800 blocks, which at the three-second target interval is close to a day.

How a producer is chosen for each individual block changed with a hard fork in October 2025. Producers had previously taken strict turns in a fixed rotation, giving every member of the set the same opportunity regardless of how much stake backed it. Selection is now randomized and weighted by delegated stake, tempered by an enforced minimum frequency so that smaller operators keep receiving block opportunities and are not crowded out by larger ones.

A block is treated as settled once a supermajority of the active set has built on top of it, which on a set this small takes only seconds, though the guarantee is economic and reputational rather than a single-round Byzantine agreement. Misbehavior is penalized in the protocol: signing two conflicting blocks at the same height slashes bonded stake, while failing to produce assigned blocks draws a smaller charge and removal from the rotation.

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.

Blockasset is present on the following networks: Binance Smart Chain, Chiliz, Solana.

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.

Two roles earn from this network. Operators run the nodes that produce and validate blocks. Holders of the native asset delegate to an operator without running anything themselves, adding to that operator's bonded stake and to its chance of being selected to produce a block. Rewards are shared between them: the operator retains a commission it sets and the remainder passes to its delegators in proportion to what each contributed.

The reward pool is divided at the protocol level rather than by discretion. Sixty-five percent goes to operators and their delegators. Twenty-five percent is directed to ecosystem development and the remaining ten percent to community incentives, both administered through governance rather than paid to node operators. Rewards are funded from newly issued native asset together with the fees collected in blocks, and the issuance parameters are governance decisions that have been amended by hard fork more than once.

Fees follow the mechanism Ethereum introduced with EIP-1559, support for which arrived in a 2024 hard fork. Every transaction carries an algorithmically determined base fee that rises and falls with demand for block space and is destroyed at the protocol level, plus an optional priority fee paid to the producer of the block for earlier inclusion. This is a deliberate divergence from the upstream codebase the chain was forked from, where the base fee is zero; here it was given a substantial starting value so that the fee market behaves in the way users of Ethereum expect. All fees are paid in the network's native asset. Smart contract execution is metered in gas and priced by the same base and priority components, and there is no recurring rent on stored state; the cost of storage is carried in the gas price of the operations that write it.

Penalties run in the other direction. Bonded stake can be slashed where an operator signs conflicting blocks, and a lesser charge applies for missed blocks or extended downtime, alongside removal from the producing set until service resumes. Withdrawing delegated stake is not immediate: it becomes available only after a protocol-defined waiting period.

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.

Blockasset is present on the following networks: Binance Smart Chain, Chiliz, Solana.

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.

Because this network reaches agreement through its own operator set rather than by settling on another chain, its energy estimate is built from the machines that set runs. The estimate starts by counting the population: the small group of block-producing operators, the wider register of candidates that run nodes without currently producing, and the broader tier of full nodes, archive nodes and public endpoint servers that hold the chain state and serve applications. Population figures are drawn from what the protocol itself records on chain about registered operators, from crawlers that walk the peer-to-peer layer, and from publicly available node directories.

For each tier a representative machine profile is inferred from the stated requirements for running the client software, which for an EVM chain of this throughput means a multi-core server with substantial memory and fast persistent storage. Power draw for that profile comes from laboratory measurement of equivalent hardware, taking both the idle floor and consumption under load, since a node kept online but lightly used still draws meaningfully. Multiplying profiles by estimated counts and by the hours in the period gives the aggregate. A small validating set does not by itself make the total small, because the non-producing node population is the larger part of the count and is the harder part to observe.

The honest caveats belong here. Neither the node count nor the hardware mix is metered: both are inferences from public observation and from what the software says it needs, and operators who run behind hosting providers or on shared infrastructure are not individually visible. The proportion of nodes running on dedicated machines rather than virtualized capacity is estimated rather than known, and virtualization changes the attributable draw. Where evidence is missing, the assumption taken is the one more likely to overstate consumption than understate it, so the figure should be read as a conservative upper reading rather than a precise one. Estimates are revised as the observable picture improves and as protocol changes alter what operators must run.

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.

Blockasset is present on the following networks: Binance Smart Chain, Chiliz, Solana.

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 is derived from where the network's machines sit rather than from any meter attached to them. The first step is to locate them. This network has an advantage and a limitation here. Its block-producing operators are few and institutionally identified, so the hosting region of the machines that matter most for consensus can often be established with reasonable confidence. The larger tier of non-producing nodes and public endpoint servers is far less visible, and it is located the usual way: from publicly observable network data, chiefly the addresses peers advertise and the hosting providers and regions to which those addresses resolve. Operators behind relays or content delivery networks cannot be placed at all.

Where a material share of the population resists direct location, the geographic distribution of a network with a comparable operator profile and comparable hosting economics is substituted, on the reasoning that similar incentives lead operators to similar places. Once a distribution exists, each location is matched to statistics for the electricity grid serving it, and the reported renewable share is the consumption-weighted average across those regional shares. Because the machine population is concentrated, the result is sensitive to a small number of hosting decisions in a way it would not be on a network with thousands of independent operators; a single large operator relocating can move the figure.

Energy intensity has a particular meaning in this context. It is the marginal energy attributable to one additional transaction, calculated by dividing estimated consumption across a reporting period by the transactions confirmed in that period. It is not a measurement of what any individual transaction costs physically. Infrastructure of this kind draws roughly the same power whether blocks are full or nearly empty, so the intensity figure falls as usage rises without any machine consuming less. Regional generation data is drawn from Share of electricity generated by renewables, compiled by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy.

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

Blockasset is present on the following networks: Binance Smart Chain, Chiliz, Solana.

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 figures reuse the geographic picture assembled for the energy analysis, replacing regional renewable shares with regional carbon intensities. Locations are inferred for the block-producing operators, the registered candidates running nodes without producing, and the wider population of full nodes and public endpoint servers, using what the protocol records on chain together with publicly observable network data. Where part of that population cannot be located directly, the distribution of a structurally comparable network stands in for it, and the resulting uncertainty is carried through into the reported number.

Each location is matched to the carbon intensity of electricity on the grid that serves it, expressed in grams of carbon dioxide equivalent per kilowatt-hour. Multiplying the electricity estimated for that location by the corresponding factor and summing across locations gives the network total.

The figure is essentially a scope 2 quantity: the indirect emissions embodied in electricity purchased from a grid. Scope 1 captures emissions from sources an operator controls directly, such as fuel burned on site in a generator; for a network running on general-purpose servers in commercial data centers, scope 1 is normally negligible, and it is reported as such unless there is specific reason to think otherwise. Emissions embodied in manufacturing and disposing of the hardware sit outside this boundary and are not counted, which means the figure understates the full life-cycle impact by design and should be read as an operational measure.

Greenhouse gas intensity is the marginal emission attributable to one additional transaction, obtained by allocating the total across the transactions confirmed in the same period. As with the energy equivalent, it distributes shared overhead rather than describing a property of any single transaction, and it responds to changes in grid factors or in where operators host quite independently of anything happening on the network. Grid carbon intensity values are taken from Carbon intensity of electricity generation, compiled by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy and published under the Creative Commons Attribution 4.0 license.

Emissions are derived from the same geographic picture used for energy sources, applied to a different set of grid statistics. Node locations are inferred from addresses observable through crawlers and public cluster information and resolved to a region; where direct observation falls short, the geographic distribution of a structurally comparable network is substituted, selected on the basis that its incentive design and agreement protocol impose similar operating demands.

Each region is then paired with a carbon intensity for its electricity, taken from Carbon intensity of electricity generation, compiled by Our World in Data from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy and made available under the CC BY 4.0 licence. Multiplying the electricity estimated to be consumed in a region by that region's carbon intensity, and summing across regions, gives the emissions attributable to running the network.

The disclosure separates two scopes. Scope 1 covers emissions from sources the operators of the infrastructure control directly, such as fuel burned on site; for a network of this kind, whose nodes are ordinary servers in rented facilities, this is normally nil or immaterial, and a zero figure reflects the absence of such sources rather than an omission. Scope 2 covers the indirect emissions embodied in the electricity those machines purchase, and is where essentially the whole footprint of this network falls.

Greenhouse gas intensity follows the same marginal logic as its energy counterpart: it expresses the emissions associated with one additional transaction rather than an average obtained by dividing an annual total by throughput. Because validators consume electricity at a fairly steady rate whether or not blocks are full, the marginal figure is small and is not a proxy for the footprint of the network as a whole. Both the absolute emissions and the intensity figure are sensitive to the grid statistics underlying them, which are revised as national energy reporting is updated.