- Cross-chain bridge protocols enable communication between blockchains—promoting greater interoperability, among other benefits.
- Although beneficial, the complex and evolving nature of bridge technology makes cross-chain bridges vulnerable to hacks and exploits.
- More effort is required to improve the security of cross-chain bridges and promote safety of users.
The recent hack on Nomad Bridge caught everyone’s attention for many reasons, particularly the free-for-all nature of the exploit. But it also brought up a far more critical issue: the vulnerability of blockchain bridges.
Months ago, I wrote about the risks of cross-chain bridging protocols, after Poly Network and Wormhole had lost record amounts to cybercriminals. One would expect the security of cross-chain bridges to have improved, but things have only gone from bad to worse.
Since the Wormhole exploit grabbed headlines in February, more cross-chain bridge hacks have followed. This includes Nomad Bridge ($190 million), Harmony Horizon Bridge ($100 million), Qubit Finance ($80 million), and Ronin Network ($650 million). Per estimates, blockchain bridges have already lost nearly $2 billion to attackers this year—that’s 69% of all funds stolen from blockchain protocols in 2022.
Given the experimental nature of blockchain technology, security vulnerabilities are likely inevitable, at least until the industry evolves robust security standards. Still, a particular sector suffering more exploits on average, as is happening cross-chain bridges, calls for concern.
The question now is: “Why are blockchain bridges getting breached and what can we do about it?” But before that, let’s start from first principles: understanding how bridges work and why they matter in the first place.
What are blockchain bridges?
A blockchain bridge connects to two or more blockchains, allowing for the transfer of tokens and data. Just like a bridge in the real world, bridges allow user assets to “travel” from one blockchain network to another.
When bridging between blockchains your assets don’t actually move anywhere. Instead, most bridge protocols work by locking up a user’s asset(s) on the original chain and issuing an equivalent amount on the destination blockchain.
In blockchain lingo, we say the original asset is wrapped—deposited into a smart contract (or a multisig wallet) on the source blockchain, while a representative version is produced for the user on the target chain. Wrapped assets make it possible to use a token (e.g., BTC) on a non-native blockchain (e.g., Ethereum). Such assets are essentially IOUs, as their value is backed by assets locked up on the original chain.
So you know bridges hold your funds in custody and mint new tokens for you to use on other chains. But how do you exit your assets from the bridge contract and redeem your IOUs? Simple—you burn the issued tokens and present the proof-of-burn, after which your locked assets are released on the original chain.
While this sounds relatively straightforward, implementing it involves many complexities. The bridge needs a reliable mechanism for the following:
- Storing user assets
- Detecting user actions (e.g., token deposits and token burns) and relaying information about these events between the two blockchains.
- Verifying the validity of information relayed from external sources
- Triggering minting and burning of tokens
Beyond the usual lock-and-mint mechanism, bridges might adopt a different system such as burn-and-mint (burning the assets on the original chain and minting new tokens elsewhere) or atomic swaps. The bridge might also differ based on its function: some bridges connect multiple blockchains or specific types. A classification of bridge types is out of scope here, but you can read Arjun Chand’s comprehensive review of different bridge mechanisms to get up to speed.
Bridges and the problem of blockchain interoperability
Bridges solve a longstanding problem: the lack of interoperability between blockchains. Bitcoin and Ethereum are essentially siloed off from each other—you cannot spend BTC on Ethereum or send ETH to a Bitcoin address. This causes problems, particularly because it limits the value users can extract from assets and prevents them from accessing the benefits of using other blockchains.
With bridges, you can move the value of your crypto anywhere. Maybe you’re tired of HODLing Bitcoin and have your eyes set on Ethereum yield farms with APRs high enough to give your grandmother a heart attack. What do you do? Deposit BTC to a bridge protocol and get wrapped BTC (wBTC).
Being an ERC-20 token, wBTC is compatible with Ethereum’s protocol, meaning you can now invest in those yield farms. Perhaps your dream of buying a Lamborghini with crypto gains might finally come true! (Disclaimer: this is not investment advice).
Just like you, many users want to move to other blockchains in search of better investments, lower gas fees, and faster transactions, amongst other reasons. This explains the explosion in the popularity of cross-chain bridges. To date, there are nearly 30 bridge protocols listed on DefiLlama (with more in the wild), with the top three bridges, including wBTC and Multichain boasting over $8 billion in total locked value (TVL) combined.
Why are blockchain bridges vulnerable to attacks?
While interoperability between blockchains has benefits, growing use of cross-chain bridges has its drawbacks—primarily the risk of user funds getting stolen. And while it’s easy to conclude that blockchain bridges are inherently unsafe, such simplistic conclusions fail to grasp the multifaceted nature of the problem.
A better approach would be to try and evaluate the different factors that have made cross-chain bridges susceptible to hacks and exploits:
1. High-value applications attract hackers
Most cybersecurity experts will tell you that the higher the value that can be extracted from exploiting a platform’s security, the more incentives for hackers to target it. Going by this logic, the incredible amount of value flowing through blockchain bridges makes them prime targets for malicious actors.
In its basic form, a cross-chain bridge is a set of smart contracts that process the custody and withdrawal of funds as well as minting and releasing of tokens. Where a bridge has many users, these smart contracts will control enormous amounts of value.
The problem is that a smart contract—much like any program—may have hidden vulnerabilities and bugs waiting to be discovered. In fact, the complex nature of many bridge exploits suggests attackers spend time carefully reviewing the code for these contracts to find critical loopholes.
Of course, it doesn’t help that funds stored in most bridge contracts aren’t secured by the underlying blockchain (no one can steal ETH from your address without accessing your private key). This is why many prefer a multichain ecosystem (à la Cosmos IBC) ahead of cross-chain communication.
2. Complexity introduces new attack vectors
Building a cross-chain bridge requires combining multiple elements to function as a single system. This includes custodians (holding user funds, minting new tokens, etc.), oracles (relaying messages about token deposit and burn event), verifiers (validating cross-chain messages), and more. While these components are necessary for functional cross-chain communication, having so many moving parts significantly increases the attack surface for blockchain bridges.
Here are some examples of attacks on cross-chain bridge protocols to highlight the problem:
- Tricking the issuer to mint tokens without collateral: With the Wormhole hack, the vulnerability came from using a deprecated function to verify signatures. By modifying the signature verification routine, the attacker was able to mint 120,000 wrapped Ether (wETH) on the Solana side of the Wormhole bridge without depositing any collateral on the Ethereum chain.
- Hijacking custodian addresses: Mudit Gupta has an excellent post-mortem on the Poly Network hack, but a rough TL;DR will suffice here. The smart contract in question held a list of custodians (“keepers”) responsible for minting and burning tokens. The contract in question could also modify the list of keepers after receiving a signed transaction from a whitelisted account.
Upon initiating a series of complex steps, the attacker was able to impersonate a keeper account and add their address to the whitelist held in the contract. Having compromised the custodians, the attacker proceeded to sign transactions transferring large sums out of the bridge contract.
- Manipulating message-verification systems: Actors behind the attack on Qubit Finance (an Ethereum-BSC bridge) took advantage of errors in the bridge contract’s input validation mechanism to mint assets not backed by any collateral. The attacker(s) managed to fake a deposit to the bridge contract on Ethereum and triggered the Qubit contract on Binance Smart Chain to mint new wrapped Ether tokens (similar to printing money out of thin air)
3. Improper security practices increase risk
Not every cross-chain bridge exploit is due to vulnerabilities; some are the result of failing to implement proper security measures. Take for example the attack on Ronin Network and Harmony’s Horizon Bridge. While both bridges used multisignature wallets for approving transactions involving the bridge contracts, the low approval thresholds—5-out-of-9 for Ronin and 2-out-of-5 for Harmony—made it easier for attackers to compromise the system.
In the case of Ronin, Sky Mavis (the company behind the Axie Infinity play-to-earn game) controlled four of the privileged accounts. After breaching Sky Mavis’ information infrastructure (via a social engineering attack on a top employee), attackers only needed to compromise one more whitelisted address (which they did) to approve malicious transactions.
Given the amount of funds at stake, avoiding a single point of failure should have been top priority for both bridges. In fact, someone did raise the alarm about centralized control of the Harmony bridge months before the attack—but it seems no one got the message.
Another case of lax security practices comes from the Wormhole hack. Here, the vulnerability had been identified before and a fix uploaded to the project’s GitHub repository. Unfortunately, Wormhole’s developers never patched the vulnerability—giving attackers enough time to exploit it later.
How Can We Build Secure Cross-Chain Bridges?
Implementing audits and bug bounties
Although often used as a marketing tool, smart contract audits can help discover errors in a bridge’s code before attackers can exploit them. As such, any bridge relying on unaudited code should be a red flag for users. Ronin Network only completed audits after the attack, for instance, and some sources suggest Poly Network never received an audit prior to launching its bridge.
But audits alone aren’t enough, as many protocols have been compromised even after multiple code reviews. One suggestion is to run a bug bounty program that incentivizes whitehat hackers to review a project’s code for critical errors and disclose them responsibly. Unlike audits performed infrequently, bug bounties can provide continuous guarantees of a bridge’s safety.
Polygon’s Plasma bridge is one example of how bug bounties can help avert costly attacks on bridge protocols. Here, the bridge had a vulnerability that would have let an attacker use the same proof-of-burn to withdraw assets repeatedly (enough to drain $850 million stored in the bridge contract). Fortunately, whitehat hacker Gerard Wagner discovered the bug and reported to the team early—earning a $2 million payout in the process.
Adopting best practices
Improving the safety of cross-chain bridges must start with implementing industry best practices for security. For example, if a multisignature wallet is used to control bridge contracts, the approval threshold should be high; moreover, custodian accounts should never be controlled by a single entity (as what happened in the Ronin case). Another suggestion is to adopt best practices for managing account keys such as using cold wallets and hardware wallets or even multiparty computation wallets.
Implementing best practices for code development also matters. If a new feature is introduced after deploying, then a new audit should be performed to ensure no errors are introduced. The Qubit Finance hack, for instance, occurred after the team introduced changes to the protocol without re-auditing the bridge contracts.
It is also not enough to commission an audit if security-related suggestions aren’t implemented. For example, Quantstamp’s audit of Nomad revealed an issue eerily similar to the vulnerability later exploited by the attacker (QSP-19). But the team obviously never addressed the issue, and the rest, as they say, is history.
Investing in better protocol design
Because bridges are still in their infancy, developers will hardly find any template for building and maintaining a secure bridge. What you have is different projects experimenting with different approaches, tradeoffs, and security mechanisms.
Even so, experience and common sense tell us a cross-chain bridge might improve its security guarantees by following certain design principles. For instance, a bridge operating with a small set of trusted entities is more susceptible to attack than one with a permissionless validator set (where anyone can join the system). In this case, attacking the latter would require compromising a large number of nodes—which is easier said than done.
Admittedly, protocol design is complex and requires extensive research into cryptoeconomics, cryptography, consensus mechanisms, and more. But, given the amount of funds at stake, spending significant effort on designing a secure bridge from scratch is the rational thing to do.
Final words
Cross-chain bridge design is still a nascent industry, with no clear frameworks for ensuring security. One can only hope bridge developers learn from history and avoid repeating the same mistakes when building the latest interoperability protocol.
In the meantime, it is important to equip users with information and resources they need to stay safe when using blockchain bridges. This won’t eliminate attacks, but it would at least discourage users from depositing funds in bridges with known security issues. In light of this, ongoing efforts like L2Bridge Risk Framework—aimed at educating users about the risks and tradeoffs unique to each cross-chain bridge—are critical.
