Blockchain bridges (also known as cross-chain bridges) enable data and value to flow freely between blockchains, and thus play an integral role in the multi-chain universe. However they’ve received fierce criticism over the past few months, following a string of damaging hacks.
On August 2nd, just a few days before this article was written, hackers siphoned more than $190 million from Nomad, a bridge between Ethereum and Moonbeam. This latest hack means that DeFi bridge users have now lost almost $2bn in less than 12 months.
We don’t want to tell you whether or not to use certain bridges. But we do want to give you the facts so you can make your own informed choice.
In this special edition of RhinoLearn, we’re going to take a detailed look at the pros and cons of each type of bridge, along with a detailed explanation of how each actually works.
If you want to read a simpler explanation of how bridges work, check out our intro post here.
How bridges are categorised: transfer type
Bridges can be categorised by both transfer type (simple to complex), and trust assumptions (strong to weak). Let’s deal with transfer types first.
Arjun Chand from Li.Fi, a bridge aggregation protocol, identifies three main types of bridges based on different transfer types. This can be further expanded to five types, although the design space is large and the lines are blurred.
The five main types of bridges, according to transfer type, are:
- Lock & Mint. Examples: Polygon official bridge, StarkNet official bridge, Shuttle.
- Token Issuer Burn & Mint. MakerDao, Arbitrum Teleport.
- Specialised Burn & Mint. Hop, Debridge.
- Atomic Swap. Stargate.
- Third Party Networks/Chains. Thorchain.
Lock & Mint
When the user wishes to move assets across chains, the tokens from their source chain are locked into the bridge smart contract. Then new versions are minted on the destination chain, as either
- A wrapped token. A bespoke simulation of a coin or token, pegged 1:1 against the original and created for a specific non-native blockchain.
Or
- A canonical token. A map of the original token that can be used on all other chains.
In both cases, the token is fully collateralised against its base asset.
When the user wishes to bridge backwards, the new tokens are burned on the destination chain and the original tokens are subsequently unlocked/released on the source chain.
This formula is extremely common: most ‘official’ layer1><layer 1 and layer 1><layer 2 bridges are constructed in this way, including the Polygon, Arbitrum and StarkNet official bridges.
Advantages
There is always 100% collateral to ‘back’ the destination chain tokens and therefore scale is possible.
Disadvantages.
- The smart contracts on the source chain become a honeypot for hackers, and destination chain tokens can become worthless if source chain funds are compromised. Some of the largest hacks have targeted bridge smart contracts that hold a large amount of tokens, such as the $600m Ronin Bridge exploit in March 2022.
- Projects and apps on the destination chain are all dependent on the one bridge, and are at the mercy of the bridge operator for security, up-time, cost and support. This is otherwise known as the ‘lock in problem’.
- This approach can be slow – users may be happy to wait several hours when it comes to transfers from Polygon to Ethereum, or from StarkNet/Ex to Ethereum, but for fraud proof systems (optimistic rollups) such as Arbitrum and Optimism, users are not prepared to wait several days for liquidity.
Token Issuer Burn and Mint
This approach is slightly different, empowering the token issuer themselves to provide liquidity for the bridge crossing.
In other words, instead of relying on third-party bonders to ‘front’ the liquidity when trying to quickly bridge tokens across gaps where the challenge periods may be long (Optimistic rolllups) or require a large block confirmation, a token issuer could step in and replace any third-party bonders.
Here’s how it works in practice:
An example of this approach is the MakerDao Arbitrum Teleporter, which allows Wormhole DAI to be quickly made available for users on L1 when bridging back from Arbitrum. In this case, the MakerDAO protocol keeps track of the eventual settlement of funds in the background via an oracle network.
Advantages
This approach removes friction and costs for the end user, whilst maintaining security for the issuer (e.g. MakerDao protocol) via fraud proof redundancy if the oracle network goes offline.
Disadvantages
The issuer of the token takes on balance sheet risk on behalf of its token holders in the event of an exploit, as bad debt is generated for the Dao (in this instance, MakerDao).
Specialised Burn and Mint
Several bridge protocols combine a ‘burn and mint’ model with the added step of a automated market maker liquidity pool, which can contain two or more similar assets, and which makes use of a specialised bridge asset as an intermediary step. If you want an example, check out this Curve Factory stablecoin pool, which is comprised of USD stablecoin constituents..
Importantly, this model facilitates the quick bridging of tokens across Layer 2s and chains as well as back to the source chain, as is the case with a lock and mint bridge. deBridge finance and HOP fall into this category.
deBridge mints specialised bridge tokens (such as deETH) on Arbitrum and other chains when users lock ETH on layer 1 Ethereum.
By itself, this deETH is not particularly useful on Arbitrum, as a much more widely used ETH token already exists as a canonical token on that particular project, but liquidity providers can then deposit a combination of ETH and deETH into a DeBridge liquidity pool (on Curve Factory) to capture both transaction fees and arbitrage opportunities from bridge users.
The bridge is then set up/initialised by minting the specialist bridge tokens on each chain and then filling the AMM Liquidity Pools.
When a user wants to swap USDC from one Layer 2 protocol to another (for example, between Arbitrum and Optimism), the user’s Arbitrum USDC is first swapped to deUSDC using the AMM pool on Arbitrum, before the deUSDC is burned on Arbitrum and minted on Optimism.
The final step is to use the AMM pool on Optimism to swap deUSDC for the USDC.
The amount of USDC locked in the Layer 1 bridge contract remains unchanged through the entire process, meaning deUSDC on both Arbitrum and Optimism remains 100% collateralised and fully redeemable for the Ethereum-locked USDC.
When slippage in the AMM pool occurs (when deUSDC or USDC is removed or inserted from the pool), external LPs are incentivised to rebalance the pools by either depositing more funds or withdrawing funds back to Ethereum via the official Arbitrum and Optimism bridges (the simple lock and mint bridges), with a wait/challenge time, before redeeming for the underlying locked assets.
The Hop bridge works in much the same way, and both Hop & DeBridge operate slashing to encourage validator nodes to remain honest and to keep the bridges functioning within service level agreements, or SLAs.
Advantages
The use of specialised bridging assets in an AMM pool, as an intermediary step in the bridging process, effectively incentivises liquidity where it is needed in the system while allowing external liquidity providers to capture arbitrage profits resulting from slippage.
Disadvantages
This approach can be more costly to users, as instead of offering a 1:1 exchange rate across the bridge, the AMM pools result in slippage.
There are also risks to LPs whose funds are deposited to the specialised bridge asset liquidity pools or who are holding the specialised bridge assets as a form of IOU awaiting redemption.
Atomic Swap
An atomic swap bridge makes use of pre-existing canonical/wrapped tokens (e.g. USDC) that have already been bridged to the destination chain, and pools these tokens on separate single asset pools on both the source and destination chains.
Examples include Stargate and the Umbria Narni Bridge.
A user bridging USDC from Ethereum to Polygon, using Stargate, deposits into the USDC pool controlled by the StarkGate smart contract on the source chain, and withdraws from the USDC pool on the destination chain. This approach can be thought of as ‘taking from one hand and giving to the other’.
Taking the concept of a pool token bridge further, some bridges also add a final automated market maker swap feature onto the end, building additional swapping functionality into the protocol as a service.
Advantages
After you have used the bridge, you are no longer dependent on its security to ensure your destination token retains value. You are either dependent on another bridge (in the case of non-native bridged tokens) or hold the native tokens on the destination chain. Transfers can also be very quick and cheap.
Disadvantages
The bridge is capital-intensive to scale as a large amount of tokens are required for the destination chain pools, which can be costly to incentivise with expensive liquidity mining programs. Pools can also easily become depleted when there is a large amount of one-way traffic.
Third Party Networks/Chains
Arguably these types of transfer mechanisms are not bridges at all, but are instead completely separate chains or networks that act as an intermediary chain.
When smart contract and messaging compatibility is not possible (for example on the Bitcoin Network), or when more generalisation is the main goal of the bridging protocol (as is the case with cross-chain messaging), bridging assets across chains in a decentralised manner requires a third party network/chain to act as an accounting and intermediary layer between chains.
Such networks rely on threshold signature systems (a network of nodes) on both the source and destination chains, which also need to be incentivised to stay honest.
Advantages
Third party networks and chains enable more blockchains to be bridged in a decentralised manner.
Disadvantages
These connectors are capital-intensive, as both nodes (to remain honest) and pools (to provide scalable liquidity) need to be incentivised on each chain.
These systems are also more complicated architecturally, which is part of the reason why the most famous example of this system, ThorChain, has been compromised on three separate occasions. However another third-party network, Synapse, was able to prevent an $8 million hack in late 2021 after identifying unusual activity in its AMM metapools.
How bridges are categorised: trust assumptions
As well as the different token transfer methods, we also need to consider different trust assumptions, with each bridge ranging from strong trustworthiness (bad) to weak trustworthiness (good).
The various levels of trustworthiness can be categorised as follows:
- Centralised bridges. Example: The Binance-to-Arbitrum bridge.
- Validator/multi-sig bridges. Wormhole, Axelar, Connext.
- State proof bridges. StarkEx to Ethereum, ZKSync to Ethereum, Nomad, Hop, Axelar, and Mina.
- Protocol-level bridges. Cosmos IBC.
Centralised Bridges
Centralised bridges solve a short-term need for quick transfers. However they are opaque and not scalable or censorship-resistant, so are limited to simple bridging.
Validator / Multi-sig Based Solutions
State Proof Bridges
State proof bridges require still weaker trust assumptions than validator bridges. They prove the state between chains, meaning that validators are not required to act as oracles (these can be either ZK proofs or Optimistic proofs). Furthermore, they don’t require any trust in any third parties, although a relayer may still be required.
There is no requirement for collateral on both sides of the bridge, since these state proof bridges can be used to securely lock assets on the sending chain, and then ‘mint’ assets on the destination chain.
State proof bridges can be slow, particularly optimistic proof ones such as Nomad and Hop. Therefore these projects often partner with solutions that provide temporary liquidity while waiting for the bridge to settle. For example Nomad partners with Connext, and Hop has a system to incentivise short-term ‘bonders’ to provide liquidity while waiting for the optimistic proof.
Here’s what the Hop Bridge looks like.
Protocol-Level Bridges
Protocol-level bridges are as good as it gets when it comes to trust assumptions, requiring weak/little trust, as everything is handled at the protocol level.
Perhaps the most notable example of a protocol-level bridge is the Inter-communication blockchain protocol (IBC) in the Cosmos ecosystem. This is really a state proof bridge, but it is implemented at a protocol level on different blockchains.
By implementing at a protocol level, it is possible to:
- Completely remove any need for collateral on either side of the bridge.
- Ensure that all chains have the same assets to mint and burn.
- Standardise the interface on every chain.
- Reduce the risk of smart-contract based bridges being hacked.
Ok, so now you understand bridges. But can you trust them?
Eventually, all major blockchains, or blockchain families, will implement protocol-level bridging as the main way to ensure maximum security and capital efficiency across chains. Until that point, however, bridges will never be able to offer the strongest possible security guarantees.
This doesn’t mean you can’t trust bridges: for all the media publicity, hacks are still very rare events, and bridges enable you to move between chains in a way that would otherwise be extremely difficult (although rhino.fi is attempting to solve this problem with its multi-chain functionality).
Ultimately, it’s about doing your research. Before using a bridge, you should look at the type of bridge it is (using our guide above) and find out whether it has suffered any hacks in the past.
And, as the technology continues to evolve, the need for this kind of diligence should drop dramatically.
