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.

Beosin, as the official audit partner of many blockchain networks such as Ronin Network, Merlin Chain, Manta Network, Self Chain, etc., will explain it in this article Berachain's architecture, the design of three native applications and related contract execution processes help readers gain an in-depth understanding of Berachain.

1. Architecture

Berachain is a Layer1 EVM equivalent chain, which is characterized by The triple token model and liquidity consensus mechanism (Proof-of-Liquidity) have been introduced to integrate liquidity, consensus and governance mechanisms, bringing more incentives to liquidity providers in the chain ecosystem.

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.

The node types in Berachain are divided into two categories: 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 built by Berachain Consensus client and framework pairing.

●Execution client: Responsible for executing smart contract code, managing state changes and executing transactions 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: /p>

$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 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. As an untransferable soulbound token, BGT 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 introduced its value to a USD 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.

Berachain uses Proof of Liquidity (PoL) mechanism different from the traditional consensus mechanism ( Like PoW or PoS), PoL takes into account the contributions made by liquidity providers of all chain ecosystems. Through liquidity mining and staking, Berachain uses PoL to inspire more users to participate in the entire Berachain ecosystem. Here is a case study of Berachain's native decentralized exchange BEX as 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 will receive the governance token (BGT) and allocate it to the chain ecosystem The different reward vaults in the , this parameter is set by each validator.

Liquidity Provider: For BEX, liquidity providers can deposit tokens (such as HONEY and BERA) to provide liquidity and obtain liquidity certificate tokens (such as $HONEY-WBERA) to pledge it to the reward voucher, thereby obtaining BGT rewards based on their contributions.

Delegate governance tokens: BGT holders can delegate them to active validators, adding that validator in the proposal area The weight of the reward is allocated at block time, which affects the allocation of BGT, but this weight will not affect the probability of the validator producing blocks.

Because the current governance token BGT mainly comes from three official native DApps on Berachain, one is Berachain's native decentralized exchange BEX, and the other is Berachain Native nonThe custodial lending agreement Bend, and another one 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 Berachain's native decentralized exchange (DEX) protocol, allowing users to trade without intermediaries Any pair of crypto assets. 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 obtain LP tokens, and then stake these tokens into PoL reward vaults to earn BGT Rewards.

Governance: BEX's governance mechanism allows new liquidity pools to be whitelisted in the PoL reward vault through proposals, allowing these pools to receive BGT rewards.

BEX's main code structure is currently divided into three Part, 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 The contract needs to be called when it comes to intermediate tokens ;

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

The third part is the Path contract. The BEX on the chain has a total of 8 types of Path contracts, different The Path contract corresponds toDifferent functions, according to the User Cmd parameters corresponding to different operations of the CrocSwapDex contract passed to the user, CrocSwapDex will complete the specified logic through the proxy calling the corresponding Path.

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 the initialization and over-staking functions of the pool

HotPath: Responsible for the most common logic of transactions, single-step exchange of tokens

HotPath: Responsible for the most common logic of transactions, single-step exchange of tokens

p>

KnockoutPath: This event is then passed when a transaction crosses a predetermined liquidity boundary or price point (called bump point). Triggered, used 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 separation process

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 are capable of preloaded liquidity when performing complex composite operations The curve is called in the context of the curve

SafeModePath: The main purpose is to limit all other operations when the DEX contract enters a state of emergency, and only allow Specific management operations

WarmPath: contains the core operation logic of liquidity providers, casting environmental liquidity (Mint ambient liquidity), Mint concentrated range liquidity, Burn ambient liquidity), destroying concentrated range liquidity (Burn concentrated range liquidity)

3.1 Add liquidity

