Snapshot: The Bridging Ecosystem in Q3 2022
Introduction
Like it or not, the “crypto” ecosystem is multi-chain, as over 30 chains hold more than $100 million in total value locked.
One of the core pieces of infrastructure holding together the current landscape is “bridges,” which let blockchains move data (like tokens) from chainA to chainB.
This research piece was written to give a snapshot of the current state of bridging, focusing on teaching readers about the wide variety of design choices currently available in the space.
Here’s the syllabus:
- Why Bridges?
- The Bridging Trilemma(s)
- Different Types of Bridges and Their Trust Assumptions
- Bonus Content: NFT Bridges
- Open Issues and Challenges
Why Bridges?
(skip this section if you know what a light client is)
Bridges are important because…
Blockchains can’t talk to each other. And bridges fix that by allowing them to talk to each other.
Blockchains are like countries. For instance, countries are operated via governments that impose rules, control currencies, and appoint official languages. In the same way, every blockchain has its own language and set of rules that entities must abide by.
Let’s look at countries and blockchains side by side:
- Bitcoin caps the supply of bitcoin at 21 million
- India imposes a national income tax of 30% on anyone earning over 1,000,000 INR
- Ethereum smart contracts are written in a programming language called Solidity
- Brazil’s national language as Portuguese
All that is to say: blockchains typically have their own language, culture, rules, currency, etc. Furthermore, blockchains are not just countries: they are islands surrounded by an endless gulf of the ocean. From the inhabitants’ perspective, there is no way into the country and nowhere out of the country.
Every blockchain is its own little country, ill-equipped to trade with other blockchains because each blockchain’s rules, languages, and systems are unique to that blockchain. This is why you can’t send ETH to a Bitcoin address or BTC to a Solana address — the blockchains (aka digital countries) just do not understand each other.
(Think about it like this: For Solana Nation to send a message to Bitcoin Nation, how would it do so? Solana Nation doesn’t know what language Bitcoin Nation speaks, has no idea what currency Bitcoin Nation uses, and, most importantly, has no idea where to even send the message.)
In essence, blockchains cannot natively communicate, and since blockchains cannot natively communicate, the data stored on each blockchain (like tokens) cannot move freely across chains.
This is where bridges come in. Just as physical bridges in the real world connect locations, blockchain bridges connect blockchains.
Bridges, the thing this whole article is about, exist to connect blockchains by allowing the transfer of information and tokens between them. That’s the entire point of bridges.
Blockchains couldn’t communicate because they each have their own rules, so bridges were built to help them talk to each other.
Now, with that intro set up, let’s break down bridges.
The Bridging Trilemma(s)
The crypto industry loves trilemmas, and bridges are the latest subject under the microscope. In the brief history of bridges, two trilemmas have been introduced:
- The Interoperability Trilemma by Arjun Bhuptani from Connext talks about three properties of interop protocols (including bridges) — trustlessness, extensibility, generalizability — and how interop protocols can only maintain two.
- The Bridging Trilemma by Ryan Zarick from Stargate talks about the three properties associated with bridges — instant guaranteed finality, unified liquidity, native assets — and how bridge builders are forced to choose two.
These trilemmas offer a sneak peek into the design possibilities with bridges and the properties bridge builders can choose from. Let’s take a look at these two trilemmas in more detail to understand the properties of bridges.
Author’s Note: Before we begin, it’s important to consider that all the trilemmas were framed by bridge builders with their own projects in mind. In addition to the trilemmas, the authors also talk about how their respective projects offer a solution to overcome the trilemmas.
Let’s dive in.
The Interoperability Trilemma — Arjun Bhuptani, Connext
The interoperability trilemma states that interop protocols can only have two of the following three properties:
- Trustlessness — the protocol has equal security to the underlying blockchain. It does not add new trust assumptions.
- Extensibility — the protocol’s ability to connect different blockchains.
- Generalizability — the protocol can pass any piece of cross-chain data, from tokens to messages to contract calls, etc. (this is called “arbitrary data messaging” in the cross-chain world)
Bridging solutions leverage different properties of the trilemma based on their primary use case.
As a result, bridges have unique strengths and trade-offs, leading to varying designs with different value propositions.
In his thesis article, Arjun Bhuptani classifies bridges into three buckets (natively verified, locally verified, externally verified) depending on which two trilemma properties are baked into a bridge’s design. Based on which bucket the bridge falls into, it will have ⅔ of the trilemma properties:
- Natively verified bridges — Trustless and Generlizeable (Cosmos IBC, Near Rainbow Bridge)
- Locally verified bridges — Trustless and Extensible (Connext, Hop)
- Externally verified bridges — Extensible and Generalizable (Examples: Multichain, Hyphen)
For the visual learners, here is a LI.FI bridge map broken down by trustlessness, extensibility, and generalizability:
Mapping bridges according to the interoperability trilemma.
The Bridging Trilemma — Ryan Zarick, Stargate
The bridging trilemma states that when designing bridges, builders must choose only one or two of the following features:
- Instant Guaranteed Finality — users and applications are guaranteed to receive funds on the destination chain immediately after a transaction has been executed on the source chain and the transaction reaches finality on the destination chain.
- Unified Liquidity — a single liquidity pool is used between different chains rather than having separate pools for different tokens.
- Native Assets — users receive native assets on the destination chain after bridging instead of wrapped assets minted by the bridges themselves, which are merely a representation of the original asset that needs to be swapped again to get the required assets.
Here are some common examples of bridge designs falling short of the bridging trilemma:
- Lock and mint bridges — Such bridges offer instant guaranteed finality as they can mint assets on the destination chain whenever required without any chance of a failed transaction. However, users receive a synthetic or wrapped asset on the destination chain, not the native asset. Example — Wormhole, Multichain.
- Liquidity networks with pools of native assets with unified liquidity — In such designs, there’s a single pool on one chain connected with additional pools on all the other chains with shared access to each other’s liquidity. As a result, these bridge designs cannot offer instant guaranteed finality since a transaction can always fail due to a lack of liquidity in the shared pools. Examples — Biconomy’s Hyphen, cBridge’s pool-based bridge.
Due to these trilemmas, building bridges comes with constraints, leading to a wide variety of bridge designs. Let’s take a look at some of these different types of bridges.
Different Types of Bridges and Their Trust Assumptions
Blockchains cannot talk to each other. In fact, they don’t even know that the other one exists. Bridges are introduced between blockchains to act as the ‘man-in-the-middle’ and enable communication between them and remove the trust boundaries between blockchains.
To do so, some bridges use off-chain actors or validators responsible for verifying the system. As a result, new trust assumptions unique to the validator set are introduced to cross-chain crypto transactions — meaning that validators are the root of trust in bridges.
However, not all bridge designs need to introduce their own validator set. Instead, they leverage the validators of the blockchains themselves. As a result, the root of trust remains with the blockchains in question and not the bridges/validators. Thus, we see that with bridges, trust is a spectrum and does not exist in an absolute form.
The different levels of trust and tradeoffs lead to a vibrant bridging landscape that can be broadly organized into three buckets: liquidity networks, native bridges, and arbitrary data messaging protocols. Let’s take a closer look at the them.
Native Bridges
Native bridges are typically built to bootstrap liquidity on a particular blockchain, making it easier to move funds to the ecosystem. Most native bridges are limited to two chains and support basic bridging functions between these blockchains — with a specific emphasis on token movements.
Interestingly, security for native bridges differs wildly. Native bridges can be broken down further into two different types of bridging mechanisms:
- Rollups (Examples: Optimism Bridge, Arbitrum Bridge, Polygon’s Plasma Bridge)
With rollups, the bridge’s security inherits the security of the L1 blockchain it is bridging to. For example, with Optimism Bridge, the validity of messages can be proven on Ethereum because Optimism runs a light client on mainnet that cryptographically ensures the validity of transactions. Rollups add the least amount of “trust” to bridging, as funds will only be released if there is cryptographic proof on the layer-1 the bridge is connected with.
Native bridges of rollups like Arbitrum, Optimism, and other L2s are considered the most secure bridges as they add the least trust assumptions. This is because native rollup bridges can verify the validity of state transitions for the source chain on the destination chain. For example, with rollups, independent validators can dispute and prove the validity of messages on mainnet.
2. Foundation-led Bridges (Examples: Avalanche Bridge, Binance Bridge, Ronin, Horizon Bridge)
Other times, native bridges are designed and validated by an L1’s or L2’s foundation to quickly host a convenient gateway for users to bridge from a liquidity-rich network like Ethereum to a new chain. For example, Avalanche Bridge relies on four wardens run by Avascan, BwareLabs, Halborn, and Ava Labs to validate transactions. While less secure from a design standpoint, since the initial chain developer is hands-on in creating the native bridge, therein lies an extra layer of reputational security. For example, Ava Labs is incentivized to honestly validate Avalanche Bridge because doing so is good for Avalanche.
Native bridges of blockchains that are foundation-led or run using an external set of validators fall on the other side of the trust spectrum compared to rollups because they add a unique validator set to the system, which acts as the source of truth (root of trust). The design of these external validators can vary, but the technique does not matter…as the source of truth has shifted from the blockchains to the newly introduced validator set. Differentiating between validator models like MPC, multi-sigs, thresholds signatures, and SGX is important, but, at the base layer, they all essentially rely on an external set of validators to confirm the state of two disparate chains.
Here’s how foundation-led bridges and rollups can be placed on the trust spectrum:
Overall, native bridges are useful. However, they are quite limited, as extensibility is usually bounded to Ethereum. Furthermore, in the case of rollups, there is a 7-day challenge period for withdrawals that severely limits the speed at which users can move assets off-chain. Additionally, while a foundation’s team is reputationally incentivized to validate a bridge honestly, native bridges with a small number of validators present a massive honeypot for attackers to target, which has led to multiple large hacks (most notably via Ronin and Harmony).
With that in mind, bridge designers have been busy building other third-party bridges to work around the limitations inherent to native bridges. This leads us to the following two buckets: liquidity networks and arbitrary data messengers.
Liquidity Networks
Liquidity networks generally focus on transferring tokens from one chain to another; in other words, they own and distribute liquidity. In essence, a liquidity network pairs a token pool on one chain with a token pool on another chain.
Liquidity networks typically function using a lock/unlock token transfer process and guarantee the safety of user funds via a dispute/slashing mechanism. With liquidity networks, when a user “bridges” tokens, they park their tokens in chainA’s token pool, and a corresponding amount of tokens are released from chainB’s token pool to the user’s address.
These systems do not actually send an asset across chains. Instead, they use liquidity providers (LPs) on different blockchains, like an AMM. For example, a user on chainA can receive the desired asset on Chain B via the LP and in return, the LP gets the user’s asset on chainA + fees for providing the desired asset on the destination chain.
From a security perspective, liquidity networks are locally verified systems that utilize a validator from the source and destination chain to confirm a specific transaction. Notably, these transactions do not require the entire validator set to agree — only one validator from each side is necessary. These systems are effectively trustless as they leave no way for the validators on each chain to collude and steal funds.
Hop is one the most popular examples of liquidity networks. Let’s briefly look into how it works:
Hop utilizes a group of relayers called “Bonders,” who move liquidity to the destination chain in exchange for a fee. Hop’s architecture relies on “Hop Bridges” to connect each chain to another. From there, Hop issues h-tokens on each of its supported networks to help facilitate liquidity. For example, if a user attempts to bridge 4 ETH from Ethereum to Arbitrum using Hop, 4 h-ETH are immediately minted on Arbitrum. Then, a “Bonder” can directly front liquidity and swap the 4 h-ETH for 4 Arbitrum-based ETH. For doing so, the “Bonder” is paid a fee because, as noted above, transfers from Optimistic rollups like Arbitrum and Ethereum take 7 days to finalize.
Other examples of liquidity networks: Across, THORChain, Connext
Author’s note → This section was specifically written for bridges designed from the bottom-up as liquidity networks. Bridges like Stargate and Portal Bridge are also liquidity networks, as their sole purpose is to move tokens from chainA to chainB. However, these bridges are built on top of arbitrary data messaging protocols, which we will cover below, so we will leave them unaddressed here.
Arbitrary Data Messaging Protocols
Here is where the idea of a “bridge” expands from “a thing that moves token X from chainA to chainB” to “a thing that lets any piece of data move from chainA to chainB.” Let’s put it like this: native bridges and liquidity networks are very similar to banks, as they are middlemen that move tokens from point A to point B.
Arbitrary data messaging protocols allow for much, much more. These bridges are not focused on the “mint” and “burn” capabilities that native bridges and liquidity networks have pioneered. Instead, an arbitrary data messaging protocol allows for users to send ~data~ from one chain to another — unlocking the potential for different types of cross-chain strategies.
By moving different types of data across chains, the cross-chain world grows from a connected ledger of who holds what to a connected ledger that can programmatically make decisions about who owns what WHEN something happens. In essence, moving data across chains unlocks the potential for cross-chain dApps and contract calls — meaning the dream of DeFi being interoperable is becoming a reality.
Here are a few use-cases that arbitrary data messaging protocols unlock:
- Liquidity networks — if data can be passed between chains, then tokens can be passed across chains. Teams have already built liquidity networks on top of arbitrary data messaging protocols like LayerZero (Stargate) and Wormhole (Portal Bridge).
- Cross-chain voting — take Ghostly Ghosts, an omni-chain NFT collection. If they were to launch a DAO and governance forum where one Ghost = one vote, a cross-chain voting mechanism would allow anyone on any chain to vote on a proposal.
- Cross-chain gaming — imagine a game built and played on Optimism to keep gas costs low while rewarding players with NFTs or tokens on Ethereum.
- Super dashboards — imagine a one-stop shop for cross-chain yield farming, collateralized loans, and one address for any chain swaps.
The current landscape of arbitrary data messaging protocols is crowded, with protocols like Wormhole, IBC, LayerZero, Nomad, and Axelar building different mechanisms for passing data between chains.
At the foundational level, arbitrary data messaging protocols are attempting to solve the original cryptographic problem → which is how Alice can send Bob an asset without a third-party intermediary without it being stolen, duplicated, or lost.
To do so, the bridges implement a host of solutions from light clients to smart contracts to entirely new blockchains. As of now, there is no ~solution~. Instead, there is a robust selection of bridge mechanisms vying for dominance.
Arbitrary data messaging protocols (ADMP) are a broad category of bridges. From our perspective, there are four ADMP validation techniques: external validators, PoS chains, Optimistic solutions, and light clients. Let’s try to understand the different systems and their trust assumptions with examples:
- Wormhole’s External Validators — Wormhole introduces a set of 19 validators responsible for verifying transactions, thereby adding unique trust assumptions, as the validator set does not belong to any of the connected blockchains. Wormhole’s security relies more on the social factor that Wormhole’s validators care about their reputation and thus won’t engage in any malicious activities.
- Axelar’s PoS Chain — Axelar enables bridging by introducing a different PoS chain between the connected blockchains. This system also uses external validators with unique trust assumptions. However, Axelar’s design is considered much more secure because a) it has more validators (>50) than Wormhole and b) it is an insured system which means the validators have to post collateral which gets slashed in case of malicious activities.
- Nomad’s Optimistic Design — Optimistic bridges like Nomad use honest watchers in the system to monitor transactions and report fraud. This design is similar to how fraud proofs work in optimistic rollups (with some nuanced differences). Nomad relies on the fact that at least one honest watcher is actively monitoring the system at any given time and can report fraud. As a result, optimistic designs enjoy high economic security because of the unknown cost of corruption (i.e., attackers can never be sure if the coast is clear from an honest watcher if the system is designed correctly).
- IBC’s Light Clients and Relays — Light client bridges like IBC are natively verified as they verify the consensus of the source chain on the destination chain. This means that cross-chain transactions are verified by all the validators of the underlying blockchain. As a result, the source of truth remains with the blockchain’s validator set. (Of course, as described in the scalability trilemma, with great security comes a lack of extensibility.)
Here’s how these bridge designs can be placed on the trust spectrum, per LI.FI’s research team:
Bonus Content: NFT Bridges
NFT bridges are technically no different than fungible token bridges. The process is ultimately the same, as a user deposits their NFT into a smart contract on chainA, some type of validation system (be it trusted or trustless) confirms the deposit, and a wrapped version of the NFT is minted on chainB. If the user wants their NFT back on the source chain, then the user burns the NFT on the source chain, a validation system confirms the burn, and the original NFT is unlocked on chainA.
With NFT bridges, a core use-case has yet to be fully realized, as the NFT space is still predominantly focused on on-chain art and community building. However, since an NFT can be anything, thinking about NFT bridges through the lens of art is needlessly limiting. The true potential for NFT bridges is essentially limitless:
- Identity — DeFi protocols already utilize NFTs to prove identity on-chain. NFT bridges would allow users to take that identity everywhere. For example, Goldfinch, a KYC’d DeFi protocol, provides customers with a Unique Identity (UID) NFT after completing its KYC program on Ethereum. With NFT bridges, this NFT could be used to receive favorable loans on other chains — without having to go through the KYC process again. (Author’s note: the Goldfinch UID is soulbound, so bridging this particular piece of identity would be more about passing the proof of ownership rather than the actual NFT across chains, though, when you really think about it, this is the same thing.)
- Gaming — NFT bridges allow a single NFT to be used in two blockchain ecosystems. At a foundational level, this is the core use-case for an NFT — leveraging the value of the NFT (be it monetary or cultural) on any blockchain. Synapse Protocol is already realizing this use case by allowing users to bridge DeFi Kingdom NFT “Heroes” between Harmony and DFK Chain (which is an Avalanche subnet) to be used in the separate deployments of the game.
- DeFi — NFTs are just wrappers for unique information. For instance, Uniswap v3 liquidity positions are represented by NFTs. However, as currently constituted, those positions can only be traded on the chain they originated from. With an NFT bridge, those NFTs could be moved across chains and potentially find a more liquid market, be used as evidence of a good credit score to take out a loan, etc.
The NFT bridging space is nascent due to the relative lack of use cases. That being said, many bridges, including the Wormhole NFT Bridge, ChainSwap, and more, are avidly building in the space.
Open Issues and Challenges
Despite bridges being a relatively new concept, the bridging ecosystem has seen tremendous growth. However, bridges are in their nascent stages of development, and building robust and secure bridges is tough. As a result, there are several open issues and challenges plaguing the bridging ecosystem and the overall experience for the users:
- Too many bridges — The bridge ecosystem grew rapidly in 2021 and 2022. The number of bridges grew to over 100. While competition and choices are good for the industry, having so many bridge options leads to confusion among users. Moreover, since the average user currently lacks the knowledge and awareness to choose the best bridge based on their requirements, the scope of making a mistake is high.
(Author’s note: The “too many choices too fast” issue is why bridge aggregators like LI.FI are being built. Bridge aggregators aggregate bridges and abstract the complex decision-making away from the end-users and developers, representing a significant UX upgrade for both retail bridgers and dApp developers.)
- Bridges with trust trade-offs — Given the massive addressable target market for bridges, time to market is crucial when building a bridge. The costs and time differ depending on the type of bridge one creates. Much like with blockchain design, where the easiest way to bring an L1 to market is to launch a centralized product, the easiest way to reduce resources in bridge design is to use a trusted design via multi-sigs or external validators. Such bridges are a security concern and a proven honeypot for hackers…
- Bridge hacks — Bridges are honeypots when it comes to hacks. In the brief history of bridges, we’ve already witnessed hacks worth over a combined $1B (Ronin $625M, PolyNetwork $600M, Wormhole $321M, Nomad $190M, Horizon $100M). While many of these bridges were hacked because of their multi-sig design (trusted), a common trend across other hacks was smart contract vulnerabilities. Experts believe that if more emphasis is not placed on building secure bridges, we will one day see a $1B+ bridge hack.
- Unanswered questions — There are a number of fundamentally unanswered questions, some of which could affect the mere existence of bridges, such as:
a) is the future multi-chain or cross-chain?’
b) ‘will bridge usage follow a power law for assets and routes?’,
c) what happens to a user’s funds if they bridge from chainA to chainB while one is experiencing a hack or a state rollback?
Closing Thoughts
The bridging ecosystem is expanding rapidly, but it’s still early days. In terms of cross-chain use cases, we’ve barely scratched the surface. Until now, the main focus had been on moving tokens across chains. This is genuinely ground-breaking on its own, but it does not unlock innovation at a grander scale. With the advent of more complex actions like contract calls, batched transactions, destination swaps, and the emergence of cross-chain messaging protocols, the bridging ecosystem is evolving — and we’re excited to be a part of it.
Thanks for reading!
Big shoutout to Mark Murdock for co-writing this research article 😄
Why LI.FI?
At LI.FI, we’re building the ultimate cross-chain money lego which offers a significant user and developer experience upgrade. We have built a product that combines the power of 20 DEXs, 10+ bridges (and counting), and 17+ smart contract blockchains into a single UX. Using our product stack, we can abstract away complicated decisions for the users and developers as we can help them choose the best bridge/DEX for the cheapest, quickest, and most secure swap route.
LI.FI: The Ultimate Cross-Chain Money Lego
If you’re a developer building a cross-chain dApp from the ground up or looking to take your existing dApp cross-chain, reach out to us and let’s work together. Our SDK, API, and Widget and ready to power your cross-chain strategy.
If you’re a degen, use /transferto.xyz to bridge and swap across 17+ chains supported by LI.FI.
Get Started with LI.FI Today
Enjoyed reading our research? Please clap for the blog and show us your support! To learn more about us:
- Head to our link portal at links.li.fi
- Read our SDK ‘quick start’ at docs.li.fi
- Join the official Discord server
- Follow our Telegram Newsletter
- Follow us on Twitter & LinkedIn
or try our any-2-any swaps NOW at transferto.xyz