Bridges and Swaps: The Future of Interoperability

How to reason about the evolution of cross chain future

Too many bridges to choose from

Ever take the wrong bridge and ended up in the wrong place and had to backtrack to get to your final destination, but ran out of gas so you got stuck? As more protocols for blockchain interoperability reach mainnet, this will be a common problem if one isn’t careful. And the impact of crossing the wrong bridge can be much worse than a quick turnaround. One might have to wait days to return, assuming they have the proper fuel[0] :)

With the explosion of blockchains and interoperability projects (+40), routing between chains will become a common occurrence. Already 10s of billions are locked in bridges across the ecosystem. But not all interoperability solutions are the same. Each one has its own trade-offs, and each one will have to fight for market share.

Bridges != Swaps

Interoperability is a catch all for blockchains interacting with each other. But there are two categories for these protocols — bridges and swaps.

Different forms of interoperability network construction

Archetypal bridge

User locks an asset on Chain A, then mints the same asset on Chain B. Some bridges are pairwise, they only connect two chains at a time. Others are more network-like, where users can transfer an asset from one chain to several potential chains — the benefit being if a user crosses the wrong bridge, they can bridge to the correct chain without having to backtrack as much. The final category is centralized bridges such as wBTC or USDC or Binance-pegged assets on BSC — this is where a centralized entity issues the asset on-chain.

Above: example of user options if they go to the wrong chain initially.

Archetypical Swap

Trades asset A on Chain 1 for asset B on Chain 2. A swap does not transfer assets between blockchains[1]. For example, Thorchain doesn’t enable users to move BTC to ETH, rather it swaps BTC for ETH. The user ends up with ETH on the Ethereum chain, in exchange for BTC on Bitcoin. However, if the desired asset is already on the destination chain[2], users can swap USDC on Matic for USDC on ETH. Depending on the construction of the swap protocol, one’s counterparty might be an AMM or a market maker. Under certain conditions, the protocol might even pay a user to swap an asset to a new chain ;).

Note interoperability solutions should also be compared in terms of trust assumptions, transfer times, liquidity, dependency risks, etc. RIP Anyswap and ChainSwap and PolyNetwork. Here’s a good reading on how to reason about bridge construction risks.

Path Dependence

Figure: xUSDC is not equal to yUSDC, an asset is defined by the bridge that brings it over.

Because each bridge has its own set of contracts, an asset is tied to the bridge that it comes across. USDC brought over by bridge X become xUSDC, and USDC brought over by bridge Y become yUSDC. xUSDC and yUSDC each have a separate ERC20 contract and therefore are not fungible or interchangeable with each other.[3]

This is horrible from a user and developer perspective. What happens if a user goes over the incorrect bridge and ends up with xUSDC when all applications use yUSDC? They’re forced to go back and use the correct bridge. Then on the application side, should developers integrate both or just one? If they integrate both, how should the assets be evaluated? Should they have the same parameters in an application, or should the risks and nuances of each bridge be taken into consideration?

If the market for a particular asset, say USDC, is big enough on a particular chain, then it’s possible that xUSDC and yUSDC can co-exist. Though in general, we suspect monopolization tendencies for bridges to dominate specific assets. This is the case with BTC on Ethereum, historically there were over a dozen competing standards, but today wBTC and HBTC represent 90% of the market share. We’d expect the original issuers of an asset to have a strong influence on which bridges they support.

Fight over Canonical Contracts

The canonical asset contract is the contract that captures developer and user mindshare, it’s the contract that everyone integrates. Users only want to have one version of an asset, not two or more versions of the same thing (no one wants to have to choose between xUSDC or yUSDC).

Bridges will compete with each other to own the canonical contract for particular tokens. For example, Matic’s Plasma bridge captures the $MATIC token market, whereas the PoS bridge is a catch-all for all other assets traveling between the Ethereum and Matic chains. In the future we expect newer bridges to try to capture specific assets from the generalized bridge. Already Aave has a bespoke bridge for transferring aTokens from ETH to Matic to handle unique accounting.

We expect these new bridges to compete on multiple fronts, such as being more secure or having a network-like construction. But the design space is expansive. Bridges could implement novel features such as flashminting, native cross-chain governance, user/developer-friendly features[4], cross-chain function calls[5], etc. That could attract more mindshare from the generic catch-all bridges. Alternatively, some applications may follow an Aave approach and build custom bridges to handle special cases (governance, mechanisms, etc) or to have more control over their assets. But then again, are dApps equipped to build robust bridges? Which is adjacent to their core business.

Economics of Interoperability

