2022 / 11 / 25 10:00
Bifrost
For the ever-changing Web3.0 world, liquid staking is an old track. Since the birth of Proof of Stake, there have been efforts to release the liquidity of Staked assets. In order to defend against long-range attacks, PoS networks generally set an unlocking period, staked to the Work Token in the network. When the staked asset needs to be released, it is necessary to wait for the unlocking period to end before the staking can be officially released. (For example, the unlocking period of Staking DOT is 21 days, and the unlocking period of Staking KSM is 7 days), such a mechanism intensifies the enthusiasm of Staking participants to seek ways to release liquidity.
Initially, it was mainly wallets and exchanges that provided custodial liquidity staking to users, and later on, decentralised protocols came to provide non-custodial liquidity staking and to issue staking derivatives that could be freely circulated and used in DeFi.
In early 2020, Bifrost launched the SLP protocol (Staking Liquidity Protocol), becoming one of the representative projects of decentralized liquidity staking services. Users stake the original work token to the PoS network through the SLP protocol, and will be able to obtain staking derivatives: vToken. vToken will undertake the function of releasing liquidity, because it can be freely exchanged in DEX at any time, and can also be used as the basic asset in DeFi to participate in other Farming activities.
With the merge of Ethereum, the liquid staking track has become the focus track again. Some industry researchers, including community partners, have found that Bifrost is very different from other liquid staking projects, and asked us many questions, such as the following one:
Many liquidity staking projects on the same track directly make contracts on other chains without their own chains. Why does Bifrost build a chain?
To answer this question, it is necessary to clarify the concept of vToken in architectural design: Most liquidity staking protocol are built on the original chain. Lido staking on ETH is an Ethereum contract implemented in the Solidity language, while Lido staking on SOL is a Solana contract implemented in the Rust language.
Thus, the native chain for Lido staking derivative, stETH, Ethereum derivative, and its native format is ERC-20. Lido Staking derivative on Solana, while the native format is SPL.
All vTokens, whether it is vETH, vKSM, vDOT, including the recently launched vMOVR and vGLMR, are all minted on the Bifrost chain. That is to say, all vTokens are on Bifrost chains. Since Bifrost is a Kusama/Polkadot parachain, all vTokens are native assets of the Dotsama ecosystem.
The most direct reason for this is that Bifrost is rooted in the Polkadot ecosystem, and is to some extent responsible for bringing external assets into Polkadot, of which Staking derivatives are an important asset type. When used in Dotsama’s DeFi ecosystem, vTokens provide users with an additional layer of income compared to the original Token.
The deeper reason is that issuing all types of vTokens on one chain allows for a uniform format for all types of vTokens and a uniform related interface, making it easier to integrate them across chains. Let’s take the example of a lending protocol to illustrate this point.
Assume that a BSC has a lending protocol and wants to integrate vToken into its protocol as a collateral type. It has two options:
Plan A
Build a BSC-Bifrost cross-chain bridge, and import the vToken as a mapped asset into the BSC as a Wrapped vToken. The protocol adds the Wrapped vToken to the collateral whitelist.
Plan B
After building a BSC-Bifrost cross-chain bridge, BSC deploys a collateral management program directly on the Bifrost chain. It notifies the lending program on the BSC via the cross-chain bridge to release the loan when a collateral action occurs on the Bifrost chain. BSC then informs the collateral program on the Bifrost side via the cross-chain bridge to release the collateral when the user returns the loan on the BSC chain.
Although Plan A requires the protocol to do more cross-chain communication, it will have a more simple procedural logic for collateral clearance. The lending protocol initiates a liquidation process when the collateral price falls below a threshold, auctioning off the collateral to repay the user’s loan. The liquidation of the collateral requires a liquidity pool calling. With Plan B, the lending protocol calls the vToken liquidity on the Bifrost chain to perform liquidation directly through the collateral management process on the Bifrost side.
However, with Plan A, there is likely no Wrapped vToken liquidity on the BSC. If there is, it is not an official pool, and liquidity will be relatively low. It is not impossible to call liquidity across chains, but the process logic is complicated. Thus, we think Plan B will be the first.
But when BSC intends to integrate for example, Lido Staking derivative, stToken, into its protocol as collateral, it is not as simple as a vToken integration.
As we mentioned, the different stTokens are native assets on other chains. With each stToken integration, it is necessary to expand the cross-chain bridge to support the new chain. Though it is possible to work with a third-party cross-chain bridge, the third-party cross-chain bridge support constrains its function.
When the lending protocol wishes to deploy collateral management contracts on the native chain in the stToken location, for every integrated stToken, they must deploy a contract. For each contract, the logic related to collateral receipt, release, clearing, and liquidity invocation, must be implemented on its deployment chain.
In short, integrating N different stTokens requires N efforts. If BSC has to integrate N vTokens, it takes only one action.
Although we gave the example of a debit protocol above, it is also clear that for other types of DeFi applications, it is easier to integrate vToken, than stToken, because it is always easier to interact with one chain than with multiple chains.
This is the deeper reason why we use a separate chain — the Bifrost chain — to host the vToken. In fact, the convenience doesn’t stop there.
If a front-end application wants to integrate vToken minting, redemption, yield display, including Swap transactions, it only needs to do the interface development once. To integrate stToken, you would have to do it N times.
Bifrost, as a Polkadot/Kusama parachain, is part of the Polkadot ecosystem, so if the DeFi program you want to integrate vToken with is already in the Polkadot ecosystem, then it will be easier to do so, without having to build your own cross-chain bridge or use a third-party cross-chain bridge. XCMP is known to have the same security level as the Polkadot relay chain, so that cross-chain integration and cross-chain communication does not add new risk exposure due to the existence of the bridge.
Above we have described the core benefits of Bifrost’s design of vToken as a native asset on the Bifrost chain, which is easy integration across chains, including easy integration with other DeFi applications and easy integration with any front-end interface.
The future is multi-chain. This is one of our fundamental judgements. Based on this judgement, we believe that cross-chain applications will be the dominant form of dApps in the future, and that cross-chain calls between applications on different chains will be the norm. Therefore, Bifrost has designed many of its DeFi products, including the SLP protocol, with the ease of cross-chain integration in mind. And we believe that the entire broad wave-card ecosystem (including the heterogeneous chain ecosystem that bridges to wave-cards) and XCM-based communications will further enable cross-chain integration between applications.
Despite Lido’s leadership in the liquidity staking space for ETH, if the future will be multi-chain, as we think, then Bifrost vToken is designed to have even more potential in the cross-chain era!
Bifrost is currently the number one player in the Kusama liquidity staking space. As we support more chains for liquid staking, the advantages of a unified vToken format and interface will become more and more significant.
