Index

General Information
Part A: Information about the offeror or the person seeking admission to trading
Part B: Information about the issuer, if different from the offeror or person seeking admission to trading
Part C: Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Part D: Information about the crypto-asset project
Part E: Information about the offer to the public of crypto-assets or their admission to trading
Part F: Information about the crypto-assets
Part G: Information on the rights and obligations attached to the crypto-assets
Part H: Information on the underlying technology
Part I: Information on the risks
Part J: Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts

2026-06-10

This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The operator of the trading platform of the crypto-asset is solely responsible for the content of this crypto-asset white paper.

This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.

The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid.

FALSE

The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.

Warning
This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.

BERA is the native gas and staking token of Berachain. Berachain is an EVM-identical Layer 1 blockchain built around Proof of Liquidity, an incentive system designed to align the chain, applications, validators and users around productive on-chain growth. Berachain remains compatible with Ethereum tooling and upgrades and is powered by BeaconKit, a modular consensus framework designed to support Ethereum-compatible blockchain networks.

BERA was launched with a genesis supply of 500,000,000 BERA and uses 18 decimal places. Its supply may increase by approximately 5% per year through Proof-of-Liquidity reward emissions distributed in the form of WBERA, subject to applicable governance parameters. The supply of the crypto-asset may also decrease, as BERA is used to pay transaction fees on the network, which are burned.

Holders of the BERA crypto-asset do not, solely by acquiring or holding BERA, acquire any ownership, equity, profit participation, repayment, redemption or compensation rights against any identified issuer, the Berachain Foundation, Bera Chain or any other natural or legal person. Holding BERA does not give rise to contractual claims or entitlements against any natural or legal person.

Not applicable

The token has been admitted to trading to the trading platform operated by Bitstamp Europe S.A. on its own initiative.

TRUE

Bera Chain Foundation

The legal issuer of BERA has not been expressly identified in official public sources relating to the BERA token.

However, official Berachain materials identify the Bera Chain Foundation as an entity involved in the BERA token distribution and in the operation and development of the Berachain ecosystem. The official BERA Token Airdrop Terms and Conditions https://airdrop.berachain.com/tos state that participation in, and receipt of, BERA tokens through the airdrop programme is organised by Bera Chain Foundation, referred to in those terms as the “Foundation”. The terms also state that eligibility and allocation of tokens under the airdrop are determined by the Foundation in its sole discretion.

Accordingly, based on our best assessment, we regard Bera chain Foundation as the entity most closely associated with the development of the Berachain and potentially the coordination of the token issuance process.

K575

C/O Silverside Management Ltd, Citrus Grove, Ground Floor, 106 Goring Avenue, PO Box 31489, Grand Cayman

KY1-1206

C/O Silverside Management Ltd, Citrus Grove, Ground Floor, 106 Goring Avenue, PO Box 31489, Grand Cayman

KY1-1206

2022-03-07

2549001ZF9FCVDG42967

BE-387850

Not applicable

Bera chain Foundation’s business activity is in relation to BERA and the Berachain project consists of supporting the development, growth and operation of the Berachain ecosystem.

Not applicable

Bitstamp Europe S.A.

5GGB

40, avenue Monterey, L-2163, Grand Duchy of Luxembourg

LU-LU

40, avenue Monterey, L-2163, Grand Duchy of Luxembourg

LU-LU

2015-05-19

549300XIBGTJ0PLIEO72

Bitstamp Europe S.A. is registered with the Luxembourg Trade and Companies Register under the number B196856.

Robinhood Markets, Inc with its registered office at 85 Willow Road, Menlo Park, California 94025, USA.

Bitstamp Europe S.A., acting in its capacity as a crypto-asset service provider (CASP) and operator of a trading platform, has prepared this crypto-asset white paper to support the admission to trading of the crypto-asset on its platform and to provide users with the information required under Regulation (EU) 2023/1114 (MiCA).

Bitstamp Europe S.A. is a Crypto-Asset Service Provider authorised with the CSSF under the number N00000003 to provide the following crypto-asset services:

• providing custody and administration of crypto-assets on behalf of clients;
• operation of a trading platform for crypto-assets;
• exchange of crypto-assets for funds;
• exchange of crypto-assets for other crypto-assets;
• execution of orders for crypto-assets on behalf of clients;
• reception and transmission of orders for crypto-assets on behalf of clients; and
• providing transfer services for crypto-assets on behalf of clients.

Bitstamp Europe S.A. is a payment institution authorised by the CSSF under number Z00000012 to provide the following payment services:

3.a) execution of direct debits, including one-off direct debits,

3.b) execution of payment transactions through a payment card or a similar device,

3.c) execution of credit transfers, including standing orders and

6.) money remittance.

Bitstamp Europe S.A. has notified the cross-border provision of payment services and of crypto-asset services in all EU and EEA member states.

Bitstamp has admitted the asset to which this white paper relates to, to trading on its own initiative on its trading platform.

Robinhood Markets, Inc. is the parent holding company of the Robinhood group.

MiCA Crypto Alliance Limited

MiCA Crypto Alliance Limited was mandated to assist in the white paper preparation by Bitstamp Europe S.A. Bitstamp Europe S.A. retains the role of person seeking admission to trading.

Berachain

BERA

BERA

Berachain is an EVM-identical Layer 1 blockchain powered by Proof of Liquidity. Proof of Liquidity is Berachain’s system for directing network emissions towards useful economic activity and rewarding participants who secure the chain, allocate emissions, provide liquidity and build applications.

The core components of a Berachain node are a consensus client, BeaconKit, and an execution client, with Bera-Reth identified as the recommended execution client. Bera-Geth, a fork of the go-ethereum client, has also been supported as an execution client and is subject to a formal deprecation proposal (BRIP-0009) in favour of Bera-Reth. BeaconKit is Berachain’s consensus client and framework for EVM chains, while the execution client handles transactions, transaction gossiping, state management and support for the Ethereum Virtual Machine.

FALSE

Not applicable

Past milestones

The Proof of Liquidity launch took place in January 2025, with the public release of the Honey Paper and Berachain mainnet.

The Berachain Foundation announced on 5 February 2025 the BERA token airdrop as part of the Berachain launch, detailing the overall distribution framework and eligibility criteria across different groups, enabling holders to verify their allocation and understand the claim process, while reinforcing the broader narrative behind the token distribution and highlighting the role of early community participation in the development of the Berachain ecosystem.

