Zeeprime Capital: The Current Status and Future Development of Cross-Chain Composability

Original Title: 《The Bridges Are Dead, Long Live The Bridges!》

Original Author: Rapolas, Zeeprime Capital

Translation: Biscuit, Chain Catcher

The multi-chain theory has existed for many years. In 2021, it emerged as the first application-driven manifestation (albeit imperfect), followed by various bridging solutions that brought us rotatooors, arbitragooors, sybilooors, and other colorful roles. The multi-chain theory has made some pragmatic strategies to promote the development of the ecosystem.

Interoperability is a multi-dimensional concept that can be interpreted differently by users based on their architecture and use cases. Therefore, popular terms like multi-chain, cross-chain, interchain, and omnichain are not rigorous enough. Most participants cannot distinguish between these concepts.

In fact, the dilemma of cross-chain bridges is being solved one by one. Users care about different aspects of cross-chain bridges or may not care at all, while developers are weighing the trade-offs of applications, and of course, there is no consensus on what the best design is.

As observers and long-term investors in the field, we have studied the architecture of universal messaging protocols and discussed the ecological development based on these framework protocols.

This article is divided into the following sections:

1. A quick review of the failure history of cross-chain bridges

2. The value trends of cross-chain bridges

3. Current solutions

   a. Heterogeneous interoperability solutions

• Axelar

• Abacus

• Nomad

• LayerZero

• Wormhole

  b. Homogeneous interoperability solutions

• Cross-Chain Message Passing (XCMP)

• Inter-Blockchain Communication (IBC) and Cross-Chain Accounts

• Disruptive bridging solution Chainflip

1. Composability

• NFT / Gaming
• Governance
• Identity/Reputation
• DeFi

1. Looking to the future

A Quick Review of the Failure History of Cross-Chain Bridges

It is important to note that cross-chain bridges are not native interoperability solutions for blockchains. Instead, cross-chain bridges attempt to fill the gaps between two blockchains and meet users' demands for low-cost block space. Admittedly, this brings a series of trade-offs for users, as the ecosystem incentives provided by cross-chain bridges across different blockchains may not cover the bridge fees, slippage, and gas fees involved.

Cross-chain bridges need to address numerous issues, and countless media have discussed these problems. Currently, the vast majority of bridges in the market are either operated by trusted centralized organizations or are trustless decentralized protocols. We want to highlight several of the most obvious categories of risk:

• Authority-proof cross-chain bridges that are entirely based on trust. When cross-chain bridge validators have no collateral, the cross-chain bridge becomes a custodial system (which is worse than CEX, as users do not require assets when crossing chains);
• Consensus vulnerabilities/failures at the cross-chain bridge layer. This could lead to losses for cross-chain bridges holding collateral funds and users holding synthetic assets created by the cross-chain bridge;
• The chains of the cross-chain bridge do not share state. During the bridging process, if Chain A suffers a 51% attack and transactions are reverted, synthetic assets on Chain B may encounter problems. In this case, assets on Chain B are no longer fully collateralized. The security of the system depends on its weakest link;
• Synthetic assets are lower-quality collateral in DeFi and may pose systemic risks. Most bridges wrap tokens into synthetic assets, which are essentially asset receipts on the bridge:
• If synthetic assets are widely used as collateral in DeFi, any decoupling for any reason could lead to asset liquidation;
• Each synthetic asset competes for liquidity, ultimately leading to user fragmentation and worse execution prices;
• Some synthetic assets require external oracles for pricing, which is another source of risk.
• Trustless bridges have at least one centralized component. While these cross-chain bridges aim to gradually become fully decentralized, there is at least one centralized component in their systems, such as oracles or relayers. If these external components fail to operate normally, it could pose risks to the system;
• Smart contract risks. As seen from the attack on the Wormhole protocol, consensus vulnerabilities are not the only attack vector. Hackers can exploit smart contracts to generate forged signatures approved by validators, allowing them to mint synthetic tokens without providing the underlying collateral. This is just one smart contract exploit, and there may be more vulnerabilities in smart contracts.

The Value Trends of Cross-Chain Bridges

With the development of Layer 1 networks, most cross-chain bridges are built to meet the immediate needs of DeFi users. There are no significant differences between externally validated bridges; they do not provide users with a higher value proposition. Over a sufficiently long timeline, the survival rate of these bridges drops to zero, but some of them are more resilient.

