Explore Berachain: Analysis of Native Protocols and Technical Key Points

Author: Beosin

Berachain is a blockchain that has attracted much attention from the market, with many innovations and features, attracting the attention of a large number of communities and developers. Berachain provides a unique solution to on-chain liquidity problems through the PoL mechanism and the three-token model. With Berachain coming online soon, Berachain launched incentive programs and TGE to attract and support Berachain’s early eco-users and projects.

In this article, we will explain Berachain's architecture, the design of the three native applications and the related contract execution process to help readers gain an in-depth understanding of Berachain.

1. Architecture

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

The Berachain architecture is mainly divided into two levels:

(1) BeaconKit consensus layer. This layer is mainly responsible for the consensus mechanism of blockchain, adopts CometBFT as the basic consensus algorithm, and introduces 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 to interact with any execution environment that is compatible with Ethereum Virtual Machine (EVM).

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

In Berachain, there are two types of node types, verification node and RPC node. Each node can be configured as a full node or archive node, each type of node is a combination of execution client and consensus client, which means that at the execution level it supports any EVM execution client and is built with BeaconKit Consensus client and framework pairing.

● 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, Eragon, Netherlands, Besu, Reth, and Ethereumjs.

● Consensus client: Responsible for reaching consensus among network nodes to ensure the verification and sorting 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 tokens that are pledged as validators

$BGT: Berachain's governance token used to participate in on-chain governance, reward allocation and delegates of validators. Compared with ordinary governance tokens, this token is unique in that BGT is a soulbound token, which means that it is not transferable, that is, users cannot transfer BGT between different addresses, but this Tokens can be exchanged for BERA at a ratio of 1:1. It should be noted that this is a one-way operation and BERA cannot be redeemed back to BGT. BGT, as an untransferable 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 through purchases or transactions.

$HONEY: Berachain's native stablecoin, used to provide stable and reliable means of exchange within and outside the Berachain ecosystem, officially introducing its value to a $1 peg. HONEY is a fully collateralized stablecoin that can be minted by depositing collateral from the whitelist into a vault. Different collaterals have different casting 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, which takes into account the contributions made by liquidity providers across all chain ecosystems. Through liquidity mining and staking, Berachain uses PoL to inspire more users to participate in the entire Berachain ecosystem. Here is an example to introduce the main process of PoL in the Berachain ecosystem:

• Initial pledge: The user first pledges BERA and becomes a verifier with block yield qualifications.
• Block Proposal: Randomly select an active validator to propose a new block.
• Reward allocation: The validator of the proposed block receives the governance token (BGT) and assigns it to different reward vaults in the chain ecosystem, which is set by the individual validators.
• Liquidity Provider: For BEX, liquidity providers can provide liquidity by depositing tokens (such as HONEY and BERA) in the BEX pool and obtaining liquidity credential tokens (such as $HONEY-WBERA) to convert them. Pledge it into the reward vault, thereby obtaining BGT rewards based on its contribution.
• Delegate governance tokens: BGT holders can delegate them to active validators, increasing the weight of the validator assigning rewards when proposing blocks, thereby affecting the allocation of BGT, but this weight will not affect the validator's block probability. .

Since the current governance token BGT mainly comes from three official native DApps on Berachain, one is Berachain's native decentralized exchange BEX, the other is Berachain's native non-custodial lending protocol Bend, and the other is native decentralized leverage For 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, which allows users to trade any pair of crypto assets without the need for intermediaries. BEX is an important part of the Berachain ecosystem. As a native decentralized exchange, it is closely integrated with the PoL consensus mechanism through the following methods:

• Liquidity Pool: Liquidity Pools on BEX can be upgraded to PoL Reward Vaults through governance, thus qualifying for BGT Rewards.
• Liquidity Provider: Users can provide liquidity on BEX and earn LP tokens, and then stake these tokens into the PoL reward vault to earn BGT rewards.
• Governance: BEX's governance mechanism allows new liquidity pools to be whitelisted in PoL reward vaults through proposals, allowing these pools to receive BGT rewards.

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

