ZetaChain (ZETA) sustainability report

ZetaChain is present on the following networks: Binance Smart Chain, Ethereum, Zeta.

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.

ZetaChain is a proof-of-stake layer-one assembled from Cosmos SDK modules and settled by the CometBFT consensus engine, with an Ethereum-compatible execution environment running alongside the native application modules. Consensus follows the familiar Byzantine-fault-tolerant pattern: at each height the engine designates a proposer weighted by bonded stake, participants exchange prevotes and precommits, and the block commits once more than two thirds of bonded weight has precommitted it. Commitment is final immediately, with no fork-choice rule and no settlement delay, and the safety guarantee holds as long as less than a third of bonded weight deviates from the protocol. Holders who do not run infrastructure may bond to an operator, and delegated stake counts toward that operator's weight in full.

What separates this network from others in the same family is a second role layered on top of consensus. A subset of the validator set runs an observation client beside the consensus node. That client maintains full nodes of the external chains the network connects to and watches them for deposits, contract calls and confirmations. Each observed external event is put to a vote inside the chain's own state as a ballot, and once observers holding a sufficient majority have voted the same way, the event is accepted by the network and a cross-chain transaction record is opened and executed.

The same set holds the authority to act on those external chains. Rather than any operator holding a signing key outright, the key is generated and used through a threshold signature scheme in which each participant holds only a share, so a supermajority must cooperate to produce a signature and no single party can move assets held at the network's external addresses. Outbound instructions are signed in a distributed ceremony, broadcast to the destination chain, then observed and voted on again to confirm settlement. Running this role requires also running a consensus validator, which anchors external-chain custody to the same bonded stake that secures block production.

In September 2026 the network's governance process approved discontinuing the chain. No date is fixed and a further proposal is required to set the timetable; validators continue to produce blocks and the mechanisms described here remain in operation meanwhile.

ZetaChain is present on the following networks: Binance Smart Chain, Ethereum, Zeta.

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.

Block rewards on ZetaChain are paid from a pool set aside at genesis and released on a fixed schedule across the network's first years, rather than from open-ended issuance. The design provides that once that pool is drawn down, a modest ongoing issuance takes over, adjusted against a target proportion of bonded stake so that rewards ease when bonding runs above target and firm when it runs below.

The split of those rewards is the distinctive part. Three quarters go to consensus participants and flow through the standard distribution rules to operators and their delegators in proportion to bonded weight, net of a commission each operator sets. The remaining quarter compensates the external-chain roles and is divided evenly between observation and threshold signing. Observation rewards are settled per ballot rather than per block: once a ballot has matured, participants who voted with the accepted outcome are paid an equal share, while a participant who abstained or voted against it has an amount deducted. Pay therefore tracks correct and timely observation of other chains, not merely uptime on this one. Transaction fees collected in each block are pooled with the emissions and distributed through the same rules.

Penalties apply against bonded stake and reach both roles. The standard consensus offenses carry the usual consequences: signing conflicting blocks at one height removes a portion of bonded stake and excludes the operator, and sustained failure to sign brings temporary exclusion with rewards withheld until the operator returns. Operators running the observation role additionally answer for repeatedly failing to report events that occurred, reporting events that do not match what the external chain shows, or declining to join key generation and signing ceremonies, and those failures are charged against the same bonded stake. Unbonding takes twenty-one days.

Users meet two kinds of cost. Execution in the Ethereum-compatible environment is priced through a base fee that the protocol adjusts up or down with how full recent blocks were, plus an optional priority tip, with the native asset serving as gas. Any call that reaches out to a connected chain carries an additional withdrawal fee covering the gas the network must itself pay on the destination chain, quoted against that chain's own gas asset in its wrapped on-chain representation and taken at the time the call is made.

ZetaChain is present on the following networks: Binance Smart Chain, Ethereum, Zeta.

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.

ZetaChain settles under a bonded proof-of-stake engine, so the estimation approach used here counts machines rather than modeling mining economics. It begins from the node population. Consensus operators are enumerable from chain state, while the broader set of full nodes, indexers and public endpoints is not, and that part is approximated from peer-to-peer crawling, advertised endpoints and operator directories, carried as a range rather than a point estimate.

