The Future of Cross-Chain Bridges: Full Chain Interoperability is Inevitable, Liquidity Bridges Will Decline

Author: 0xmiddle, Geek Web3

Editor: Faust, Geek Web3

Introduction: In the Web3 ecosystem, cross-chain bridges are a very important part, serving as a key facility to break the silos between chains and achieve interconnectivity among thousands of chains. In the past, there has been a lot of exploration and practice regarding cross-chain technology, and the number of related cross-chain bridge products has reached hundreds. Some are dedicated to building a unified interoperability layer, while others attempt to facilitate the circulation of multi-chain assets, with varying visions and technical solutions.

This article aims to explore: What does the future of cross-chain bridges look like? Which cross-chain protocols have more potential? Which cross-chain applications are more likely to achieve widespread adoption? What approaches should developers take to build cross-chain applications? In the following text, the author will discuss the development trends of cross-chain bridges and present three core arguments:

A new generation of secure and high-performance cross-chain bridges will become mainstream.

Full-chain applications will become a new dApp paradigm.

Official bridges from asset issuers like USDC will replace liquidity swap bridges.

Main Text: Cross-chain technology can be understood as an extension of scalability. When a single chain is insufficient to handle all transaction requests, multiple chains can be used to bear the load, connected by cross-chain bridges. To understand cross-chain bridges, it is essential to clarify the problems they aim to solve, which can be categorized into different levels.

In simple terms, cross-chain bridges can be divided into the protocol layer and the application layer. The protocol layer is responsible for providing a secure and orderly platform for cross-chain message transmission, while the application layer builds dApps on this platform to meet various user needs in different scenarios.

Evolution of Cross-Chain Bridges at the Protocol Layer

The core of the protocol layer is the security mechanism for cross-chain message transmission, which refers to the verification methods for cross-chain messages. Based on different verification methods and the ideas of figures like Vitalik, the industry has previously categorized cross-chain bridges into three types: hash time-locked atomic swaps, witness verification, and light client verification. Later, Arjun Bhuptani, the founder of Connext, summarized cross-chain bridges into local verification, external verification, and native verification paradigms.

Among them, local verification is only suitable for asset cross-chain transfers and cannot support arbitrary message cross-chain transfers, and the user experience is not friendly (users need to perform two operations to complete a transaction). Some of the earliest cross-chain bridges that adopted this approach have since changed course and abandoned this route. Native verification is the most secure but comes with high costs; on one hand, the gas costs paid by users are too high, and in some cases, it may not be economically feasible at all. On the other hand, the coding costs for developers are also high, as they need to develop corresponding light client verification programs for different blockchains, resulting in a massive engineering workload and extremely limited adoption.

Ultimately, most cross-chain bridges still adopt external verification solutions, where both user gas costs and development implementation costs are relatively low, and they support arbitrary message cross-chain transfers. However, the biggest criticism of external verification is its security. Whether it’s the recently collapsed Multichain, or the RoninBridge (Axie Infinity's official bridge) and HorizenBridge (Harmony Chain's official bridge) that were hacked for their keys, they all tell us that purely external verification solutions cannot become the ultimate solution for cross-chain bridges! The security risks of cross-chain bridges hinder the development of cross-chain dApps, making application layers very cautious when designing corresponding businesses. They aim to avoid any links related to cross-chain interoperability as much as possible, and well-known applications tend to prefer building their own cross-chain bridges (this is true for leading DeFi projects like AAVE, Maker, and Compound). One can imagine that in a city with poor security, people would choose to avoid traveling as much as possible, and the wealthy would travel with bodyguards. However, it is encouraging that a new generation of safer cross-chain bridges is rapidly emerging, including dual-security-layer bridges like LayerZero and Chainlink CCIP; ZK bridges that combine ZK technology with light clients (representative projects: Polyhedra, MAP Protocol, Way Network); optimistic verification bridges that use economic game mechanisms to protect cross-chain security (representative projects: Nomad, cBridge); and bridges that combine ZK and TEE technologies (representative projects: Bool Network). 【To understand their specific mechanisms, refer to the author's previous article "Multichain Collapsed, What Can Save Cross-Chain Bridges?"】 In summary, the new generation of cross-chain bridge infrastructure achieves higher security without sacrificing performance, providing a solid guarantee for application layers in cross-chain interoperability-related designs.

Paradigm Shift of Cross-Chain Interaction at the Application Layer

