Across layer 1 chains, developers are building cross-chain bridges to break down siloed ecosystems and connect users across Web 3. Cross-chain bridges need to solve two problems. They need to provide low transaction fees and have low latency periods for those transactions. Bridges are launching all the time, as users don’t want to put their funds at risk and they want access to new markets without any friction. This article will break down key features of cross-chain bridges and what users can look for before transferring their assets.
What are Bridges
A bridge holds the assets on a layer-1 blockchain while the same assets are released on another (and external) service. It defines who has custody of the funds and the conditions that must be satisfied before the assets can be unlocked.
Bridges have two main problems that they need to solve. First, fees – it is expensive to transfer large amounts of funds between chains. Traditionally, to transfer funds across chains, token holders have to use exchanges. Exchanges, both centralized and decentralized, charge a fee for transfers. The larger the assets being transferred, the larger the cost.
Second, transfer times are long. When token holders transfer large amounts of money across chains, users want to leave little to chance. The last thing anyone wants is for their funds to get stuck across chains with high latency during transfers.
All bridges need to register, account for, and broadcast three things to run.
- Deposits: a user deposits funds into the bridge, and the bridge needs to present a representation on the other chain.
- Updating account balances: chains notify the bridge about the new account balances, and bridges use this information to aid the withdrawal process.
- Withdrawal: a user can withdraw their assets from the bridge according to their balance on the other system, and the issued tokens are burnt on the other system
Ontologically most cryptocurrency exchanges are off-chain bridges. But the rest of this article will focus on the rest of this article is about crypto and cross-chain bridges.
Bridge Design Features
Good bridge design takes into account three key aspects from the chains that they are connecting.
- Data availability: all the data from the blockchains need to be publicly available and accessible to the bridge
- Withdrawal integrity: the bridge needs to guarantee that all honest user funds can be withdrawn if the connected network is compromised.
- Protocol liveness: the bridge needs to guarantee that transactions can be executed.
Bridges ensure the liveness and security of user funds by deploying their security model independent of the blockchain networks it is connecting. Any rewards or incentives from the chains are outside of the incentives from the bridge.
This also means that the staking looks different depending on the bridge. Some bridges may have their own nodes that make blocks (such as Axelar). However, some may not have any form to make blocks (like deBridge) but still reward those staking to relay nodes or oracles to support the network’s security.
From a technical standpoint, there are three approaches:
- Light-client-based bridge: These bridges are usually connected to the other chains via their security models and rely heavily on them for withdrawal integrity and protocol liveness.
- Oracle-based bridge: Oracle-based bridges are easy to deploy but more centralized compared to other bridges. These bridges do not have a blockchain, but they have their own security model to support liveness, can support fast transaction times, withdrawal integrity, and data availability.
- Cross-Chain Liquidity bridge: These bridges have their own supported protocols with a separate security model to support liveness, strong incentives, and their own method for keeping data availability, withdrawal integrity, and liveness.
Types of Bridges
In keeping with the theme of threes, we’ve identified three types of bridges that you can spot in the wild:
The first types are native L1 bi-directional bridges, such as the Rainbow Bridge from Near, Wormhole from Solana, or the Gravity Bridge from Cosmos. These bridges connect native assets across two chains. The goal of these bridges is to bring more liquidity onto the network by enabling token holders to transfer their assets across the bridge to be used in other circumstances.
The native L-1 chains rely on bridges to accurately represent assets from other chains, including the record of withdrawals and deposits. NFTs, tokens, or other assets can cross over the bridge. One key aspect is that running infrastructure for the bridge becomes a part of running the infrastructure for the network’s security. As such, they often become a part of the network themselves and are not incentivized.
For example, Cosmos Hub validators will run the Gravity Bridge infrastructure on Cosmos, just as the Ethereum nodes will undertake some responsibilities for broadcasting and receiving transactions. This is a case where the bridge will share the native blockchain’s security model, making it unique.
Another native, bi-directional bridge is Solana’s Wormhole Bridge. Wormhole uses decentralized cross-chain oracles that track and broadcast when users lockup their tokens and burn them on one chain. But similar to the Gravity Bridge – there is no token with Wormhole or any incentivization mechanism to run oracles, thus just becoming a part of the network infrastructure.
The second type of cross-chain bridge includes wrapped bridges. These bridges are not bi-directional; rather, they connect to other chains, wrap the original asset’s value in a native mechanism, and broadcast them onto the other chain. Unlike bi-directional bridges, they can connect with any chain, and these types of bridges use oracles and their own security model, separate from the blockchains themselves. deBridge and BiFrost are both wrapped bridges.
deBridge uses oracles to broadcast their transactions across the chain. Oracles read and broadcast transactions from other chains. When users transfer tokens across the chain, deBridge oracles read the transaction moving the tokens to deBridge, lock them in a smart contract and issue a newly wrapped asset to an account on the other chain.
The last type is cross-chain liquidity chains, where there is no liquidity on either side of the bridge, and it is the bridge’s responsibility to fill that role to provide that. These bridges have the most amount of flexibility in the Web 3 space. They can bridge any protocol, provide incentives, and utility through supporting applications. Bridges like Axelar and Connext have levels of application and use cases across networks. They’re not bi-directional, and they have applications beyond just bridging networks.
Axelar is a bridge that provides two critical protocols to (1) connect the multiple autonomous blockchain ecosystems and (2) provide an application-level stack that sits on the other protocol; this allows dApp developers to connect to any chain and perform cross-chain requests. Since they have their own security model and staking incentives for both validators and staker, they are a reasonably robust bridging protocol.
What Makes a Robust Bridge
Bridges that have independent security outside of the chains that they are connecting are the best for connecting more than two chains. These bridges also should have a logical incentive structure that supports validators or oracles in providing consensus or accurately broadcasting data across the chains.
Good bridge design has to balance incentivizing the infrastructure providers and keeping transaction fees low, relay transactions quickly, and provide data representations accurately.
Role of Bridges in Web 3
In a growing multi-chain world, we need more liquidity for DeFi applications. But beyond that, the future of Web 3 hinges on cross-chain accessibility. If Web 3 dApps want to remain on Ethereum, they’ll need lower fees, and if L1 chains, like NEAR and Solana, want to access users (therefore more adoption), chains will either need to connect on a dApp level or a transactional level.
Cosmos Hub is well-positioned to use the gravity bridge with the Cosmos SDK layers to connect with chains that can run independently from the Cosmos Hub. As opposed to parachains on Polkadot, they have to run Polkadot-specific infrastructure. Cosmos SDK chains are similar but are free to change and model their network design while having independent security.
IBC connects the SDK, and the Gravity Bridge connects them to Ethereum, providing low transaction fees and low latency periods during transactions. Sustaining chains like Sentinel, Althea, and Akash will directly benefit by having more users pay for their services using stablecoins or other assets of choice.
Outside of the Cosmos ecosystem, both Connext and Axelar are well-positioned to have a cross-chain function that is chain agnostic, connecting to layer one protocols to bridge assets and connect token holders directly to dApps across the ecosystem.
As Web 3 continues to expand, bridges will open doors across the ecosystem and unleash a new level of usability for DeFi applications and infrastructure. Bridges ultimately lead the way for new markets and more usability – increasing value across ecosystems.