Secondly, we believe that universal messaging protocols are a more fundamental service infrastructure compared to bridges, significantly enhancing the services for use cases like cross-chain identity, governance, and DeFi, and becoming a moat for these protocols. Bridges are businesses of network effects, while universal messaging protocols can help projects capture value. We expect to see 2-3 permissionless messaging protocols with optimal trade-offs (outlined in the next section below), on top of which more differentiated cross-chain bridges will emerge.

Current Solutions

Few can discern universal messaging from cross-chain bridges. We view cross-chain bridges as underlying communication channels that can support data transmission and smart contract calls, upon which applications can be built, including token bridges. This type of framework should help resolve some of the divergences in the cross-chain bridge narrative.

Communication between heterogeneous blockchains must involve intermediary cross-chain bridges. Nowadays, some of these messaging formats are built to support homogeneous communication (IBC in Cosmos, XCM in Polkadot), while heterogeneous communication has not been well developed. There are many reasons, including development difficulty, security, and network latency.

In short, universal messaging protocols weigh the pros and cons of various aspects and bet on the features that users care about. Then, applications built by developers based on these protocols choose the most suitable design solutions. We see the main trade-offs as follows:

• Security design. Relying on third-party consensus (e.g., Wormhole, conversely, like Nomad);
• Sovereign consensus/regions. Having customizable security designs, building applications, and isolating failures (e.g., Abacus) versus global security models (e.g., Axelar);
• Cost of messaging. Some low-cost design mechanisms, such as optimistic fraud proofs (e.g., Nomad), are much cheaper to implement than other design mechanisms (like light clients (IBC));
• Latency. Messaging between two different states introduces latency. It depends on block time and validation design. For example, due to the 30-minute fraud time required for optimistic confirmations, LayerZero's approach has faster finality compared to Nomad. Latency can lead to information leakage, instant attacks, and other forms of MEV, which are currently completely excluded from interoperability discussions.

There is also an unresolved question regarding the token value capture of these protocols. While proof-of-stake models are quite intuitive and transparent, if tokens from other protocols are used for sovereign security purposes in addition to the tokens of the cross-chain bridge protocol itself, value may shift from the cross-chain bridge protocol tokens to other protocol tokens. Even so, the proof-of-stake mechanism will increase throughput and consensus, allowing the cross-chain bridge protocol tokens to generate value.

Cross-chain bridge protocols without proof-of-stake models may not yet have determined their token value capture. Overall, we believe that messaging protocols/bridges have not yet defined clear business models, even though they have already achieved valuations in the billions. For example, it can be compared to TCP/IP, where Cosmos IBC has a perfect product-market fit but does not rely on its native token ATOM (instead, the execution burden is borne by the validators of the various blockchains connected by IBC).

Finally, the current utility of messaging protocols is limited to cross-chain communication for multi-chain block space. Their future direction depends on the fate of Layer 2 networks built on Ethereum.

Heterogeneous Interoperability Solutions

Axelar

Axelar is a proof-of-stake blockchain with an external validation design that includes a collection of validators running full nodes or light client validators connecting to other networks.

Axelar supports universal messaging across multiple EVM environments and Cosmos-based public chains, reporting its on-chain state to facilitate consensus among validators, and then generating and transmitting messages between them. Each validator does not need to run a node for each chain they support, allowing the protocol to support more networks.

Axelar deploys a gateway contract on each connected chain. This contract is used to receive and send messages between Axelar and external blockchains. Axelar validators collectively hold the keys to control this contract (proportional to the staked AXL tokens), and messages/transactions will only pass through when the validators' votes reach a minimum threshold.

Application developers connect to the Axelar network through a set of APIs that allow them to make requests to the network and call functions on different connected chains via the gateway contract. Among them, application developers can build their own relayer services instead of using Axelar's default relayer.

Overall, this architecture simplifies the workload for developers (no need to build proprietary cross-chain solutions), but its security is outsourced to Axelar's consensus nodes, which may present a single point of failure. Additionally, since all messaging goes through Axelar's chain, Axelar must have sufficient scalability to continuously meet demand; otherwise, it will become a technical bottleneck for throughput.

A potentially interesting use case for designs like Axelar is atomic transactions across two chains. This is because Axelar consensus can be used to order events and set conditions for executing transactions. However, this is complex in practice, as the states of two asynchronous environments are constantly changing, and atomic swaps at the Axelar consensus level may also fail.