Initially, all dApps were almost deployed on Ethereum due to a lack of alternatives. However, as the application layer ecosystem flourished, Ethereum became overloaded, providing opportunities for the development of other public chains, leading to the emergence of various ETH killers, sidechains, and Layer 2 solutions. From the perspective of dApps, Ethereum is like a super city such as Shanghai, with a large population but limited resources and high costs. If my business scenario requires high throughput but low interoperability, I can deploy on a less crowded sidechain. For example, a printing factory or plantation does not need to be located in Shanghai but can be situated in the suburbs. The story of dYdX leaving Ethereum is well-known. At the same time, a dApp can be deployed on multiple chains, creating a "chain store" model to serve users on different chains, expanding scale and revenue. For instance, the first successful case of a vampire attack—Sushiswap—has been deployed on 28 chains, essentially on every public chain we can think of. However, this multi-chain application ecosystem provides a poor experience for users: To interact with applications on different chains, users must understand the differences between chains, register addresses on multiple chains, fund gas fees on each chain, and finally transfer assets across different chains—oh my, it’s exhausting! Worse still, many DeFi protocols involve the use of liquidity. If you deploy on multiple chains, you must guide liquidity across those chains, which can lead to liquidity being dispersed across different chains, with depth not being shared. This results in greater price impact when users trade. Some have expressed concerns about the development of Ethereum L2, believing that L2 may fragment Ethereum's liquidity, causing it to lose its competitive edge. Others have proposed unified liquidity solutions like SLAMM, but this solution creates more problems than it solves and is quite clumsy; interested friends can look for related materials to explore further. The real core issue is: How can we aggregate resources and ecosystems across chains so that users do not have to perceive the existence of "chains"? For example, if I have 1 ETH, can I use it wherever I want, hiding the automatic conversion and payment of gas fees on different chains? If I want to use a certain application, can I use it on any chain without needing to transfer assets? At the same time, project teams should not have to choose sides or redeploy on multiple chains but can deploy on the most suitable chain, allowing users from different chains to access it? The application layer needs a new paradigm that hides the "chain" layer. Some have imitated the concept of "account abstraction" and created a new term called "chain abstraction," which conveys this idea. How does an LSD project achieve this? For example, Bifrost claims to be the pioneer of full-chain LSD, adopting a different architectural design from other LSD products. Bifrost has its own chain, Bifrost Parachain, which is a parachain of Polkadot. The liquidity staking module of Bifrost is only deployed on Bifrost Parachain, and the liquidity of its LSD assets—vToken—is also entirely on Bifrost Parachain, but other chains can use the liquidity staking module and liquidity on Bifrost Parachain through remote calls. This way:

• Users can mint vToken on other chains;
• Users can redeem vToken on other chains;
• Users can exchange vToken on other chains, but the liquidity involved is from the Bifrost chain;
• Users can provide liquidity for vToken/Token pools on Bifrost Parachain from other chains and receive LP Tokens;
• Users can destroy LP Tokens on other chains to redeem liquidity.

These operations make users completely unaware of the cross-chain transmission process behind the scenes; everything feels like it is completed locally. Everyone can experience this through the Omni LSD dApp, which currently supports remote minting/redeeming/exchanging of vToken on Ethereum, Moonbeam, Moonriver, and Astar. Without the above features, if a user wants to mint vDOT on Moonbeam, they would have to manually perform three cumbersome steps: ① Cross-chain transfer DOT from Moonbeam to Bifrost ② Stake DOT on Bifrost chain to obtain vDOT ③ Cross-chain transfer vDOT back to Moonbeam! However, with the remote call feature, users' assets seem to remain on the Moonbeam chain while completing the above three steps, directly converting DOT to vDOT on the Moonbeam chain. In other words, throughout the process, users experience Bifrost's services as if they were using a local application on Moonbeam. Sounds cool, right? But how is this achieved? It’s not complicated; Bifrost has deployed a remote module on other chains to receive user requests and transmit them cross-chain to Bifrost Parachain. Once the liquidity staking module completes the processing, it returns the results cross-chain to the remote module. Users only need to initiate requests on the remote chain, and the subsequent process will be triggered and completed by Relayers. Bifrost refers to its architecture as "full-chain architecture," contrasting it with the multi-chain deployment strategies of other LSD protocols as shown in the diagram below: The reason for elaborating on Bifrost's architecture is to help everyone thoroughly understand what Bifrost means by "full-chain architecture." The architecture represents a brand new universal paradigm. Chainlink described this architecture in its blog post "Cross-Chain Smart Contracts" as a "headquarters + branch" model. The main logic of the application is placed on one chain, like a "headquarters," while other chains provide a remote access module to interact with end users (gathering user input and outputting the desired results), akin to "branches." After the branch collects user input, it transmits that input cross-chain to the headquarters. The headquarters processes the input and then transmits the result cross-chain back to the branch, outputting it to the user. In some cases, different modules of the headquarters may be split across different chains, collectively forming a virtual headquarters. In this architecture, the main logic of the program resides in the headquarters, providing a unified state record for the application, thus resolving issues of fragmented liquidity and user experience. Furthermore, applications built on this architecture also exhibit better cross-chain composability, allowing applications on other chains to remotely access the functions of the headquarters just like users on other chains. Although Bifrost calls this structure "full-chain architecture," the author personally does not favor the term "full-chain" or Omni-Chain, as it is ambiguous. This term was originally coined by LayerZero to highlight its unparalleled scalability, but LayerZero has not fully clarified what "full-chain" actually means. Is it "all chains"? Certainly not, as no application runs on all chains. An author involved in a gaming project claimed to be creating a full-chain game, but upon further inquiry, it turned out that this "full-chain" referred to "all code being on-chain," distinguishing it from some Web3 games that only put asset data on-chain, which is entirely unrelated to what LayerZero refers to as "full-chain." I believe a more appropriate expression would be "chain abstraction," Chain-Abstraction, or Chain-Agnostic, both of which can convey a state where "users do not need to care about chains."

