This report aims to capture the current status, future trends, and the impact on the broader cryptocurrency ecosystem in the field of cross-chain bridges.

Author: Ryan Yi

Translation: Mars Finance

TL;DR

• As the number of assets and chains in the cryptocurrency ecosystem continues to grow, the importance of cross-chain bridges is also increasing.

• The main use cases for bridges are still asset transfer (transferring tokens from one chain to another) and exchange (trading tokens from chain A with tokens from chain B). Bridges compete in differentiation aspects such as distribution, product features, and security profiles.

• Looking ahead, major multi-chain issuance technologies (such as CCTP), listings, and overlaps with oracles will impact the use and popularization of bridges.

Disclosure and Footnotes: Projects supported by Coinbase Ventures' investment portfolio are indicated with an asterisk (*) when first referenced in this article.

Bridges have become the core infrastructure for protocols, service providers, and user access to cryptographic use cases. This report aims to capture the current status, future trends, and the impact on the broader cryptocurrency ecosystem in the field of cross-chain bridges.

Current Key Points/Learnings

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

• Native bridges: These are usually standardized contracts that users interact with to deposit/withdraw assets. These can be operated by a set of trusted participants or through decentralized consensus. Chains/L2s running on compatible open-source stacks can also leverage compatibility with first-party security bridges. Examples include Optimism OP Stack*, Arbitrum Nitro*, Cosmos IBC, Superbridge.

• Third-party bridges: These are networks/validators located between chains, acting as "middlemen." Most bridges follow some variant of this design. Examples include Axelar*, Wormhole*, LayerZero (Stargate)*.

• Bridge aggregators: These integrate the previously mentioned two bridge types and provide the best route for cross-bridge for end users/enterprise partners. Examples: Socket*, Li.Fi*.

2. The main purpose of bridging is to provide incremental services between the ledger/chain/location of data/assets and the intended destination for execution of data/assets. The main use cases are still asset transfer (transferring tokens from one chain to another) and exchange (trading tokens from chain A with tokens from chain B).

• Asset transfer: There is an asset (ETH) on "chain A" that is not issued on "chain B." The bridge can facilitate the transfer of assets from "chain A" to "chain B," for example, by using the Zora Native Bridge* to bridge USDC from ETH L1 to Zora L2.

• Exchange: There is a transaction ($ETH) on "chain A" and a transaction ($ATOM) on "chain B." The bridge will send the tokens and then execute the exchange. Examples include [1] Squid Router "swap" and built on top of Axelar "bridging." [2] 0x*'s Matcha handles "exchange" and integrates with Socket to handle "bridging."

• Others: These may include any type of call data or contract ownership, such as governance or multisig ownership. For example, the Uniswap v3 contract is deployed on many EVM chains, but the core governance contract exists on the ETH mainnet. Uniswap Foundation* prefers to have a single contract and execute messages to 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 sign of liquidity/usage.

• The traction of native bridges is directly related to the success of the underlying L2 usage. Bridge contracts will hold funds and can serve as a measure of bridge TVL to L2. According to L2 Beat data, rollup TVL ranges from $50 million to $8 billion.

• Notable third-party bridges like LayerZero, Wormhole, and Axelar are traction based on TVL, trading volume, and chain coverage.

• LayerZero: TVL: ~$304M; Trading Volume: ~$23.9B; Transactions: 34.5M [Source]

• Wormhole: TVL: ~$850M; Trading Volume: $30B; Transactions: 1.7M [Source]

• Axelar: TVL: ~$224M; Trading Volume: $7B; Transactions: 1M [Source]

Bridge aggregators typically route transactions, so the trading volume metric is more appropriate. The distribution between consumers and enterprises (winning signs) is a key metric. Major providers include Socket and Li.Fi.

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

• Security: Fine differences in security will depend on the preferences of the demand side. Most users using bridges seem to prefer speed/latency + cost over security beyond the minimum viable threshold.

• Smart Contracts: Most hacks in bridging occur at the smart contract level. In most bridges, users lock funds in the chain A contract → the bridge reads the chain A contract → mints the user's funds on the chain B contract. Misconfigurations in contract withdrawal permissions can lead to hacking attacks.

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

• Relayer + Oracle: dApps/developers can set up white-labeled relayer + oracle for their own. They can also choose from options set up by other relayer + oracle setups.

• PoS Chains: Security is achieved through consensus in a proof-of-stake manner.

• Distribution: Bridges will attempt to leverage existing partner channels and adopt backend infrastructure GTM.

• Wallets: Bridges will strive to become the infrastructure/API behind existing wallet/portfolio aggregators' bridging functionality. For example, the collaboration between Phantom and Li Fi, and Coinbase Wallet with Socket. Portfolio frontends/wallets will all have some form of bridging support (e.g., Zerion*/Zapper*/Metamask*).

• B2C Frontend: Bridges typically establish a website portal where any user can connect their 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 do not have to jump back to L1 and then to L2 to use the application. It can be seen as an abstract version of the "B2C" mentioned above but natively supported by developers in the application interface. Examples include Aevo*.

