- Published:
- Last updated:
Introduction to Berachain’s Technical Architecture
The Berachain protocol is an Ethereum Virtual Machine (EVM)-compatible blockchain that allows for the development of customizable decentralized applications (dApps) and additional iterations on top of its platform.
Berachain’s Ethereum-compatibility is provisioned through the platform’s proprietary Polaris Virtual Machine, which allows for simplified application development compared to other Ethereum-focused Cosmos iterations such as Ethermint.
Provisioned via its EVM-compatible design, Berachain allows for the creation of smart contracts that are compiled from Solidity or Vyper to bytecode, meaning that its partnership-ecosystem projects — such as those developed on Cosmos and Celestia — are able to access the Ethereum via Berachain. This is a big deal because it unlocks a vast amount of liquidity sharing between these networks and others.
Berachain’s consensus makes use of CometBFT and enables full modular functionality through the Polaris VM for the creation of various data layers and customization frameworks tailored to address a wide-range of use cases. This is extremely innovative because it allows for full integration with numerous chain types on Cosmos, Ethereum, and Celestia (e.g., Polygon CDK Layer 2’s, OP Stack Layer 2’s, rollups on Celestia, as well as Layer 1’s on both Cosmos and Ethereum).
On Berachain, CometBFT combines with the network’s Proof-of-Liquidity (PoL) consensus mechanism to drive liquidity throughout the ecosystem through its all-encompassing relationship with the protocol’s validators, governance processes, and user-engaged DeFi suite.
Proof of Liquidity is of great significance because it truly drives the Berachain protocol and its underlying ecosystem unlike few models in blockchain today. In fact, the feedback mechanism that PoL and the network’s validators drive towards network users could be considered a first-of-kind economic framework in blockchain systems.
Comet BFT Consensus
Like most Cosmos-focused chains, Berachain leverages CometBFT. That said, differently from other Cosmos iterations, the platform combines CometBFT with its novel consensus mechanism, Proof of Liquidity.
First and foremost, CometBFT is built to be easy-to-understand, highly performant, and user-friendly for the development of a vast range of dApps and utilities.
More technically, CometBFT is a software infrastructure that enables replication of applications across numerous types of machines (nodes operating on distinct blockchain networks). Essentially, CometBFT is an enhanced version of Tendermint Consensus built as the foundation for most Cosmos-enabled blockchains.
As long as at least 2/3rds of nodes remain operational through CometBFT, the integrity of the Berachain network is maintained by ensuring that all live machines (nodes) have access to the same transaction log and compute the same state.
The absence of secure state machine replication (i.e., the ability to ensure that all interconnected nodes work as intended to support the functioning of the protocol) is a significant issue many distributed systems encounter because it plays a vital role in the fault tolerance of numerous on-chain applications, ranging from currency economics and overall infrastructural integrity.
Byzantine fault tolerance (BFT) allows machines to handle failures in numerous ways, even if the machine itself becomes malicious. Although BFT has been prevalent for decades, it has just recently gained mainstream traction, mainly due to the success of blockchain-focused platforms such as Bitcoin and Ethereum.
In simple terms, blockchains are a modernized version of BFT presented as a peer-to-peer (P2P) network that harnesses cryptographic authentication. More specifically, CometBFT is made up of two main technical components that allow it to operate as intended:
- A blockchain consensus engine - based on the Tendermint Consensus algorithm, the consensus engine guarantees that all machines within the system record the same transactions in the correct order.
- An application interface - the Application Blockchain Interface (ABCI) is solely focused on the delivery of transactions to applications for processing.
Differently from blockchains furnished with built-in state machines, CometBFT allows developers to make use of BFT to initiate state machine replication for a wide range of applications using many different types of programming languages and development environments that are fully customizable and can be tailored to support specific uses. This makes the framework highly advanced compared to most blockchain iterations currently in production, as evidenced by Tendermint’s (CometBFT is the newest version of Tendermint) long-term battle-tested reputation in the space.
Berachain’s Polaris EVM Smart Contract Creation Engine
Berachain's smart contract creation and execution engine is realized through the EVM-compatible Polaris Virtual Machine. Contrastingly to other Cosmos-based virtual machines like Ethermint, Polaris recalibrates the capabilities of EVM-compatibility via a novel Cosmos-native configuration.
This model allows for full interoperability with the entire Cosmos ecosystem, enabling support for the next generation of decentralized applications built on Cosmos (and multiple chains). The Polaris VM achieves EVM connectivity through its Polaris EVM library and several additional constructs. As a reminder, a software library is a collection of development-focused resources used to enable software development.
To complement this reliable Ethereum functionality, Polaris Ethereum provides developers with a means to create stateful procompiles and custom modules that can be harnessed to create extremely powerful and efficient smart contracts.
This modular-focused design extenuates a framework for the development of a modular composable stack that efficiently separates the EVM runtime layer (the layer responsible for state transitions that actually change the blockchain continuously throughout its lifecycle) to improve its overall usability.
This design is one of the defining characteristics that allows Berachain developers to create many different types of applications and protocols that are highly superior when it comes to scalability, developer user-experience, and security.
Modularity allows for connectivity with numerous types of chains on Cosmos, Celestia, Ethereum, and others (think Polygon CDK Layer 2’s, OP Stack Layer 2’s, and Layer 2 rollups on Celestia; as well as both Cosmos SDK Layer 1’s and Ethereum Layer 1’s).
These features allow Polaris to create a system that goes way beyond the basic implementation of Ethereum, resulting in a markedly improved EVM experience, highlighting an all-encompassing alternative to existing implementations that is fully interoperable with a host of ecosystems outside of Berachain and even Ethereum itself.
Proof of Liquidity As An Economic Feedback Mechanism
To help ensure the Berachain ecosystem operates as intended, Proof of Liquidity consensus is interconnected with the platform’s governance and economic model. More specifically, the Proof-of-Liquidity framework is designed as a solution to address several critical issues faced by most Proof of Stake (PoS) consensus models.
The Proof of Liquidity framework addresses three main inefficiencies:
- Solves issues related to staking centralization
- Builds liquidity systematically within the protocol and the overall Berachain ecosystem
- Works together to align protocol and validator incentivization
Proof of Stake was designed to improve upon the Proof of Work (PoW) systems that earlier blockchain iterations such as Bitcoin, Litecoin, and others employed.
Proof of Stake is built to balance speed, security, and decentralization by allowing user staking instead of relying on a mining-based model prevalent in PoW systems.
By making use of Proof of Stake, token holders are able to validate transactions and create new blocks correlated to the amount of cryptocurrency they are willing to “stake” as collateral within a delegate or validator node.
Differences Between Proof of Stake and Proof of Liquidity
As is exemplified in numerous production-ready protocol renditions, Delegated Proof of Stake (DPoS) was meant to improve upon its Proof of Stake predecessor.
More specifically, DPoS networks allow network participants to delegate stake needed to vote on the election of nodes (typically called ‘delegates’) required to validate transactions and produce new blocks on the network. Compared to typical PoS networks, DPoS was designed to be more efficient and decentralized while allowing for greater user-involvement in network systemization processes.
However, more largely overall, Proof of Stake networks exhibit numerous challenges in many respects, specifically:
- Improving protocol security typically leads to a reduction in on-chain liquidity required to facilitate actions such as transactions, liquidity pools, and so on.
- Overall stake distribution on-chain becomes too centralized because newly minted tokens are allocated to the same network participants (i.e., network participants often choose to stake their governance tokens with the largest validators).
- Protocols have minimal opportunity to enhance the security of the chain they are developing applications on.
- Validators generally receive limited benefit from the protocols they run infrastructure for.
Berachain makes use of its proprietary Proof-of-Liquidity consensus to eliminate the challenges we introduced above by adhering to the following:
- In return for providing liquidity to BEX liquidity pools, users earn BGT, which is used for Proof of Liquidity delegation.
- User-held BGT is delegated to validators operating within the network.
- Validator block production is based on the validator’s proportional BGT weight delegated towards them. In turn, delegators & validators receive BGT network rewards.
- Through various liquidity pools, validators vote on future BGT inflation rates.
- Rewards (in the form of bribes) are distributed from validators to their corresponding delegators in the event they have been created by the validator.
As is evidenced above, Proof of Liquidity eliminates the first issue we touched on with Proof of Stake through two main mechanisms:
- The BGT delegation token is decoupled from the BERA gas token
- BGT can only be earned by providing liquidity to the Berachain Exchange
The end result is that the token used for staking is no longer the same token used to carry out numerous on-chain actions (meaning that BERA is responsible for different mechanisms than BGT). At the same time, further liquidity is incentivized because there is only one way to earn BGT tokenized rewards because BGT cannot be bought on the open market (meaning more users will carry out the required actions to earn the BGT governance token).
Decentralizing Token Inflation and Eliminating Stake Centralization
To combat the second issue most PoS chains face related to stake centralization and token inflation, Bearachain emits new BGT to liquidity providers. In Berachain’s model, because stake is not given directly back to stakers, and instead is allocated towards distinct market participants (that continuously interact with the protocol on-chain), newly realized token inflation is more evenly distributed when compared to traditional PoS networks.
Finally, the third and fourth issues with Proof of Stake we touched on above are addressed concurrently though Proof of Liquidity because the model incentivizes protocols and validators to work together as a means to incentivize a protocol’s newly created liquidity pool via BGT; and also because the model ensures protocols support those validators to accumulate BGT stake through bribes (an incentivization mechanism that connects builders and users with validators).
A Deep Dive Into the Role of Berachain Validators
Berachain validators play a critical role in realizing the connectivity and operational efficiency of the larger Berachain network by helping ensure the protocol’s security and scalability while working in conjunction with decentralized Proof of Liquidity consensus (which rewards validators in BGT when they propose new blocks on-chain).
On Berachain, to maintain security and protocol integrity, validators are randomly selected to propose new blocks or affirm the validity of proposed blocks. Berachain’s distributed system leverages BGT (the Berachain Governance Token) to incentivize validators to act in an honest and reliable manner to increase the overall equitability of the platform.
More specifically, validators earn BGT regards via transaction fees and block rewards for ensuring the security of the protocol; therefore, providing a financial impetus for users willing to participate in the network’s operational maintenance. What’s more, validators on Berachain have a higher probability of being selected for a given consensus round if they hold more BGT tokens via a weighted random selection process.
Overall, Berachain validators help control economic incentives and reward rates (in BGT) given to protocol users across the ecosystem; an underserved role and set of responsibilities for validators in the industry. Block by block, validators are responsible for directing inflation back into the Berachain ecosystem via numerous on-chain instances, in turn ensuring the network’s overall liquidity (this can also be extended to any governance-approved smart contract on the network should it be passed).
In turn, each validator is able to set its own incentives and the amount of BGT rewards it accrues via a wide variety of governance-approved proposals. Relatedly, the weighted average of these distributions across the network’s ~100 validators determines the APYs of each liquidity pool. This is similar to Curve and Frax gauges, but instead of veCRV/veFXS (tokens used to determine voting power on Curve and Frax), the average distribution and weighting of BGT across the validator set determines network-wide rewards rates.
Users who delegate BGT within their respective validators earn fees in HONEY (Bera’s stablecoin) from the host of protocols that participate in Proof of Liquidity, along with bribes from their corresponding validator they are delegated to. Lastly, users are able to burn (destroy) 1 BGT in exchange for 1 BERA anytime they want. However, this is a one-way process, meaning that once BGT is burned, it is gone for good.
This provides users with the option to choose whether they'd like to hold the liquid gas token (BERA) or the governance token (BGT) (which allows them to earn fees in bribes and the HONEY stablecoin), while also influencing the distribution of rewards throughout the ecosystem to simultaneously accrue fees from applications driven by BGT emissions.
In summary, Berachain is an wholly compatible EVM-compatible Layer 1 that allows users to provide liquidity on various on-chain protocols (via a DEX, perpetuals marketplace, lending and borrowing platform, and future not-yet-created platforms voted on via governance) to obtain BGT, delegate it with network validators to earn fees/bribes and burn it via BERA. Therefore, this entire cycle allows users to contribute liquidity on-chain while also bootstrapping the platform’s security.
This model also furnishes a huge opportunity for Cosmos Hub validators by allowing them to attract new capital and engage in a new governance framework. This is largely realized because these validators are now able to (through Berachain’s Ethereum-compatible Polaris VM) attract delegates and liquidity from Ethereum’s EVM landscape, removing a barrier that has long been a restriction to Cosmos ecosystem growth.
Bribes and Ecosystem Liquidity Incentivization
As we briefly touched on above, Berachain validators make use of a system called bribes that incentives users to delegate their BGT to them instead of another validator within the set. Through this framework, a bribe is provided each time a new block is proposed by a validator. However, similarly to the real-world, there is no guarantee that the validator will accept the bribe.
Bribes play an especially important role in the economic equitability of the system because they actually allow new protocols building on the network to bootstrap liquidity in an extremely efficient manner compared to most typical blockchains.
For example, if a protocol building a DEX on top of Berachain successfully passes a governance vote to have their protocol-specific smart contracts included in the set of main Berachain contracts, those liquidity providers will receive BGT rewards (similarly to how DEXs, perpetuals platforms, and lending LPs receive rewards at genesis).
These BGT rewards help offset the cost associated (think user acquisition, marketing, development etc.) with building a protocol on Berachain, meaning in the long-run, that the team behind the project will have a better chance of gaining tracking, attracting liquidity at a lowered cost, and becoming successful long-term.
Conversely, bribes also allow validators to diversify their treasury needed for long-term development by receiving exposure to many new protocols at no cost to their own users and delegates.
To participate in Proof of Liquidity, users must obtain some BGT governance tokens. In order to do so, the user must deposit another token as liquidity (BERA, HONEY or others) into the Berachain Exchange (BEX) which helps them earn rewards in BGT based on their gauge weight. Recall that the gauge weight is a mechanism that rewards users based on the amount of BGT they send to the liquidity pool as well as the total percentage of BGT they have supplied in proportion to the total BGT supplied to the pool by all users)
Emissions
The validator set on Berachain makes use of an emissions-based mechanism that shares BGT rewards through a precompiled contract called Berachef that allocates a percentage of protocol awards to specific whitelisted (pre-screened and KYC verified) liquidity pools. This essentially means that in order to obtain BGT, users must deposit liquidity into a pool on the Berachain exchange because it cannot be purchased on the open market (thereby forcing users to contribute liquidity to the ecosystem so that its synergistic Proof of Liquidity flywheel effect is realized).
Protocol Rewards
Similarly to blockchains that employ Proof of Stake architectures, Berachain’s Proof of Liquidity network generates incentivized rewards for BGT token holders in relation to on-chain activities based proportionally to their amount of delegated BGT.
In a larger context, rewards accrued on Bearchain constitute three main categories, including:
1. Block Captured Value: On Berachain, rewards passed on as Block Captured Value (BCV) are produced through the use of native dApps on the Bearachain platform including BEX, Honey, and Perps. More explicitly, specific transaction types that occur within these dApps incur a fee that is allocated to a validator in the form of Block Captured Value. In this process, validators take a percentage of the BCV via commision while the rest is denominated to BGT delegators. More distinctly these fees are separated as follows:
- BEX Fee when a user conducts a swap on the BEX, a percentage of the swap fee will be allocated as a portion of the BCV.
- Honey Fee when a user deposits or withdrawals their assets between USDC and Honey, a portion of the fee used is allocated as BCV, while the remaining portion buffers the stablecoin peg on the exchange.
- Perps Fee when a user makes use of the Berachain perpetuals exchange, various transaction types allocate a portion of fees to block captured value.
2. BGT Inflation: The Berachain protocol creates new BGT every time a block is created based on the inflation rate of the network at that given time. This BGT is then sent to liquidity providers that allocate liquidity to certain BEX liquidity pools based on the total amount of new BGT emissions voted towards them by validators during the specific consensus round (or epoch).
3. Gas Fees: Like all blockchain networks, gas fees are required to ensure that transactions are correctly sent and received on the platform (on Berachain these come in the form of EIP-1559 fees similarly to Ethereum). On Berachain specifically, a base fee and a priority fee allow the network to operate as intended. The base fee is burned, while the priority fee represents a tip given to validators and their corresponding delegators.
Berachain Native Oracles
To enable many of the in-house applications that operate within the greater Berachain protocol, the system makes use of a proprietary native oracle system to aggregate and supply consistent real-time price feed data (for the US dollar).
This functionality is realized through a Cosmos-associated module and precompile structure that allows for application and user interaction. Price feeds on the Berachain oracle contribute to the Oracle Precompile Contract which allows developers to integrate the oracle system into their applications to continuously obtain the most accurate real-time price feed data.
The Berachain blockchain oracle is complemented via Skip’s oracle framework which makes use of vote extensions from the newest version of the Application Blockchain Interface (known as ABCI++) enabled via CometBFT’s v0.38 release. This allows validators to contribute to the oracle by providing pricing pairs for each block, enabling validators to choose default providers or their own providers for pricing data.
As of January 2024, the Berachain oracle supports numerous price feeds including BTC/USDC, ETH/USDC, ATOM/USDT, TIA/USDT, and USDC/USDT, with many more being introduced in time. Right now, Berachain oracles rely on price feed data from Coinbase, Coingecko, and OKX, with more price feed data providers to be added soon.
