Exploring Berachain: Analysis of Native Protocol and Technical Highlights

Author: Beosin

Berachain, as a blockchain that has attracted significant market attention, possesses multiple innovations and features that have drawn the interest of a large community and developers. Berachain provides a unique solution to on-chain liquidity issues through its PoL mechanism and three-token model. With the mainnet launch of Berachain approaching, it has introduced incentive programs and TGE to attract and support early ecosystem users and projects.

This article will help readers gain a deeper understanding of Berachain by explaining its architecture, the design of its three native applications, and the related contract execution processes.

1. Architecture

Berachain is a Layer 1 EVM-equivalent chain characterized by the introduction of a triple-token model and a liquidity consensus mechanism (Proof-of-Liquidity), integrating liquidity, consensus, and governance mechanisms to provide more incentives for liquidity providers in the chain ecosystem.

The architecture of Berachain is mainly divided into two layers:

(1) BeaconKit Consensus Layer. This layer is primarily responsible for the blockchain's consensus mechanism, using CometBFT as the underlying consensus algorithm, and introducing Proof-of-Liquidity on this basis. CometBFT is a consensus protocol based on Tendermint that can provide fast transaction confirmations and Byzantine fault tolerance (BFT). In Berachain, BeaconKit further encapsulates CometBFT, enabling it to interact with any Ethereum Virtual Machine (EVM) compatible execution environment.

(2) EVM Execution Layer. The execution layer of Berachain uses the same virtual machine—EVM (Ethereum Virtual Machine)—to ensure that Berachain supports existing Ethereum toolchains, smart contracts, and ecosystems, allowing developers to directly port smart contracts and decentralized applications (dApps) from Ethereum to Berachain.

There are two types of nodes in Berachain: validator nodes and RPC nodes. Each node can be configured as a full node or an archive node, and each type of node is a combination of an execution client and a consensus client, meaning that from an execution perspective, it supports any EVM execution client and pairs with the BeaconKit consensus client and framework built on Berachain.

● Execution Client: Responsible for executing smart contract code, managing state changes, and executing transaction logic. By using the Ethereum Engine API, Berachain supports six mainstream EVM execution clients: Geth, Erigon, Nethermind, Besu, Reth, and Ethereumjs.

● Consensus Client: Responsible for reaching consensus among network nodes, ensuring the validation and ordering of transactions and blocks. Berachain uses BeaconKit as its consensus client.

2. Proof-of-Liquidity (PoL)

The Proof-of-Liquidity (PoL) token economic model of Berachain mainly involves three core tokens:

$BERA: BERA is the native gas token of Berachain, used to pay transaction fees and as a staking token for validators.

$BGT: The governance token of Berachain, used for on-chain governance, reward distribution, and delegation for validators. Unlike ordinary governance tokens, BGT is a soulbound token, meaning it is non-transferable; users cannot transfer BGT between different addresses, but this token can be exchanged for BERA at a 1:1 ratio. It is important to note that this is a one-way operation, and BERA cannot be exchanged back for BGT. As a non-transferable soulbound token, BGT represents that only users who actively participate in the Berachain ecosystem (such as providing liquidity, lending, etc.) can participate in governance, rather than acquiring it through purchase or trading.

$HONEY: The native stablecoin of Berachain, used to provide a stable and reliable means 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 collateral from a whitelist into a treasury. Different collateral types have different minting rates, determined by BGT governance.

The Proof of Liquidity (PoL) mechanism adopted by Berachain differs from traditional consensus mechanisms (such as PoW or PoS) by considering the contributions of all liquidity providers in the chain ecosystem. Through liquidity mining and staking, Berachain utilizes PoL to incentivize more users to participate in the entire Berachain ecosystem. Below, we will introduce the main processes of PoL in the Berachain ecosystem using Berachain's native decentralized exchange BEX as an example:

• Initial Staking: Users first stake BERA to become validators with block proposal rights.
• Block Proposal: A random active validator is selected to propose a new block.
• Reward Distribution: The proposing validator will receive governance tokens (BGT) and allocate them to different reward treasuries in the chain ecosystem, with this parameter set by each validator.
• Liquidity Providers: For BEX, liquidity providers can provide liquidity by depositing tokens (such as HONEY and BERA) into the BEX pool and receive liquidity certificate tokens (such as $HONEY-WBERA), which they can stake in the reward treasury to earn BGT rewards based on their contributions.
• Delegated Governance Tokens: BGT holders can delegate their tokens to active validators, increasing the weight of that validator in reward allocation when proposing blocks, thus affecting the distribution of BGT, but this weight does not affect the validator's block proposal probability.