Related Reading: 《In-Depth Analysis of Cross-Chain Communication Protocol Axelar: How to Unlock Cross-Chain Composability and Liquidity?》

Abacus

Abacus adopts a trustless external validation design: validators stake ABC tokens on each chain they sign messages on, and if they misbehave, the protocol can penalize them.

Abacus allows messaging across EVM blockchains while ensuring that the value of the state and validators' tokens remains the same. This achieves trustlessness and attaches economic costs to fraudulent activities. The network has inboxes and outboxes on each connected chain, where applications send and receive data. Validators sign messages in the outbox, while processors monitor and handle messages in the inbox.

Abacus enhances the anti-censorship characteristics of messaging, as validators cannot selectively choose which messages they want to sign. Instead, validators are signing a verification node: a Merkle root that contains all application messages from various connected chains. Most other messaging protocols only sign individual messages, which are easier to censor.

The Abacus model allows application developers to attach conditions to their inboxes, effectively placing another security layer called sovereign consensus on incoming data. This provides security assurances for developers' applications. Therefore, Abacus's native token can be used by application-specific validators, creating additional governance scenarios for the token.

While the protocol itself is primarily a tool for developers (maintaining a single application code across multiple chains, designing sovereign consensus), it also benefits users by enhancing security. Teams building on the Abacus network will have the advantage of enabling cross-chain lending, managing positions from a single source, or offloading computation to cheaper Layer 2 networks.

Nomad

Nomad bridges through optimistic fraud proofs. Optimistic means that unless someone proves the sent message is invalid, all messages are assumed to be valid by default. Validators sign messages on the original chain, and after a 30-minute fraud period, cross-chain transactions are processed.

Nomad's optimistic design is a trust-minimized approach. It allows applications on EVM chains to send messages using an updater that is signed. Fraud by the updater is allowed but costly (the updater's collateral can be slashed), it is public (watchers can compare the transmitted messages with the expected messages in the Merkle tree), and it can be rejected (applicable to all messages during the 30-minute fraud period).

The smart contract on the source chain (Home) collects and manages the message tree and holds the updater's bond, while the contract on the target chain manages a copy of the messages and sends the received messages to the final recipient.

The optimistic design removes validators from the architecture (making the system more trustless) while minimizing the cost structure compared to light client bridges (which are secure but very expensive). This achieves a balance between cost and security—rather than observing the entire chain, the agents in the Nomad design only use very specific bits in the chain—containing the Merkle tree of messages.

Today's watcher list is permissioned (run by the team) to avoid protocol halts, and watchers can spam by submitting false challenges for free, blocking all transactions from passing through. To make the watcher setup permissionless and decentralized, watcher fees could be introduced, making it economically unfeasible to submit false challenges.

The most significant trade-off made by Nomad may be the 30-minute optimistic fraud period, which applies to and extends the execution time of all messages. That said, as the protocol matures and the watcher incentive mechanisms strengthen, the fraud period can be shortened; otherwise, specific applications using Nomad can choose the fraud period that best suits them (shorter fraud periods can be used for low-value exchanges).

Nomad is already exploring several interesting use cases:

• Cross-chain governance for Uniswap: establishing governance processes on a single chain and implementing them across multiple chains through standardized smart contract solutions;

• Asset bridging in collaboration with Connext: shortening the 30-minute fraud time by directly utilizing liquidity pools established on different chains through the Connext bridge. Liquidity providers bear the optimistic fraud risk and are compensated through fees paid by users using the bridge;

• Recurring cross-chain payments for Superfluid: paying subscription fees, salaries, rewards.

Related Reading: 《Seed Round Financing of $22 Million, What’s the Story Behind Cross-Chain Interoperability Protocol Nomad? How Does It Work?》

LayerZero

LayerZero is a messaging protocol that connects a set of smart contracts (endpoints) on different blockchains through relayers and oracles.

LayerZero allows arbitrary data transmission between connected chains. While it currently supports EVM chains, other chains may be added in the future—Solana, Cosmos, Polkadot. The protocol deploys a set of smart contracts on each connected chain (the so-called endpoints). Its purpose is to allow users to send and receive messages using the network. Compared to IBC, this is a more relaxed approach, as there is no need to run light clients, and network costs are variable rather than fixed.

