Author: Beosin

Berachain, as a blockchain that has garnered significant market attention, possesses multiple innovations and features that attract a large number of community members 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 within the chain's 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 provides fast transaction confirmation 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 as Ethereum—the EVM (Ethereum Virtual Machine), ensuring 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.

Node types in Berachain are divided into two categories: validator nodes and RPC nodes. Each node can be configured as a full node or an archive node, with each type being a combination of an execution client and a consensus client. This means that from an execution perspective, it supports any EVM execution client and pairs 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 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 Berachain's native gas token, 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 validator delegation. 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; 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: Berachain's native stablecoin, 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's 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 eligibility.
• Block Proposal: A random active validator is selected to propose a new block.
• Reward Distribution: The proposing validator receives governance tokens (BGT) and allocates them to different reward treasuries in the chain's 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's 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 governance token BGT mainly comes from three official native DApps on Berachain: 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 primarily 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 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 to PoL reward treasuries through governance, 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 for 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 exchanges 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 exchanges, 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 corresponding to different operations passed into the CrocSwapDex contract, 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 exchanges
• KnockoutPath: Triggered when a transaction crosses a predetermined liquidity boundary or price point (referred to 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 contained within the HotPath that handles ordinary exchanges, thus 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: Include intermediate components related to single atomic operations, which can be called in the context of preloaded liquidity curves when executing complex compound operations.
• SafeModePath: Primarily aims to restrict 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 section mainly introduces the common logic of adding liquidity and token exchanges. 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.

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, 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 parameters passed in. The contract includes three types of adding liquidity logic: MINTAMBIENTLIQLP, MINTAMBIENTBASELP, and MINTAMBIENTQUOTE_LP, representing direct addition of a specified amount of liquidity, as well as 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 Exchange

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

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

Curve State Management

Curve State Snapshotting: To optimize gas consumption, BEX copies the current Curve State from on-chain storage (EVM Storage) to memory and rewrites 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 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 interval (or tick), the system gradually consumes or accumulates 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 interval through the bitmap. However, since the liquidity in the pools on the BEX chain currently adopts ambient liquidity, meaning liquidity providers provide liquidity globally rather than adding concentrated liquidity at specified prices, the token exchange 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 and is 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 in 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 as a reward. Over time, the balance of AHONEY tokens obtained by these users will increase with the accumulation of interest, helping to maintain the ecosystem of the lending pool and ensuring that borrowers always have funds available for borrowing. In the future, liquidity providers can also withdraw the corresponding amount of HONEY tokens using the withdraw interface at a 1:1 ratio with AHONEY tokens to realize profits.

Borrowers can use the borrow interface to collateralize their assets to borrow HONEY tokens below the value of the collateral and receive the corresponding amount of vdHONEY, which is a 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 also receive a certain amount of governance tokens (BGT), which stimulates borrowers' willingness to borrow, maintains the ecosystem of the lending pool, and 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 receive 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 tokens have 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 balance of ATOKEN tokens owned by the user based on the current interest amount, allowing them to withdraw the corresponding collateral token at a 1:1 ratio.

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

4.2 Lending and Borrowing

When borrowers use Bend for lending, they first need to provide sufficient collateral to the pool through the supply function, and then call the borrow function to take out a loan. The borrow function first updates the reserve cache to ensure the latest reserve information, and then calls the validateBorrow function to verify the legality of the loan, including checks on the borrowing limit, collateral value, and user credit. If these validations pass, the corresponding amount of debt tokens, namely vdHONEY tokens, will be minted based on the collateral value, allowing the borrower to receive the corresponding amount of HONEY tokens.

When borrowers need to repay the loan, the repay function will also first update the reserve cache and interest rates, and based on the reserve cache and borrowing interest rates, determine the amount of HONEY tokens the borrower needs to repay. After a successful repayment, the corresponding amount of vdHONEY tokens will be burned. Borrowers can only use the withdraw function to retrieve the corresponding amount of collateral after successfully repaying a sufficient amount of vdHONEY tokens, ensuring that the current debt remains in a healthy state when withdrawing collateral.

4.3 Liquidation

When the value of a borrower's collateral 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 result in a low health factor. If the health factor is less than 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, 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, expenditure, and base token for all transactions. Users can earn rewards 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 who deposit funds into 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 trades initiated by users, and if validated, the contract will create 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 the counterparty for traders, providing liquidity for trades. Users can deposit funds into the Vault to earn platform fee revenue and PoL token incentives.

6. Conclusion

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

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。