Currently, the main sources of the governance token BGT on Berachain come from three official native DApps: one is the native decentralized exchange BEX, another is the native non-custodial lending protocol Bend, and the third is the native decentralized leveraged trading platform Berps. This article will mainly introduce the business logic of these three projects.

3. PoL and BEX

BEX (Berachain Exchange) is the native decentralized exchange (DEX) protocol of Berachain, allowing users to trade any pair of crypto assets without intermediaries. BEX is an important component of the Berachain ecosystem, closely integrated with the PoL consensus mechanism in the following ways:

• Liquidity Pools: Liquidity pools on BEX can be upgraded through governance to become PoL reward treasuries, thus qualifying for BGT rewards.
• Liquidity Providers: Users can provide liquidity on BEX and receive LP tokens, which can then be staked in the PoL reward treasury to earn BGT rewards.
• Governance: The governance mechanism of BEX allows proposals to whitelist new liquidity pools into the PoL reward treasury, enabling these pools to receive BGT rewards.

By studying the contracts on the test chain, the main code architecture of BEX is divided into three parts. The first part is the BeraCrocMultiSwap contract (https://bartio.beratrail.io/address/0x21e2C0AFd058A89FCf7caf3aEA3cB84Ae977B73D), which is primarily responsible for multi-path token swaps when a user's token exchange involves intermediate tokens.

The second part is the CrocSwapDex contract (https://bartio.beratrail.io/address/0xAB827b1Cc3535A9e549EE387A6E9C3F02F481B49), which handles all operations between users and pools, including adding and removing liquidity, token swaps, etc.

The third part is the Path contract, with a total of 8 types of Path contracts on-chain for BEX. Different Path contracts correspond to different functions, and based on the User Cmd parameters passed by the user to the CrocSwapDex contract for different operations, CrocSwapDex will call the corresponding Path through a proxy to complete the specified logic.

The main logic of the project is divided into the following categories based on different Path functions:

• BootPath: Contract upgrade-related functions
• ColdPath: Management logic unrelated to transactions, including pool initialization and over-collateralization functions
• HotPath: Responsible for the most common transaction logic, single-step token swaps
• KnockoutPath: Triggered when a transaction crosses a predetermined liquidity boundary or price point (known as a bump point), used to reassess or adjust liquidity. Unlike ordinary transaction paths, the code for crossing liquidity boundaries is complex and cannot be fully included in the HotPath that handles ordinary swaps, hence it is processed separately.
• LongPath: Responsible for handling long-chain compound order transactions, typically referring to complex trades composed of multiple single operations in decentralized trading platforms or liquidity pools.
• MicroPaths: Intermediate components related to single atomic operations that can be called in the context of pre-loaded liquidity curves when executing complex compound operations.
• SafeModePath: Primarily aimed at limiting all other operations when the DEX contract enters an emergency state, allowing only specific management operations.
• WarmPath: Contains the core operational logic for liquidity providers, minting ambient liquidity, minting concentrated range liquidity, burning ambient liquidity, and burning concentrated range liquidity.

3.1 Adding Liquidity

This article mainly introduces two common logics: adding liquidity and token swaps. When a user adds liquidity, they first call the userCmd function of the CrocSwapDex contract through the frontend or contract, where callpath is a 16-bit index used to identify the corresponding Path contract to which the command call is forwarded via DELEGATECALL.

Then, the contract calls the callUserCmd function of the ProxyCaller contract, which proxies the call to the corresponding Path contract based on the passed proxyIdx, at this point being the WarmPath contract. The commitLP function of the WarmPath contract will enter the corresponding branch logic for adding liquidity based on the passed parameters. The contract includes three types of adding liquidity logic: MINTAMBIENTLIQLP, MINTAMBIENTBASELP, and MINTAMBIENTQUOTE_LP, representing directly adding a specified amount of liquidity, and calculating the amount of liquidity to be added based on the base or quote token in the pool.

Finally, the mintAmbientLiq function of the WarmPath contract is primarily responsible for minting liquidity, which will call the settleFlows function of the SettleLayer contract to mint the corresponding liquidity certificate tokens for the user.

The logic for removing liquidity is similar to that for adding liquidity and will not be detailed here.

3.2 Token Swaps

When a user performs a token swap using BEX, they first call the multiSwap function of the BeraCrocMultiSwap contract, which will perform the swap step-by-step in the CrocSwapDex contract according to the swap path. Then, it calls the caluserCmd function of the CrocSwapDex contract to enter the specified HotPath or KnockoutPath to execute the specific swap logic, using the most common HotPath contract here. The HotPath will call the swapOverPool function of the MarketSequencer to calculate the amount of tokens to be swapped. Finally, the HotPath contract calls the settleFlows function of the SettleLayer contract to transfer the target tokens obtained after the swap to the user.

In summary, compared to traditional DEXs like Uniswap V2, BEX has the following features:

Curve State Management

Curve State Snapshotting: To optimize gas consumption, BEX will copy the current curve state from on-chain storage (EVM Storage) to memory and write the modified state back to the chain after the transaction is completed.

The information saved in the snapshot includes priceRoot, ambientSeeds, and concLiq_. For concepts like liquidity seeds, refer to the Ambient Finance (Crocswap) whitepaper: https://crocswap-whitepaper.netlify.app/

Swap Execution

Step-by-step execution of transactions: The code architecture of BEX allows for step-by-step execution of transactions, especially during large-scale trades that may cross multiple liquidity boundaries (like ticks in Uniswap V3). When crossing a liquidity boundary, liquidity and prices need to be readjusted. Iterative calculation: By traversing each liquidity range (or tick), the system will gradually consume or accumulate the liquidity of the transaction until the transaction is completed or the user's price limit is reached.

Bitmap structure: Similar to Uniswap V3, Ambient DEX uses a bitmap to mark whether liquidity exists within each price range and quickly finds the next available liquidity range through the bitmap. However, since the liquidity pools on BEX currently use ambient liquidity, meaning liquidity providers provide liquidity globally rather than adding concentrated liquidity at specified prices, the token swap operations currently do not differ much from Uniswap V2.

4. PoL and Bend

Bend is a non-custodial lending protocol on the Bera chain, primarily providing basic lending services for the Berachain ecosystem. This project is an important component of the Berachain ecosystem, closely integrated with the PoL consensus mechanism in the following ways.

Borrowers can borrow HONEY tokens by collateralizing cryptocurrencies (similar to wBTC, etc.), and while borrowing, they can also earn a certain amount of governance tokens, which helps improve the distribution of BGT under the PoL consensus mechanism. HONEY providers can provide liquidity for HONEY, thus earning interest from the lending activities.

The main participants in Bend are three types:

1. Liquidity providers supplying $HONEY tokens (Suppliers).
2. Borrowers collateralizing cryptocurrencies to borrow HONEY tokens (Borrowers).
3. Liquidators ensuring the protocol's solvency (Liquidators).

The following diagram illustrates the main architecture of the project:

By studying the contracts on the test chain, liquidity providers will deposit HONEY tokens through the supply interface to receive the corresponding amount of AHONEY tokens at a 1:1 ratio. Over time, the balance of AHONEY tokens obtained by these users will increase with the accumulation of interest, helping to maintain the ecology of the lending pool and ensuring that borrowers always have funds available for borrowing. Later, liquidity providers can also use the withdraw interface to redeem the corresponding amount of HONEY tokens using AHONEY tokens at a 1:1 ratio, thus realizing profits.

Borrowers can collateralize their assets through the borrow interface to borrow HONEY tokens below the value of their collateral and receive the corresponding amount of vdHONEY, which is the debt token. The vdHONEY token is similar to the HONEY token and will also increase in quantity over time, requiring borrowers to repay more HONEY tokens. However, on the Bera chain, when borrowers borrow HONEY tokens, they will also receive a certain amount of governance tokens (BGT), which stimulates borrowers' willingness to borrow, maintains the ecology of the lending pool, and also contributes to the PoL consensus.

In Bend, anyone can become a liquidator. When a borrower's health factor falls below 1, it indicates that the value of the borrower's collateral is insufficient to cover the debt value, allowing the liquidator to initiate liquidation and earn 5% of the value of the collateral as a liquidation reward, thus incentivizing liquidators to perform liquidations.

4.1 Adding Liquidity

When liquidity providers deposit liquidity, the supply function first updates the current reserve cache and interest rates, helping to maintain the health of the reserve cache and interest rates while obtaining the latest reserve cache data. It then verifies whether the current ATOKEN token has reached the minting limit to avoid excessive minting of ATOKEN tokens.

If these checks and updates pass, the corresponding amount of ATOKEN tokens will be minted directly at a 1:1 ratio for the liquidity provider. When liquidity providers withdraw liquidity, the withdraw function also first updates the current reserve cache and interest rates, then calculates the latest ATOKEN token balance based on the current interest amount, allowing for a 1:1 withdrawal of the corresponding collateral token.

It is important to note that if the liquidity provider has borrowed, they must do so under healthy borrowing factors to withdraw the corresponding amount of liquidity. Currently, only HONEY tokens can be used as borrowing assets for lending, and other collateral types cannot earn interest through borrowing.

4.2 Borrowing and Lending

When borrowers use Bend for borrowing, they first need to have sufficient collateral deposited into the pool through the supply function, then call the borrow function to proceed with borrowing. The borrow function first updates the reserve cache to ensure the latest reserve information, then calls the validateBorrow function to verify the legality of the borrowing, including the borrowing limit, collateral value, user credit, and other information. If these validations pass, the corresponding amount of debt tokens, i.e., vdHONEY tokens, will be minted based on the value of the collateral, allowing them to receive the corresponding amount of HONEY tokens.

When borrowers need to repay their loans, the repay function will also first update the reserve cache and interest rates, then calculate the amount of HONEY tokens the borrower needs to repay based on the reserve cache and borrowing interest rates. Upon successful repayment, the corresponding amount of vdHONEY tokens will be burned. Borrowers can only use the withdraw function to withdraw the corresponding amount of collateral when they have successfully repaid enough vdHONEY tokens, ensuring that their current debt remains healthy.

4.3 Liquidation

When a borrower's collateral value is insufficient, anyone can call the liquidationCall function to act as a liquidator. The liquidationCall function first updates the debt cache data, then calls the validateLiquidationCall function to check the borrower's health factor and collateral availability. If the borrower's current debt value exceeds the liquidation threshold, it will lead to a low health factor. If the health factor is below 1, the liquidator can successfully execute the liquidation, burning the borrower's debt tokens and sending the collateral to the reserve treasury address. The liquidator can earn 5% of the value of the collateral as a liquidation reward from this liquidation, incentivizing them to perform liquidations.

5. PoL and Berps

Berachain Berps is a decentralized leveraged trading platform that allows for perpetual futures contract trading. The native stablecoin of Berachain, $HONEY, serves as the collateral for all trades, expenditures, and deposits. Users can earn profits by providing trading liquidity in the $bHONEY treasury. Treasury depositors will earn trading fees generated by Berps and act as counterparties to traders' positions. Additionally, the treasury can also receive PoL incentives, meaning users depositing funds in the treasury will earn $BGT.

Currently, Berps has launched on the testnet and supports U-based perpetual contract trading for four tokens: BTC, ETH, ATOM, and TIA.

The architecture of Berps is very similar to existing decentralized perpetual trading platforms in the market, with the following important contracts:

● Entrypoint: The entry point for users to conduct trades (including liquidations). The Entrypoint contract checks the legality of the user's initiated trades, and if validated, the contract creates the corresponding trade for the user.

● FeesAccrued: Calculates and manages borrowing fees.

● FeesMarkets: Calculates and manages all fees related to trading pairs.

● Markets: Manages parameters and limits for all trading pairs.

● Orders: Manages user-submitted trade orders and stores user funds.

● Settlement: Updates the status changes of trades.

● Vault: Acts as a counterparty for traders, providing liquidity for trades. Users can deposit funds into the Vault to earn platform fee revenues and PoL token incentives.

6. Conclusion

In summary, Berachain is an EVM-equivalent L1 blockchain built on the Cosmos SDK, adopting a unique Proof-of-Liquidity (PoL) consensus mechanism that rewards users providing liquidity to Berachain. Utilizing PoL, Berachain enhances the liquidity and security of the chain. Compared to other blockchains, Berachain has native applications BEX, Bend, and Berps, offering users a series of DeFi services such as token swaps, liquidity mining, lending, and perpetual trading. Combined with PoL, this will enable Berachain to excel in trading depth and user experience in DeFi.