When Ethereum, the earliest smart contract platform, was born, most decentralized applications could only be deployed on Ethereum. With the flourishing of the public chain ecology and the development of L2s, applications have more choices.
Firstly, applications can choose to deploy on a specific chain that suits their business needs. Each chain or Layer 2 solution has its unique mechanism design, with different degrees of decentralization, privacy, data availability, and other features, catering to the needs of various applications.
At the same time, user-friendly tools for creating chains have become more mature, enabling application developers to develop their chains and customize relevant features. A typical example is the DYDX protocol, deployed initially on Ethereum as a decentralized derivatives trading market. It has migrated to a separate Cosmos Zone to meet its throughput requirements better.
Secondly, applications can choose to deploy on various chains, allowing users on different chains to access the services provided by the application. This approach can expand the business scale and increase protocol revenue from the application’s perspective. An example is AAVE’s well-known lending protocol, which deployed its program on six chains.
However, the multi-chain landscape and the choices mentioned above for applications create fragmentation in the Web3 ecosystem, including user experience and liquidity fragmentation.
In many DeFi protocols, liquidity depth is integral to the core user experience. However, the same liquidity cannot exist simultaneously on multiple chains. When a DeFi protocol is deployed on a new chain, liquidity needs to be accumulated, which can reduce the overall efficiency of the protocol.
To address this issue, a new application paradigm is being explored — Omni-dApps. Omni-dApps are a novel way of building applications, where developers design the application as a whole with omni-chain interoperability as a prerequisite rather than simply replicating a single-chain application onto multiple chains.
Omni-dApps consist of different modules on different chains that are interoperable and form a complete application. Compared to multi-chain deployment, Omni-dApps can extend their reach to more chains, allowing users on various chains to access the program’s services without experiencing fragmentation in user experience or liquidity.
The architecture of an omni-chain application can be described as a “headquarters + branch” model. The main logic of the application is placed on one chain, like a “headquarters.” Then, a remote access module is provided on other chains to facilitate interaction with end users (receiving user input and outputting desired results), like individual “branches.”
After the branch receives user input, it passes the input across chains to the headquarters, where it is processed. The input result is then passed back across chains to the branch, which outputs it to the user. In some cases, different modules of the headquarters may be split across other chains, collectively forming virtual headquarters.
Firstly, it is easy to scale. The main logic of the program is processed on one chain, and the application has a unified state record. When the branch module is deployed on a new chain, it can inherit all the state records and liquidity from the headquarters without reinventing the wheel.
Secondly, the user experience is better. Users do not need to worry about which chain the program is deployed on and can access the program from any branch, just like accessing a local program. They do not need to transfer assets back and forth, learn to operate on various blockchains or prepare multiple types of gas for transactions.
Thirdly, it is easy to integrate across chains. When other applications integrate with this program, they only need to connect with the headquarters to use all its functions and liquidity, rather than connecting with all branches separately.
In the table below, we compare omni-chain architecture with multi-chain deployment:
Omni-chain applications have high requirements for operability between chains. Currently, there are many issues with interoperability between heterogeneous chains, including the lack of a secure and reliable infrastructure and a common language for expressing intentions. However, the Polkadot ecosystem does not have these limitations:
As a pioneer of the Omni-chain LSD protocol, Bifrost chose to use a parachain to host the global state of the program and deployed the SLP module to support vToken minting and redemption. Additionally, Bifrost deployed the official liquidity pool for vTokens on this chain, which will serve as the “headquarters” module for omni-chain LSD.
We will first deploy “branch” modules on other parachains and, when infrastructure permits, on heterogeneous chains. Ultimately, users can mint, redeem, and exchange vTokens on any chain. It is worth noting that users will be able to mint, redeem, and exchange all vTokens on any chain, not just a specific vToken. For example, users can mint, redeem, and exchange vGLMR, vMOVR, vDOT, and vASTR on Moonbeam, not just vGLMR.
Furthermore, we expect other dApps on other chains to achieve deep integration with Bifrost by accessing remote modules rather than users directly using “branch” modules. For example, a lending protocol on a particular chain can automatically help users convert collateral into vTokens for a mortgage, thereby increasing user yield without additional operations.
Omni-chain applications open up new possibilities for us as a new paradigm. In addition to the arbitrary chain minting, redemption, and exchange of LSD assets, we can imagine more scenarios:
Under the omni-chain architecture, applications can enable users to complete these operations without knowledge of the cross-chain process. When omni-chain applications become the mainstream paradigm for decentralized applications, application developers and users will experience unprecedented freedom in the blockchain world.
