Berachain (BERA) sustainability report

NameBlockNodes SAS
Relevant legal entity identifier969500PZJWT3TD1SUI59
Name of the crypto-assetBerachain
Beginning of the period to which the disclosure relates2025-09-27
End of the period to which the disclosure relates2026-09-27
Energy consumption250422.48814 kWh/a

Consensus Mechanism

Berachain is present on the following networks: Berachain.

Berachain splits consensus from execution across two processes that every node operator runs side by side. Execution is handled by an Ethereum-compatible client holding the state and running the virtual machine; consensus is handled by a client built around a modified CometBFT engine, and the two communicate over the same engine interface Ethereum node software already uses. The result is an Ethereum execution environment settling under a Byzantine-fault-tolerant proof-of-stake engine rather than Ethereum's attestation and checkpoint machinery.

Consensus advances in timed rounds. A proposer is designated at each height in proportion to bonded stake, and a block commits once operators representing more than two thirds of bonded weight have voted for it, which makes it final in that same block: there are no attestation committees, no epochs and no delayed finalization. Where a proposer fails to deliver, the round times out and another operator proposes at that height. Entry to the active set is governed by bonded stake in the network's native asset. An operator must bond at least two hundred and fifty thousand units, is capped at ten million, and must rank among the top sixty-nine by bonded amount, a ceiling set by governance. Voting power follows the bonded amount rounded down to a fixed granularity, and an operator leaves the set only by exiting voluntarily or by being displaced by a larger entrant.

Proof of Liquidity describes what happens to the block reward rather than how blocks are ordered. Each block issues a fixed quantity of the native asset in its wrapped form, of which only a small fixed portion goes to the proposing operator. The larger portion is routed by an on-chain allocation contract into reward vaults, contracts that pay out to participants who have deposited approved liquidity positions, and operators decide how their allocation is spread across the approved vaults. Consensus participation therefore determines where liquidity incentives land, which is the design's distinguishing feature.

That design changed substantially after launch. Until July 2026 emissions were paid in a second, non-transferable asset that also carried governance rights, and an operator's emissions scaled with how much of it had been delegated to them. A hard fork removed that asset from the mechanism: emissions are now fixed per block, no longer scale with delegation of a separate token, and the retired asset has no remaining role in reward allocation or governance, with outstanding balances converting when claimed.

Incentive Mechanisms and Applicable Fees

Berachain is present on the following networks: Berachain.

Each block on Berachain issues a fixed quantity of the network's native asset in wrapped form, divided along fixed lines rather than by any variable weighting. A small fixed portion is credited to the proposing operator, and the larger fixed portion goes to the distributor that feeds reward vaults. Because both rates are constant, an operator's emissions no longer scale with delegated balances of a separate token, as they did before the July 2026 fork. Annual issuance from these emissions runs at roughly five percent of supply and is a governance parameter.

The vaults are where the incentive structure becomes unusual. A protocol wanting emissions steered toward its own liquidity supplies incentive tokens of its own to a vault. The operator whose allocation directed emissions there takes a commission on those incentive tokens, and what remains is auctioned for the wrapped native asset, with the proceeds accruing to the staking vault whose share token ordinary stakers hold. Depositors of eligible liquidity positions therefore collect the block emissions, the protocols seeking that liquidity pay for it in their own assets, and stakers who simply bond the native asset receive the value realized from selling those incentives. Allocation is granted through agreements that require demonstrable on-chain usage, replacing the earlier arrangement in which allocation was bid for through delegation-weighted voting.

Additional holders can add stake to an operator directly through the deposit contract or indirectly through pooling contracts, subject to the per-operator ceiling. Enforcement at the consensus layer works chiefly through forfeiture and exclusion: an operator that fails to propose when designated earns nothing for that slot, an operator that stops participating ceases to earn altogether, and an operator displaced from the active set has its bonded stake returned to its withdrawal address and must generate fresh consensus keys before re-entering.

Users pay for execution in the native asset under an Ethereum-style fee market. Every block carries a base fee per unit of gas that the protocol raises when blocks run above their gas target and lowers when they run below, and that base fee is burned, permanently removing those units from circulation. A separate priority tip, set by the sender, goes to the block producer. Contract execution and storage are metered through the standard virtual-machine gas schedule, with no recurring rent charged against stored state.

Energy consumption sources and methodologies

Berachain is present on the following networks: Berachain.

Berachain reaches agreement through bonded proof of stake, so the estimation approach applied here builds upward from the machines that run the network rather than from any model of mining hardware economics. The starting point is the size of the node population. Consensus operators can be enumerated from chain state; the surrounding population of full nodes, archive nodes, indexers and public endpoints cannot, and is approximated from crawling the peer-to-peer topology, from advertised endpoints and from operator directories, held as a range rather than a single number.