On 21 March 2025, Berachain announced “Berachain Governance Phase 1: First Whitelisted Reward Vaults Approved”. The announcement stated that, from 24 March 2025, the first batch of reward vaults beyond existing BEX pools would go live, enabling more applications to compete for emissions and direct incentives to validators and users. The announcement described this as the beginning of Phase 1 of Berachain governance and a move from a limited launch within native BEX pools towards a more open, application-first ecosystem.

On 28 March 2025, Berachain stated that the second batch of Proof-of-Liquidity reward vaults had been approved and that, starting on 31 March 2025, a new set of vaults would go live across the Berachain ecosystem.

On 7 April 2025, Berachain stated its governance was evolving as the network scaled. It introduced new standards for RFRV submissions, added clarity around token and incentive eligibility, and set out a more structured process for future submissions.

Proof of Liquidity updates were implemented in April 2025, including support for a maximum of three incentive tokens per reward vault and modifications to block reward emissions. At the time of those updates, Berachain's inflation framework targeted annual Berachain Governance Token (BGT) emissions of approximately 10%. Subsequently, Bera Labs proposed reducing the target annual BGT inflation rate to approximately 5% in order to reduce dilution, improve sustainability and emission efficiency, and align more closely with other Layer 1 blockchain networks.

14 April 2025, Berachain stated that RFRV Batch 3 was live and that the full five-member Governance Guardian council had been announced. It also stated that the Governance Guardian council would ratify reward vaults moving forward.

BERA staking was launched in July 2025, allowing users to earn yield on BERA through the Hub. The WBERA staker vault and incentive fee collector contracts also shipped, and Proof-of-Liquidity incentive fees flowed through the collector to BERA stakers

Reward vault rate-based emissions were added in July 2025, allowing reward vault managers to configure emissions to flow at a target per-second rate, with the distribution period computed automatically from the reward amount and target rate.

A validator commission cap was introduced in July 2025, capping validator commission on incentive tokens at 20% and automatically capping existing validators with rates above 20%.

Safe integration documentation for adding incentives to a reward vault from a Safe multisig was added in October 2025.

Proof-of-Liquidity integration updates were added in October 2025, including Incentivize Anything playground examples.

Staking pools were released in February 2026, and validator-operated liquid staking went live. Validators could deploy a pool, offer stBERA liquid shares to their community, and earn commission on Proof-of-Liquidity incentives flowing through their validator. Stakers could deposit any amount of BERA, receive auto-compounding stBERA, and withdraw through a shared WithdrawalVault with an on-chain finalisation delay.

Bera-Geth, a fork of the Go-Ethereum execution client, was formally proposed for deprecation on 20 January 2026 through BRIP-0009. The proposal was subsequently finalised, establishing Bera-Reth as the primary and officially supported execution client for the Berachain network.

Future milestones

The Proof of Liquidity roadmap states that Proof of Liquidity changes over time and identifies the next major roadmap item as “May 2026 - PoL Next”. The Proof-of-Liquidity (PoL) next upgrade is intended to simplify the Berachain token model by consolidating Proof-of-Liquidity mechanics into sWBERA, making emissions BERA-based, phasing out boost mechanics and directing incentives into sWBERA. It also states that businesses would integrate once, users would no longer need to learn PoL-specific concepts, and value would flow through a single predictable rail.

The Proof-of-Liquidity changes launched approximately 24 hours before the Fusaka hardfork, with activation on Bepolia on 26 May 2026 and the mainnet will be activated on 23 June 2026.

The genesis supply of BERA is 500,000,000 BERA. Of this amount, 84,000,000 BERA, representing 16.8% of the genesis supply, is allocated to initial core contributors, including advisors and members of Big Bera Labs, the core contributors to the Berachain blockchain. A further 171,500,000 BERA, representing 34.3% of the genesis supply, is allocated to Seed, Series A and Series B investors.

The remaining 244,500,000 BERA, representing 48.9% of the genesis supply, is allocated to the community. This community allocation includes 79,000,000 BERA, representing 15.8% of the genesis supply, for an airdrop to testnet users, Berachain and ecosystem NFT holders, social supporters, ecosystem decentralised applications and community builders. It also includes 65,500,000 BERA, representing 13.1% of the genesis supply, reserved for future community initiatives, including incentive programmes, grants and other initiatives involving community input through Snapshots, requests for proposals and similar mechanisms. In addition, 100,000,000 BERA, representing 20% of the genesis supply, is allocated to ecosystem and research and development purposes, including ecosystem development, research and development, growth, Berachain Foundation operations, developer programmes, node operator delegations and the evolution of Proof of Liquidity.

All allocated parties are subject to the same vesting terms, consisting of a 1-year cliff with no unlock before the cliff, an initial unlock of approximately 16.67% after the cliff, and linear vesting of the remaining allocation over the following 24 months.

Not applicable

Bitstamp Europe S.A. has admitted the token to trading based on its market considerations.

When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account. If a client wants to hold the token in their own wallet, they will need to (i) provide an external blockchain wallet address, where the crypto-assets will be sent if a withdrawal is initiated and (ii) satisfy all other requirements applicable to a withdrawal in line with the Regulation (EU) 2023/1113 of the European Parliament and of the Council of 31 May 2023 on information accompanying transfers of funds and certain crypto-assets.

When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account and a client does not need to fulfill any other technical requirement to hold the crypto-assets on their Bitstamp account, apart from have either a computer or phone with an internet connection and appropriate software in order to interact with the Bitstamp services.

Bitstamp Europe S.A.

BESA

Investors can access the trading platform through https://www.bitstamp.net or via the Bitstamp applications.

There are no costs involved in creating an account on the trading platform, however trading fees and other costs apply in accordance with the fee schedule available at https://www.bitstamp.net/fee-schedule.

Not applicable

There are no conflicts of interest arising at the moment of writing the white paper in relation to the offer or admission to trading. Bitstamp Group has a strict Code of Conduct and Trading Policy in place. They both mitigate the possibility of conflicts of interest.

In accordance with the Code of Conduct all officers, directors, employees, agents, representatives, contractors and consultants (and other persons, regardless of job or position), are required to report any situation where there is the potential for conflict of interest between their interests and interests of Bitstamp. The Trading Policy that is in place within the Bitstamp Group prohibits all forms of market manipulation and has been designed to prevent insider trading.

Not applicable, as this point pertains to an 'offer to the public', whereas this white paper relates to admission to trading.

