As a blockchain that has attracted much attention from the market, Berachain has many innovations and features, attracting the attention of a large number of communities and developers. Berachain provides a unique solution to the on-chain liquidity problem through the PoL mechanism and the three-token model. As Berachain is about to launch the mainnet, Berachain has launched an incentive plan and TGE to attract and support Berachain's early ecological users and projects.

Beosin is the official audit partner of multiple blockchain networks such as Ronin Network, Merlin Chain, Manta Netowork, and Self Chain. In this article, we will help readers gain a deeper understanding of Berachain by explaining the architecture of Berachain, the design of the three native applications, and the related contract execution process.

1. Architecture

Berachain is a Layer1 EVM equivalent chain. The characteristics of this chain are the introduction of a triple token model and a liquidity consensus mechanism (Proof-of-Liquidity), which integrates liquidity, consensus and governance mechanisms, bringing more incentives to liquidity providers in the chain ecosystem.

The Berachain architecture is mainly divided into two layers:

(1) BeaconKit consensus layer. This layer is mainly responsible for the consensus mechanism of the blockchain, using CometBFT as the basic consensus algorithm, and introducing Proof-of-Liquidity on this basis. CometBFT is a consensus protocol based on Tendermint that provides fast transaction confirmation and Byzantine Fault Tolerance (BFT). In Berachain, BeaconKit further encapsulates CometBFT so that it can interact with any execution environment compatible with the Ethereum Virtual Machine (EVM).

(2) EVM execution layer. Berachain's execution layer uses the same virtual machine as Ethereum - EVM (Ethereum Virtual Machine), ensuring that Berachain supports the existing Ethereum toolchain, smart contracts and ecosystem, allowing developers to directly port smart contracts and decentralized applications (dApps) on Ethereum to Berachain.

There are two types of nodes in Berachain, validation 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, which means that from an execution level, it supports any EVM execution client and is paired with the BeaconKit consensus client and framework built by Berachain.

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

● Consensus client: Responsible for reaching consensus between network nodes, ensuring the verification and ordering of transactions and blocks. Berachain uses BeaconKit as a consensus client.

2. Proof-of-Liquidity (PoL)

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

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

$BGT: Berachain's governance token, used to participate in on-chain governance, reward distribution and validator delegation. Compared with ordinary governance tokens, the uniqueness of this token is that BGT is a soulbound token, which means that it is non-transferable, that is, users cannot transfer BGT between different addresses, but the token can be exchanged for BERA at a ratio of 1:1. It should be noted that this is a one-way operation, BERA cannot be exchanged back to BGT. BGT, as a non-transferable soulbound token, represents that only users who actually participate in the Berachain ecosystem (such as providing liquidity, lending, etc.) can participate in governance, rather than being obtained through purchase or trading.

$HONEY: Berachain's native stablecoin, used to provide a stable and reliable means of exchange within and outside the Berachain ecosystem, and its official introduction is pegged to $1. HONEY is a fully collateralized stablecoin that can be minted by depositing whitelisted collateral into the vault. Different collateral has different minting rates, which are determined by BGT governance.

The Proof of Liquidity (PoL) mechanism adopted by Berachain is different from traditional consensus mechanisms (such as PoW or PoS). PoL takes into account the contributions made by liquidity providers in all chain ecosystems. Through liquidity mining and staking, Berachain uses PoL to incentivize more users to participate in the entire ecosystem of Berachain. The following takes Berachain's native decentralized exchange BEX as an example to introduce the main process of PoL in the Berachain ecosystem:

• Initial staking: Users first stake BERA to become validators with block production qualifications.

• Block proposal: Randomly select an active validator to propose a new block.

• Reward distribution: Validators who propose blocks receive governance tokens (BGT) and distribute them to different reward treasuries in the chain ecosystem. This parameter is set by individual validators.

• Liquidity providers: For BEX, liquidity providers can provide liquidity by depositing tokens (such as HONEY and BERA) in the BEX pool and obtain liquidity certificate tokens (such as $HONEY-WBERA), which are staked in the reward treasury to receive BGT rewards based on their contributions.

