Original author:Ryan Yi

Original compilation: Mars Finance

TL;DR

As the number of assets + chains in the crypto ecosystem continues to grow, the importance of cross-chain bridges also increases.

The main use case for bridging remains asset transfer (tokens on one chain to tokens on another chain) + exchange (tokens on chain A trade with tokens on chain B). Bridge competes on differentiators such as distribution, product features and security profiles.

Going forward, major multi-chain issuance technologies (such as CCTP), listings, and overlap with oracles will have an impact on the use and popularity of bridging.

Disclosure and Footnote: Projects supported by Coinbase Ventures portfolio companies are indicated with an asterisk (*) when first cited in the article below.

Bridges have become the core infrastructure for protocols, service providers, and users to access cryptographic use cases. This report aims to capture the current state of the cross-chain bridge space, future trends, and impact on the broader crypto ecosystem.

Current takeaways/learnings

1. Classification: The types of bridges can be divided into 3 categories: native bridges, third-party bridges and bridge aggregators.

Native Bridge: Typically a canonical contract that users will interact with to deposit/withdraw assets. These can be operated by a group of trusted participants or through decentralized consensus. Chains/L2s running on compatible open source stacks can also take advantage of bridging compatibility with first-party security. For example, Optimism OP Stack*, Arbitrum Nitro*, Cosmos IBC, Superbridge.

Third-party bridge: is a network/validator that sits between chains and acts as the “middleman”. Most bridges follow a variation of this design. Examples include Axelar*, Wormhole*, LayerZero (Stargate)*.

Bridge Aggregator: Integrates the first two bridges listed above and provides end users/enterprise partners with optimal routing across the bridges. For example: Socket*, Li.Fi*.

2. The main purpose of the bridge is to provide services for the increment between the data/assets (ledger/chain/location) and the expected execution destination of the data/assets. The main use case remains asset transfer (tokens on one chain to tokens on another chain) + exchange (tokens on chain A are exchanged for tokens on chain B).

Asset transfer: There is an asset (ETH) on Chain A that is not issued on Chain B. A bridge can serve to send assets from Chain A to Chain B, for example, bridging USDC from ETH L1 to Zora L2 via the Zora Native Bridge*.

Exchange: There is a ($ETH) transaction on Chain A and a ($ATOM) transaction on Chain B. The bridge will send the tokens and then perform the exchange. Examples include [1] Squid Router swap and built on Axelar bridge. [2] 0x*s Matcha is responsible for switching and integrates Socket to handle bridging.

Others: These may include any type of call data or contract ownership, such as governance or multi-signature ownership. For example, Uniswap v3 contracts are deployed on many EVM chains, but the core governance contracts exist on the ETH mainnet. Uniswap Foundation* would rather have a single contract and execute messages on other chains in a one-to-many manner (rather than creating a governance contract on each chain). (source)

3. Bridges are typically measured by on-chain AUC (or TVL) as a marker of liquidity/usage.

The traction of the native bridge is directly related to the success of the underlying use of L2 itself. The bridge contract will hold funds and can be used as a way to measure bridging TVL to L2. According to L2 Beat, the TVL of rollups ranges from $50 million to $8 billion.

Notable third-party bridges are LayerZero, Wormhole, and Axelar, which are based on traction in TVL, transaction volume, and chain coverage.

LayerZero: TVL: ~$304M; Volume: ~$23.9B; Transactions: 34.5M [source]

Wormhole: TVL: ~$850 M; Volume: $30 B; Transactions: 1.7 M [source]

Axelar: TVL: ~$224M; Volume: $7b; Transactions: 1M [source]

Bridge aggregators typically route transactions, so the volume metric is more appropriate. Distribution between consumers and businesses (a sign of winning) is the key metric. Major providers include Socket and Li.Fi.

4. Bridges compete on various aspects of differentiation, and there may be multiple winners depending on use case and distribution.

Security: The nuances of security will depend on demander preferences. Most users of bridges seem to prefer speed/latency + cost over security beyond a minimum feasible threshold.

Smart Contracts: Most hacks in bridging occur at the smart contract level. In most bridges, the user locks funds in the chain A contract → the bridge reads the chain A contract → mints the user’s funds on the chain B contract. Misconfiguration of withdrawal permissions in the contract may lead to hacker attacks.

Multisig: Control of the contract is delegated to a group of trusted participants. These are typically operated by the project team and other trusted stakeholders.

Relayer + Oracle: dApps/developers can white label setup for their own Relayer + Oracle. They can also choose from a menu of options for other Relayer + Oracle settings.

PoS chain: Security is achieved through consensus in the form of proof of stake.

Distribution: The bridge will try to leverage existing partner channels and adopt GTM as the backend infrastructure.

Wallets: Bridges will strive to be the infrastructure/API behind existing wallet/portfolio aggregator bridging capabilities. Examples include Phantom’s collaboration with Li Fi and Coinbase Wallet’s collaboration with Socket. Portfolio frontends/wallets will all have some form of bridging support (e.g. Zerion* / Zapper* / Metamask*).

B2C frontend: The bridge will usually set up a website portal where any user can connect the wallet + bridge funds. Examples include Stargate.Finance (LayerZero), Bungee.Exchange (Socket), Jumper.Exchange (Li Fi) and Squid Router (Axelar)

DApps: DApps themselves will include a “deposit” feature that uses bridging so users don’t have to jump back to L1 and then L2 to use the application. Think of it as an abstract version of the B2C mentioned above, but supported natively by developers in the API. Examples include Aevo*.

Developer Platform: Many bridge companies will leverage existing distributions of developer platforms to enable. For example Conduit RaaS, Microsoft Azure + Axelar, Google Cloud + LayerZero.

