Bridges: Designs, Trade-offs, and Opportunities
Over the last year, Ethereum’s dominance as the primary smart contract blockchain was challenged by alternative Layer 1s. The multichain world was no longer up for debate; it became a reality. As these new chains gained adoption, their heterogeneous consensus mechanisms, smart contract languages, and community values fragmented Web3 into various ecosystems.
L1 Market Share (% of Aggregate TVL)
These compartmentalized ecosystems individually created value for their respective communities, but much of the synergistic value across chains was lost due to the lack of interoperability. Fragmentation also led to increased tribalism, more attack vectors, and a worse user experience.
For the industry to grow and onboard billions of new users, the friction between these chains must be minimized. This is the primary objective of a crypto bridge.
This report will cover the definition of a bridge, the classifications of different bridge designs, the tradeoffs between different designs, the risks associated with bridges, and our view on the bridge ecosystem’s future.
Defining & Categorizing Bridges
At the most abstract level, a bridge transfers information between two or more blockchains. This functionality is most commonly used to swap an asset on one blockchain (the “source” chain) for an asset on another chain (the “target” chain). However, bridges can also be used to communicate data or messages from the source chain to the target chain. As of this writing, over 100 blockchain bridges are currently used to transfer information across both Layer 1 and Layer 2 ecosystems. This increasingly complex landscape makes the sector difficult to understand for new entrants, so developing frameworks to simplify the various designs can be helpful. Recently, Arjun Chand created a useful framework to organize the many types of bridges into distinct categories. We take a similar approach to classify the various forms of bridges.
Bridges can be categorized by a number of characteristics. These include how they transfer information across chains, their trust assumptions, and the types of chains they connect.
We argue that the most important factor is how they transfer data from one chain to another.
Cross-Chain Mechanisms
Pool-Based Bridges
To understand how Pool-Based bridges work, let’s consider a user who wants to move USDT from Ethereum to Polygon. The user first deposits the Ethereum version of USDT into a designated contract address (the pool) on Ethereum and specifies the recipient address on the Polygon network to which this USDT should be credited. The bridge uses this information to transfer to the specified Polygon address a Polygon version of USDT.
Pool-Based Bridge Mechanism
A major limitation of this design is that the bridge must have sufficient assets in the target chain’s pool for the user to actually move funds. In the example above, if the Polygon USDT pool is empty, the USDT deposited in the Ethereum pool will be “stuck” until another user requests the reverse transfer from Polygon to Ethereum with enough USDT to replenish the Polygon USDT pool. Additionally, these types of bridges only allow a single type of asset transfer across chains (e.g. USDT from Ethereum to Polygon). If you want to exchange USDT on Ethereum for MATIC on Polygon, you can only do so after receiving USDT on Polygon.
The primary advantage of this design is that users do not need to rely on the security of the pool after they have received their tokens on the new chain. The assets they receive are native versions of the asset on the new chain, and therefore do not rely on redemption to the underlying asset in order to maintain their value. This is in contrast to another commonly used bridge design: lock & mint / burn & redeem.
Lock & Mint / Burn & Redeem
Another common type of bridge uses a mechanism known as “locking” or “burning”, followed by either minting or redeeming, respectively. We will once again use the Ethereum USDT to Polygon USDT example from the previous section to describe how the mechanism works. As before, the user begins by depositing the Ethereum version of USDT into a designated contract address owned by the bridge and specifying the recipient address on Polygon. This step is referred to as “locking.” However, unlike before, this type of bridge “mints” or issues its own version of the deposited asset on Polygon and credits it to the recipient account. These minted tokens are often called “wrapped” tokens, and their value is dependent on the ability to eventually redeem them for the underlying asset on the source chain. When the user wants to move back to Ethereum, the wrapped token is simply sent to the bridge contract address on Polygon and “burned”. This allows the underlying asset on Ethereum to be redeemed and sent to the specified recipient address.
Locking USDT To Mint Wrapped USDT
Burning Wrapped USDT To Unlock USDT
Because wrapped tokens rely on their redeemability to maintain their value, holders of wrapped assets are exposed to smart contract risk. If the pool on the source chain is exploited and drained of the underlying assets, the wrapped tokens become worthless. This is precisely what happened during the recent exploit on the Wormhole bridge, resulting in a loss of over $320 million.
That said, the advantage of the lock/burn & mint mechanism is that these bridges can always allow for the transfer of assets from the source chain to the target chain and vice versa. This is because they do not require an available pool of tokens to sit in the bridge’s contract on the target chain. This gives these types of bridges an advantage in terms of scalability.
Native Swap Bridge (with Decentralized Intermediary Chain)
This type of bridge has grown in popularity over the past year or so, in part driven by the growth of THORChain. A native swap bridge allows a user to exchange a native token on the source chain for a different native token on the target chain. For example, a user can swap native BTC for native ETH on their respective chains, without the need for wrapped assets. This is enabled through the use of a cross-chain automated market maker (AMM) and the use of an intermediary chain which monitors and records the states of the source and target chains. Although the ability to swap different native assets across chains is highly useful, this type of bridge uses what is arguably the most complicated transfer mechanism.
To explain how it works in simple terms, let’s walk through an example of a native swap of BTC to ETH, using a basic version of THORChain’s architecture as a reference.
Swapping Native BTC to Native ETH via a Decentralized Intermediary Chain and Built-In AMM
In this example, a user holding BTC would begin by sending this BTC (along with the recipient Ethereum address) to a Bitcoin address, known as a vault. This vault is controlled and monitored by a number of nodes which observe the incoming transaction and record the updated state of the Bitcoin vault on the intermediary chain (e.g. THORChain). Once the nodes have confirmed that BTC was received by the vault, the nodes calculate the appropriate amount of ETH to credit to the user on the Ethereum blockchain. Like any other AMM swap, the price at which the cross-chain swap is executed depends on the size of the swap relative to the respective amounts of BTC and ETH available in the vaults on both chains. A larger swap which “uses up” a larger amount of available liquidity will get executed at a less favorable price than a small swap which uses very little of the available liquidity. Once the swap amount has been calculated, the intermediary chain sends a message to the Ethereum network to send the appropriate amount of ETH from the vault address to the user’s recipient address.
In contrast to a pool-based bridge, a native swap bridge with an intermediary chain offers a higher level of decentralization and censorship resistance. For bridge users, it also avoids the smart contract risk created by wrapped assets, although liquidity providers can still have their assets stolen from the AMM’s liquidity pools via hacks or exploits.
Despite these advantages, the architecture of these bridges is far more complicated than other bridge designs. Creating a credibly decentralized native swap bridge is highly capital-intensive and time-consuming. As an example, in order to enable native swaps from BTC to ETH, every single THORChain node must also run a full Bitcoin node as well as a full Ethereum node. Furthermore, each THORChain node must be incentivized to behave honestly and reliably. All this must be done just to enable a single swap.
Native Swap Bridge (via Stablecoin Swaps)
This type of bridge aims to offer the convenience of native swaps combined with the architectural simplicity of pool-based bridges. Essentially, these bridges work much like a pool-based bridge, but with one additional step added to them to allow users to receive a different asset on the target chain than the one they deposited on the source chain. One example of this type of bridge is LayerZero Labs’ Stargate bridge. We will once again use an example to explain how they work. In this case, let’s consider a native swap of SOL to ETH.
Swapping Native SOL for Native ETH through the Use of Two AMMs and a Cross-Chain Stableswap Bridge
Once again, the user starts by depositing their asset, SOL, into a designated contract address on Solana which is owned by the bridge. However, unlike in previous examples, this deposit actually triggers an AMM swap of SOL to a stablecoin on Solana. For example, it may swap SOL to USDC. From here, the bridge functions much like a pool-based bridge; the stablecoin balance in the Solana contract address is credited by the bridge provider to the user on the Ethereum contract address. Finally, once the USDC has been credited to the user on Ethereum, the bridge executes another AMM swap from USDC to ETH. This ETH is then credited to the user’s specified recipient address. Essentially, these bridges function as pool-based bridges which only transfer stablecoins across chains, in order to provide better price execution during the cross-chain transfer process. As usual, the AMM swap execution prices on both chains are a function of the swap size relative to the available liquidity in both pools.
This architecture avoids the smart contract risk of wrapped assets and offers a simpler cross-chain communication mechanism than the intermediary chain architecture. However, there is a risk of receiving an unfavorable swap price, depending on the available liquidity of each AMM.
Home/Replica Contract Messaging (via Optimistic Fraud Proofs)
This particular type of bridge utilizes two contract addresses located on separate chains, known as the Home contract and the Replica contract, along with four different incentivized off-chain actors, to send messages across blockchains. Perhaps the most notable protocol in this category is Nomad, allowing multi-chain applications to more easily communicate across blockchain ecosystems. Let’s walk through another simplified example of sending a message from Ethereum to Polygon to explain how it works:
Sending a Message Across Chains Through the Use of Home and Replica Contracts Which Are Updated, Monitored, and Propagated by Incentivized Off-Chain Actors
A user on Ethereum would begin by submitting a message to the Home contract address on Ethereum. The Home contract collects this message and puts it in a queue along with other messages it receives. At this point, an off-chain actor known as an “updater” signs the group of messages to update the state of the Home contract. In order to sign these messages, the updater must post collateral to the Home contract which will be slashed if any malicious behavior is later proven to have occurred. A second off-chain actor, the “watcher”, monitors the Home contract as well as the Replica contract on Polygon to ensure that all messages are recorded and sent correctly. Because the bridge relies on optimistic fraud proofs, the watcher is responsible for submitting proof of malicious activity to prevent their processing and to penalize the malicious updater. Otherwise, messages will be assumed by the bridge to have been correctly recorded and sent (hence the name, “optimistic”). Assuming the watcher does not detect an issue with the updater’s actions, a third off-chain actor, the “relayer”, will transmit the messages to the Replica contract on Polygon. Finally, a fourth off-chain actor, the “processor”, propagates the message from the Replica contract to the end recipient(s) of the message.
This architecture is more appropriate for messaging/data transfer between blockchains, but theoretically could also be used to transfer assets, as asset transfers are ultimately just data describing changes to account balances.
One major drawback of this bridge design is that there is a dispute time delay (DTD) that can last ~ 30 minutes where watchers scan for suspicious behavior and contest malicious transactions. Two protocols, Connext and Hop, can shorten this wait time by allowing other market participants to send tokens directly to the end recipient before the fraud proof window has expired. In effect, these two protocols carry the risk associated with malicious transactions in exchange for a fee from recipients who want faster liquidity.
Trusted vs. Trustless
In this classification, bridges fall under two categories. They are either a) trusted or b) trustless. In other words, a user either trusts a third party to maintain the security and operation of the bridge or they rely on software that is designed and run in a distributed manner such that no single entity can alter its state or its operation. Some examples of trusted bridges include xPollinate, Matic Bridge, and Binance Bridge. Some examples of trustless bridges include THORchain, Ren, and Cosmos IBC.
Importantly, the distinction between trusted and trustless is not black and white — rather, it is a spectrum. A distributed software protocol with a smaller or more geographically concentrated set of operators will be more susceptible to single points of failure than a system with a larger, more heterogeneous set of operators. Similarly, a bridge which requires users to lock up assets in a contract address in exchange for wrapped assets also requires them to trust that the code has been written in a way that prevents exploits or theft. Non-custodial bridges do not require this trust, even if they are more commonly run by a centralized entity.
What They Connect
Layer 1 to Layer 1
Layer 1 to Layer 1 bridges allow users to transfer funds from one L1 ecosystem to another. For example, Wormhole’s Portal bridge enables asset transfers from Solana onto Ethereum. By increasing the interoperability amongst these Layer 1 ecosystems, web3 users have the freedom to spend their time and resources on their preferred chain while maintaining the flexibility to switch chains whenever they choose.
Layer 1 to Layer 2
Layer 1 to Layer 2 bridges allow a L1 chain, such as Ethereum, to communicate with Layer 2 chains built on top of the Layer 1 chain. For example, a user may want to bridge ETH from the Ethereum mainnet onto Arbitrum, Optimism, or ZkSync. They could accomplish this by transferring their tokens using each L2’s native bridge, or they could use a third party bridge such as Across. As L2 ecosystems continue to grow, these bridges will play a big role in transitioning Ethereum’s mainnet activity onto L2s.
Layer 2 to Layer 2
As the first half of 2022 comes to a close, Layer 2 roadmaps are becoming increasingly clear. Polygon’s various Layer 2 scaling solutions (Miden, Hermez, Nightfall), Starkware’s ZK-rollup Starknet, and Matter Lab’s ZkSync 2.0 will provide the core building blocks necessary for developers to build applications that are not bugged down by exorbitant gas fees. However, these various L2s are not natively compatible so there is a risk that they could become fragmented versions of what we have seen with L1s. The goal of L2 to L2 bridges is to ensure that L2 ecosystems reap the benefits of high throughput, low gas fees, and strong security while reducing potential fragmentation across L2s. Some projects actively working to accomplish this goal include Hop Protocol and Orbiter Finance.
Bridge Trade-offs
Despite the dozens of bridge designs, no bridge has been able to obtain all three properties of the interoperability trilemma. The interoperability trilemma, a term coined by Arjun Bhuptani, states that bridges can only possess two of the following three properties: generalizability, extensibility, and trustlessness.
- Generalizability: ability to pass arbitrary data between two chains
- Extensibility: ability to rapidly deploy on heterogeneous chains
- Trustlessness: minimization of trust assumptions
The Interoperability Trilemma
Similar to the scalability trilemma, when a bridge chooses two of these properties, the last one suffers. As an example, Connext is a trustless bridge that enables token transfers between two EVM-compatible chains. At the moment, it cannot pass arbitrary data, which implies that it has prioritized the extensibility and trustlessness properties over generalizability. Other bridges such as ZetaChain prioritize extensibility and generalizability at the expense of trustlessness by requiring an additional layer of trust through the bridge’s validator set.
Because the primary use case for bridges has been token transfers between two blockchains, most projects have chosen generalizability and extensibility to quickly deploy on heterogenous chains and maintain the flexibility to pass arbitrary data. This has allowed these types of bridges to deploy faster than many of their competitors and satiate the market’s need for token transfers. While this comes at an unbeknownst cost to many of their users (to be covered in the risks section), these types of bridges can expand their use cases from executing simple token transfers to becoming more comprehensive developer platforms.
An analogy that describes a bridge’s transition from a token transfer mechanism to an application platform can be illustrated by comparing a bridge to a toll road that connects two highly congested cities. Every time a user wants to travel from city A to city B, the toll road earns fees. Bridges have been slowly moving away from this toll road model towards a town model where developers build applications on top of the bridge to create a town in between City A and City B.
Sprawling Towns (Ecosystems) Will Eventually Develop on the Toll Booth (Bridges) that Connect Different Cities (Blockchains)
Because some bridges have tens of thousands of unique users and have transferred billions of dollars in volume, they can use their existing user activity to incentivize developers to build applications on top of their bridges. Continuing with the toll road analogy, developers can be compared to ambitious entrepreneurs who decided to move into the small town after witnessing an influx of wealthy citizens (users). After seeing more activity occur in this town, other entrepreneurs move into the town and start creating bigger businesses (applications). Before long, this small town grows larger, and the toll road that was used as a transportation medium between the two large cities is now a gateway to this booming town.
Bridges as Application Platforms or “Layer Zeros”
There are some notable projects that are trying to become the booming town illustrated in the previous analogy. These projects focus on creating novel ways to link data across chains, while providing the foundation for a dapp ecosystem. They include:
RenVM
An example of the aforementioned toll-road & town analogy is RenVM & the Catalog protocol. RenVM supports cross-chain transactions using the lock & mint / burn & redeem mechanism described previously. Right now, this allows users to move BTC to and from both Ethereum and Polygon via wrapped BTC tokens called “renBTC”. Bridging can be thought of as one application that is built on top of RenVM. In addition to this, Catalog is a protocol taking the first step in generalizing RenVM modules to build an automated market making (AMM) solution within RenVM itself. Catalog is built using the first ever “boundless liquidity” mechanism. This AMM design not only uses Catalog’s own liquidity pools, but also leverages the liquidity pools of third-party DEXes, regardless of which chain they exist on. In this example, Catalog is working with RenVM and its existing ecosystem of users to enable more complex transaction types in a familiar user experience.
LayerZero
LayerZero is a communication primitive that allows for data and information to be sent across EVM chains that have a LayerZero endpoint. A LayerZero endpoint is essentially an on-chain client. A chain with a ZRO endpoint can conduct a transaction with any other chain with a ZRO endpoint. A third-party oracle service such as Chainlink is needed to sit between the endpoints and acts as the transactional and messaging security mechanism.
LayerZero ensures the validity of cross-chain communication by requiring that two independent entities, the Oracle and Relayer, corroborate the transaction
Applications that deployed on the various Layer 1 blockchains will find this approach very simple. For example, if a Dapp was built on Polygon, it is a fairly straightforward task to use the endpoint and quickly onboard your dapp onto LayerZero. Decentralized applications such as Stargate use the communication standard set forth by LayerZero to create decentralized exchanges/bridges.
ZetaChain
ZetaChain is a Layer 1 blockchain that does not have a need for wrapped assets to transfer value cross-chain, and does not need bridges for every pair of blockchains. This is enabled by Zetachain’s use of cross chain messaging, which allows for data and values to be sent across chains and layers. Utilizing omnichain smart contracts, developers can program ZetaChain to listen to and act upon events on connected blockchains. ZetaChain relies on consensus of validator nodes to secure itself and a distributed threshold signature scheme to secure the private keys on connected chains to avoid a single point of failure. PoS provides incentives for validators to act correctly.
What separates Zetachain from other competitors like LayerZero is that even blockchains without smart contracts, such as Bitcoin, can be incorporated into the multi-chain network.
These bridge platforms allow for interoperability between chains and allow for new ecosystems to be built upon them. This enables new use cases beyond sending a token from chain A to chain B. That said, each unique mechanism of a bridge/bridge platform has a degree of risk.
Risks Associated with Bridges
Given the technical complexity involved in navigating cross-chain message passing, there are various risks involved when using bridges. Some of the main risks include:
Bridge Risks
To mitigate censorship risks and halting risks, users can simply limit their use of trusted bridges and optimistic bridges. However, security risks can never be completely avoided, so it is important to understand the possible attack vectors to assess which security systems are more robust than others.
The two main attack vectors that are used to undermine a bridge’s security are 1) smart contract exploits and 2) root of trust exploits.
Two Main Attack Vectors for Bridges
A smart contract exploit occurs when a malicious actor successfully attacks a bridge at its application layer. Because most bridges must deploy secure smart contracts on all the chains that they connect, newer blockchains are easier targets for attacks. Languages such as Rust, CosmWasm, and Substrate all have growing developer communities but they do not possess the same number of developer tools and auditing firms as mature languages like Solidity, so the likelihood of a bug slipping through to mainnet is higher. When one factors in the elements of speed and competition when developing a bridge, it is easy to understand why smart contract exploits are the most common attack vector for hackers.
As for root of trust exploits, these hacks require a malicious actor to successfully attack the underlying verification method used by a bridge. In the case of the Ronin hack, the malicious actor attacked the honest majority assumption by accessing 5 out of 9 of Sky Mavis’, the studio behind Axie Infinity, private keys. Once the hacker breached Sky Mavis’ centralized security system, the rest was history.
As one can see, the vulnerabilities are not easily seen from the outside in, but the costs associated with poor security systems can be enormous. Over the last year, the cumulative cost of bridge exploits has exceeded $1.5 billion dollars.
Notable Bridge Exploits Over the Past Year
To make matters worse, unaware web3 users could easily feel safer when using higher TVL/TVB bridges because it appears that these bridges are robust enough to handle large volumes of token transfers; however, there is not a clear correlation between TVL/TVB and security. In fact, one could argue that the security of the bridge is at a greater risk as the TVL/TVB increases given the larger economic incentive for a malicious actor to find a vulnerability.
Therefore, understanding the underlying security system of the bridge one uses should be considered when transferring funds. If a retail trader needs to send 0.5 ETH quickly to ensure a NFT mint, then security does not need to be the top priority. However, if a DAO plans on transferring 10,000 ETH to a contract on a different chain, then the underlying security of the bridge should be carefully examined.
Closing Thoughts
As the crypto industry continues to develop, new bridge designs will be explored, new security models will be experimented with, and novel bridge-based applications will emerge. The success of a few secure, flexible, and efficient bridges will allow greater interconnectivity amongst protocols and communities. While there may be some short-term pain as the insecure bridges get filtered out, the sector’s future looks bright.
Disclaimer
Amber Group has invested in Nomad, Orbiter, Catalog, ZetaChain, and we provide routing/bonding/liquidity services for many of the protocols listed above. The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.