Not applicable, as this point pertains to an 'offer to the public', whereas this white paper relates to admission to trading.

Crypto-assets other than asset-referenced tokens or e-money tokens

BERA is used to pay for transactions on Berachain, and transaction fees paid in BERA are burned.

BERA is also used for validator staking. Validators stake BERA to enter the active validator set, and block-production probability is proportional to the amount of BERA staked. Additional stakers may deposit BERA to a validator directly or through a staking pool, subject to the applicable protocol procedures.

BERA also functions within Berachain’s PoL system. Proof of Liquidity is Berachain’s system for directing network emissions towards useful economic activity and rewarding participants who secure the chain, allocate emissions, provide liquidity and build applications. Block rewards are emitted as WBERA, which is wrapped BERA on a 1:1 basis. WBERA emissions are routed partly to validator operators and partly through BeraChef to Reward Vaults.

BERA or WBERA may also be deposited into the sWBERA Staking Vault, where depositors receive sWBERA. sWBERA accrues yield from the Incentive Auction and that users may participate by depositing BERA into the sWBERA Staking Vault.

Not applicable

BERA is the native gas and staking token of Berachain. Berachain is an EVM-identical Layer 1 blockchain built around Proof of Liquidity, an incentive system designed to align the chain, applications, validators and users around productive on-chain growth. Berachain remains compatible with Ethereum tooling and upgrades and is powered by BeaconKit, a modular consensus framework designed to support Ethereum-compatible blockchain networks.

BERA was launched with a genesis supply of 500,000,000 BERA and uses 18 decimal places. Its supply may increase by approximately 5% per year through Proof-of-Liquidity reward emissions distributed in the form of WBERA, subject to applicable governance parameters. The supply of the crypto-asset may also decrease, as BERA is used to pay transaction fees on the network, which are burned.

Holders of the BERA crypto-asset do not, solely by acquiring or holding BERA, acquire any ownership, equity, profit participation, repayment, redemption or compensation rights against any identified issuer, the Berachain Foundation, Bera Chain or any other natural or legal person. Holding BERA does not give rise to contractual claims or entitlements against any natural or legal person.

Berachain

www.berachain.com

2026-07-11

2026-07-10

Not applicable

English

C75S6N2RJ

L7XQXLN44

FALSE

TRUE

TRUE

Not applicable, holders of the BERA crypto-asset do not, solely by acquiring or holding BERA, acquire any ownership, equity, profit participation, repayment, redemption or compensation rights against any identified issuer, the Bera Chain Foundation, Bera Chain or any other natural or legal person. Holding BERA does not give rise to contractual claims or entitlements against any natural or legal person.

Accordingly, all functionalities associated with BERA are functional and protocol-based. They include the ability to use BERA for transaction fees, staking-related functions and participation in Berachain’s Proof-of-Liquidity mechanisms where applicable. These functionalities are further described in F.2.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable

FALSE

Not applicable

Not applicable

TRUE

Not applicable

Not applicable

FALSE

Not applicable

FALSE

Not applicable

FALSE

Not applicable

There is no written legal agreement between the issuer and the crypto asset-holder that sets out the laws that govern the legal relationship between those two parties. In the absence of such an agreement, the laws that govern that relationship will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

There is no written legal agreement between the issuer and the crypto asset-holder that sets out which jurisdiction's courts will have authority to deal with a dispute between the crypto asset-holder and the issuer. In the absence of such an agreement, the laws of the competent court will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

Not applicable as DTI is provided in F.13

Networking, transport and session

Berachain nodes operate through a split architecture in which validator nodes and RPC nodes each run both an execution client and a consensus client. The execution client handles EVM transaction processing and state transitions and the consensus client coordinates validator agreement and block finalisation. BeaconKit communicates with the execution client through the Engine API, a JSON-RPC interface that separates the responsibilities of transaction execution and consensus while allowing the consensus layer to drive block production and finality. Validator nodes are eligible to propose blocks and receive block rewards. RPC nodes serve the same architecture but without participation in consensus.

EVM-compatible wallets and applications interact with Berachain through standard RPC endpoints. The mainnet connection parameters are RPC URL https://rpc.berachain.com/, chain ID 80094, currency symbol BERA, and block explorer https://berascan.com/.

Serialisation and data structures

Berachain's execution layer preserves Ethereum-style transaction compatibility through Bera-Reth whilst also defining a Berachain-specific Proof of Liquidity transaction type for protocol-level reward distribution. This custom transaction type is assigned the value 126 (hexadecimal 0x7E). Its structure includes a chain identifier, sender address, destination address, nonce, gas limit, gas price, and input data. The payload is encoded using recursive length prefix encoding, and the transaction hash is computed using Keccak-256 over the typed encoding, giving the Proof of Liquidity transaction a deterministic binary representation and identifier. Proof of Liquidity transactions are generated by the protocol and originate from a designated system address rather than from an ordinary user signing process.

Cryptography and key material

EVM-identical execution and compatibility with EVM-based wallets allow BERA accounts to be generated and managed using the same cryptographic primitives as Ethereum. Berachain's execution environment is identical to the Ethereum Virtual Machine as used on Ethereum Mainnet, which specifies ECDSA over the secp256k1 elliptic curve for account key material. Accounts are identified by addresses derived from an ECDSA public key over the secp256k1 elliptic curve. Private keys and account access are held exclusively by the user. Hardware wallets that support EVM accounts are compatible with Berachain through standard RPC configuration.

Ledger, state and execution

BERA has a genesis supply of 500,000,000 tokens and uses 18 decimal places. Annual inflation is approximately 5%, distributed as WBERA through the Proof of Liquidity emission system and subject to governance. Transaction fees paid in BERA are burned on inclusion, permanently reducing circulating supply.

Execution takes place in an EVM-identical environment via Bera-Reth. Bera-Reth processes transactions, constructs execution payloads, and applies EVM state transitions. Berachain keeps pace with Ethereum improvements and ships protocol upgrades approximately every six months. During block construction, Bera-Reth selects transactions from the transaction pool and enforces block gas limits. Proof of Liquidity system transactions are injected as protocol-level operations and handled separately from ordinary user transactions. BeaconKit manages the consensus layer and communicates execution results through the Engine API. The current mainnet-recommended versions are BeaconKit v1.3.9 and Bera-Reth v1.3.3.

Implementation and architecture

