Inspiration

In terms of utilizing Polkadot's interoperability, we are drawing inspiration from XCM v3, which is the latest version of the Cross-Consensus Message (XCM) format. XCM v3 supports complex message routing and is expected to further improve the interoperability of different blockchain networks. Additionally, we are considering the use cases discussed in the ISMP post (https://polkadot.polkassembly.io/post/1864) that provide valuable insights into the potential benefits of multi-chain development. By leveraging off XCM v3 and the insights from the ISMP post, we believe that Polkadot protocols can take full advantage of the benefits of multi-chain development, such as improved scalability, security, and interoperability.

Context

We hope to integrate Bifrost’s Liquid Staking Pallet with Polkadot XCM to create a product with XCM features. Based on the feature of cross-chain invocation, developers can remotely interact with Bifrost SLP pallet in parachains that support any environment, truly achieving the multi-chain expansion of DeFi protocols.

Problem Statement

As for the expansion of DeFi protocols to multiple chains, Ethereum's multi-chain DeFi protocols usually "copy" single-chain contracts to multiple chains to achieve "multi-chain deployment". However, this approach may bring some problems:

• User Experience Fragmentation: In order to use different on-chain services, users need to transfer assets across multiple chains, register addresses on different chains, and learn about different operations on each chain. Many times, users need to go through multiple steps and prepare various types of Gas to achieve the desired result.
• Liquidity fragmentation: In many types of DeFi protocols, liquidity depth is a core part of the user experience. However, the same liquidity cannot exist simultaneously on multiple chains. Every time a DeFi protocol is deployed on a new chain, liquidity needs to be rebuilt, which reduces the overall efficiency of liquidity.
• Polkadot needs to introduce more PoS assets from external chains to accumulate underlying liquidity for DeFi and establish upper-layer applications.
• LST governance rights integration: At present, there is no LST in the market that can inherit the governance rights of the original chain. On the one hand, most proposals in the Ethereum ecosystem are implemented off-chain. On the other hand, due to the lack of interoperability restrictions, LST is technically unable to inherit the original chain governance rights. However, with the gradual popularity of Polkadot OpenGov, how LST retains the governance rights of the original chain has become a key issue. And we're working hard to achieve this by leveraging XCM's interoperability.

Our Vision

In order to solve both problems of "multi-chain deployment" and “liquidity fragmentation” at the same time, we can adopt a new approach, which is to deploy the protocol "subject" that owns asset issuance rights only on one chain, and then expand it to other chains that support cross-chain calls. This method can not only solve the problems mentioned above, but can also improve the overall security of the protocol. Therefore, we suggest using Polkadot XCM to achieve this, and using cross-chain bridges to expand to outside Polkadot. (We are prioritizing Bridge Hub as the solution at next stage.)

For heterogeneous blockchains like Ethereum, we can still ensure that the sovereignty of asset issuance is placed on the Polkadot side, and asynchronous LST minting is achieved through system parachains like the Asset Hub and through bridges.

In the above figure, Other LSTs in corresponding ecosystems such as BSC, Ethereum, etc., require separate liquidity maintenance for the LST protocol, and the asset types of LST may not be compatible with Polkadot Substrate. However, Bifrost will deploy remote pallets (contracts on EVM chains), enabling one-click deployment and cross-chain LST interactions.

This model can be described as a "headquarters + branch" model. The main program logic is placed on one chain, the "headquarters". A lightweight program, a “brand store” is provided on other chains to facilitate interaction with end users (to obtain user input and output the results they need). When a "branch store" or user provides input, the input is transmitted across chains to the "headquarters", where it is processed and the result is output, then the result is transmitted back across chains to the "branch store" for output to the user.

For Bifrost, the LST casting protocol SLP (Staking Liquidity Protocol) deployed on the Bifrost chain acts as the "headquarters". The protocol called SLPx, which is invoked on other remote chains, acts as the "branch store".

Omni Liquid Staking Advantages

1. Easy to expand. The main logic of the program is processed on a single chain, and the application has a unified state record. When users deploy “branch modules” on a new chain, they can inherit all the state records and liquidity from the “head office” without having to reinvent the whole thing;