The second part is the CrocSwapDex contract (https://bartio.beratrail.io/address/0xAB827b1Cc3535A9e549EE387A6E9C3F02F481B49), which is responsible for all operations of users and pools, including adding and removing liquidity and redeeming tokens. Wait;

The third part is the Path contract. The BEX on the chain has a total of 8 types of Path contracts. Different Path contracts correspond to different functions. According to the user's user's User Cmd parameters for different operations of the CrocSwapDex contract, CrocSwapDex will complete it through the proxy calling the corresponding Path. Specify 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-staking functions
• HotPath: Responsible for the most common logic of trading, single-step exchange of tokens
• KnockoutPath: This event is triggered when a transaction crosses a predetermined liquidity boundary or price point (called bump point) to reevaluate or adjust liquidity. Unlike ordinary trading paths, the code across liquidity boundaries is complex and cannot be completely included in the HotPath that handles ordinary exchanges, so the processing is separated.
• LongPath: Responsible for processing long-chain compound order transactions, usually referring to complex transactions composed of multiple single operations in a decentralized trading platform or liquidity pool.
• MicroPaths: Contains intermediate components related to single atomic operations that can be called in the context of a preloaded liquidity curve when performing complex composite operations.
• SafeModePath: The main purpose is to limit all other operations when the DEX contract enters a state of emergency and only allow specific administrative operations.
• WarmPath: Contains the core operating logic of liquidity providers, such as casting environmental liquidity (Mint ambient liquidity), casting centralized range liquidity (Mint concentrated range liquidity), destroying environmental liquidity (Burn ambient liquidity), and destroying centralized range Surround liquidity ( Burn concentrated range liquidity)

3.1 Add liquidity

This article mainly introduces two common logics: 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 to identify the corresponding Path contract to which the command call is forwarded through DELEGATECALL;

Then the contract calls the callUserCmd function of the ProxyCaller contract, and calls the corresponding Path contract according to the incoming proxyIdx proxy, which is the WarmPath contract; the commitLP function of the WarmPath contract will enter the corresponding liquidity branch logic based on the incoming parameters, and the contract includes MINT_AMBIEN T_LIQ_LP , MINT_AMBIENT_BASE_LP, MINT_AMBIENT_QUOTE_LP three types of liquidity add logics represent the direct addition of a specified amount of liquidity, and the amount of liquidity added is calculated according to the base token or quote token in the pool.

Finally, the mintAmbientLiq function of the WarmPath contract is mainly responsible for minting liquidity. This contract calls the settlementFlows function of the SettleLayer contract to mint the corresponding liquidity credential tokens for the user.

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

3.2 Token Exchange

When the user uses BEX to exchange tokens, first call the multiSwap function of the BeraCrocMultiSwap contract, which will be redeemed in the CrocSwapDex contract in steps according to the redemption path; then call the caluserCmd function of the CrocSwapDex contract to enter the specified HotPat h or KnockoutPath to execute specific The redemption logic is used here. HotPath will call the swapOverPool function of MarketSequencer to calculate the number of tokens redeemed; finally the HotPath contract will call the settlementFlows function of the SettleLayer contract to give the user the target obtained after transferring money to exchange. Tokens .

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

CurveState Management

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

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

Swap Execution

Step-by-step transaction execution: BEX's code architecture allows step-by-step transaction execution, especially when trading at large scale, crosses multiple liquidity boundaries (such as ticks in Uniswap V3). When crossing a liquidity boundary, liquidity and price need to be readjusted. Iterative computing: 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 bitmaps to mark whether liquidity exists in each price range and quickly find the next available liquidity interval through the bitmap. However, since the current pool liquidity on the BEX chain adopts environmental liquidity, that is, liquidity providers provide liquidity globally, rather than adding centralized liquidity at a specified price, they are currently in token exchange operations. , not much different from uniswap V2.

4. PoL and Bend

Bend is a non-custodial lending agreement on the Bera chain, and the core is to provide the basic lending services for the berachain ecosystem. This project is an important part of the Berachain ecosystem. As an official lending market, it is connected with the PoL consensus mechanism through the following methods. Closely combined.

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

There are three main players in Bend:

1. Provide liquidity providers (Suppliers) of $HONEY tokens.

2. Borrowers who mortgage cryptocurrencies to borrow HONEY tokens.

3. Liquidators (Liquidators) who ensure that the agreement is solvency.

The following figure shows the main architecture of the project:

By studying the contracts on the test chain, liquidity providers will currently deposit HONEY tokens through the supply interface to obtain the corresponding number of AHONEY tokens in a 1:1 ratio as return. Over time, the balance of AHONEY tokens obtained by these users will increase with the increase in interest. It helps to maintain the ecology of the lending pool and ensures that the borrower always has funds to borrow and in the future liquidity provider. You can also use AHONEY tokens to get the corresponding number of HONEY tokens through the withdraw interface to achieve profitability.

The borrower can collateralize the collateral through the borrow interface, thereby lending HONEY tokens lower than the collateral value based on the value of the collateral, and obtaining the corresponding amount of vdHONEY, that is, debt tokens. vdHONEY tokens are similar to HONEY tokens, and they will also increase in quantity over time, requiring borrowers to repay more HONEY tokens. However, in the Bera chain, while borrowing HONEY tokens, the borrower will also obtain a certain amount of governance tokens (BGT), which will stimulate the borrower's enthusiasm for borrowing, maintain the ecology of the lending pool, and also provide PoL consensus Contributions were made.

In Bend, anyone can become a liquidator. When the borrower's health coefficient is less than 1, it is proved that the borrower's collateral value 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 incentivizing the liquidator to perform liquidation .

4.1 Add liquidity

When the liquidity provider is making liquidity deposits, the supply function will first update the current reserve cache and interest rate, which will help maintain the health of the reserve cache and interest rate and obtain the latest reserve cache data at any time, and then verify the current ATOKEN. Whether the token reaches the minting limit, avoid minting too many ATOKEN tokens.

If these checks and updates are passed, the corresponding number of ATOKEN tokens will be minted directly to the liquidity provider 1:1. When the liquidity provider performs liquidity withdrawal, 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, thereby withdrawing 1:1 Corresponding collateral tokens.

It is worth noting that if the liquidity provider here makes a loan, it is necessary to withdraw the corresponding amount of liquidity when the lending factor is healthy. And in the current Berachain, only HONEY tokens can be lent as loan assets, and other collateral cannot rely on loans to obtain interest.

4.2 Lending

When the borrower uses Bend to borrow, he first needs to have a sufficient amount of collateral to the pool through the supply function, and then call the borrow function to borrow. The borrow function will first update the reserve cache to ensure the latest reserve information. Then call the validateBorrow function to verify the legality of this loan, and verify it including the loan limit, collateral value, user credit and other information. If these verifications are passed, the corresponding number of debt tokens, i.e. vdHONEY tokens, will be minted based on the collateral value 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 this time based on the reserve cache and lending interest rate. After successful repayment, the corresponding amount of vdHONEY tokens will be destroyed. . The borrower can only use the withdraw function to withdraw the corresponding amount of collateral when the current debt is successfully repaying a sufficient amount of vdHONEY token so that the current debt is still in a healthy state.

4.3 Clearing

When the borrower's collateral is insufficient, anyone can call the liquidationCall function as the liquidator for liquidation. 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, it will cause the health factor to be too low. If the health factor is less than 1, the liquidator can successfully perform liquidation, destroy the borrower's debt tokens, 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, thereby incentivizing the liquidator to conduct liquidation.

5. PoL and Berps

Berachain Berps is a decentralized leveraged trading platform that allows for perpetual futures contract trading. Berachain's native stablecoin $HONEY is the base token for collateral, expenditure and deposits for all transactions. Users can earn profits by providing transaction liquidity in the $bHONEY vault. The depositor will earn transaction fees generated by Berps and act as a counterparty to the trader's position. In addition, Berps's vault can also receive PoL incentives, that is, users who deposit funds in the vault will receive $BGT.

At present, Berps has launched a test network and supports U-based perpetual contract trading in four tokens: BTC, ETH, ATOM and TIA.

Berps' architecture is very similar to the existing decentralized perpetual trading platform in the current market, with the following important contracts:

● Entrypoint: The entrance for users to conduct transactions (including clearing). The Entrypoint contract will check whether the transaction initiated by the user is legal. If the verification is passed, the contract will create the corresponding transaction for the user.

● FeesAccrued: Calculate and manage loan fees

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

● Markets: manages parameters and limitations for all transaction pairs

● Orders: manage transaction orders submitted by users and store users' funds

● Settlement: Update the status changes of transactions

● Vault: As a trader's counterparty, provide liquidity for trading. Users can deposit funds to Vault to obtain platform fee income and PoL token incentives.

6. Summary

In summary, Berachain is an EVM equivalent L1 blockchain built on the Cosmos SDK. It adopts a unique Proof-of-Liquidity (PoL) consensus mechanism. Users who provide liquidity to Berachain will receive rewards from the PoL mechanism. . With 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, and perpetual trading. Combined with PoL, this will enable Berachain to Excellent in DeFi's transaction depth and user experience.