Berachain uses a modular Layer 1 architecture with structurally distinct execution and consensus clients. BeaconKit provides the consensus-client framework and is built around modified CometBFT consensus, using validator voting through prevotes and precommits. Bera-Reth, a lightly modified fork of the Reth execution client, handles EVM execution and supports Berachain-specific transaction logic. Validator and RPC nodes both run an execution client and a consensus client in tandem.

Berachain deposits are consumed from the execution payload's request list in accordance with EIP-6110. Each execution-layer block that includes deposit transactions surfaces them as a deposit event from the BeaconDeposit contract. BeaconKit parses and applies the deposit in the same block. There is no follow distance or per-epoch processing queue, and once the execution-layer block is finalised, the deposit is reflected in validator state.

The contracts repository uses Foundry tooling for building and testing the Berachain contract suite.

Deployed contracts and addresses

The following core protocol contracts are deployed on Berachain mainnet. All contracts are verified on Berascan, and ABI files are published in the berachain/ abis repository.

BGT was used in earlier iterations of Proof of Liquidity for governance weight and reward routing. It is now deprecated and no longer influences validator reward allocation, block rewards, or ecosystem proposals. Existing BGT holders may redeem it for BERA via the Berachain Hub.

BERA is the native asset of the Berachain Layer 1 rather than a contract-deployed token. Its presence and balances are maintained at the protocol level through Bera-Reth state management rather than through a smart contract. WBERA is the wrapped, ERC-20-compatible representation of BERA on a 1:1 basis; its contract address is 0x6969696969696969696969696969696969696969. The sWBERA Staking Vault (0x118D2cEeE9785eaf70C15Cd74CD84c9f8c3EeC9a) issues sWBERA in exchange for deposited BERA or WBERA.

Validators may additionally operate staking pools via smart contracts, enabling liquid staking services for their communities. Staking pool participants receive liquid shares (stBERA) that grow in value as rewards accumulate. Staking pool contracts are governed by the berachain/contracts-staking-pools repository.

BERA is the native asset of a Layer 1 network and does not inherit consensus from another chain. Consensus is provided by Berachain's own stack: BeaconKit as the consensus framework, Bera-Reth as the execution client, and the Engine API connecting the two.

BeaconKit uses modified CometBFT consensus. Validators exchange prevotes and precommits; a block is finalised immediately when more than two-thirds of validators have committed to it. This produces single-slot finality. There are no block-depth confirmation requirements and no chain-reorganisation risk after finalisation, in contrast to Ethereum's approximately 13-minute finality window.

The active validator set is capped at 69 validators, selected as the top 69 by staked BERA. Entry requires a minimum deposit of 250,000 BERA; no single validator may stake more than 10,000,000 BERA. A validator's voting power is the amount of BERA deposited, rounded down to the nearest 10,000 BERA. Block proposal probability within the active set is proportional to this voting power. Deposits are processed via the BeaconDeposit contract on the execution layer and reflected in validator state in the same block, using the EIP-6110 deposit flow.

Validators progress through a defined lifecycle: Deposited, Eligible, Active, Exited, and Withdrawn. After one epoch in the Deposited state, a validator becomes Eligible; after a further epoch it enters the Active state. Exit occurs voluntarily or when a higher-stake validator displaces the lowest-ranked participant in the active set. On exit, all staked BERA is returned to the validator's pre-registered Withdrawal Credentials Address after one epoch delay. Validators removed from the active set cannot be reactivated using the same CometBFT identity.

Validator block production triggers Proof of Liquidity reward routing, linking consensus participation to application-side liquidity incentives. The specific emission parameters and routing mechanics are described in H.5.

Network-level execution fees

BERA is the asset used to pay transaction fees on Berachain. All fees collected are burned, removing the paid amount from circulation permanently. The fee-burn design separates ordinary transaction cost from the Proof of Liquidity reward mechanisms used for validator and vault incentives.

Protocol-level reward flows

Block rewards are emitted as WBERA. Each block carries two reward components. The base emission of 0.4 WBERA per block is paid directly to the block-producing validator's operator address. A variable Reward Vault emission, currently set at up to 1.305 WBERA per block, is routed through BeraChef to whitelisted Reward Vaults according to each validator's configured reward allocation weights. The variable portion is calculated using a formula that incorporates a boost parameter reflecting the validator's relative position within network incentive delegation. Both components are emitted by the BlockRewardController. Emitted WBERA is streamed to Reward Vault stakers over a rolling three-day distribution window rather than being instantly claimable, creating a sliding accumulation period.

BeraChef manages validator reward allocation. Each validator may configure a custom allocation specifying the proportion of their variable WBERA reward to route to each eligible Reward Vault. Allocation weights must sum to 100 and take effect after a 450-block delay. If a validator does not update its allocation within approximately 302,400 blocks (seven days), BeraChef applies a baseline allocation directing emissions to vaults with active incentives. Validators receive protocol-provided incentive tokens from the Reward Vaults to which they route emissions, and may charge a commission on those incentive tokens. The default commission rate is 5% and the maximum is 20%, enforced by the BeraChef contract.

Governance controls two additional surfaces within the Proof of Liquidity emission system. The DedicatedEmissionStreamManager governs Dedicated Emission Stream allocations, which allow a governance-defined carve-out of Reward Vault emissions to be directed to specific vault arrangements. Governance also sets the shared collector (FeeCollector) that receives redirected incentive tokens from factory-created vaults, converting them into WBERA-denominated yield for liquid staking through the sWBERA mechanism. The BGTIncentiveFeeCollector handles legacy incentive fee settlement.

WBERA serves as the single per-block emission token for Proof of Liquidity. sWBERA accrues yield through the Incentive Auction settlement mechanism: net incentive tokens received by the BGTIncentiveFeeCollector are auctioned for WBERA, and the proceeds are distributed pro-rata to sWBERA holders and registered LST Staker Vault participants.

Validator incentives and staking mechanics

The active validator set consists of the top 69 validators by BERA stake. Block proposal probability is proportional to staked BERA voting power (rounded to the nearest 10,000 BERA). Validators enter the active set by depositing at least 250,000 BERA, up to a maximum of 10,000,000 BERA per validator, via the BeaconDeposit contract. Validators who earn block rewards must claim them through the Distributor contract within 8,191 seconds of block production, or risk forfeiting those rewards.

BERA holders who do not operate a validator may stake their holdings directly to an active validator, providing delegation-based participation in block-production incentives through staking pools where operators offer this service.