Every single interoperability solution has different costs for using them. Users have to pay a fee on the originating chain, but generally receive assets for free on the destination chain. For bridges the costs tend to be fixed, where the size of the transaction does not affect the cost to go across. This is not the case with swapping protocols, or at least the ones that use AMMs. As the depth of the liquidity pool will affect the price that a user gets to move across it. For large transfers it might make sense to take a slower but more cost effective route.

Predictions for Interoperability

1. Bridges fighting for market share — with dozens of bridging protocols coming online, there will be a tremendous fight for market share. Initially, bridges will start by connecting under-connected chains and targeting assets that have yet to be bridged. But that market is small and quickly closing; eventually, bridges will play a narrative game — trying to persuade the market that their solution is the “safest”. Or maybe they will start yield farming programs to attract liquidity :)
2. Speed doesn’t matter for small transactions on bridges because there are “fast bridges” or swaps — Bridges will not compete on speed with each other as there are swapping protocols with significantly lower security that enable users to traverse blockchains faster. A current incarnation is Hop protocol, where users trust an oracle to relay their transaction across a chain. And for small transactions, the risk is relatively low. For large transactions, users may desire to take a slower bridge that has lower fees and increased security. (And if there is insufficient liquidity in the “fast bridges”, users are forced to take slower bridges)
3. Large users, yield seekers and market makers will be the largest bridge consumers — each blockchain is its own siloed self-contained community. This is especially true when there are stronger native onramps to each chain. The average user does not need to use a bridge. Only yield seekers trying to find the latest farm far out on the risk curve or professionals trying to arbitrage assets and rates across chains.
4. Interoperability will break crypto’s dependency on atomicity — the magic of transactions on one chain is atomicity. This is why flash loans can exist only in a blockchain environment; if any aspect of the transaction fails, the entire transaction reverts. Look at DEX aggregators. Users either get all the assets they want, or the transaction fails; they don’t have to worry about only getting half. Atomicity does not exist for applications in real life. Smart order routers — the IRL version of DEX aggregators have to build logic to handle exchange connections dropping or transaction failures. Interoperability will force developers to have a different mindset when building cross-chain applications. Now partial failure cases have to be accounted for.
5. Interoperability aggregators — there are dozens of bridges and swapping solutions. Many teams will attempt to build an aggregator to unify them all. This is a nontrivial technical and UX problem for these teams; you no longer have atomicity :).
6. Fiat assets will remain centrally issued and only bridged onto new chains — fiat-backed assets such as USDC will be issued directly by CENTRE to other chains. This will also create problems[3]. For the newest chains that are still untested, bridges will bring over fiat-backed assets as issuers will wait for the chain to prove itself.
7. Bridges are useful if a user already has assets on the destination chain. What is the point of bringing over an asset if the user doesn’t already have the native fee token? Otherwise, the assets become stuck. Users have to acquire the native gas token either through a centralized exchange or a swap protocol. We expect interoperability to potentially abstract gas away or inform users to also swap / bridge over the native assets of the destination chain before bringing other assets over.
8. Some bridges will collaborate and share a canonical contract to make the UX for developers and users seamless, at the cost of increased risk (have to trust both bridges). Celo Optics is pioneering this. (h/t @pranaymohan)

Footnotes

[0] Generally users pay using the native token of the source chain to move assets to the destination chain. If they do not have the native token of the destination chain, they will be unable to pay to bridge back to the original source chain.

[1] Technically a bridge doesn’t transfer assets between blockchains either, the asset is locked on the origin chain for the duration of the cross chain activity — but this purely a technicality.

[2] Via an existing bridge.

[3] This dynamic of bridged assets having a different contract address from natively issued ones will cause large liquidity fragmentations. For example, USDC is natively issued on ETH and Solana. If there is a huge demand spike for USDC on Solana and CENTRE is slow to issue more, users who bridge USDC from ETH to Solana will learn that this bridged USDC is not interchangeable with USDC issued natively on Solana. Which is a horrible UX, the only way to fix this is if Centre acts as a centralized stableswap and lets users move USDC between chains quickly. (h/t Dev Ohja)

[4] Preventing users from sending tokens to the contract. Letting developers use batchCall to save gas, etc.

[5] In the future we expect cross chain function calls to become more important. One can imagine a cross chain ETF product that owns different assets on each chain, automated rebalancing can occur through cross chain contract calls.

Thanks to Dev Ojha, Jon Kol and Will Nuelle for feedback.

Legal disclaimer: Galaxy Digital Ventures may or may not be invested in some of the mentioned protocols above.