Exploring Berachain: Analysis of Native Protocols and Technical Highlights
TechFlow Selected TechFlow Selected
Exploring Berachain: Analysis of Native Protocols and Technical Highlights
Analyzing Berachain's architecture, the design of its three native applications, and the related contract execution processes.
Navigating Web3 tides with focused insightsAuthor: Beosin
Berachain, a blockchain receiving significant market attention, features multiple innovations and characteristics that have attracted extensive interest from the community and developers. Through its Proof-of-Liquidity (PoL) mechanism and three-token model, Berachain offers a unique solution to on-chain liquidity challenges. With Berachain preparing to launch its mainnet, it has introduced incentive programs and a token generation event (TGE) to attract and support early ecosystem users and projects.
This article explains Berachain's architecture, design of its three native applications, and related contract execution processes to help readers gain a deeper understanding of Berachain.
1. Architecture
Berachain is a Layer 1 EVM-equivalent chain that introduces a three-token model and a liquidity-based consensus mechanism (Proof-of-Liquidity), integrating liquidity, consensus, and governance mechanisms to provide greater incentives for liquidity providers within the chain’s ecosystem.
Berachain's architecture consists of two primary layers:
(1) BeaconKit Consensus Layer. This layer handles the blockchain's consensus mechanism, using CometBFT as the base consensus algorithm and incorporating Proof-of-Liquidity. CometBFT is a consensus protocol based on Tendermint that provides fast transaction confirmation and Byzantine Fault Tolerance (BFT). In Berachain, BeaconKit further encapsulates CometBFT to enable interaction with any Ethereum Virtual Machine (EVM)-compatible execution environment.
(2) EVM Execution Layer. Berachain uses the same virtual machine as Ethereum—the EVM (Ethereum Virtual Machine)—ensuring compatibility with existing Ethereum tooling, smart contracts, and ecosystems. This allows developers to directly port Ethereum smart contracts and decentralized applications (dApps) to Berachain.
Nodes in Berachain are divided into two types: validator nodes and RPC nodes. Each node can be configured as either a full node or an archive node. Each node type combines an execution client and a consensus client, meaning that at the execution level, it supports any EVM execution client paired with Berachain's BeaconKit consensus client and framework.
● Execution Client: Responsible for executing smart contract code, managing state changes, and processing transaction logic. By using the Ethereum Engine API, Berachain supports six major EVM execution clients: Geth, Erigon, Nethermind, Besu, Reth, and Ethereumjs.
● Consensus Client: Responsible for achieving consensus among network nodes and ensuring validation and ordering of transactions and blocks. Berachain uses BeaconKit as the consensus client.
2. Proof-of-Liquidity (PoL)
Berachain’s Proof-of-Liquidity (PoL) token economic model revolves around three core tokens:
$BERA: BERA is Berachain’s native gas token, used to pay transaction fees and serve as staking collateral for validators.
$BGT: Berachain’s governance token, used for on-chain governance participation, reward distribution, and delegation by validators. Unlike standard governance tokens, BGT is a soulbound token—non-transferable, meaning users cannot transfer BGT between addresses. However, BGT can be redeemed 1:1 for BERA. This is a one-way operation; BERA cannot be converted back into BGT. As a non-transferable soulbound token, BGT ensures that only users who actively participate in the Berachain ecosystem (e.g., providing liquidity, lending) can engage in governance, rather than those who acquire it through purchase or trading.
$HONEY: Berachain’s native stablecoin, designed to provide a stable and reliable medium of exchange within and outside the Berachain ecosystem. Officially pegged to the value of 1 USD, HONEY is a fully collateralized stablecoin that can be minted by depositing whitelisted collateral into vaults. Different collateral types have varying minting ratios determined by BGT governance.
Berachain’s Proof-of-Liquidity (PoL) mechanism differs from traditional consensus models like PoW or PoS by recognizing contributions made by all liquidity providers across the chain’s ecosystem. Through liquidity mining and staking, Berachain leverages PoL to incentivize more users to participate in its ecosystem. Below is an overview of the PoL process using Berachain’s native decentralized exchange, BEX:
-
Initial Staking: Users stake BERA to become validators eligible to produce blocks.
-
Block Proposal: An active validator is randomly selected to propose a new block.
-
Reward Distribution: The proposing validator receives governance tokens (BGT) and allocates them to various reward vaults across the ecosystem, with parameters set by individual validators.
-
Liquidity Providers: On BEX, liquidity providers can deposit tokens (e.g., HONEY and BERA) into pools to provide liquidity, receive liquidity pool tokens (e.g., $HONEY-WBERA), and stake these tokens in reward vaults to earn BGT rewards based on their contribution.
-
Delegating Governance Tokens: BGT holders can delegate their tokens to active validators, increasing the weight of that validator’s reward allocation during block proposals, thereby influencing BGT distribution—though this does not affect the validator’s block-proposal probability.
Currently, governance tokens (BGT) are primarily distributed through three official native DApps on Berachain: BEX, the native decentralized exchange; Bend, the native non-custodial lending protocol; and Berps, the native decentralized leveraged trading platform. This article will focus on explaining the business logic of these three projects.
3. PoL and BEX
BEX (Berachain Exchange) is Berachain’s native decentralized exchange (DEX) protocol, enabling users to trade any pair of crypto assets without intermediaries. As a key component of the Berachain ecosystem, BEX integrates closely with the PoL consensus mechanism in the following ways:
-
Liquidity Pools: BEX liquidity pools can be upgraded via governance to become PoL reward vaults, making them eligible to earn BGT rewards.
-
Liquidity Providers: Users can provide liquidity on BEX to receive LP tokens, which they can then stake in PoL reward vaults to earn BGT rewards.
-
Governance: BEX governance allows proposals to whitelist new liquidity pools into PoL reward vaults, enabling those pools to earn BGT rewards.
By analyzing contracts on the testnet, BEX’s main codebase is currently divided into three parts. The first is the BeraCrocMultiSwap contract (https://bartio.beratrail.io/address/0x21e2C0AFd058A89FCf7caf3aEA3cB84Ae977B73D), which handles multi-path token swaps and is invoked when a user’s swap involves intermediate tokens;
The second is the CrocSwapDex contract (https://bartio.beratrail.io/address/0xAB827b1Cc3535A9e549EE387A6E9C3F02F481B49), responsible for all user interactions with pools, including adding/removing liquidity and swapping tokens;
The third part consists of Path contracts. There are eight types of Path contracts on-chain for BEX, each corresponding to different functions. Depending on the User Cmd parameter passed to the CrocSwapDex contract, CrocSwapDex uses proxy calls to invoke the appropriate Path contract to execute specific logic.
The project’s core logic is categorized by Path function as follows:
-
BootPath: Contract upgrade-related functionality
-
ColdPath: Management logic unrelated to trading, including pool initialization and over-collateralization features
-
HotPath: Handles the most common trading logic—single-step token swaps
-
KnockoutPath: Triggered when a trade crosses a predefined liquidity boundary or price point (called a bump point), used to re-evaluate or adjust liquidity. Unlike regular trading paths, crossing liquidity boundaries involves complex code that cannot be fully contained within the HotPath handling normal swaps, so it is processed separately
-
LongPath: Handles long-chain compound order transactions—complex trades composed of multiple single operations within decentralized exchanges or liquidity pools
-
MicroPaths: Intermediate components related to individual atomic operations, callable within the context of pre-loaded liquidity curves during execution of complex composite operations
-
SafeModePath: Designed to restrict all other operations when the DEX contract enters emergency mode, allowing only specific administrative actions
-
WarmPath: Contains core logic for liquidity providers—minting ambient liquidity, minting concentrated range liquidity, burning ambient liquidity, and burning concentrated range liquidity
3.1 Adding Liquidity
This section covers two common operations: adding liquidity and token swaps. When a user adds liquidity, they first call the userCmd function of the CrocSwapDex contract via frontend or direct contract invocation. Here, callpath is a 16-bit index identifying which Path contract the command should be forwarded to via DELEGATECALL;
Next, the contract calls the callUserCmd function of the ProxyCaller contract, which proxies the call to the corresponding Path contract based on the provided proxyIdx—in this case, the WarmPath contract. The commitLP function in WarmPath routes to the appropriate liquidity-adding branch based on input parameters, supporting three liquidity-adding logics: MINT_AMBIENT_LIQ_LP, MINT_AMBIENT_BASE_LP, and MINT_AMBIENT_QUOTE_LP. These represent directly specifying the amount of liquidity to add, or calculating the liquidity amount based on the base or quote token in the pool.
Finally, the mintAmbientLiq function in the WarmPath contract handles liquidity minting. It calls the settleFlows function in the SettleLayer contract to issue corresponding liquidity receipt tokens to the user.
The logic for removing liquidity is similar and will not be detailed here.
3.2 Token Swaps
When a user performs a token swap on BEX, they first call the multiSwap function of the BeraCrocMultiSwap contract, which executes the swap step-by-step within the CrocSwapDex contract. Then, the caluserCmd function of the CrocSwapDex contract is called to enter the designated HotPath or KnockoutPath for executing the actual swap logic—here, we use the commonly used HotPath contract. HotPath calls the swapOverPool function of MarketSequencer to calculate the output token amount. Finally, the HotPath contract invokes the settleFlows function of the SettleLayer contract to transfer the resulting target tokens to the user.
In summary, compared to traditional DEXs like Uniswap V2, BEX has the following characteristics:
CurveState Management
Snapshotting CurveState: To optimize gas usage, BEX copies the current CurveState from on-chain storage (EVM Storage) into memory and writes the modified state back after the transaction completes.
The snapshot includes information such as priceRoot, ambientSeeds, and concLiq_. For concepts like ambient seeds, refer to the Ambient Finance (Crocswap) whitepaper: https://crocswap-whitepaper.netlify.app/
Swap Execution
Step-by-step Swap Execution: BEX’s architecture enables incremental swap execution, particularly for large trades that cross multiple liquidity boundaries (similar to ticks in Uniswap V3). When crossing a boundary, liquidity and price must be readjusted. Iterative Calculation: By traversing each liquidity interval (or tick), the system gradually consumes or accumulates liquidity until the trade completes or reaches the user’s price limit.
Bitmap Structure: Similar to Uniswap V3, Ambient DEX uses bitmaps to mark whether liquidity exists in each price range and quickly locate the next available liquidity interval. However, since all current BEX pools on-chain use ambient liquidity—where providers offer liquidity globally rather than concentrating it at specified prices—the current token swap behavior is largely similar to Uniswap V2.
4. PoL and Bend
Bend is a non-custodial lending protocol on the Berachain, primarily providing foundational lending services for the Berachain ecosystem. As a key component of Berachain and an official lending market, Bend tightly integrates with the PoL consensus mechanism.
Borrowers can deposit cryptocurrencies (such as wBTC) as collateral to borrow HONEY tokens and simultaneously earn a certain amount of governance tokens (BGT), helping complete BGT distribution under the PoL mechanism. Meanwhile, HONEY suppliers can provide HONEY liquidity and earn a share of the interest generated from borrowing.
Bend has three main participant types:
1. Liquidity providers supplying $HONEY tokens (Suppliers).
2. Borrowers who pledge crypto assets to borrow HONEY tokens (Borrowers).
3. Liquidators who ensure protocol solvency (Liquidators).
Below is the project’s main architecture:
Based on analysis of testnet contracts, liquidity providers deposit HONEY tokens via the supply interface and receive AHONEY tokens in a 1:1 ratio. Over time, the balance of these AHONEY tokens increases with accrued interest, helping sustain the lending pool and ensuring borrowers always have funds available. Later, providers can withdraw their original HONEY tokens 1:1 using the withdraw interface, thus realizing profit.
Borrowers use the borrow interface to pledge collateral and receive HONEY tokens up to a value lower than their collateral, while also receiving vdHONEY tokens—debt tokens. Similar to HONEY, the vdHONEY balance grows over time, requiring borrowers to repay increasingly more HONEY. However, on Berachain, borrowers also receive a certain amount of governance tokens (BGT) when borrowing HONEY, incentivizing borrowing activity, sustaining the lending pool, and contributing to the PoL consensus.
On Bend, anyone can act as a liquidator. When a borrower’s health factor drops below 1, indicating their collateral value is insufficient to cover their debt, liquidators can initiate liquidation and receive 5% of the collateral’s value as a liquidation reward, incentivizing prompt liquidation.
4.1 Adding Liquidity
When liquidity providers deposit funds, the supply function first updates the current reserve cache and interest rates to maintain healthy reserves and access up-to-date data. It then verifies whether the ATOKEN cap has been reached to prevent excessive minting.
If checks pass, ATOKEN tokens are minted 1:1 for the provider. During withdrawal, the withdraw function also updates the reserve cache and interest rate, calculates the updated ATOKEN balance based on accrued interest, and allows 1:1 redemption of the underlying HONEY tokens.
Note that if the provider has outstanding loans, they must maintain a healthy borrowing factor to withdraw liquidity. Currently, only HONEY can be borrowed as an asset on Berachain; other collaterals do not generate interest through lending.
4.2 Borrowing
When borrowers use Bend to take out a loan, they must first deposit sufficient collateral via the supply function. Then, they call the borrow function. This function first updates the reserve cache to ensure up-to-date data, then calls validateBorrow to verify loan legitimacy—including checks on borrowing limits, collateral value, and user credit. Upon passing validation, debt tokens (vdHONEY) are minted, and the corresponding amount of HONEY tokens is issued.
To repay, the repay function also updates the reserve cache and interest rate, determines the required HONEY repayment amount, and upon successful repayment, burns the corresponding vdHONEY tokens. Borrowers can only withdraw their collateral via the withdraw function after repaying enough vdHONEY to restore their position to a healthy state post-withdrawal.
4.3 Liquidation
When a borrower’s collateral value becomes insufficient, anyone can call the liquidationCall function to initiate liquidation. This function first updates debt cache data, then calls validateLiquidationCall to check the borrower’s health factor and collateral availability. If the debt exceeds the liquidation threshold, the health factor drops too low. If the health factor is below 1, the liquidator successfully executes liquidation, burns the borrower’s debt tokens, and sends the collateral to the reserve treasury. The liquidator receives 5% of the collateral’s value as a liquidation reward, incentivizing active monitoring and liquidation.
5. PoL and Berps
Berachain Berps is a decentralized leveraged trading platform enabling perpetual futures contract trading. Berachain’s native stablecoin, $HONEY, serves as the base token for all collateral, payments, and deposits. Users can earn returns by providing trading liquidity in the $bHONEY vault. Vault depositors earn trading fees generated by Berps and act as counterparty to traders’ positions. Additionally, Berps vaults are eligible for PoL incentives—users depositing funds into the vault receive $BGT.
Berps is currently live on testnet and supports U-margined perpetual contracts for four tokens: BTC, ETH, ATOM, and TIA.
Berps’ architecture closely resembles existing decentralized perpetual trading platforms, featuring the following key contracts:
● Entrypoint: Entry point for user trades (including liquidations). The Entrypoint contract validates user-initiated trades and creates corresponding trades upon successful verification.
● FeesAccrued: Calculates and manages funding fees
● FeesMarkets: Calculates and manages fees associated with all trading pairs
● Markets: Manages parameters and constraints for all trading pairs
● Orders: Manages user-submitted orders and stores user funds
● Settlement: Updates the state of trades
● Vault: Acts as counterparty to traders, providing trading liquidity. Users deposit funds into the Vault to earn platform fee revenue and PoL token incentives.
6. Summary
In conclusion, Berachain is an EVM-equivalent L1 blockchain built on the Cosmos SDK, employing a unique Proof-of-Liquidity (PoL) consensus mechanism that rewards users who provide liquidity to the network. By leveraging PoL, Berachain enhances capital liquidity and security. Compared to other blockchains, Berachain features native applications—BEX, Bend, and Berps—that offer users a comprehensive suite of DeFi services including token swapping, liquidity mining, lending, and perpetual trading. Combined with PoL, this positions Berachain to excel in DeFi trading depth and user experience.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@Beosin_com