Governance of parameters

Reward Vault creation is permissionless, but governance must whitelist a vault before validators can route emissions to it. The whitelisting process requires submission of a Request for Reward Vault form and a proposal thread on the Governance Forum. Governance controls vault whitelisting, Dedicated Emission Stream caps, incentive fee routing destinations, and emission parameters. Changes to governance-controlled parameters are subject to the Timelock contract delay, providing a reaction window before parameter changes take effect. On-chain governance is managed through the Governance contract, with the Timelock contract enforcing execution delays.

FALSE

TRUE

Zellic — Berachain PoL Patch Review — 6 February 2026

• Object: Review of a pull request introducing a Guaranteed Emission stream for a foundation-managed subset of Reward Vaults. Reviewed contracts included GuaranteedEmissionManagerDeployer, BeraChef, Distributor, GuaranteedEmissionManager, and RewardAllocatorFactory, specifically assessing whether the BGT emission token distributes correctly each time the distributeFor function is called.
• Results: Two findings identified — one low-severity issue and one informational issue. No critical, high, or medium findings were reported.
• Actions: The low issue (missing disable-initialiser protection in the GuaranteedEmissionManager implementation contract) was fixed in a subsequent commit. The informational issue (duplicate receiver checks in reward allocation) was acknowledged with off-chain validation and monitoring measures.

Sigma Prime — Bera-Reth and Bera-Geth Security Assessment — September 2025

• Object: Assessment of Berachain-specific changes in the Bera-Reth and Bera-Geth repositories, focusing on the enshrined Proof of Liquidity distribution transaction. The assessed change introduced a new PoL transaction type that automatically calls distributeFor for the previous block proposer at the start of each block.
• Results: Twenty issues identified — four critical, one medium, five low, and ten informational. The critical issues concerned cross-client consensus mismatches and malformed transaction handling, including inconsistent PoL transaction validation before Prague1, a gas-limit mismatch, missing RLP length validation, and empty-block validation after Prague1.
• Actions: All four critical issues were resolved. The medium issue (sender-vector misalignment affecting specific pending-tag RPC methods) was accepted as a non-consensus-critical risk.

Cantina — BeaconKit Security Competition — 21 February 2025

• Object: Competitive security review of BeaconKit conducted over the period from 20 December 2024 to 24 January 2025. Scope covered consensus, block processing, deposit handling, blob handling, and state-transition logic.
• Results: Thirty-six issues identified — zero critical, seven high, three medium, eight low, and eighteen informational. High and medium findings addressed deposit processing, proposal validation, execution-chain halt conditions, and state-transition checks.
• Actions: Findings and remediation recommendations were presented to the Berachain team for resolution.

Perimeter — BeaconKit Defensive Fuzzing — 7 January 2025

• Object: Defensive fuzzing of BeaconKit invariants using Medusa, targeting consensus and state-transition behaviour through generated input scenarios.
• Results: No fewer than 10,000,000 invariant-test instances were executed. This assessment complements manual reviews by testing invariant preservation under a large volume of automatically generated cases.
• Actions: Assurance provided through automated adversarial testing coverage. No novel discrete vulnerabilities were reported.

Perimeter — Proof of Liquidity Defensive Fuzzing — 7 January 2025

• Object: Defensive fuzzing of Proof of Liquidity contract invariants using Echidna and Medusa, targeting contract-state transitions under generated inputs.
• Results: No fewer than 50,000,000 invariant-test instances were executed, increasing coverage of PoL contract behaviour under adversarial conditions.
• Actions: Assurance provided through automated adversarial testing coverage. No novel discrete vulnerabilities were reported.

Quantstamp — Berachain Native Smart Contracts — 14 January 2025

• Object: Security review of native smart contracts covering staking, stablecoin, and governance code.
• Results: Fifteen findings in total across severity categories.
• Actions: The majority of salient findings were fixed or mitigated, as recorded in the report's final status table.

Spearbit — Proof of Liquidity Security Review — 22 November 2024

• Object: Security review of Berachain Proof of Liquidity contracts over a 14-day engagement, covering the contract-monorepo protocol components governing emission routing and validator-linked reward flows.
• Results: Twenty-seven issues identified across severity levels.
• Actions: Sixteen issues fixed; eleven issues acknowledged. The remediation summary distinguishes fixed items from acknowledged items.

Spearbit — Governance Security Review — 24 October 2024

• Object: Security review of Berachain governance contracts including BerachainGovernance and Timelock-related logic, covering upgradeable-contract initialisation and governance-controlled behaviour.
• Results: Findings included a UUPS initialisation issue in the upgradeable contract structure.
• Actions: The UUPS initialisation issue was fixed by Berachain and resolved by Spearbit. Governance controls key Proof of Liquidity parameters and vault whitelisting mechanisms.

Nethermind — Proof of Liquidity Review — 27 November 2024

• Object: Independent review of Proof of Liquidity contracts supporting emissions, vaults, and reward routing.
• Results: Four points of attention identified, characterised as informational or best-practice observations rather than higher-severity vulnerabilities.
• Actions: Findings documented. No critical or high-severity remediation was required.

Guardefy / Panprog — Proof of Liquidity Audit — 14 October 2024

• Object: Security audit of Berachain Proof of Liquidity contracts covering reward distribution, vault interaction, and validator-linked incentive design across high, medium, and low severity categories.
• Results: Findings reported across high, medium, and low severity categories.
• Actions: Findings addressed by the Berachain team in accordance with the report.

Market volatility and liquidity

BERA is subject to material price fluctuations arising from broader crypto-asset market conditions, trading venue depth, macroeconomic events, and project-specific developments. Liquidity can vary significantly across centralised exchanges, bridging routes, and decentralised pools, which may widen spreads, increase slippage, or impair execution at expected prices during periods of market stress.

Irreversibility of transactions

Transfers and other on-chain operations involving BERA are final once included in a finalised block and cannot be reversed at protocol level. Erroneous transfers, fraudulent interactions, or mistaken wallet operations may result in permanent loss with no recovery mechanism at the protocol or interface level.

Key custody and wallet security

Control over BERA depends entirely on the private key for the relevant wallet. Loss, theft, destruction, or mishandling of private keys permanently prevents access to associated BERA. No key recovery mechanism is offered by Berachain or the Bera Hub interface, and no third-party custodian holds keys on users' behalf.