This article mainly introduces adding liquidity and There are two common logics for 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. At this time, it is the WarmPath contract; the commitLP function of the WarmPath contract will enter the corresponding according to the incoming parameters. The liquidity branch logic of the contract includes three types of liquidity logic: MINT_AMBIENT_LIQ_LP, MINT_AMBIENT_BASE_LP, MINT_AMBIENT_QUOTE_LP, respectively, which represent the direct addition of a specified amount of liquidity, and the base token or quote generation in the pool Calculate the addition of flow by coin pricing the quantity of sex.

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 certificate token 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 followed by the redemption path in CrocSwapDex Redeem in the contract; then call the caluserCmd function of the CrocSwapDex contract to enter the specified HotPath or KnockoutPath to execute the specific redemption logic, and use the most common HotPath contract here; HotPath will call the swapOverPool of MarketSequencer Function, calculate the number of tokens to be redeemed; mostAfter the HotPath contract calls the settleFlows function of the SettleLayer contract to the target token obtained after transferring and redemption.

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

CurveState Management

CurveState Management

CurveState Management( Snapshotting CurveState: In order to optimize gas consumption, BEX will copy the current curve state (CurveState) 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 price root (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/

Transaction execution (Swap Execution)

Step execution of transactions: BEX's code architecture allows for step-by-step execution of transactions, especially when large-scale transactions, which will cross 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 bitmap to mark whether liquidity exists in each price range, and quickly search through the bitmap A available liquidity range. 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. , with uniswapV2 is not much different.

4. PoL and Bend

Bend is a non-custodial lending agreement on the Bera chain. The core is to provide basic lending services for the berachain ecosystem. This project is the Berachain ecosystem. An important component of the company, as an official lending market, is closely integrated with the PoL consensus mechanism through the following methods.

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

Bend has three main players:

1. Provide $HONEY tokens Liquidity providers (Suppliers).

2. Borrowers who mortgage cryptocurrency to borrow HONEY tokens.

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

The following figure shows the main structure 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 provide subsequent liquidity providers. You can also use AHONEY tokens to get the corresponding number of HONEY tokens through the withdraw interface 1:1 to achieve profitability.

The borrower can collateralize the collateral through the borrow interface, so as to borrow HONEY tokens lower than the collateral value based on the collateral value and obtain the corresponding one. Quantity of vdHONEY, i.e. debt tokens. vdHONEY tokens are similar to HONEY tokens, and they will also increase in the number over time, so that borrowers need 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 in 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 helps maintain Reserve cache and interest rate health and obtain the latest reserve cache data at any time. Then verify whether the current ATOKEN token reaches the minting ceiling to avoid minting too many ATOKEN tokens.

If these checks and updates are passed, the corresponding number of ATOKEN tokens will be directly minted 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 borrows, 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, first there is a sufficient amount of collateral to the pool through the supply function, and then the borrow function is called for the borrowing. 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, and successfully repay it Then destroy the corresponding amount of vdHONEY tokens. The borrower can only use the withdraw function to retrieve the corresponding amount of collateral when the current debt is withdrawn.

4.3 Liquidation

When the borrower's collateral value is insufficient, anyone can call the liquidationCall function as the liquidator for liquidation. The liquidationCall function will first update the debt cache data, and then call ValidateLiquidationCall function checks the borrower's health factor and collateral availability, which can cause the health factor to be too low if the borrower's current debt value exceeds the liquidation limit. If the health factor is less than 1, the liquidator can successfully perform the liquidation and destroy the borrower Debt tokens, and the collateral is sent 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 collateral and expenditure for all transactions and the underlying tokens for deposits. Users can earn profits by providing transaction liquidity in the $bHONEY vault. The vault depositor will earn transaction fees generated by Berps and act as a counterparty to the trader's position. In addition, Berps' vault also You can get the incentive of PoL, that is, users who deposit funds in the gold warehouse will get $BGT.

At present, Berps has been launched on the test network and supports BTC, ETH, and ATOM U-basis perpetual contract transactions with four tokens of TIA.

Berps architecture Very similar to the existing decentralized perpetual trading platforms in the current market, the following important contracts are mainly:

●Entrypoint: The entrance for users to conduct transactions (including clearing).EntrypoThe int 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 all transactions Regarding related fees

●Markets: Manage parameters and limitations for all transaction pairs

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

●Settlement: Update transaction status changes

●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, using a unique liquidity proof (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.