State of Bridging
By Ryan Yi
Tl;dr
The importance of bridges have grown as the # of assets + # of chains are continuing to grow in the crypto ecosystem.
The main use-case for bridges continues to be in asset transfers (tokens in one chain versus another) + swaps (trade token on Chain A for token on Chain B). Bridges compete on various aspects of differentiation such as distribution, product features, and security profiles.
Looking to the future, primary multichain issuance technologies (like CCTP), go-to-market, and overlap with oracles will have implications on the usage and popularity of bridges.
Disclosures and footnotes: Coinbase Ventures portfolio company backed projects are denoted with an asterisk (*) when first referenced in the article below.
Bridges have emerged as core infrastructure for protocols, service providers, and users in accessing crypto use-cases. This report is meant to capture the current state of the bridging landscape, the future trends in bridging, and the implications for the broader crypto ecosystem.
Current Takeaways / Learnings
1. Taxonomy: the types of bridges can be thought of across 3 categories: Native Bridges, 3rd-Part Bridges, and Bridge Aggregators.
Native Bridges: are generally the canonical contract that a user will interact with to deposit / withdraw assets. These can be operated by a set of trusted participants, or through decentralized consensus. Chains / L2s that operate on compatible open-source stacks may also leverage bridge compatibility with first-party security. Examples include Optimism OP Stack*, Arbitrum Nitro*, Cosmos IBC, Superbridge.
3rd-Party Bridges: are networks / validators that sit between the chains and act as “middle-men.” Most bridges follow a variant of this design. Examples include Axelar*, Wormhole*, LayerZero (Stargate)*.
Bridge Aggregators: integrate the first two bridges listed above and provide the best route across bridges for an end-user / enterprise partner. Examples include Socket*, Li.Fi*.
2. The main purpose of a bridge is to service the delta between the (ledger / chain / location) of data / assets and the intended execution destination of data / assets. The main use-cases continue to be in asset transfers (tokens in one chain versus another) + swaps (trade token on Chain A for token on Chain B).
Asset Transfers: There is an asset (ETH) on “Chain A” that is not natively issued on “Chain B”. Bridges can service sending that asset from “Chain A” to “Chain B.” For example, bridging USDC from ETH L1 to Zora L2 thru the Zora Native Bridge*.
Swaps: There is a trade for ($ETH) on “Chain A” for ($ATOM) on “Chain B”. Bridges will send the token and then execute the swap. Examples include [1] Squid Router “swap” and built on top of Axelar “bridging”; [2] Matcha by 0x* takes care of “swap”, and integrates Socket to take care of “bridging.”
Other: 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 lives on ETH mainnet. Uniswap Foundation* would rather have a single contract and execute a message as “one-to-many” to the other chains (vs. creating a governance contract on every chain). [source]
3. Bridges are usually measured by onchain AUC (or TVL) as a sign of liquidity / usage.
Native Bridges traction is directly tied to success of the underlying usage of the L2 itself. The bridge contract will hold funds and can serve as a way to measure the bridged TVL to the L2. According to L2 Beat, TVL of Rollups are anywhere from ~$50M all the way to ~$8B.
Notable 3rd-Party Bridges are LayerZero, Wormhole, and Axelar based on traction of TVL, volume, and chain coverage.
Bridge aggregators generally route transactions so a volume metric is more appropriate. Distribution among consumers and enterprises (winning logos) is the key metric. Leading providers include Socket and Li.Fi.
4. Bridges compete on various aspects of differentiation and there will likely be multiple winners depending on the set of use-cases and distribution.
Security: The security nuances will depend on the demand side’s preference. Most consumers who use bridges seem to prefer speed / latency + cost over security above a minimum viable threshold.
Smart Contracts: Most hacks in bridging have happened at the smart contract level. In most bridges, a user locks funds in Chain A’s contract → bridge reads Chain A contract → mints on Chain B contract to the user’s funds. Misconfigurations around withdrawal access in the contracts can lead to hacks.
Multisig: Control over the contracts are delegated to a set of trusted participants. These are usually operated by the project team and other trusted sets of stakeholders.
Relayer + Oracle: The Dapps / developers can whitelabel their own relayer + oracles for their set-up. They can also choose from a menu of options of other relayer + oracle set-ups that are live.
PoS Chain: Security is achieved by consensus in a Proof-of-Stake manner.
Distribution: Bridges will try to utilize existing partner channels as well as taking a back-end infrastructure GTM.
Wallets: Bridges will try to become the powering infrastructure / API behind existing wallets / portfolio aggregators’ bridging features. Examples include Phantom partnering with Li Fi and Coinbase Wallet partnering with Socket. Portfolio front-end / wallets will all have some form of bridging support (ex. Zerion* / Zapper* / Metamask*).
B2C Front-Ends: Bridges will often set up a website portal where any user can connect a 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” function which uses bridging under-the-hood so users do not have to hop back to L1 and then to the L2 to use the application. Think of this as an abstracted version of the “B2C” mentioned above but natively supported by the developer into the application interface. Examples include Aevo*.
Developer Platforms: Many bridging companies will utilize a developer platform’s existing distribution to get enabled. Examples include Conduit RaaS, Microsoft Azure + Axelar, Google Cloud + LayerZero.
Ecosystem: While all the major 3rd-party bridges cover all the same chains, they will try to get first-mover advantage by dedicating resources to claim ground in a specific chain / developer ecosystem. The reasoning is that as the set of product features need to be more advanced in order to differentiate, it is easier to scale within an 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’s ecosystem coverage is strong given their early involvement. DeBridge is also finding growth in traction.
Cosmos: Axelar’s ecosystem coverage is strong given their ability to offer IBC compatible transactions. One datapoint is that new chains utilizing IBC (ex. Celestia*) get Day-1 coverage.
Other ecosystems can be serviced by most providers.
Product / Feature Set: Because Bridges are in the “abstraction” business, they will often need to do bespoke smart contract work that enables specific use-cases. As a result, bridge teams often end up carving a niche to find dedicated verticals / domains. Examples include NFT / Payments (ex. Decent), Gas Abstraction, and Swaps.
What We’re Paying Attention To
CCTP (Circle’s multichain USDC standard) will be an important datapoint on implications on bridges. CCTP is a standard by Circle* to help with multichain issuance of USDC.
Pre-CCTP: When a new chain launched, it would use a bridged version of USDC due to lack of support for native USDC (because Circle would have to approve and add support for each new chain’s native version of USDC on their roadmap). Because the chains want to have Day-1 DeFi support, USDC would be bridged from ETH L1 and a bridged version of USDC became the standard on the new chain.
Example: An example might be axlUSDC by Axelar or the USDC.e on Arbitrum – USDC on ETH L1 that is bridged through Axelar and the Arbitrum Bridge, respectively.
Implications: This leads to liquidity fragmentation because Chain A bridged USDC vs Chain B bridged USDC builds a dependency on the individual bridge operators. Individual ecosystem DeFi protocols will integrate it as an asset and it becomes harder to unwind.
Post-CCTP: When a new chain launches, it will deploy a USDC token contract that conforms to the CCTP Circle standard. When Circle is ready to go live on the chain, it can take over the implementation that CCTP supported. Basically new USDC contracts have backwards compatibility to conform to a standard down-the-line.
Example: NewChain is a new L2 that goes live and it doesn’t have native USDC yet. NewChain deploys USDC contract which conforms to the standard. NewChain supports bridged USDC in short-term – but importantly it can be taken over by CCTP and bridged USDC can become native USDC.
Implication: If you are a developer, you would usually have a dependency on the bridged USDC and be locked-in to any liquidity program tied to the asset and the bridge . With CCTP, you have a transition to enable USDC natively, and you can hit the CCTP API to enable the x-chain transfer for USDC.
Adoption of CCTP has consequences around the long-term defensibility of bridges.
Bridged USDC (that is non CCTP) is locked in DeFi pools and will remain so until it is unwinded or becomes a minority of the asset mindshare on the chain.
While CCTP will work with bridges (given their distribution) to help support CCTP, CCTP adoption should naturally result in a higher share of native USDC issuance and a lower share of bridged USDC. Bridged USDC as an asset locked-in various DeFi pools should naturally unwind in the long-term.
Example: Bridged-to-Native USDC ratios are: Arbitrum: [57% – 43%]; Base: [33%–67%]; Optimism: [80%–20%]; Polygon: [77%– 23%].
The story of CCTP will be an important lesson for bridges in terms of approaching asset issuers and locking them into a multichain-first approach at the technology level. Bridges will have to compete in other areas of differentiation such as latency, security, and distribution.
Bridges will continue to find usage as long as the # of chains and the demand for UX abstraction increases.
This year, movements in the blockspace settlement trend (modularity, rollups, data availability, and so forth) will have implications for how users execute transactions + move assets – and bridges will be the popular choice in enabling this UX.
Over time, native protocol and technology improvements should help users obviate withdrawal periods (7 days in current Optimistic Rollup designs) and get “fast-track” sends / receives.
Verified wallets and users that hold an onchain attestations (like Coinbase Verifications) in the future might be able to interact onchain with centrally-managed liquidity bridges.
Application-hosted wallets (and self-hosted wallets) will continue to bake in “Bridge Plus” efforts – where instead of “Swap” and “Bridge” as two different transactions, they will be combined as one transaction for better UX outcome.
Bridges and oracles will eventually compete for rights to data issuance.
Bridges are trying to move to win 1st-party issuers to utilize / use their infrastructure. CCTP shows that the native issuer wants to build compatibility that lessens dependency on any single bridge. Some projects are experimenting with issuance of token-standards to be multi-chain as well. While CCTP is USDC-focused, how a token gets issued natively can differ alot. Example: $OP was launched natively on Optimism chain; most ERCs were issued natively on ETH L1. Connext has a token standard called xERC (think CCTP for any ERC20)
Oracles can be thought of as “bridges” but for offchain data issuers. Chainlink takes offchain data (prices for crypto on CeFi) and brings it onchain – though they do not natively own the data itself, it has monetized by providing this as a third-party. Conceptually this is similar to how bridges are positioned today. Both oracles + bridges will continue to service the delta that exists between those that demand data / assets and those that can bridge it over. Eventually they will need to become tooling for 1st-party data issuers in order to maintain a long-term moat / defensibility. Chainlink has their own bridging product called CCIP which is further evidence of overlap.
In conclusion, Bridging and Interoperability will continue to be a top-of-mind trend because in an environment where the number of chains are growing, in order for protocols and users to meet the demand for abstracted UX, bridges will emerge as compelling service providers. Within the Bridging landscape, Coinbase Ventures is investing in new use-cases that emerge from bridging. If you’re building in these areas, we would love to hear from you – Ryan Yi’s DMs are open!
Subscribe to Coinbase Ventures to receive new posts directly to your inbox.