Endpoints are connected by relayers and oracles. After interacting with the endpoint on the source chain, the relayer sends transaction proofs to the target chain, while the oracle sends the block header. The endpoint on the target chain combines the block header to verify the received transaction proof to validate the message. Both the relayer and oracle are paid by users interacting with the endpoint on the original chain.

The key assumption and potential risk vector of this model is that relayers and oracles will not collude by providing fraudulent proofs and block headers to the target chain.

LayerZero currently runs a default relayer, although it will be open-source, allowing any application to run its own relayer to enhance security (assuming it does not want to collude with the oracle against itself);
Chainlink is the expected preferred oracle, but it is not without risks, as it effectively introduces third-party consensus to LayerZero. Currently, since Chainlink is not ready to support the protocol, oracle functionality is performed by FTX/Sequoia/Polygon.

We can consider having a custom, application-specific relayer as an additional security level that applications may want to isolate themselves from Chainlink's input. However, for most teams, running a relayer may not make sense, and they will simply choose LayerZero's default relayer.

An application utilizing the LayerZero messaging protocol is Stargate—released by the LayerZero team—it is essentially a cross-chain DEX for native, paired assets. There is a liquidity pool on each chain, provided by LP tokens, into which the Stargate bridge enters. However, Stargate does not maintain a single liquidity pool between two chains but is able to unify them and allow for bi-directional transfers.

Related Reading: 《LayerZero White Paper: A Trustless Omnichain Interoperability Protocol》

Wormhole

Wormhole has an external validation design, but there is no connection between the validators (guardians). Validators run full nodes for each connected chain.