The Inevitable Decline of Liquidity Swap Bridges

Finally, we need to discuss another important proposition in the cross-chain field—liquidity. First, we need to clarify which level this issue belongs to. Liquidity does not belong to the protocol layer, as it is unrelated to the secure and orderly transmission of cross-chain messages; it belongs to the application layer and is a special type of application—SwapBridge. The largest category of cross-chain applications is asset bridges, which can be divided into WrapBridge and SwapBridge. The former helps users achieve asset transfer through lock-mint/burn-unlock logic, also known as "asset transfer bridges," while SwapBridge helps users achieve direct exchanges of native assets by reserving liquidity across multiple chains, also known as "liquidity swap bridges." Among them, SwapBridge has the widest application range, with numerous projects, and different SwapBridge projects essentially compete on liquidity efficiency, striving to provide users with the greatest depth at the lowest liquidity expenditure. From another perspective, liquidity is the core service provided by SwapBridge, and the competition revolves around who has the cost advantage, which follows the same logic as general business competition. Here, it is important to understand that cost advantages created by subsidy strategies are unsustainable; you must have an advantage at the liquidity mechanism design level. Many projects in the SwapBridge space, including Stargate, Hashflow, Orbiter, Symbiosis, Synapse, and Thorswap, have showcased various innovations in improving liquidity efficiency, and the author previously wrote an article summarizing this: “Ten Thousand Word Report: Reviewing 25 Liquidity Swap Cross-Chain Bridges and Their Liquidity Mechanisms” However, the CCTP launched by USDC issuer Circle has rendered the efforts of many SwapBridge projects meaningless; in other words, CCTP has eliminated SwapBridge. This feels akin to the Trisolaran civilization spending billions of years and over 200 rounds of civilization to solve the three-body problem, only for Circle to tell you: the three-body problem is unsolvable! For example, in cross-chain exchanges of assets, USDC is the most widely used medium asset. This means that when you need to exchange asset A on chain X for asset B on chain Y, you often need to first exchange A for USDC on chain X, then exchange USDC on chain X for USDC on chain Y, and finally exchange USDC on chain Y for asset B. Therefore, the main form of liquidity reserved by SwapBridge on various chains is USDC. CCTP can support the direct exchange of USDC on chain X for native USDC on chain Y through burn-mint logic, eliminating the need for liquidity reserves. In other words, CCTP incurs no liquidity costs, allowing users to experience extremely low bridge fees. You might say, besides USDC, aren’t there other commonly used medium assets like USDT? Not to mention that in the DEX space, the usage rate of USDT is far lower than that of USDC; are you not worried that Tether might also follow Circle's lead and do something similar? Therefore, I want to tell everyone: SwapBridge is dead, and the official bridges from asset issuers will have an unbeatable cost advantage in cross-chain liquidity. As for some SwapBridge projects integrating CCTP, that’s just the logic of aggregators.

Conclusion

The protocol layer of cross-chain bridges is becoming more secure and reliable, and the era of multi-signature bridges is coming to an end. The past impression of insecurity associated with cross-chain will dissipate with the widespread adoption of the new generation of cross-chain infrastructure; cross-chain applications are iterating through paradigms, significantly improving user experience, and the significance of "chain abstraction" is no less than that of "account abstraction," creating conditions for the mass adoption of Web3; Circle's launch of CCTP has ended the era of liquidity competition among SwapBridge projects, revealing the ultimate fate of cross-chain asset exchanges. In summary, the cross-chain field is undergoing dramatic changes! Understanding the path ahead will enable us to move forward with greater confidence.