The chain's node architecture shapes the hardware profile in a specific way. A participant does not run one program but two: a consensus client and an execution client, operating as separate processes on the same host and exchanging work over the engine interface. The representative machine is therefore sized from the combined published requirements of both clients rather than from either alone, which raises the assumed processor, memory and storage specification above what a single-process chain would imply. Reward vaults and the allocation contracts that feed them are ordinary contract state executed by the same clients, so they add computational load but no separate infrastructure to count.

Power draw for each profile comes from laboratory measurement of comparable equipment under load and at rest. Idle draw is included deliberately, because machines of this kind are provisioned for peak demand and left running continuously, and that resting consumption forms much of the annual total. Multiplying profiles by the estimated population and by hours of operation yields the network figure, with an allowance added for hosting overhead. Where a figure is needed for one asset rather than the whole network, a share of the network total is attributed to it according to observed on-chain activity, and an asset present on several networks has its shares summed.

The honest qualifications are these. Node counts derive from public observation and will miss machines that stay unadvertised; a single hardware profile stands in for a varied and partly virtualized population; and none of this is metered measurement. Where evidence is absent the assumption taken is the one that raises the estimate, and figures are revised as observation improves.

Key energy sources and methodologies

Berachain is present on the following networks: Berachain.

The renewable share reported for Berachain is inferred rather than measured, by establishing where the network's machines are and then reading the electricity statistics of those places. The inputs are publicly observable: nodes advertise addresses so that peers can reach them, those addresses resolve to hosting providers and regions, and crawling the peer-to-peer layer repeatedly yields a country-level picture of the network. Regions disclosed by operators, and the known siting of the hosting facilities they use, tighten that picture further.

Because a participant runs a consensus client and an execution client on the same host, the two are treated as one physical location for this purpose; the architecture adds to the consumption attributed to a site without spreading it across additional ones. Where the geographic distribution still cannot be resolved with confidence, the observed spread of a structurally similar network is used instead, similar meaning that it rewards participation comparably and demands comparable hardware, so its operators weigh the same considerations when choosing where to host. That substitution approximates, and it is the largest single contributor to uncertainty in the published share.

Locations are then matched against public statistics on how electricity is generated in each country or region, weighted by the consumption attributed to each, and aggregated into the proportion of the network's electricity that comes from renewable sources. The figure is a grid average: it describes what the regional system delivered, not a supply contract held by any particular operator.

Energy intensity is a different measure and should not be confused with the total. It expresses the marginal energy cost of one further transaction, the additional consumption the network incurs by processing one more transaction on top of what it already handles. Since these machines run continuously whether blocks are full or nearly empty, that marginal quantity is small and shrinks as throughput increases.

Electricity generation statistics are drawn 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.

Key GHG sources and methodologies

Berachain is present on the following networks: Berachain.

Greenhouse-gas figures for Berachain follow from the energy estimate by way of the carbon intensity of the electricity the network consumes; they are not observed directly. The geographic distribution assembled for the energy assessment is reused without change: the consumption attributed to each country or region is multiplied by that region's average emissions per unit of electricity generated, and the products are summed across regions. Since grid intensity varies by more than an order of magnitude from one system to another, the assumed geography bears on the result as heavily as the quantity of electricity does.

Two scopes are kept apart. Scope 1 captures emissions from sources the network's operators directly control, in practice fuel combusted on site, chiefly in standby generation. For infrastructure of this kind the quantity is negligible and is generally treated as zero, since the machines sit in facilities that purchase grid electricity rather than generating their own. Scope 2 captures the indirect emissions embodied in that purchased electricity, and effectively the entire reported figure falls there. Emissions arising from manufacturing the hardware, from constructing the facilities that house it, or from the wider activities of the organizations that operate it fall outside both scopes and are excluded.

Greenhouse-gas intensity is defined marginally, in the same way as its energy counterpart: the emission attributable to settling one additional transaction, rather than an annual total divided by a count of transactions. Treating it as an average would misdescribe a network whose infrastructure consumes power continuously regardless of how much it is asked to do.

Uncertainty accumulates at each step. Grid intensity values are annual averages that cannot reflect the hours in which power was actually drawn. Low-carbon supply arrangements held contractually by an individual operator are invisible to a grid-average method. And where a comparable network substituted for locations that could not be established, that approximation passes through into the emissions estimate untouched.

Carbon intensity statistics are drawn 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 made available under the Creative Commons Attribution 4.0 license.