AIOZ Network (AIOZ) sustainability report
| Name | BlockNodes SAS |
| Relevant legal entity identifier | 969500PZJWT3TD1SUI59 |
| Name of the crypto-asset | AIOZ Network |
| Beginning of the period to which the disclosure relates | 2025-09-27 |
| End of the period to which the disclosure relates | 2026-09-27 |
| Energy consumption | 345.56688 kWh/a |
Consensus Mechanism
AIOZ Network is present on the following networks: Binance Smart Chain, Ethereum, Osmosis.
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.
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.
Osmosis is a sovereign chain built with the Cosmos SDK, reaching agreement through CometBFT, the Byzantine fault tolerant engine that carried the name Tendermint Core until its rename in 2023. Blocks are committed in rounds: a validator from the active set proposes, the set votes in a prevote stage and then a precommit stage, and the block is finalized the moment precommits representing more than two thirds of bonded voting power are collected. Nothing is probabilistic about this, so a committed block cannot be reorganized away and no confirmation depth needs to be observed. The guarantee the engine provides is that honest validators never commit conflicting blocks while fewer than one third of bonded voting power misbehaves; past that point the chain halts instead of forking.
Validators are ranked by the stake bonded to them, self-bonded and delegated counted together, and the highest ranked fill a fixed number of active slots, which on this network is seventy, a deliberately tighter set than several of the chains it interoperates with. Delegation lets holders of the native asset assign their weight to an operator and share in that operator's rewards, and it carries the same downside the operator carries. Bonded stake takes a fortnight to unwind, roughly half the period used elsewhere in the ecosystem.
What sets this network apart from a general-purpose Cosmos chain is that its exchange lives inside the state machine rather than in contracts deployed on top of one. Pool creation, routing a swap across several pools, concentrated liquidity positions, and the accounting of trading fees are all protocol modules that validators execute as part of processing a block, so a trade is a consensus-level state transition carrying exactly the same finality as a transfer. The protocol also runs an arbitrage module of its own, which inspects a proposed block for price discrepancies its pools have opened and captures the correction for the protocol rather than leaving it to outside searchers. A number of recurring operations, issuance and reward distribution among them, are processed once per daily epoch instead of every block.
Incentive Mechanisms and Applicable Fees
AIOZ Network is present on the following networks: Binance Smart Chain, Ethereum, Osmosis.
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.
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.
Three groups are paid on this network, and the balance between them has shifted markedly. New units of the native asset are minted on a daily cadence along a schedule that steps down by a third every seven hundred and thirty days, and governance decides how each day's issuance is split. Liquidity provision was once the largest claim on that issuance; it has since been removed from the split entirely, on the argument that trading revenue rather than subsidy now sustains the pools. The staking share has been cut back as well, with most of each day's issuance now directed into the community fund alongside a fixed development allocation. Bonded stake is increasingly compensated from revenue instead: transaction fees collected in the native asset accrue to stakers, and fees paid in other accepted denominations are converted first.
That revenue comes from trading. Every swap pays a spread factor to the providers of liquidity in each pool it touches, and separately a taker fee to the protocol, set by default at a tenth of a percent and overridden route by route by a delegated fee committee that prices heavily traded pairs down and thin ones up. Taker fees collected in the native asset are split so that the larger part is destroyed and the remainder is paid to stakers. Taker fees collected in other assets are divided between the community fund and a buyback that acquires the native asset before splitting it the same way, which ties the rate of destruction directly to trading volume. Liquidity providers may bond their positions for additional incentives, and a superfluid arrangement lets the portion of a bonded position represented by the native asset be delegated to a validator at the same time, so one unit of capital both secures consensus and backs a pool.
Ordinary transactions pay gas at a base price that climbs when blocks fill and falls back when they empty, resting on a governance-set minimum, a mechanism intended to price out spam rather than to raise revenue; fees may be paid in a whitelisted set of denominations, not only the native one. Validators must charge at least five percent commission. Signing two conflicting blocks costs a validator and its delegators a share of bonded stake and permanent exclusion from the set, while missing too many blocks results in jailing rather than confiscation.
Energy consumption sources and methodologies
AIOZ Network is present on the following networks: Binance Smart Chain, Ethereum, Osmosis.
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 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.
The reported consumption for this network is a modeled estimate rather than a measurement taken from a meter, and it is built from the machines that keep the chain running. The first task is to size that machine population. It comprises the seventy validators in the active set, the bonded candidates waiting outside it, and the full, archive, and indexing nodes that serve the trading interfaces, routing services, and relayers connecting this chain to its neighbors. The count is approximated from peer discovery on the public network, from what operators publish about their own deployments, and from the chain's own on-chain register of who is bonded.
Each machine is then represented by a hardware profile. The client software publishes the processor, memory, disk, and bandwidth a node needs to stay in sync, and a machine meeting those requirements stands in for the node. This chain sits at the demanding end of the range for its family, because validators execute swap routing, concentrated liquidity accounting, and the protocol's own arbitrage checks inside block processing rather than delegating them to a contract layer, and because several recurring tasks are batched into a daily epoch that produces a pronounced load spike. Electrical draw for the representative machine comes from controlled measurement of comparable equipment across its load range, idle draw included, since nodes are powered continuously. Draw multiplied by population over the reporting period gives the network total, from which a per-asset share is apportioned using observed on-chain activity.
Two caveats matter. The population and the hardware mix are inferred from public observation and stated software requirements, not from operator disclosure, and where evidence is missing the assumption chosen raises rather than lowers the estimate, so the figure is likelier to overstate than understate. Second, a correction: earlier assessments attributed to this network a share of another chain's consumption on the grounds that the other chain contributed to its security. That is not how this network is secured. It has its own validator set, its own bonded stake, and its own penalties, and the estimate here covers only the machines that run it. Figures are restated as observation improves.
Key energy sources and methodologies
AIOZ Network is present on the following networks: Binance Smart Chain, Ethereum, Osmosis.
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 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.
Because electricity is generated differently from one grid to the next, the renewable share reported for this network depends on establishing where its machines are. Locations are inferred from publicly observable network data: the addresses validators and other nodes advertise to their peers, the hosting ranges into which those addresses fall, and whatever operators choose to publish about their own infrastructure. The output is a distribution of the node population over countries and regions, never a precise site for a given machine. Where the distribution cannot be established with confidence, the observed distribution of a network with a comparable consensus design and comparable rewards is substituted, on the assumption that similar economics lead operators to similar places.
Every region in that distribution is then paired with published statistics on the composition of its electricity generation, and the network's estimated consumption is weighted across the regions to yield the proportion met from renewable sources. The generation statistics are taken from Share of electricity generated by renewables, compiled by Our World in Data with major processing from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy.
Energy intensity is reported as a marginal quantity and should not be read as consumption divided by transaction count. It answers a narrower question: how much additional energy the network draws when one further transaction is included in a block. That distinction is particularly sharp here. Validators run continuously and commit blocks on a fixed cadence whether or not there is trading to process, so nearly all of the draw is a standing cost, and the incremental cost of one more swap, which is executed by the same validator process as any other message, is very small by comparison.
The method's weakest link is geolocation. An address identifies a hosting provider rather than a customer, machines behind large commercial cloud regions are assigned to the advertised region rather than to a physical building, and the grid statistics are averages over a country or region that ignore any supply arrangement an individual facility has made. Where a stand-in distribution has been used, its representativeness remains an assumption.
Key GHG sources and methodologies
AIOZ Network is present on the following networks: Binance Smart Chain, Ethereum, Osmosis.
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 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 figures are constructed from the energy estimate and the geographic estimate together. The distribution of nodes across regions is inferred from publicly observable network data, with the distribution of a structurally comparable network standing in where direct observation is insufficient. Each region's share of estimated consumption is then multiplied by the emissions released per unit of electricity generated on that region's grid, and the results are summed to give the network total.
Carbon intensity values are taken from Carbon intensity of electricity generation, compiled by Our World in Data with major processing from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy, and published under the Creative Commons CC BY 4.0 license.
The distinction between the two reported scopes is worth spelling out. Scope 1 captures emissions from sources the infrastructure's operators control directly, essentially combustion happening on their own premises. Validators and supporting nodes for this network are conventional servers housed in data centers and supplied from public grids, so there is ordinarily nothing of that kind to record and the scope 1 figure is reported at or close to zero rather than omitted. Scope 2 captures the emissions embodied in the purchased electricity that those machines consume, and in practice the entire footprint falls under it. Greenhouse gas intensity mirrors energy intensity in construction: it expresses the emissions attributable to one additional transaction at the margin, not an average obtained by dividing a total by a count.
Every uncertainty already present in the consumption and location estimates propagates into these figures, and the intensity data introduces another. Published grid intensities are annual averages across a region; they cannot reflect the hours at which a node's consumption actually falls, nor any generation a particular operator has contracted for directly. Where the evidence is thin, the conservative assumption is preferred, meaning the reported emissions are more likely to sit above the true value than below it, and every figure is revised as the underlying observation improves.