Proof of Liquidity allows developers to bootstrap their application's activity by incentivizing usage with BGT Rewards. Developers can incentivize users to take any action or even a sequence of actions and award users with BGT that is not theirs! Recall that with PoL, the BGT that is pushed and awarded to applications comes from validators. Validators emit rewards every time they build a block, and through their cutting board, validators define how they want to distribute those BGT rewards to whitelisted rewards vaults.
A PoL reward vault on Berachain is a white-listed smart contract that receives BGT from validators. It accepts a specific ERC20, defined by its creator, as a staking token and awards stakers a proportional amount of the BGT pushed to that vault. The application decides what that ERC20 token is and how end users acquire that token. This leaves much room for creativity in thinking about how developers want users to interact with their applications.
Let’s take BEX, Bend, and Berps, the three applications with BGT-earning reward vaults, as examples.
Users can earn BGT through BEX by depositing an eligible LP token into its whitelisted reward vault. Since each pair has its LP token (i.e. HONEY-WBERA, HONEY-ETH, etc.), each pair could have its reward vault. Only some pairs have a rewards vault eligible for receiving BGT from validators. Recall that all rewards vaults must be approved through governance, and therefore, only some of the pools in BEX would be earning BGT (unless they were all approved). BEX has rewards vaults for each BGT-earning pool and the ERC20 each vault accepts is the LP token for that pool!
On Bend, Berachain’s native lending protocol, users earn BGT by depositing a debt token representing the amount of HONEY borrowed, something automatically handled by Bend. To borrow, users must deposit collateral in one of the accepted tokens and use that to borrow HONEY.
In Berps, Berachain’s native perps platform, users can earn BGT by providing liquidity into the vault that is used to collateralize the berps platform– it’s a counterparty to all trades so when people are winning, it goes down in value when losing, it goes up in value. When a user deposits HONEY into the vault, they receive an equal amount of bHONEY representing the amount they deposited. Users stake this bHONEY token in the Berps rewards vault.
Reward Any Action
In each of these examples, the application earning BGT has the flexibility to define the journey for how an end user gets the token that must be staked into their rewards vault. On Bex you have to LP into a pool; on Bend, you have to borrow HONEY; and on Berps, you have to provide liquidity into the vault. These examples are relatively simple, but there is room for complex journeys that take users through various application flows to access that final staking token. Applications can now incentivize users to go on specific journeys using validators’ BGT!
At the smart contract level, a user needs a specific ERC20 token to stake in a rewards vault to earn BGT. How they acquire that token is completely up to the creator of that rewards vault, and it can range from simple, one-step actions, to complex, multi-step journeys that end with claiming an ERC20.
With this model, developers can encapsulate any specific action with a rewards vault, and a given application can have more than one rewards vault to incentivize targeted actions. This can be used to bootstrap activity, acquire more liquidity (for cheaper), and act as a shepherd meant to guide users to interact with your application in a particular way.
A common misconception about PoL is that protocols must use their governance token as the staking token, and that only protocols who have TGE’d can participate in PoL. In this model, tokens are used to prove that a user has taken a specific action, such as staking a receipt token in a vault. This means that protocols without their native tokens can also participate in Proof of Liquidity (PoL). Although these protocols may not have a native governance token, protocols can issue receipt tokens meant to serve for bookkeeping similar to how BEX, Bend, and Berps do.
By decoupling the idea of reward vaults and governance tokens, it becomes more clear that there is an unlimited amount of creativity that protocols can use in designing their quests for users to acquire the staking token. Protocols can also implement multiple reward vaults, each with its own staking token. For example, a perpetuals protocol could issue one receipt token for users who go long and a different token for those who go short on a particular asset. This setup would allow them to create separate reward vaults for long and short positions on each asset. Similarly, an application could create a reward vault to incentivize users to go long on its token while setting up another vault to reward users for shorting a competitor's token.
Additionally, a protocol could set up a reward vault on the borrowing side of a money market. For example, if WETH is on the borrowing side, the protocol can make LST looping profitable, even if the borrowing rate for WETH on the exchange is higher than the supply rate from staking yield. This is possible if the difference is less than the incentives provided through the reward vault.
No Free Lunches
Although it is awesome that developers get to create incentivized flows for their users, this doesn’t come for free– otherwise, BGT just becomes a subsidy token.
Recall that for an application to get a BGT-earning rewards vault, it must go through governance approved by BGT holders. Applications will be evaluated on the value they are driving back to BGT holders, among other things. To get an understanding of what kind of value can be shared with BGT holders, take BEX, Bend, and Berps as examples: All three applications take a fee from users upon use, which gets distributed to BGT delegators. A smart contract, FeeCollector, collects these fees from the native Dapps and auctions them for a payout token, then distributed among BGT delegators. Developers can easily tap into this existing infrastructure to outsource the complex logic behind sharing fees with BGT stakers by sending fees in any token to FeeCollector.sol. For example, if you were an NFT project, you could allocate some percentage of mint fees to be sent to FeeCollector and use this to attract new users in the ecosystem to participate in the mint, motivating the ecosystem for a full mint.
The FeeCollector works based on efficient markets theory. Tokens are dumped into the FeeCollector and at any point, someone can pay the predetermined payout amount to acquire the supply of a specific token. Typically, you'd expect MEV actors to set up systems that buy the tokens right when it's profitable to do so. FeeCollector.sol accepts any kind of token in any amount, and once the contract reaches the specified payout amount, an auction is triggered and the basket of tokens is sold for the payout amount in the payout token, in this case, HONEY.
Proof of Liquidity opens up a new design space for developers on Berachain, enabling them to craft unique and incentivized user journeys without bearing the direct cost of rewards. By leveraging validators' BGT emissions, developers can drive specific behaviors, enhance liquidity, and guide users through tailored interactions with their applications. However, this tool comes with a responsibility—projects must demonstrate value to the BGT ecosystem to earn BGT holders’ votes to whitelist their reward vault, making it eligible for BGT emissions. The symbiotic relationship between applications and BGT holders ensures that incentives remain aligned, laying the ground for sustainable growth for the Berachain ecosystem.