Trading venue and interface access

Access to BERA trading or transfers may be affected by exchange listing decisions, venue policies, geographic access restrictions, and sanctions controls. The Bera Hub interface may restrict, suspend, or terminate access for affected users, and applicable eligibility conditions include prohibitions on restricted, sanctioned, or blocked persons, as well as VPN-circumvention prohibitions. Interface restrictions do not prevent on-chain transfer of BERA but may impair access to the official platform features.

Gas and transaction cost variability

All Berachain transactions require payment of fees in BERA. Displayed fee estimates are indicative and may differ from amounts paid on execution. Estimation errors or fee changes can affect the economic outcome of transfers, staking actions, and other on-chain interactions.

Delisting Risks

Bitstamp Europe S.A. might remove the token from trading in line with Bitstamp Markets Trading Rules.

Operator and legal-entity risk

Berachain Corporation and the Berachain Foundation are the entities associated with the Berachain site and services. Neither entity is authorised or regulated by a financial services regulatory authority in relation to the provision of financial services, investment services, or crypto-asset services. As a result, they are not subject to prudential supervision, capital adequacy requirements, or the conduct of business rules applicable to regulated financial institutions. Accordingly, users do not benefit from regulatory protections typically available in regulated environments, including compensation schemes, regulatory mediation, or supervisory complaint mechanisms. Any entity-level events, such as restructuring, dissolution, or other legal or operational changes, may impact disclosures, platform access, or the continuity of ecosystem-related services.

Regulatory and jurisdictional exposure

While BERA is the subject of this white paper submitted under Regulation (EU) 2023/1114, regulatory classifications applicable to BERA and to the entities operating the Berachain ecosystem may differ across jurisdictions outside the European Union. In jurisdictions without an equivalent comprehensive crypto-asset framework, regulatory authorities may apply existing financial instruments, securities, or payments regulation in ways that affect Bera Chain Foundation's and Berachain Corporation's ability to operate, make disclosures, or continue support activities. Sanctions regimes, anti-money laundering obligations, or new legislative requirements in any jurisdiction could impose compliance burdens on these entities, restrict the availability of services, or require changes to the Berachain ecosystem's operations that affect BERA holders.

Liability and dispute constraints

The Bera Hub Terms of Use limit the liability of the operating entities to a fixed financial cap per claim and require that most disputes be resolved through confidential, binding individual arbitration rather than through courts or class proceedings. BERA holders who suffer loss as a result of platform malfunction, service interruption, interface error, or disputed transaction have limited options for legal recovery: compensable amounts are capped, class actions are excluded, and arbitration must be conducted under specified procedural rules. Practical barriers to dispute resolution may therefore prevent full recovery even where a holder's loss arises directly from the actions or omissions of the platform operators.

Supply and inflation dynamics

BERA launched with a genesis supply of 500,000,000 BERA. Approximately 5% annual inflation is added through Proof of Liquidity WBERA emissions, subject to governance adjustment. Simultaneously, transaction fees are burned. The net supply trajectory depends on the balance between emission rates and fee-burn volumes, both of which are subject to on-chain governance and network usage patterns.

Allocation and unlock concentration

34.3% of the genesis supply was allocated to investors and 16.8% to initial core contributors, subject to a one-year cliff followed by an initial unlock and linear vesting over 24 months. Concentrated allocations and scheduled unlock events can create increased sell-side pressure or governance influence at or after vesting milestones.

Utility and demand dependency

BERA functions as the native gas and staking token for Berachain. Demand depends on network usage, validator participation, application activity, and the continued relevance of Proof of Liquidity incentives. Sustained reduction in any of these drivers can reduce demand for BERA without a corresponding reduction in circulating supply.

Staking and validator participation risk

Validators must stake BERA and block proposal probability is proportional to staked BERA. Validator exit, withdrawal timing, or stake concentration can affect network operations, reward expectations, and the economic position of stakers. All staked BERA on a validator returns to a single pre-registered Withdrawal Credentials Address on validator exit, which may impair orderly fund return for stakers who delegated without verifying withdrawal arrangements.

Active-set concentration

The active validator set is capped at 69 validators. Liveness, block production, and reward allocation all depend on this bounded group of operators, concentrating risk in the event of coordinated failure, unavailability, or misconduct within the active set.

Staking-pool and liquid-staking risk

Validator-operated staking pools issue liquid stBERA shares to stakers. Stakers using these pools assume smart-contract risk, validator-operational risk, withdrawal-timing risk, and share-accounting risk in addition to ordinary BERA custody risk. Staking pool contracts include an emergency pause mechanism and automatic full-exit triggers if the minimum balance threshold is breached, but these controls do not guarantee loss prevention in all scenarios.

sWBERA unbonding and opportunity cost

sWBERA is a yield-bearing receipt token representing a staked BERA position in the WBERA Staker Vault. Unstaking requires initiating a withdrawal request that enters a seven-day unbonding period. Shares are burned at the time of queue, so assets reserved during unbonding do not compound or earn Incentive Auction yield. Users requiring immediate liquidity cannot exit without accepting this delay.

Emergency hard-fork authority

Berachain's core development team has demonstrated the ability to execute emergency protocol changes that halt or alter network state without prior community governance. In November 2025, following a Balancer V2 exploit targeting BEX liquidity pools, Berachain deployed an emergency hard fork (Prague3) that imposed account and transfer freezes, followed by a second hard fork (Prague4) reversing those freezes. This sequence confirms that the network can be altered by its core team outside the standard governance process, creating uncertainty for holders regarding finality and protocol immutability in extreme circumstances.

Public-ledger privacy

All BERA transactions are recorded on a public blockchain and can be viewed and analysed by any third party. Address-level activity may be correlated with personal information collected through official services, potentially enabling de-anonymisation.

Proof of Liquidity implementation risk

Proof of Liquidity is a novel mechanism designed to align validator, application, and user incentives through emission routing. Defects in this mechanism, misconfigured emission weights, or misaligned incentive design could distort reward flows, reduce participation, or fail to produce the intended relationship between validators and ecosystem applications.

Governance and emissions-control concentration

BeraChef's reward allocation configuration, Reward Vault whitelisting, and Dedicated Emission Stream settings are controlled through on-chain governance. Concentrated influence over governance processes can determine which protocols receive WBERA emissions, how incentive fees are routed, and how emission parameters are adjusted over time. Governance decisions that favour particular validators or vaults can distort the competitive balance of the Proof of Liquidity system.