• Delegated governance tokens: BGT holders can delegate them to active validators, increasing the weight of the validator in distributing rewards when proposing blocks, thereby affecting the distribution of BGT, but this weight will not affect the probability of the validator producing blocks.

Since the current governance token BGT mainly comes from the three official native DApps on Berachain, one is Berachain's native decentralized exchange BEX, one is Berachain's native non-custodial lending protocol Bend, and the other is the native decentralized leverage trading platform Berps, this article will mainly introduce the business logic of these three projects.

3. PoL and BEX

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

Liquidity Pools: Liquidity pools on BEX can be upgraded to PoL reward treasuries through governance, making them eligible 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: BEX's governance mechanism allows new liquidity pools to be whitelisted in the PoL reward treasury through proposals, enabling these pools to receive BGT rewards.

Through the study of the contracts on the test chain, the main code architecture of BEX is currently divided into three parts. The first part is the BeraCrocMultiSwap contract (https://bartio.beratrail.io/address/0x21e2C0AFd058A89FCf7caf3aEA3cB84Ae977B73D), which is mainly responsible for the multi-path exchange of tokens. When the user's token exchange involves intermediate tokens, this contract needs to be called;

The second part is the CrocSwapDex contract (https://bartio.beratrail.io/address/0xAB827b1Cc3535A9e549EE387A6E9C3F02F481B49), this contract is responsible for all operations between users and the pool, including adding and removing liquidity, exchanging tokens, etc.;

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

The main logic of the project is divided into the following categories according to different Path functions:

• BootPath: contract upgrade related functions

• ColdPath: transaction-independent management logic, including pool initialization and over-collateralization functions

• HotPath: responsible for the most common transaction logic, single-step exchange of tokens

• KnockoutPath: When a transaction crosses a predetermined liquidity boundary point or price point (called a bump point), this event will be triggered to reassess or adjust liquidity. Unlike normal trading paths, the code that crosses liquidity boundaries is complex and cannot be fully included in the HotPath that handles normal exchanges, so it is processed separately

• LongPath: Responsible for processing long-chain compound order transactions (Long-chain Compound Orders), which usually refers to complex transactions composed of multiple single operations in decentralized trading platforms or liquidity pools

• MicroPaths: Contains intermediate components related to single atomic operations, which can be called in the context of preloaded liquidity curves when performing complex compound operations

• SafeModePath: The main purpose is to restrict all other operations and only allow specific management operations when the DEX contract enters an emergency state

• WarmPath: Contains the core operating logic of liquidity providers, Mint ambient liquidity liquidity), Mint concentrated range liquidity, Burn ambient liquidity, Burn concentrated range liquidity

3.1 Adding liquidity

This article mainly introduces two common logics of adding liquidity and token exchange. When a user adds liquidity, the userCmd function of the CrocSwapDex contract is first called through the front-end or contract, where callpath is a 16-bit index used to identify the corresponding Path contract to which the command call is forwarded through DELEGATECALL; the contract then calls the callUserCmd function of the ProxyCaller contract, and calls the corresponding Path contract according to the passed-in proxyIdx proxy, which is the WarmPath contract at this time; the commitLP function of the WarmPath contract will enter the corresponding branch logic for adding liquidity according to the passed-in parameters. The contract includes three types of liquidity addition logic: MINT_AMBIENT_LIQ_LP, MINT_AMBIENT_BASE_LP, and MINT_AMBIENT_QUOTE_LP, which represent directly adding a specified amount of liquidity, and calculating the amount of added liquidity according to the base token or quote token in the pool.

Finally, the mintAmbientLiq function of the WarmPath contract is mainly responsible for casting liquidity. The contract will call the settleFlows function of the SettleLayer contract to cast the corresponding liquidity certificate token for the user.

The logic of removing liquidity is similar to adding liquidity, so this article will not introduce it in detail.

3.2 Token Exchange

When a user uses BEX to exchange tokens, the multiSwap function of the BeraCrocMultiSwap contract is first called, which will exchange in the CrocSwapDex contract step by step according to the exchange path; then the caluserCmd function of the CrocSwapDex contract is called to enter the specified HotPath or KnockoutPath to execute the specific exchange logic. The most common HotPath contract is used here; HotPath will call the swapOverPool function of the MarketSequencer to calculate the number of tokens to be exchanged; finally, the HotPath contract calls the settleFlows function of the SettleLayer contract to transfer the target token obtained after the exchange to the user.

In summary, BEX has the following characteristics compared to traditional DEXs such as uniswap V2:

• Curve State Management

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

The information saved in the snapshot includes price root (priceRoot), liquidity seed (ambientSeeds) and concentrated liquidity (concLiq_). For concepts such as liquidity seeds, please refer to the white paper of Ambient Finance (Crocswap):https://crocswap-whitepaper.netlify.app/

• Transaction Execution

Step-by-step execution of transactions: BEX's code architecture allows for step-by-step execution of transactions, especially in large-scale transactions that cross multiple liquidity boundaries (such as ticks in Uniswap V3). When crossing a liquidity boundary, liquidity and price need to be readjusted. Iterative calculation: By traversing each liquidity interval (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 in each price range, and quickly finds the next available liquidity interval through the bitmap. However, since the pool liquidity on the BEX chain currently adopts environmental liquidity, that is, liquidity providers provide liquidity globally, rather than adding centralized liquidity by specifying prices, the current token exchange operation is not much different from uniswap V2.

4. PoL and Bend

Bend is a non-custodial lending protocol on the Berachain. Its core is to provide basic lending services for the berachain ecosystem. The project is an important part of the Berachain ecosystem. As an official lending market, it is closely integrated with the PoL consensus mechanism in the following ways.

Borrowers can borrow HONEY tokens by pledging cryptocurrencies (similar to wBTC, etc.), and can also obtain a certain number of governance tokens while borrowing, which helps the PoL consensus mechanism to improve the distribution of BGT. HONEY providers can provide HONEY liquidity to obtain interest sharing generated by borrowing.

There are three main participants in Bend:

1. Liquidity providers (Suppliers) who provide $HONEY tokens.

2. Borrowers (Borrowers) who pledge cryptocurrencies to borrow HONEY tokens.

3. Liquidators (Liquidators) who ensure that the protocol is solvent.

The following figure shows the main architecture of the project:

Through the study of the contracts on the test chain, currently liquidity providers will deposit HONEY tokens through the supply interface and obtain the corresponding number of AHONEY tokens in return at a 1:1 ratio. Over time, the balance of AHONEY tokens acquired by these users will increase with the increase of interest, which helps maintain the ecology of the lending pool and ensures that borrowers always have funds to borrow. In the subsequent period, liquidity providers can also use the withdraw interface to use AHONEY tokens to withdraw the corresponding number of HONEY tokens at a 1:1 ratio, thereby achieving profitability.

Borrowers can use the borrow interface to pledge collateral, thereby lending HONEY tokens that are lower than the value of the collateral according to the value of the collateral, and obtaining the corresponding number of vdHONEY, i.e., debt tokens. Similar to HONEY tokens, vdHONEY tokens will also increase in number over time, requiring borrowers to repay more HONEY tokens. However, in the Bera chain, borrowers will also obtain a certain number of governance tokens (BGT) while borrowing HONEY tokens, which will stimulate borrowers' enthusiasm for borrowing, maintain the ecology of the lending pool, and also contribute to the PoL consensus.

In Bend, anyone can become a liquidator. When the health coefficient of the borrower is less than 1, it proves that the value of the borrower's collateral is not enough to cover the debt value. The liquidator can initiate liquidation and obtain 5% of the value of the collateral as a liquidation reward, thereby motivating the liquidator to liquidate.

4.1 Adding Liquidity

When the liquidity provider is depositing liquidity, the supply function will first update the current reserve cache and interest rate, which helps to maintain the health of the reserve cache and interest rate and obtain the latest reserve cache data at any time. Then it will verify whether the current ATOKEN token has reached the casting limit to avoid casting too many ATOKEN tokens.

If these checks and updates are passed, the corresponding number of ATOKEN tokens will be directly cast to the liquidity provider at a 1:1 ratio. When the liquidity provider withdraws liquidity, the withdraw function will first update the current reserve cache and interest rate, and then calculate the latest ATOKEN token balance currently owned by the user based on the current latest interest amount, so as to withdraw the corresponding collateral tokens at a 1:1 ratio.

It is worth noting that if the liquidity provider here borrows, the corresponding amount of liquidity can only be withdrawn when the borrowing factor is healthy. And in the current Berachain, only HONEY tokens can be borrowed as loan assets, and other collateral cannot rely on borrowing to obtain interest.

4.2 Borrowing

When the borrower uses Bend to borrow, first, a sufficient amount of collateral must be pledged to the pool through the supply function, and then the borrow function is called for borrowing. The borrow function will first update the reserve cache to ensure the latest reserve information, and then call the validateBorrow function to verify the legitimacy of this loan, including the loan limit, collateral value, user credit and other information. If these verifications are passed, the corresponding number of debt tokens, namely vdHONEY tokens, will be minted according to the value of the collateral to obtain the corresponding number of HONEY tokens.

When the borrower needs to repay the loan, the repay function will also update the reserve cache and interest rate first, and obtain the number of HONEY tokens repaid by the borrower based on the reserve cache and the lending rate, and destroy the corresponding number of vdHONEY tokens after successful repayment. The borrower can only use the withdraw function to withdraw the corresponding amount of collateral when he successfully repays a sufficient number of vdHONEY tokens so that the current debt is still in a healthy state when the collateral is withdrawn.

4.3 Liquidation

When the borrower's collateral value is insufficient, anyone can call the liquidationCall function as a liquidator to liquidate. The liquidationCall function first updates the debt cache data, and 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 limit, the health factor will be too low. If the health factor is less than 1, the liquidator can successfully execute the liquidation, destroy the borrower's debt token, and send the collateral to the reserve vault address. The liquidator can obtain 5% of the value of the collateral from this liquidation as a liquidation reward, which incentivizes the liquidator to perform liquidation.

5. PoL and Berps

Berachain Berps is a decentralized leverage trading platform that allows perpetual futures contract trading. Berachain's native stablecoin $HONEY is the base token for collateral, expenditures, and deposits for all transactions. Users can earn income by providing trading liquidity in the $bHONEY vault. Vault depositors will earn transaction fees generated by Berps and act as counterparties to traders' positions. In addition, Berps' vaults can also receive PoL incentives, that is, users who deposit funds in the vault will receive $BGT.

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

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

●Entrypoint: The entry point for users to conduct transactions (including liquidation). The Entrypoint contract will check whether the transaction initiated by the user is legal. If it passes the verification, the contract will create a corresponding transaction for the user.

● FeesAccrued: Calculate and manage lending fees

● FeesMarkets: Calculate and manage fees related to all trading pairs

● Markets: Manage parameters and limits of all trading pairs

● Orders: Manage trading orders submitted by users and store users' funds

● Settlement: Update transaction status changes

● Vault: As the counterparty of the trader, it provides liquidity for the transaction. Users can deposit funds into Vault to obtain platform fee income and PoL token incentives.

6. Summary

In summary, Berachain is an EVM-equivalent L1 blockchain built on Cosmos SDK, using a unique Proof-of-Liquidity (PoL) consensus mechanism. Users who provide liquidity to Berachain will receive rewards from the PoL mechanism. Using PoL, Berachain enhances the liquidity and security of the chain. Compared with other blockchains, Berachain has native BEX, Bend and Berps applications, providing users with a series of DeFi services such as token exchange, liquidity mining, lending, perpetual trading, etc., combined with PoL, this will make Berachain excel in DeFi's transaction depth and user experience.