• Developer Platforms: Many bridging companies will leverage existing developer platform distributions. For example, Conduit RaaS, Microsoft Azure + Axelar, Google Cloud + LayerZero.

• Ecosystems: While all major third-party bridges cover the same chains, they will vie for first-mover advantage by investing resources in specific chain/developer ecosystems. The rationale is that, as the product feature set requires more advanced capabilities, it is easier to expand within the ecosystem's VM/smart contract framework.

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

• Solana: Wormhole has a broad ecosystem coverage as they got involved early. DeBridge also found traction growth.

• Cosmos: Axelar has strong ecosystem coverage as they are capable of providing IBC-compatible transactions. One data point is that new chains using IBC (e.g., Celestia*) gain Day-1 coverage.

• Other ecosystems can be serviced by most providers.

• Product/Feature Set: Because bridging is in the "abstract" business, they often need to do custom smart contract work to support specific use cases. Therefore, bridging teams often end up carving out a niche market to find specialized vertical areas. Examples include NFT/payment (e.g., Decent), Gas Abstraction, and Swaps.

What We're Watching

CCTP (Circle's multi-chain USDC standard) will be an important data point affecting bridges. CCTP is the standard for USDC multi-chain issuance facilitated by Circle*.

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

• Example: For instance, Axelar's axlUSDC or USDC.e on Arbitrum – USDC on ETH L1 bridged through Axelar and Arbitrum.

• Impact: This will lead to liquidity fragmentation as bridged USDC on chain A and bridged USDC on chain B rely on a single bridge operator. Individual ecosystem DeFi protocols will integrate it as an asset and become increasingly difficult to unwind.

• Post-CCTP: When a new chain launches, it will deploy a USDC token contract compliant with the CCTP Circle standard. When Circle is ready to operate on the chain, it can take over the CCTP-supported implementation. Essentially, the new USDC contract has backward compatibility to comply with the standard downstream.

Example: NewChain is a new L2 platform that does not have native USDC yet. NewChain deploys a USDC contract compliant with the standard. NewChain supports bridged USDC in the short term, but importantly, it can be taken over by CCTP, and bridged USDC can become native USDC.

• Tip: If you are a developer, you typically rely on bridged USDC and lock any liquidity plans tied to assets and bridging. With CCTP, you can transition to native-enabled USDC and use the CCTP API to enable x-chain transfers for USDC.

Adopting CCTP has implications for the long-term defensibility of bridges.

• Bridged USDC (i.e., non-CCTP) is locked in DeFi pools and will remain so until it is unwound or becomes a small portion of on-chain asset mindshare.

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

Example: Ratio of bridged to native USDC: Arbitrum: [57% – 43%]; Base: [33%–67%]; Optimism: [80%–20%]; Polygon: [77%– 23%].

• The CCTP story will be an important lesson for bridges in taking a multi-chain-first approach at the technical level to asset issuance and locking. Bridges must compete in other differentiation areas such as latency, security, and distribution.

Bridges will continue to be used as long as the number of chains and the demand for abstracted user experiences increase.

• This year, changes in blockchain settlement trends (modularization, rollups, data availability, etc.) will impact how users execute transactions and move assets, and bridging will be a popular choice to achieve this user experience.

• Over time, improvements in native protocols and technology will help users avoid withdrawal periods (current Optimistic Rollup design is 7 days) and gain "fast lane" sending/receiving.

• Verified wallets and users holding on-chain proofs (e.g., Coinbase Verifications) may be able to interact with centrally managed liquidity bridges on-chain.

• Wallets hosted by applications (and self-hosted wallets) will continue to strive for "Bridge Plus" – merging "Swap" and "Bridge" as a single transaction for better user experience outcomes.

Bridges and oracles will ultimately compete for data publishing rights.

• Bridges are working to secure first-party issuer use/utilization of their infrastructure. CCTP indicates that native issuers want to build compatibility to reduce reliance on any single bridge. Some projects are also attempting to issue multi-chain token standards. While CCTP focuses on USDC, the way native issuance tokens are handled may be vastly different. For example, $OP is natively issued on the Optimism chain; most ERC is natively issued on ETH L1. Connext has a token standard called xERC (think CCTP for any ERC20).

• Oracles can be thought of as "bridges," but for off-chain data issuers. Chainlink fetches off-chain data (e.g., cryptocurrency prices on CeFi) and brings it on-chain – although they do not own the data themselves, they monetize it by providing this data as a third party. Conceptually, this is similar to the positioning of bridges today. Oracles + bridges will continue to provide incremental services for those needing data/assets and those able to bridge data/assets. Ultimately, they will need to become tools for first-party data publishers to maintain long-term moats/defensibility. Chainlink has its own bridging product CCIP, which is further evidence of overlap.

In conclusion, bridging and interoperability will continue to be the most important trends as bridges become prominent service providers to meet the demands of protocols and users for abstracted user experiences in an environment of increasing chain numbers. In the field of bridging, Coinbase Ventures is investing in new use cases brought about by bridging. If you are building in these areas, we would love to hear from you – Ryan Yi's DMs are open!

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。