One feature of this network materially changes the calculation and has to be handled explicitly. Operators carrying the observation role do not run a single node. Alongside the consensus and execution processes they run full nodes of every external chain the network connects to, so that they can watch those chains directly rather than trusting a third party. A machine in that category consumes far more storage and bandwidth, and draws more power, than a machine running only the chain's own software. The estimate therefore treats the observing subset as a separate class with its own hardware profile, sized from the combined published requirements of the observation client and the external-chain clients it depends on, and applies the lighter profile only to participants that run the chain's own software alone.

Power draw for each profile is taken from laboratory measurement of comparable equipment at load and at rest, with idle draw included, since these machines are provisioned for peak demand and run continuously. The network total is the aggregate across the estimated population over hours of operation, with an allowance for hosting overhead. Where a figure is required for a single asset, a share of the network total is attributed to it based on observed on-chain activity, and shares from every network an asset is issued on are summed.

The caveats are the usual ones and they bind harder here. Node counts rest on public observation and will understate machines that do not advertise. Hardware profiles stand in for a mixed and partly virtualized population. Where evidence is thin the conservative assumption is taken, meaning the one that raises rather than lowers the estimate, and figures are revised as observation improves.

ZetaChain is present on the following networks: Binance Smart Chain, Ethereum, Zeta.

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.

Deriving a renewable share for ZetaChain means first working out where the network physically runs, because the electricity supplying a machine is a property of its grid rather than of the software on it. Locations are inferred from publicly observable network data: nodes advertise reachable addresses, those addresses map to hosting providers and to regions, and repeated crawling of the peer-to-peer layer builds a country-level distribution. Operator disclosures and the known locations of hosting facilities refine it further.

This network complicates the exercise in one respect. Operators carrying the observation role also run infrastructure for the external chains they watch, and that infrastructure is ordinarily co-located with their own node rather than distributed elsewhere, so it inherits the same grid. It is attributed to the location established for the operator, not to the geography of the chain being observed.

Where the distribution cannot be resolved with adequate confidence, the geographic profile of a structurally comparable network is used in its place, comparable meaning that it rewards participation along similar lines and asks similar things of hardware, so that operators face similar incentives when choosing where to host. This is an approximation and it is the leading source of uncertainty in the published share.

The distribution is then combined with public statistics on how electricity is generated in each country or region, weighted by the consumption attributed there, to give the share of the network's electricity that comes from renewable generation. The result is a grid-average measure describing what the regional system supplied, not a claim about supply contracts held by any individual operator.

Energy intensity is reported separately and means something narrower: the marginal energy cost of one further transaction, that is, the extra consumption caused by processing one more transaction on top of existing load. Because this infrastructure runs continuously whether or not blocks are full, that marginal quantity is small and declines as throughput grows.

Generation data comes from Share of electricity generated by renewables, compiled by Our World in Data from Ember and from the Energy Institute's Statistical Review of World Energy.

ZetaChain is present on the following networks: Binance Smart Chain, Ethereum, Zeta.

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.

The emissions figures for ZetaChain are calculated rather than metered, by converting the estimated electricity consumption into emissions using the carbon intensity of the grids the network draws on. The geographic distribution built for the energy assessment carries straight over: consumption assigned to each country or region is multiplied by that region's average emissions per unit of electricity generated, and the results are added together. Grid intensity differs by more than an order of magnitude across regions, so the assumed geography influences the outcome as strongly as the consumption estimate itself.

Two scopes are distinguished. Scope 1 covers emissions from sources the network's operators directly control, which in practice means fuel burned on site, typically in standby generation. That quantity is negligible for infrastructure of this kind and is normally treated as zero, because nodes are hosted in facilities that buy grid electricity rather than generate their own. Scope 2 covers the indirect emissions embodied in that purchased electricity and accounts for effectively the whole figure. Emissions from manufacturing the hardware, from constructing data centers, and from the wider operations of the organizations involved lie outside both scopes and are not included.

Greenhouse-gas intensity is defined in the same marginal terms as its energy counterpart: the emission attributable to settling one additional transaction, rather than an annual total divided by a transaction count. Reading it as an average would misrepresent a network whose machines draw power continuously irrespective of load.

Several uncertainties travel with the result. Grid intensity values are annual averages and cannot reflect the hours during which power was actually consumed. Contractual low-carbon supply arrangements, if any operator holds them, are invisible to a grid-average method. And wherever a comparable network stood in for locations that could not be resolved, that approximation propagates into the emissions estimate unchanged.

Carbon intensity data comes from Carbon intensity of electricity generation, compiled by Our World in Data from Ember and from the Energy Institute's Statistical Review of World Energy and published under the Creative Commons Attribution 4.0 license.