Each blockchain connected by Wormhole (6 EVM chains plus Solana, Oasis, and Kusama's Karura) has a core contract deployed by Wormhole. By running a node on each chain, Wormhole's guardians can observe the state and see incoming messages. Thereafter, messages are verified by reaching consensus on Wormhole and relayed to the core contract on the target chain. Messages are encapsulated and received in a format called VAA (Verifiable Action Approval), which only allows for message composability across all connected chains.

All 19 Wormhole guardians observe each chain, and consensus requires at least two-thirds of the guardians to verify a message. Guardians are participants with vested interests not only in Solana but also in other ecosystems (e.g., validators) and are trusted not to collude with users of the protocol. Given that guardians do not have collateral bonds, it can be viewed as an authority-proof system. The relayer that transmits messages to the target chain can be permissionless and application-specific. Wormhole's long-term vision is to combine zero-knowledge proofs and light clients into a so-called compressed light client proof system, where consensus on the state of connected chains can be achieved at minimal cost in a trustless manner.

Today, there are two extensions on top of the underlying messaging protocol: token bridges and NFT bridges. Both host assets on the source chain and issue wrapped assets on the receiving chain.

Wormhole supports multiple applications, including the Pyth oracle, which can use Wormhole to send on-chain price data from Solana to other blockchains. Given the differences in block times, the reverse is impractical.

Homogeneous Interoperability Solutions

Cross-Chain Message Passing (XCMP)

XCMP is a locally validated messaging protocol—messages are ultimately signed by validators, who simultaneously protect the chains exchanging messages.

XCMP is designed to facilitate communication between parachains (Layer 1 equivalents) on Polkadot. The protocol uses a specific messaging structure called Cross-Consensus Message Format (XCM), which contains XCMP messages. Messages are exchanged between collators—the full nodes of the main chain and their specific parachains—conveying state transitions.

After triggering a smart contract on parachain A, the collator of that parachain places the message in an outbound queue (indicating the target parachain B). The collator of parachain B actively scans for inbound messages, and once found, places it in an inbound queue for processing. This is when the collator on parachain B can propose a new block, and when validators reach consensus on the occurrence of message passing (as they can read inbound and outbound messages on both chains).

Notably, for security purposes, parachains can indicate which other parachains they want to communicate with by opening communication channels and specify the conditions for processing inbound messages.

XCMP allows protocols to go beyond data transmission—instead, smart contracts can execute another smart contract on different chains. This assumes that the chains in question share the same implementation through Polkadot's Substrate blockchain framework and use the same pallet. In this sense, XCMP is a walled garden—it works within the Polkadot ecosystem but not outside of it.

Inter-Blockchain Communication (IBC) and Cross-Chain Accounts

IBC is a locally validated messaging protocol—each connected chain runs a light client of the counterpart chain and does not require external consensus to validate state.

IBC, like Polkadot's XCM, is a communication format. Blockchains built using the Cosmos SDK and Tendermint consensus can connect to other chains in the Cosmos ecosystem using IBC. Since IBC is based on light clients, chains can continuously reach consensus on the state of other blockchains by validating the block headers of other blockchains.

While the maintenance cost of the light client approach is very high, it is the most secure design to date (compared to heterogeneous messaging protocols), provided you trust the consensus of the two chains communicating via IBC. In addition to light clients, IBC also requires (permissionless) relayers to transmit packets (token transfers, smart contract calls, etc.) across the two blockchains in a supported format.

Inter-chain accounts leverage the latest capabilities of IBC, allowing users to perform operations on the target chain while simultaneously being on the source chain, without manually transferring tokens. This includes governance voting, liquidity transfers, staking, etc.—users can remotely control accounts located on different blockchains. This cross-chain communication requires both chains to establish mutual channels, effectively allowing the governance of both chains to choose with whom they want to exchange messages.

Each Cosmos SDK/Tendermint chain must choose to join this system and accept the light client operational overhead of all other chains within IBC. While the IBC model does not exclude non-Cosmos SDK chains from joining, they must effectively be accepted and become part of the security model and technology stack.

Disruptive Bridging Solution Chainflip

While not a messaging protocol or a cross-chain bridge, we feel that Chainflip deserves mention here. You can think of it as a decentralized exchange for native token swaps across all supported chains, with its own set of validators (consensus). The business case is to replicate the experience and business model of centralized exchanges for spot trading, but on-chain and in a permissionless manner. Chainflip is built in direct response to Thorchain and its underlying asset (RUNE) model.

Chainflip will have its own proof-of-stake blockchain and 150 permissionless validators, running full nodes or light clients for all connected chains. Validators will observe chains, reach consensus, and transfer funds by using a multi-party computation system to swap tokens. The protocol effectively has a relayer and oracle built into its design, making this architecture also usable for universal messaging, but the team has decided not to do so to optimize the spot trading protocol.

Chainflip is divided into two layers: settlement and accounting:

• The settlement layer is native to each chain and is where all native tokens reside.
• The accounting layer tracks balances, processes events, and executes cross-chain transfer instructions. It also reserves a virtual AMM for all currency pairs and tracks the assets of liquidity providers.

As swaps are executed, virtual balances are updated until the swap is complete, and assets will be paid to users as local payments on the receiving chain. In other words, this architecture allows users to deposit tokens into a vault on Chain A and withdraw swapped tokens from a vault on Chain B.

As liquidity providers, users will be able to provide collateral in any supported (native) token and participate in their preferred liquidity pools. The AMM itself is based on a JIT (just-in-time) design that particularly encourages market makers to compete for liquidity fees by providing the best prices in incoming trades—this ultimately benefits users. Due to the inherent latency of cross-chain interactions, all market makers are aware of the trades in advance.

Application developers will be able to use Chainflip by calling any public endpoint on the Chainflip network via websocket or JSON RPC. After notifying the network that it is ready to swap with the receiving chain and specified wallet, the application will receive a unique deposit address, and when deposited, the swap will automatically initiate for the user.

Related Reading: 《Brief Analysis of Chainflip Labs: A New Cross-Chain Trading Protocol Invested by Pantera Capital》

Interconnected Applications

In this section, we will explore use cases for cross-chain applications—NFT/Gaming, Governance, Identity/Reputation, and DeFi. To make these applications chain-agnostic, they first need to connect to APIs or smart contracts deployed by universal messaging protocols.

Another workaround is to allow application developers to use SDKs like Biconomy. Essentially, Biconomy will build its own bridging infrastructure, leveraging universal messaging protocols in the backend, and then abstract cross-chain transfers, such as NFT purchases or gas token swaps.

NFT/Gaming

This category can leverage universal messaging protocols in the following ways:

• NFT x DeFi. Borrowing NFTs in a chain-agnostic manner—loans and collateral will be on different blockchains;
• Cross-chain NFT utility. Owning an NFT (e.g., PFP or gaming project) on Chain A and accessing its utility across all other chains;
• Optimizing chain selection for holding NFTs and gaming experiences. This means moving games to higher throughput environments while keeping NFTs on blockchains with the best security assurances;
• Whitelisting and bounty programs. Unlike random off-chain tasks used for whitelisting, projects can create bounties for operations across various chains for people to collect fragments (almost like a game). A fully completed puzzle will allow them to mint an NFT on Ethereum.

Overall, we believe that gaming interoperability is overstated, as once you break it into several environments, game balance becomes an issue, and the entire space is in its early stages, with everyone developing on their own islands.

As for NFT x DeFi, this category must first find product-market fit on a single chain, and currently, the supply of this product far exceeds the demand for it.

Governance

Cross-chain voting will allow communities to organize and implement governance while being decentralized across multiple chains. Essentially, voting will occur on each chain and then sent to a single choice chain for counting. Governance decisions will then be messaged to each chain where the application resides for implementation.

Voting can also occur on a single chain but allows DAOs to control contracts existing on other chains. Another cross-chain use case for DAOs is to redirect accrued fees from all chains where the deployed applications are back to the treasury on the main chain using universal messaging protocols.

Identity/Reputation

This may be the most exciting aspect of cross-chain composability, although it is the most distant, as even today, there is no unified form of identity expression on a single blockchain.

Applications leveraging universal messaging protocols will be able to:

• Consider creditworthiness across multiple chains for issuing loans (higher credit scores = better terms);
• Provide gated access control to content or data (assuming you meet eligibility criteria based on on-chain activities across multiple chains);
• Issue proofs based on multi-chain activities;
• Aggregate and measure social capital from web3 social platforms across all chains (e.g., fan engagement).

Just as DeFi has liquidity fragmentation, identity represented in the form of wallet addresses is also incomplete when scattered across multiple blockchains.

Decentralized Finance (DeFi)

As outlined by several protocol teams, DeFi applications are broad in scope. It essentially abstracts all intermediary transactions and gas to capture yield opportunities on other chains.

The direct ideas are:

• Cross-chain perpetual contracts. Rage Trade aims to create the most liquid ETH/USD perpetual futures market using Uniswap V3 and LayerZero by:
• Allowing liquidity providers in other DeFi primitives (AMM, money markets, other derivatives applications) to deposit their yield-generating tokens into Rage Trade contracts on the original chains (Avalanche, Ethereum L1, Polygon, BSC, Arbitrum);
• Using these original chain deposits to provide concentrated liquidity for the ETH/USDC pair on Uniswap V3 on the main chain (Arbitrum) behind LayerZero's messaging protocol. Assets are provided in an 80/20 ratio, where 80% of the collateral is retained in the original vault, and 20% is used to provide ETH/USDC liquidity;
• Using LayerZero's Stargate to settle profits and losses across original chains in USD;
• The end result: 1) Liquidity providers are incentivized to provide their yield tokens, as the 80/20 strategy is superior from a yield perspective; 2) Enhanced liquidity for the ETH/USDC pair, as liquidity provision is aggregated cross-chain.

