Author: Glaze & Fundamental Labs Research
Special thanks to Dominator008@Celer, Outprog.eth@everFinance, Zhixiong Pan.
TL;DR
The multichain ecosystem is booming. cross-chain bridges are the base for the multichain ecosystem. There are lots of opportunities in the cross-chain market. In this report, we will explore the potential of the cross-chain market.
There are generally three kinds of technique approaches:
Local Verification
External Verification
Native Verification
Cross-chain bridges have four functions:
Asset-specific
Chain-specific
Application-specific
Generalized
When reviewing a bridge, we care about the following characteristics:
Capital efficiency
Connectivity
Security
Trustless
Insured
Trusted
Speed
Statefulness
There are lots of players in the cross-chain bridge markets. New players face fierce competition, security risks, and need to collect enough TVL. Following are opportunities in this area:
Bridges between layer2s, bridges between layer2 and layer1
Bridges with new tokenomics
Bridge SDK
Bridge Aggregator
ZK Bridge
Market Overview
We are entering a multichain era. The Ethereum dominance decreases. Alt chains take more market dominance. After Ethereum, there are Solana, Avalanche, Polkadot, Terra... These chains are becoming mature and have a complete ecosystem. There are over 115 active blockchains (data from Layer1 Blockchain Protocol). The below chart describes the market dominance of different chains.
Source: https://coin360.com/
Blockchain applications are powerful because of their composability. After entering the multichain era, developers are exploring the possibilities of cross chains.
Developers start with the simplest case, transferring assets between different chains. CEX is the first tool to help people move assets between chains, but this is not an open and crypto native solution.
Now cross-chain bridges have iterated over several generations. Lots of competitors are polishing their products in this area. There are over 80 different bridge projects (data from DecentralizedFinance).
Source: DefiLlama - DeFi Dashboard
Intuition about Cross-chain
The key idea of cross-chain bridges is passing some information from the source chain to the destination chain. It is a simple idea, but how to make it cheap, secure, and extensible is a big problem.
When stepping into cross-chain bridge protocol design, the two main issues for developers are:
How to effectively verify the cross-chain transactions?
How to judge the data consistency on target and destination chains?
For these two questions, developers have different answers and we will introduce several mainstream solutions.
Technical design of cross-chain
Based on how developers verify cross-chain transactions, there are three main solutions:
Local Verification
External Verification
Native Verification
In the cross-chain protocol, there are mainly four steps:
Monitor: Monitor the state and smart contract function call in the source chain.
Consensus (Optional): Relay nodes reach a consensus on the correctness of the relaying message.
Signing: Relay nodes sign the message.
Relay: Pass the message from the source chain to the destination chain.
Local Verification
Hash Time Lock Contract (HTCL) is the most common method for local verification. The is one of the oldest solutions and the easiest one to implement.
Suppose Alice wants to send assets cross-chain to Bob. Alice generates a random number Ka and Bob generates a random number Kb. Alice sends hash(Ka) to Bob and Bob sends hash(Kb) to Alice. They use the received hash to lock their assets with an expiration time. After the lock expires, Alice and Bob can use the random number to unblock the assets.
HTCL is easy to implement, supports the atomic transaction, and, most important, it is trustless. It does have a few limitations. HTCL faces scalability issues because it is P2P. In real-life, users will be hard to transfer a large number of tokens to another chain, because the user cannot find his/her counterparty. Another problem is that it cannot support complex use cases like cross-chain messages.
External Verification
The cross-chain protocol relies on external relayers to pass messages from the source chain to the destination chain. To increase the decentralization, robustness, and safety, there is a relayer network to deliver the transactions. After reaching the consensus in the relayer network, the message will be passed to the destination chain. The whole relayer network performs like a multi-sig wallet.
The problem with this approach is decentralization and safety. The users need to trust the relayer network. The nodes in the relayer network are often bonded. However, the slashing condition is hard to calculate. Thus safety is not guaranteed.
Native Verification
In this model, there is a light client running on the destination chain which can validate and read events or states on the source chain. After the block headers and transactions relaying to the destination chain, the light client can verify the validity natively on the destination chain.
This approach is relatively safe and trustless. Users don’t need to trust the intermediary entities, because the light client can verify the validity. However, this approach costs a lot, especially running a light client on Ethereum. Also, it is development intensive. The cross-chain protocols need to build light clients for every supported chain.
Most technique designs can fit into these three approaches. However, there are some novel approaches. ZKLink and ZKCross use a hub and ZKRU to achieve cross-chain function. Users deposit funds from the source chain to the ZKRU and withdraw the fund from ZKRU to the destination chain. This looks like a ZKRU with multiple base layers. The ZKRU node operators generate proofs for batches of txs and put them into ZKRU smart contracts on all these base layers. An oracle network will ensure data consistency among all ZKRU smart contracts on all these base layers.
Another approach is similar to Tornado Cash. The user makes a deposit on the source chain and generates ZK proofs. Then the user withdraws the token on the destination chain with his/her ZK proofs.
Functions of Cross-chain Bridges
There are roughly four types of bridges:
Asset-specific
Chain-specific
Application-specific
Generalized
Asset-specific
This kind of bridge only helps specific assets to be used across all chains. This kind of bridge collects collateral on the source chain and proved wrapped assets on other chains.
Asset-specific bridge is easy to implement and has unlimited liquidity because the bridge mints wrapped tokens. One common example is most bridges for BTC. Users get the wrapped version, like WBTC on other chains.
Chain-specific
This kind of bridge is built to cross assets from one chain to the other. The bridge will lock tokens on one side and mint native or wrapped tokens on the other side. This kind of bridge is popular in the bridge ecosystem and it is meaningful for chains. For example, when Secret Network launches, it has multiple chain-specific bridges. Users can easily bridge assets from outside to Secret Network.
Application-specfic
This kind of bridge is designed for application expansion to multiple chains. With the application-specific bridge, the developer does not need to deploy the full dapp on every chain. Instead, the developer only deploys a light and modular adapter on each chain. However, it is hard to add more complex functions in the future. Examples are Compound chain and Thorchain.
Generalized
This kind of bridge can be used to deliver messages between chains. Dapps can use this kind of bridge for cross-chain communication purposes, like calling another smart contract on the other chain. Based on this cross-chain communication protocol, developers can increase the user experience in multi-chain scenarios. Staying on one chain, users can reach anything on other chains. Users will not feel the gap between chains.
LayerZero ignites the generalized bridges market. Some chain-specific bridges are implementing their own cross-chain communication protocols like Celer and Anyswap.
Bridge Evaluation
Similar to the trilemma in blockchain, the cross-chain bridge also has its own trilemma. Most projects can only get two out of three.
Unified liquidity: This means the bridge has only one pool on chain A. This one pool is tied to all the other chains.
Instantly guaranteed finality: Before the transaction resolves on the source chain, the cross-chain tx will resolve on the destination chain.
Native assets: The bridge mints native assets to users on the destination chain, not wrapped assets
Besides the cross-chain bridge trilemma, there is interoperability trilemma:
Trustless
Extensible
Generalizable
Most solutions can only get two out of three.
Local Verification = Trustless + Extensible
External Verification = Extensible + Generalizable
Native Verification = Trustless + Generalizable
When reviewing cross-chain bridges, there are five important aspects:
Security: What is the security assumption of the bridge. Do users need to trust anyone? If the fund is lost, what is the backup plan?
Speed: How long users will wait to get their funds on the destination chain.
Connectivity: How many different chains do the bridge support.
Capital efficiency: The efficiency of the liquidity and tx costs.
Statefulness: Ability to support cross-chain communication.
Featured Bridges
Multichain
Multichain is a generalized bridge with external validation. The SMPC network secures Multichain. Multichain has 32 running nodes with 0 stakings.
Multichain currently supports 44 chains, 2090 bridges, and $5.66B TVL. Multichain supports asset transfer, cross-chain communication, and NFT bridges.
For cross-chain communication, the developer needs to implement the following two interfaces:
function anyCall(address _to, bytes calldata _data, address _fallback, uint256 _toChainID) function anyExec(address _from, address _to, bytes calldata _data, address _fallback, uint256 _fromChainID)
Currently, the anyCall is permissioned. Developers need to contact the Multichain team to whitelist their contracts and deposit some fees in the destination contract. It has poor functionality and docs compared to other competitors.
cBridge
cBridge is developed by Celer. cBridge is a generalized bridge with external validation. The State Guardian Network (SGN) secures cBridge. There are a total of 18 validators and 1.2B $CELR staked, around $36M to secure $700M TVL. If there are any security problems, the staked $CELR in SGN will be slashed.
Source: The SGN as a cBridge node gateway and Service Level Agreement (SLA) arbitrator - Celer cBridge
cBridge has $45M daily transaction volume and 3k daily txs. It has $700M TVL across 28 chains.
Besides transferring fungible tokens, cBridge also supports NFT cross-chain transfer in two ways:
Wrapped NFT
Native NFT
For wrapped NFT, cBridge will lock the original NFT and mint a wrapped version on the destination chain. However, for native NFT, cBridge will burn the original NFT on the source chain and mint a new one on the destination chain.
Only NFT following this template can be used as native NFT.
cBridge also offers SDK for developers. Developers only need to care about two steps:
Get quote.
Send transactions onchain.
Besides cross-chain assets, Celer supports cross-chain communication. The whole workflow with token transfer looks like the following diagram:
Source: Celer IM Design Patterns - Celer Inter-chain Message (IM)
The token transfer will go through cBridge and the message will go through SGN and executor.
Similar to LayerZero, the developer only needs to add two functions to the smart contract. Compared to LayerZero, Celer additionally supports token transfer.
// Send message MessageSenderLib.sendMessageWithTransfer() MessageSenderLib.sendTokenTransfer() // Receive message executeMessageWithTransfer
LayerZero
My colleague Iris wrote a dedicated report for LayerZero.
In short, LayerZero mixes native verification and external verification to achieve a generalized function bridge supporting cross-chain communication.
LayerZero is especially easy to use for developers. Developers only need to implement two functions:
function send( uint16 _dstChainId, bytes calldata _dstContractAddress, bytes calldata _payload, address payable _refundAddress, address _zroPaymentAddress, bytes calldata _adapterParams ) external payable; function lzReceive( uint16 _srcChainId, bytes calldata _srcAddress, uint64 _nonce, bytes calldata _payload ) external;
LayerZero has an active community. The LayerZero team implemented Stargate, a cross-chain asset bridge on top of the LayerZero protocol. The community implemented ERC-721O for the NFT cross-chain.
ChainPort
ChainPort is an external verification, chain-specific bridge. It supports 7 chains and has a $208M TVL. The settlement time is around 2.5 minutes. Listing new tokens on ChainPort is permissionless. In the future, ChainPort will release insurance and use ML to detect unusual activities.
Developers can integrate ChainPort into their smart contracts with the following functions:
function depositTokens( address token, uint256 amount, unit256 networkId ) function burnTokens( address bridgeToken, uint256 amount ) function crossChainTransfer( address bridgeToken, uint256 amount, uint256 networkId )
Nil Foundation
Nil Foundation recently released one Demo, verifying Mina states on Polygon and Ethereum.
In one word, this infra allows smart contracts on Polygon or Ethereum to verify the validity of Mina state. With this infra, smart contracts have the ability to recognize invalid cross-chain tx.
This infra can generate Mina state proof and smart contracts on Polygon and Ethereum can verify the proof onchain. In the future, cross-chain apps can directly verify the cross-chain tx validity with this infra. For example, apps can use this infra to verify the tx validity passing from the relayers. We are moving from using game theory to math to ensure the validity of cross-chain tx.
In the demo, it takes around 1 min to generate the proof and costs 2.5m gas to verify it. If the gas price is 80, this costs 0.5 ETH for verification on Ethereum.
We can use this infra to build a bridge from Mina to Ethereum with the following steps:
The bridge locks $MINA on Mina.
The infra generates Mina state proof.
The infra put Mina state proof it onto Ethereum.
Ethereum checks if the state proof is valid.
Ethereum accepts and stores the proof in case it is valid and rejects otherwise.
The bridge checks the state and releases WMINA on Ethereum.
In the future, more EVM chains will be able to verify the Mina state proofs onchain. However, it is not feasible to generate Ethereum state proofs and verify on the Mina onchain.
Cross-bridge Ecosystem
LI.FI
LI.FI is a developer-friendly aggregator for cross-chain bridges and DEXs. Users can exchange one token on the source chain for another token on the destination chain. LI.FI now supports Connext, Hop, cBridge, Multichain, Hyphen, Optimism, Polygon, Arbitrum, and Avalanche cross-chain bridges. For exchanges, LI.FI supports Parawap, 1inch, 0x, Dodo, Uniswap, Sushiswap, Quickswap, Honeyswap, Pancakeswap, Spookyswap, Spiritswap, Solarbeam, Beamswap, and ubeswap.
Based on LI.FI SDK, LI.FI team implements transferto.xyz. Users can customize slippage, which bridge, and DEX to use. Users can find lots of mainstream tokens on transferto.xyz.
For developers, LI.FI provides different ways to integrate LI.FI. If developers don’t need any customizations, developers can use iframe to integrate the trading widget in 5 minutes. Besides iframe, developers can use Node.js API to send cross-chain transactions.
Source: LI.FI
LI.FI has over $250M daily swapped and 186 daily transactions.
Tokenomics
Most tokens in the cross-chain bridge are used as governance tokens. Few tokens can be staked to share the whole protocol revenue. These tokens are also used to incentivize the liquidity providers as mining rewards. Plus, the rewards are used to rebalance the liquidity pool, guiding the liquidity to the appropriate pool.
XY Finance, a cross-chain bridge, raises $12m, but its ATH market cap is $8m. Now its market cap is $3m. In most cases, we can treat cross-chain bridge tokens like DEX tokens, which always perform badly because of the emission. Developers are still looking for specialized scenarios for cross-chain tokens. As investors, we need to be cautious about the cross-chain bridge tokenomics.
Source: coingecko
Security Risks
In one year, the total loss of bridge in hack events is around $1.2B. The fee for the bridge is around 5‱. Multi is the big player in the cross-chain bridge. Thirty days volume for Multi is $5B. One year is around $70B volume with $35M fee. It is certain that the whole revenue of the cross-chain bridge market is still less than the loss fund.
It is hard for cross-chain bridges to stay safe. After reviewing major security issues in these hack events, we found that these issues are all different. Hackers are able to find problems in different parts of the system.
In the Polynetwork hack, the hacker utilized privilege-related vulnerabilities:
The executer contract doesn’t check the input. The executer contract executes arbitrary cross-chain transactions without verification.
The executer contract has the privilege to change the keeper role, which is crucial to the whole system.
The hacker passed the cross-chain transaction which changes the keeper role. Although the hacker didn’t have the permission to change the keeper role, the privileged executer contract helped the hacker to do this. Thus the hacker successfully stole $6B funds.
After the Polynetwork hack, developers remove any privileges of the executer contract and add whitelists for the allowed cross-chain transactions.
In Ronin cross-chain bridge hack, the hacker stole the private keys of admins by hacking the RPC server.
Hackers are discovering different attacking vectors. We don’t know what will be the next security issues of cross-chain bridges. Cross-chain bridges are complex. Thus it is hard to keep them safe. Besides, there are no standards for cross-chain bridges. Developers are implementing their own bridges with their own ideas. It is similar to developers making tokens without using ERC20 library from Openzeppelin. If there is a safe and easy-to-use cross-chain library, the cross-chain bridges will be much more secure.
Wrap Up
There are generally three kinds of technique approaches:
Local Verification
External Verification
Native Verification
Cross-chain bridges have four functions:
Asset-specific
Chain-specific
Application-specific
Generalized
When reviewing a bridge, we care about the following characteristics:
Capital efficiency
Connectivity
Security
Trustless
Insured
Trusted
Speed
Statefulness
There are lots of players in the cross-chain bridge markets. New players face fierce competition, security risks, and need to collect enough TVL. Following are opportunities in this area:
Bridges between layer2s, bridges between layer2 and layer1: There are not as many players in this market as players in the cross-chain bridge markets. This market is still early. In the future, we expect transactions in layer1 to move to layer2. This means more protocol revenues for protocols in this market.
Bridges with new tokenomics: Nobody knows how to use tokens appropriately in the cross-chain bridge. Most tokens are used as governance tokens and secure the whole network. We often see TVL increases, but the token price decreases. The token price does not reflect the progress of the project.
Bridge SDK: A toolkit or standard for building bridges. Developers can quickly construct their own bridges to extend their applications over more chains. Multichain is the future. With this toolkit, developers can expand to new chains fast and secure.
Bridge Aggregator: The aggregator connects with multiple bridges and offers better UX and lower fees. The DeFi market proves the necessity of aggregators. After DEXs, lots of aggregators join the market. This will happen again in the cross-chain bridges market.
ZK Bridge: ZK bridges can offer a better, cheaper, and safer cross-chain experience. Developers can easily build apps on top of the ZK bridge. Nil Foundation made significant progress in Solana and Mina, but it is hard to expand to other chains.
Find us
You can find more cross-chain bridges on decentralized finance.
I am the tech associate in Fundamental Labs. You can find me on Twitter and find FL here.
If you like this report, feel free to like and share this report with your friends. This helps us a lot.
Reference
What's wrong with bridges？ - The Anti-Ape (substack.com)
Blockchain Bridges: Building Networks of Cryptonetworks | 1kxnetwork (medium.com)