Reward Vault whitelisting and eligibility risk

Reward Vaults must be whitelisted through governance before validators can direct WBERA emissions to them. Governance decisions, inconsistent application of eligibility criteria, or emergency veto actions can affect which protocols receive BERA-linked incentives or result in existing whitelist approval being revoked.

Ecosystem incentive sustainability risk

Reward Vault eligibility requires live, verified contracts, a minimum of 2 months of active incentives, and a target of at least USD 10,000 per month in incentive value. Incentive programmes that fall below these thresholds, are delayed, or are withdrawn can reduce expected application liquidity and weaken the utility case for BERA-driven participation.

Validator operations risk

Validators must maintain node infrastructure, consensus identity, execution operator identity, and withdrawal credentials. Operator misconfiguration, inadequate monitoring, failure to follow production guidance, or failure to upgrade client software within required time windows can affect validator uptime, reward generation, and withdrawal execution.

Upgrade execution and client deprecation risk

Berachain ships protocol upgrades approximately every 6 months and publishes specific version requirements for continued chain following. BRIP-0009 proposes the formal deprecation of Bera-Geth in favour of Bera-Reth. Node operators running Bera-Geth must migrate to Bera-Reth or risk losing chain synchronisation after the Fusaka hard fork. Additionally, Berachain plans to migrate BEX from Balancer V2 to Balancer V3 to address the disclosed and exploited vulnerability in the current BEX vault logic. Delays in or failures to execute these migrations on schedule create chain-following and liquidity risk.

RPC and infrastructure dependency risk

Users and applications relying on public RPC endpoints are subject to rate limits and shared resource constraints. Indexer lag, endpoint unavailability, or high network demand may delay transaction submission or distort the apparent state of BERA balances and transactions in interfaces relying on these data sources.

Native application dependency risk

Berachain's ecosystem includes BEX as a native decentralised exchange and Bend as a native lending protocol. Defects, exploits, or economic failures in these applications affect liquidity depth and user confidence supporting BERA utility, even where BERA itself is not the affected contract.

Data handling and privacy risk

Blockchain addresses, wallet information, balances, transaction histories, and connected-application data may be collected through official services. Blockchain information may be combined with personal information, creating profiling risks that persist independently of service access, given the public nature of the Berachain ledger.

Third-party disclosure risk

Personal and blockchain information may be shared with affiliates, identity-verification providers, analytics providers, other service providers, business partners, and legal or regulatory authorities. This creates dependency, confidentiality, and regulatory risks that are outside the direct control of BERA holders.

Service continuity and interface access risk

The Bera Hub interface and associated Berachain platform services may impose jurisdictional restrictions, eligibility conditions, and sanctions controls that limit access for specific users or regions. The platform may be restricted, suspended, modified, or discontinued. External events including regulatory intervention, network-level disruptions, software failures, or force-majeure circumstances may independently impair access to BERA-related platform features. Interface restrictions do not affect the on-chain transferability of BERA but can materially impair access to staking, reward claims, governance participation, and other platform-dependent functions.

Consensus and client implementation risk

Berachain uses BeaconKit with modified CometBFT consensus, paired with a separated execution client. Bugs, version skew between consensus and execution clients, or Engine API integration errors can disrupt block production, finality, state visibility, or network operation. The network is currently in active development with regular protocol upgrades, each carrying integration and compatibility risks.

EVM execution risk

Berachain operates with Bera-Reth, a lightly modified fork of the Reth execution client. Execution-client defects, regression from upstream changes, or incompatible modifications to EVM behaviour can affect transaction processing, application compatibility, and node reliability.

Smart-contract and protocol logic risk

Berachain's core systems and native applications rely on smart contracts for staking, Proof of Liquidity distribution, BEX trading, Bend lending, Reward Vaults, and related functions. Logic defects, access-control failures, or unexpected contract interactions can cause incorrect reward distribution, impaired swap execution, failed lending operations, or loss of user funds.

Upgradeable and proxy-contract risk

Staking pool deployment creates per-validator proxy contracts governed by a role-based access-control system with multiple privileged roles. Proxy or upgradeable deployments introduce risks arising from implementation, initialisation, or permission errors that may not be apparent until a contract upgrade or emergency action is executed.

Bridge and interoperability risk

Asset transfers into and out of Berachain may involve bridging infrastructure. The official BeraBridge is built on LayerZero wrapped asset bridge smart-contract technology. Bridge misconfiguration, relay failure, Decentralised Verifier Network (DVN) downtime, or cross-chain state desynchronisation can disrupt deposits, withdrawals, or wrapped-asset movements. Bridge risks are distinct from and independent of Berachain network risk.

Oracle and lending-market dependency risk

Bend's lending markets depend on oracle-provided price feeds for collateralisation, loan-to-value ratios, and liquidation triggers. Oracle failures, stale pricing, flash-loan manipulation, or incorrect market configuration can cause unfair liquidations, failed borrowing activity, or systemic under-collateralisation affecting BERA-adjacent liquidity on the network.

BEX and liquidity-pool risk

BEX uses pool contracts that govern swap mathematics and a single shared Vault contract that holds assets across all liquidity pools. Pool logic errors, vault access failures, or malicious token interactions can affect swap execution, liquidity provision, and price impact across the BEX trading environment.

Known BEX Balancer V2 vulnerability and prior exploit

BEX incorporates Balancer V2 contract logic and shares a vulnerability in the Balancer V2 Vault implementation disclosed on 21 January 2025. On 3 November 2025, this vulnerability was exploited against BEX liquidity pools, resulting in material losses across affected pools. Berachain responded with an emergency hard fork. Current liquidity providers in BEX are advised to monitor the Berachain documentation for front-end warnings regarding potentially vulnerable tokens. Berachain has stated plans to migrate BEX to Balancer V3, which addresses this vulnerability, but no confirmed mainnet timeline has been published as of the date of this white paper.

RPC, explorer, and indexer visibility risk

RPC nodes and block explorers provide access and visibility but do not themselves participate in consensus unless they are active validators. Rate limits, endpoint unavailability, parsing errors, or indexer lag can distort the apparent state of BERA transactions in user interfaces that depend on these data sources.

Quantum computing risk