• Cross-chain lending. Borrowing money on Chain B using collateral on Chain A, rather than wrapping collateral and forcing it cross-chain;

• Cross-chain DEX (or DEX aggregator). Interchangeable liquidity across all connected chains—it can be of the Stargate or Chainflip type or CLOB;

• Cross-chain yield aggregation. Capturing all yield farming opportunities from one chain.

Looking to the Future

At a high level, we can envision two extreme outcomes for the future of cross-chain. The idealistic version would allow us to operate seamlessly across different ecosystems without compromising security and self-regulation across different domains. The realistic version resembles the structure of today's internet—open areas connected to closed areas, but different environments have varying degrees of security and sovereignty.

In the coming years, we may continue to enforce interoperability. However, the early work of teams like Abacus and Nomad suggests that we may lean towards conditional cross-chain communication, and security is customizable to avoid far-reaching impacts in the event of failures. Connectivity is valuable, but separation and choice must be preserved.

Cross-chain composability as an industry has only scratched the surface. To a large extent, the focus has been on developing cross-chain bridges, which are the most obvious use case after competitive Layer-1 launches. We believe that some of the theoretical application concepts outlined in this article will be realized in the next 12 months.

Related Reading:

《Comprehensive Analysis of Cross-Chain Bridges: Design, Trade-offs, and Opportunities》

《First Class: In-Depth Analysis of the Current Development Status of Cross-Chain Bridges and the Potential of Various Projects》

《High-Risk Areas in the Crypto World: What Common Vulnerabilities Do Cross-Chain Bridges Have?》