Ecosystem: While all major third-party bridges cover all the same chains, they strive for first-mover advantage by investing resources in specific chains/developer ecosystems. The rationale is that since the product feature set needs to be more advanced to differentiate, it is easier to scale within the virtual machine/smart contract framework of the ecosystem.

EVM: Socket is dedicated to the EVM rollup ecosystem (OP Stack, Arbitrum*, Polygon* CDK). L2s like Aevo and Lyra are existing users.

Solana: Wormhole’s ecosystem is very broad because they were involved early on. DeBridge has also seen an increase in traction.

Cosmos: Axelar’s ​​ecosystem reach is strong due to their ability to offer IBC compliant transactions. One data point is that new chains using IBC (e.g. Celestia*) get Day-1 coverage.

Other ecosystems can be served by most providers.

Product/Feature Set: Because bridges are in the abstract business, they often need to do custom smart contract work to support specific use cases. As a result, bridging teams often end up carving out a niche, looking for specialized verticals. Examples include NFT/payments (e.g. Decent), Gas Abstraction and Swaps.

what are we paying attention to

CCTP (Circle’s multi-chain USDC standard) will become an important data point for the impact of the bridge. CCTP is Circle*’s standard to help USDC multi-chain issuance.

Pre-CCTP: When a new chain launches, it will use a bridged version of USDC due to the lack of support for native USDC (since Circle must approve and add support for native USDC to each new chain on their roadmap). As the blockchain hopes to have Day-1 DeFi support, USDC will be bridged from ETH L1, and the bridged version of USDC will become the standard for the new blockchain.

Example: For example, axlUSDC on Axelar or USDC.e on Arbitrum – USDC on ETH L1, bridged through Axelar and Arbitrum respectively.

Impact: This leads to liquidity fragmentation because chain A bridging USDC and chain B bridging USDC rely on a single bridge operator. Separate ecosystem DeFi protocols will integrate it as an asset and become more difficult to unwind.

Post-CCTP: When a new chain launches, it will deploy a CCTP Cicle-compliant USDC token contract. When Circle is ready to run on-chain, it can take over the implementation of CCTP support. Basically, the new USDC contract has backward compatibility to comply with the fallout of the standard.

Example: NewChain is a new L2 platform that does not yet have native USDC. NewChain deploys a standards-compliant USDC contract. NewChain supports bridging USDC in the short term, but the important thing is that it can be taken over by CCTP and the bridging USDC can become native USDC.

Tip: If you are a developer, you will typically rely on bridging USDC and locking in any liquidity plans tied to the asset and the bridge. Using CCTP, you can transition to enabling USDC natively, and you can click on the CCTP API to enable x-chain transfers for USDC.

The adoption of CCTP has had an impact on the long-term defensibility of the bridge.

Bridged USDC (i.e. non-CCTP) is locked in the DeFi pool and will remain that way until it is released or becomes a fraction of the on-chain asset’s mindshare.

While CCTP will use bridges (given their distribution) to help support CCTP, adoption of CCTP will naturally lead to a higher share of native USDC issuance and a lower share of bridged USDC. Bridging USDC as an asset locked in various DeFi pools will naturally unwind over the long term.

For example: the ratio of bridged to native USDC is: Arbitrum: [57% – 43%]; Base: [33% – 67%]; Optimism: [80% – 20%]; Polygon: [77% – 23%].

The story of CCTP will be an important lesson in Bridge’s multi-chain first approach to approaching asset issuers and locking them in at the technical level. Bridges must compete in other areas of differentiation such as latency, security, and distribution.

Bridges will continue to be used as long as the number of chains and the need for user experience abstractions increases.

This year, changes in blockspace settlement trends (modularization, rollups, data availability, etc.) will have an impact on how users perform transactions + move assets, and bridging will be a popular choice to enable this user experience.

Over time, improvements in native protocols and technology will help users avoid withdrawal periods (currently 7 days for Optimistic Rollup designs) and gain fast lane sending/receiving.

In the future, verified wallets and users holding on-chain proofs (such as Coinbase Verifications) may be able to interact with centrally managed liquidity bridges on-chain.

Application-hosted wallets (and self-hosted wallets) will continue to work on Bridge Plus - instead of Swap and Bridge as two different transactions, they will be merged into one transaction for more Good user experience results.

Bridges and oracles will eventually compete for data publishing rights.

Bridge is working hard to get first party issuers to leverage/use their infrastructure. CCTP demonstrates that native publishers want to build compatibility to reduce dependence on any single bridge. Some projects are also trying to issue multi-chain token standards. While CCTP is USDC-focused, the way tokens are issued natively could be significantly different. For example: $OP is issued natively on the Optimism chain; most ERCs are issued natively on ETH L1. Connext has a token standard called xERC (think any ERC 20 CCTP)

Oracles can be thought of as bridges, but for off-chain data issuers. Chainlink takes off-chain data (prices of cryptocurrencies on CeFi) and brings it on-chain – even though they don’t own the data themselves, it monetizes it by providing it as a third party. Conceptually, this is similar to how bridges are positioned today. Oracles + Bridges will continue to serve those who need data/assets and those who can bridge the delta that exists between them. Ultimately, they will need to become tools for first-party data publishers to maintain long-term moats/defenses. Chainlink has its own bridging product, CCIP, which is further evidence of overlap.

In summary, bridging and interoperability will continue to be the most important trends, as bridging will become a compelling service provider in an environment where the number of chains continues to grow in order to meet protocol and user needs for an abstract user experience. In the bridging space, Coinbase Ventures is investing in the new use cases that bridging brings.