Berachain account security relies on ECDSA using the secp256k1 elliptic curve, the same cryptographic standard used by Ethereum. This scheme is vulnerable to Shor's algorithm running on a sufficiently powerful quantum computer, which could theoretically derive private keys from exposed public keys. While no quantum computer with sufficient capability exists today, advances in quantum hardware could render this standard insecure in the long term. Berachain does not currently implement post-quantum cryptographic primitives. Migration to post-quantum standards would require a protocol upgrade and coordinated adoption across the full ecosystem of wallets, clients, and applications.

Open-source and software integrity risk

Berachain's clients and contracts use open-source components. Undetected bugs or supply-chain compromises introduced into upstream dependencies could propagate into deployed code. Contract compilation, deployment, and upgrade processes carry integrity risks if developer environments, signing keys, or CI/CD pipelines are compromised.

Offer-Related Risks

• Key custody and wallet security: Private keys are held exclusively by the user. No key escrow, recovery, or custodial mechanism exists at the protocol level. This eliminates centralised key-management failure as an attack surface while placing full responsibility for key protection on each holder.
• Trading venue and interface access: Eligible-user controls, sanctions screening, and VPN-circumvention prohibitions apply at the Bera Hub interface. These restrict access by non-eligible users at the platform level, independently of BERA's transferability on-chain.

Crypto-Asset-Related Risks

• Supply and inflation dynamics: Transaction fees are burned on execution, providing a deflationary offset to WBERA emissions. The annual inflation rate is approximately 5% and is subject to reduction through on-chain governance. BERA tokenomics, including genesis supply, allocation, vesting schedule, and inflation mechanics, are published in the official documentation and verifiable on-chain.
• Staking and validator participation risk: Validator stake requirements, withdrawal credential rules, and active-set mechanics are fully documented. Withdrawal credentials must be registered at the first deposit and cannot be changed thereafter, preventing validator operators from redirecting staked funds unilaterally after onboarding.
• sWBERA unbonding and opportunity cost: Withdrawal requests are represented as transferable ERC-721 NFTs, allowing users to transfer or sell a queued withdrawal position during the 7-day unbonding period if liquidity is needed. Cancellation of requests is permitted at any time before completion, with shares reminted at the current exchange rate.

Project Implementation-Related Risks

• Reward Vault whitelisting and eligibility risk: Reward Vault whitelisting requires verified on-chain deployment, a minimum TVL, at least one independent audit with no recent unresolved exploits, minimum incentive duration, and minimum monthly incentive value. An emergency veto mechanism allows immediate suspension of vault emissions in the event of security incidents or evidence of abuse, providing a circuit breaker outside the standard governance cycle. Existing whitelisted vaults are subject to periodic reevaluation and must continue to meet eligibility criteria.
• Validator operations risk: Production guidance, recommended client versions, and monitoring configuration (Prometheus and Grafana) are published. Operators are instructed to avoid exposing JSON-RPC and WebSocket ports to public networks and to verify client versions against published recommendations before each upgrade window.
• Upgrade execution and client deprecation risk: Upgrade-specific operator guidance and version requirements are published in the official documentation for each hard fork. The migration path from Bera-Geth to Bera-Reth is documented with a step-by-step guide available at https://docs.berachain.com/nodes/operations/bera-geth-to-reth.

Technology-Related Risks

• Smart-contract and protocol logic risk: Core protocol contracts, Proof of Liquidity contracts, BEX, Bend, and Reward Vault contracts have undergone multiple independent security reviews by firms including Spearbit, Quantstamp, Nethermind, Perimeter, Cantina, Sigma Prime, Zellic, and Zenith. All audit reports are publicly available at https://github.com/berachain/security-audits. A bug bounty programme hosted by Immunefi, with a maximum reward of USD 250,000 for critical vulnerabilities, provides an ongoing disclosure and incentive channel for external researchers.
• Known BEX Balancer V2 vulnerability: Front-end warnings are displayed on BEX for potentially vulnerable token interactions. Current BEX liquidity positions are not affected by the vulnerability. A migration to Balancer V3, which resolves the underlying vulnerability, is planned. Deployed BEX contract addresses and the security disclosure are published at https://docs.berachain.com/build/bex/deployed-contracts.
• RPC, explorer, and indexer visibility risk: Berascan is the official block explorer for Berachain. Official RPC and explorer endpoints are published in the documentation. Self-hosted RPC guidance is available for operators seeking to reduce dependency on shared public infrastructure.

Bitstamp Europe S.A.

549300XIBGTJ0PLIEO72

BERA

BERA is the native asset of a Layer 1 network and does not inherit consensus from another chain. Consensus is provided by Berachain's own stack: BeaconKit as the consensus framework, Bera-Reth as the execution client, and the Engine API connecting the two.

BeaconKit uses modified CometBFT consensus. Validators exchange prevotes and precommits; a block is finalised immediately when more than two-thirds of validators have committed to it. This produces single-slot finality. There are no block-depth confirmation requirements and no chain-reorganisation risk after finalisation, in contrast to Ethereum's approximately 13-minute finality window.

The active validator set is capped at 69 validators, selected as the top 69 by staked BERA. Entry requires a minimum deposit of 250,000 BERA; no single validator may stake more than 10,000,000 BERA. A validator's voting power is the amount of BERA deposited, rounded down to the nearest 10,000 BERA. Block proposal probability within the active set is proportional to this voting power. Deposits are processed via the BeaconDeposit contract on the execution layer and reflected in validator state in the same block, using the EIP-6110 deposit flow.

Validators progress through a defined lifecycle: Deposited, Eligible, Active, Exited, and Withdrawn. After one epoch in the Deposited state, a validator becomes Eligible; after a further epoch it enters the Active state. Exit occurs voluntarily or when a higher-stake validator displaces the lowest-ranked participant in the active set. On exit, all staked BERA is returned to the validator's pre-registered Withdrawal Credentials Address after one epoch delay. Validators removed from the active set cannot be reactivated using the same CometBFT identity.

Validator block production triggers Proof of Liquidity reward routing, linking consensus participation to application-side liquidity incentives. The specific emission parameters and routing mechanics are described in H.5.

See H.5

2026-01-01

2026-06-03

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at : www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Land use: 2158.84071 m²

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). Estimates on individual node weight, hazardous components and depreciation rate are used.
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). Usage of natural resources is approximated through land use metrics. Land use, water use and water recycling are calculated based on energy mix-specific estimates of purchased electricity land intensity, purchased electricity water intensity, and water recycling rates.
Full methodology available at: www.micacryptoalliance.com/methodologies