Crosschain Interoperability
and Security

Abstract

Without interoperability, the liquidity of assets is fragmented. In order to facilitate the exchange of value between different blockchains, interoperability is essential, and hence the need to build bridges.  At the core of every bridge is a messaging infrastructure that sends data across chains. Bridges are applications built on top of this layer and can be categorized based on their application, such as token bridges, NFT bridges, governance bridges, lending bridges, and ENS bridges. They can also be categorized by the way in which crosschain messages are validated: decentralized, centralized, or hybrid. Each of these types has varying trust assumptions and in order to evaluate the security of each type, we need to consider  3 main pillars of bridge security: Economic Security (cost to attack), Implementation Security (secure by design), and Environment Security (safety of the chains connected). These pillars can be compromised by stealing signer keys, colluding with validators, maliciously upgrading contracts, exploiting code vulnerabilities, compromising RPC endpoints, and re-org attacks. To mitigate such threats one should  follow smart contract best practices, test  their code, conduct audits, implement security updates, monitor for real-time detection  of threats , avoid trusted third parties, prevent contamination by horizontal scaling (compartmentalized liquidity pools), validate the invariants on a forked version before execution, make messaging layer upgrades optional (to prevent forced malicious upgrades) and open-source code so white-hats can secure it. Additionally, a good threat response plan should include a faster response time once the attack has begun . And lastly, having a standardized risk assessment framework can be useful from the users’ perspective to select the appropriate bridge for their transaction size and security needs.

Acknowledgment

This report has been co-authored by:

LI.FI: with Arjun Chand and Mark Murdock

LI.FI is a multi-chain liquidity and data middleware that provides access to nearly 20 blockchains, enabling the moving and swapping of assets and sharing of data by aggregating infrastructure solutions including cross-chain bridges, relevant data sources, and decentralized exchanges, which allows for seamless interoperability for platforms and users.

Hacken: with Oleksandr Nazarov

Hacken is a blockchain security auditor born in 2017 with a vision of transforming Web3 into a safer place. With 5+ years of experience, hundreds of blockchain partners, and thousands of secured crypto projects, Hacken protects technological businesses and crypto communities worldwide with the most competitive suite of professional cybersecurity services.

We also would like to thank our co-publishers:

Cross-Chain Coalition : with Alex Martin

The CCC is a community focused on scaling cross chain infrastructure through events & education. It counts most of the bridges in the space as members

Foreword

Coinchange and its Research department are happy to share their fifth Research Report titled “Crosschain interoperability and security - Categorization and solutions”. Our first report was based on Permissioned DeFi where we discussed the emergence of regulated decentralized finance for the institutions. Our second report was about the NFT landscape with insights on adoption and misconceptions about NFTs. Our third report focussed on NFT financialization and the potential yield-generating opportunities in the NFT sector. The fourth Research Report deep dived into the Institutional asset of choice and barriers to entry of those new participants. 

Through these research reports, we aim to shed light on sectors, protocols, and various aspects of the crypto space to allow a broad spectrum of new, and existing participants to easily understand the trends, the opportunities available and shortcomings of the space. We collaborate with prominent companies in the space to help shape those understandings and further the adoption of cryptocurrencies at large. 

As part of our continuous improvement process, feel free to share via email any research subject you would like to have covered by our team or any collaborative work you would like to work on with us at the following email address: ccf.research.support@coinchange.io

Executive Summary

1.0 The Need For Interoperability Of Blockchains

Blockchains are becoming increasingly important as a tool for removing intermediaries and easy access to digital asset ownership. The technology offers unparalleled security, transparency and trust, allowing users to securely store and transfer digital data, such as cryptocurrency, in a distributed and immutable manner. In order to facilitate the exchange of value between different blockchains, interoperability is essential. Without interoperability, the liquidity of assets is fragmented and the interconnectedness of different blockchains is limited. Bridges have been built between these parallel blockchains to ease fragmentation of liquidity and allow users to hop from one blockchain to another seamlessly.

2.0 What Are The Types Of Bridges?

There are different types of bridges that facilitate interoperability between different blockchains. At the core of every bridge is a messaging infrastructure that sends data across chains, facilitating various transfers (e.g. LayerZero, Axelar, Wormhole, CCIP) Bridges are applications built on top of this messaging layer and can be categorized based on their application or utility, such as token bridges, NFT bridges, governance bridges, lending bridges, and ENS bridges. (e.g. Stargate, Aptos, Satellite, Portal) Bridges can also be categorized based on the way in which crosschain messages are validated, which can be done in a decentralized, centralized, or hybrid way. Decentralized validation is the most complex to build and can be done through a natively verified bridge or an optimistically verified bridge. Centralized validation is less complex to build but comes with less security. Hybrid validation is a combination of the two and aims to balance security and complexity. Bridge aggregators work similarly to Decentralized Exchange (DEX) aggregators by bringing together multiple bridges to provide users with the most efficient option for their crosschain asset transfers and exchanges, taking into consideration factors like cost, speed, slippage, and security.

3.0 Why and How Do Bridges Break?

Bridges present a challenge for blockchains since they need to be able to trust and validate external information. Different bridges use different mechanisms to ensure the message is valid and hence it is incredibly difficult to build fully secure bridges. Chainalysis data has revealed that bridge hacks have accounted for a staggering 69% of the total funds stolen in the DeFi space in the past two years. This is due to three core reasons: new technology, a large attack surface area, and the high value of funds at stake. There are three main pillars of bridge security, Economic Security (how costly could the attack be), Implementation Security (how secure is the design), and Environment Security (how safe are the connected chains), each of which can be compromised in many different ways such as stealing signer keys, colluding with validators, maliciously upgrading smart contracts, exploiting smart contracts vulnerabilities, compromising the RPC endpoints, re-org attacks etc. Out of the top five most expensive hacks, three were due to compromised ‘Implementation Security’ and two were due to compromised ‘Economic Security’. It is interesting to note that none have been due to compromised ‘Environment Security’ although this could happen in the future. Thus, bridge hack is a growing problem, as bridges are a common target for attackers and we will discuss how developers can mitigate these attacks, respond to a hack, and assess the safety of a bridge through risk scoring.

4.0 What Can Be Done Moving Forward To Analyze and Mitigate Bridge Risks?

Developers must implement effective threat mitigation measures to ensure the security and reliability of their blockchain bridges. These measures focus on preventing hacks before they occur, rather than dealing with the aftermath of a hack. By taking this proactive approach, developers can protect the assets that their bridges handle and reduce the likelihood of their network being damaged. Following smart contract best practices, testing, audits, security updates, monitoring for real-time detection for threat mitigation, avoiding trusted third parties, preventing contamination by horizontal scaling (compartmentalized liquidity pools for different chain pairs), using pre-crime (i.e. validate the invariants on a forked version before executing on the main), making messaging layer upgrades optional (so that the bridge isn't forced into malicious upgrades) and even open-sourcing the code so that white-hats can secure it in exchange for bug-bounties are some ways to mitigate threats. Threat response is still an important part of any security strategy as even with the best threat mitigation measures in place, it is still possible for a hack to occur. Having a well-defined threat response plan can help minimize the damage and recover lost assets. A good threat response plan should include a faster response time, which can be achieved by using continuous monitoring tools that alert you. The sooner the response, the higher the chances of recovering funds. And lastly we propose a two part standardized risk assessment framework that bridge users can use to guide themselves to choose the right bridge for their transaction requirements and level of security needed. The first part of the framework consists of gathering all the relevant information about the protocol by answering a set of questions, and the second part of the framework consists of scoring questions that require the data gathered in the first part.

1.0 The Need For Interoperability Of Blockchains

1.1 Need For Blockchain Interoperability

Blockchains are becoming increasingly important as a tool for managing and controlling digital assets. The technology offers unparalleled security, transparency and trust, allowing users to securely store and transfer digital data, such as cryptocurrency, in a distributed and immutable manner. Bitcoin was the world’s first and oldest public, permissionless blockchain meant to facilitate peer to peer transfer without the need for an intermediary. But it has its own limitations on the user activity it can handle per block making it too slow for instantaneous exchange of value. Ethereum was launched a few years later as the faster, more efficient blockchain compared to Bitcoin. With the introduction of composability on Ethereum and building of smart contract protocols for various DeFi applications, the number of use cases grew, and Ethereum's initial design was no longer scalable. In order to relieve the Ethereum Mainnet from data and execution load, many Layer-2 blockchains were built on top of Ethereum. Additionally alternative Layer-1 blockchains were built with different consensus mechanisms, to tackle scalability and faster transaction throughput. 

In a world where blockchains are becoming increasingly popular and widespread, the need for interoperability is greater than ever. With so many different blockchains in operation, each with its own design implementation, different consensus mechanisms, different coding languages and hence different token standards, interoperability has become essential in order to facilitate the exchange of value between different blockchains. Without interoperability, the liquidity of assets is fragmented and the interconnectedness of different blockchains is limited. Lack of interoperability makes it difficult to use the different blockchains and to realize the full potential of the technology. Ultimately bridges were built between these parallel blockchains in order to ease fragmentation of liquidity and allow users to hop from one blockchain to another seamlessly. 

One indication of the need for interoperability was recently demonstrated by the Uniswap protocol. Uniswap is the largest DEX in the DeFi ecosystem on Ethereum and they recently expressed their interest to deploy their v3 on BNB chain. What was notable was that the community members openly discussed the ‘Cross-Chain Bridge Assessment Process’ and allowed the various bridge teams to present their architecture and security assumptions in the Uniswap governance forum. By the end of Jan 2023, they ran a Snapshot proposal titled, “[Temperature Check] Which bridge should Uniswap v3 use for cross-chain governance messaging between Ethereum and BNB Chain?”  where Wormhole came out as the top choice. 

In a nutshell, whenever one blockchain (eg. Ethereum) connects to any other blockchain (eg. Solana), there is a bridge (eg. Portal) involved leveraging a messaging infrastructure (e.g Wormhole). In that sense, a bridge is a rules based protocol, fundamental for a scaling solution. 

1.2 What Is A Bridge?

Before we define a bridge, we need to introduce another term called ‘Messaging Protocol’ which is the interoperability layer and we can say that two chains are always connected by a messaging protocol. A bridge is an application built on top of this messaging protocol. For example, a token bridge is an application on top of this messaging protocol that allows you to send tokens across chains, an NFT bridge is an application on top of this messaging protocol that allows you to send NFTs across chains. There could be a governance bridge that allows you to vote from different chains. Thus generally speaking, bridges can be thought of as applications built on top of some messaging protocol and the bridges will inherit the security of the messaging protocol. Optimism has an optimistic messaging bridge and any token bridge that's built on top inherits the same rollup security inherited from Ethereum. What that means is,  all messages passing through the bridge are thought to be non-fraudulent until proven otherwise during the challenge period by a set of decentralized network of watchers.

Circle Inc., the organization behind USDC, can also be seen as a bridge between a bank in the US and a blockchain (such as Ethereum or Solana or Polygon), where you deposit USD on one side and receive USDC on the other and vice-a-versa. It's definitely not like the bridging infrastructure that we usually know of. It's more of an oracle as it's trying to digitize a real world asset (USD) into a digital one (USDC). But in some sense it's accepting deposits on one end and giving you other assets on the other end just like a bridge would. Similarly, Centralized Exchanges (CEX) can also act as bridges although the infrastructure might be opaque to the end user. For example, one can exchange USDT on Ethereum for USDT on Avalanche using Coinbase Exchange.

It is important to note that the most common bridges are not able to physically move tokens between blockchains. Instead, they are made up of two smart contracts that hold tokens and a set of rules that determine who has access to those tokens. These two smart contracts communicate with each other through messages with cryptographic signatures. These messages contain instructions for the smart contracts on the destination chain to create or release new tokens, which then completes the transaction. Therefore, blockchain bridges must be able to verify the validity of these messages. 

Now that we understand what a bridge is and why we need it, in the next section let’s uncover the different ways to categorize them. 

2.0 What Are The Types Of Bridges?

Before we dive into the different types of bridges, an important thing to note is that there are many different ways to describe the same technology and hence it can get a bit confusing while categorizing bridges. Additionally, some bridges use a hybrid model, further blurring the distinctions between the types. For example, Polygon PoS Bridge is a light client based from Polygon-Ethereum because the Smart Contract on Ethereum verifies Polygon-consensus. But from Ethereum-Polygon it is a normal validator-set as they don't validate Ethereum-consensus on Polygon. So with the help of lectures, presentations and personal talks with various organizations such as L2BEAT, Polygon, Connext, Hop, LayerZero Labs, Hacken and LI.FI this is our attempt to provide a structure for bridge categorization:

2.1 Messaging Infrastructure

At the very core of every bridge is a ‘Messaging Infrastructure. This acts as the layer that sends data across chains, facilitating various transfers. Bridges are applications built on top of this messaging layer. So the hierarchy is a messaging layer, then bridge applications on top of it. 

One example of a messaging infrastructure is LayerZero, which is a generalized data messaging protocol that describes itself as an “omni-chain” solution. By using gas-efficient, non-upgradable smart contracts, lightweight messages can be carried across chains. User applications building with LayerZero simply need to implement two functions — send and receive. As its name implies, LayerZero is a ground-level piece of infrastructure that can power liquidity networks, yield aggregators, lending protocols, and many other DApps that build out unique and fascinating multichain crypto applications. For example, Stargate is a liquidity network built on top of LayerZero that facilitates crosschain swapping while Aptos Bridge is built on top of LayerZero and is a token bridge for transferring assets from Ethereum to Aptos.

Another example of a messaging infrastructure is the Axelar Network, and Satellite is a web application built on top of the Axelar Network that provides an easy to use interface which enables users to transfer their crypto assets from one chain to another. 

Yet another such infrastructure is the Cross-Chain Transfer Protocol (CCTP), which is a permissionless on-chain utility that can burn native USDC on a source chain, and mint native USDC of the same amount on a destination chain. Developers can embed CCTP into their apps and provide users with the most capital efficient way to transfer USDC across chains. They can leverage CCTP to build novel crosschain apps that stack together the various functionalities of trading, lending, payments, NFTs, gaming etc. It is built by Circle, which is the issuer of USDC and their goal is to eliminate the use of ‘lock and mint’ type bridge (we will be discussing this model in the next section) which locks USDC on one chain and issues a synthetic version of USDC on the other chain adding a new set of risks. However this particular infrastructure layer allows users to send only USDC token as the verifier of the burn event is the parent company Circle. CCIP, which is the Cross-Chain Interoperability Protocol built by Chainlink, also provides a universal, open infrastructure for developers to build secure services and applications that can send messages, transfer tokens, and initiate actions across multiple networks. 

Based on the application or the utility of the bridge, there can be several types of bridges such as Token bridges, NFT bridges, Governance bridges, Lending bridges, ENS bridges etc. Additionally, bridges can be categorized based on the different ways of validating a crosschain message. The validation could be achieved in 1. A decentralized way, 2. A centralized way or 3. Some hybrid versions of the two. 

‍

2.2 Decentralized Validation

These types of bridges are the most complex to build. Polygon’s plasma bridge, Optimism and Arbitrum rollups use a decentralized validation model. Although the sequencers a.k.a the nodes that collect the transactions, are in some cases centralized, their aim is to be truly decentralized bridges in the future. 

Decentralized verification of cross-chain messages can be of two types: 1. Natively Verified and 2. Optimistically Verified. Let’s dive into each of these types. 

2.2.1 Natively Verified Bridge 

This is a type of bridge where the chain’s underlying validators verify the transactions. For example Light Clients or Rollup AMBs (Arbitrary Messaging Bridge) that the Polygon PoS bridge uses. This can be achieved in two ways: 

• Light client Verifying Validity of the State

These are the most secure way to do crosschain transactions. They verify the validity of a state transition that happened on the source chain, on the destination chain. Rollups on Ethereum, such as ZK rollups or optimistic rollups are an example of this. ZK rollups will create a ZK Proof (ZKP) that attests that all of the transactions were done correctly and Optimistic rollups will submit fraud proofs that can be challenged if one thinks they are malicious. 

Thus bridging assets from Ethereum to Polygon, for example, is dependent upon the security of the Ethereum chain and not on that of Polygon. Several companies are currently building ZK bridges, including StarkWare, ZK Scroll, and ZK Sync. Polygon's ZK EVM, which was announced at ETH CC earlier this summer, is the first open-source ZK EVM implementation and is considered the most advanced of these. However, other companies that have announced the launch of their ZK EVMs have not yet made their code open-source. This serves to illustrate the level of development that has been achieved by Polygon and the network effects that will benefit them as first movers.

Polygon's existing non-ZK bridges are already in active use by many users, making it potentially simpler for them to transition their assets to the ZK bridge than to a newly developed bridge from another community. Nevertheless, competition is essential to ensure both teams strive to create better, more secure, and faster solutions, ultimately benefiting the sector as a whole.

• Light client Verifying Consensus

Light clients validating consensus is another way that is less secure than the previous one. These include bridges that validate the consensus of a source chain on a destination chain. In this case, the light clients only validate that majority of the consensus on the source chain attests to the transaction. They don’t validate the transactions themselves. Let’s say ⅔ of the validators on the source chain say the transaction is non-malicious, then it is accepted as non-malicious. Polygon PoS bridge (checking consensus of the Heimdall chain), Cosmos IBC (verifying signatures of another Cosmos chain) are great examples of this type. Suppose the validators of a source chain in IBC collude to submit a fraudulent transaction then the destination chain on IBC will still accept the transaction as the bridge only verifies that the source chain consensus was achieved. Another example includes NEAR Rainbow bridge (disregarding an Optimistic component related to the complexity of validating NEAR sig scheme there).

2.2.2 Optimistically Verified Bridge

This is a type of bridge where 1-of-N watchers can prove fraud within a delay window. The way fraud is proven is, there is a Merkle tree of updates stored on the origin domain (where the messages are sent from) and one can prove that some root is incorrect on the origin domain. To disconnect other domains from processing that message, we would have to rely on a watcher to call disconnect on this domain. It is important to note that while only the origin chain can prove fraud, the destination chains can be disconnected by a trustworthy watcher.

In general, with optimistic bridging, if a transaction is initiated, the process assumes the correct amount and details have been submitted. There is then a challenge period of typically seven days, during which nodes can contest the accuracy of the details if they have cause to believe they are incorrect. If a challenge is accepted, the bridging transaction will fail, and if no challenge is made, the funds will be bridged after the seven-day window. Security in this model relies heavily on the nodes challenging transactions and requires the use of bots and monitoring scripts to ensure security and prevent collusion amongst node operators. If a challenge is made, and a node attempts to censor it, users can force the node to post on Layer 1 and ensure the transaction is included on Layer 2.

The implementation of a seven-day challenge period prior to exit provides an added layer of security as it allows ample time for the security team to identify and address any potential bugs. Through proper monitoring, alerting, and anomaly detection, the majority of any bugs discovered are likely to be caught in this seven-day period, thereby ensuring that funds are released securely.

Examples include Hop Protocol, Connext Amarok, Across, Nomad Token Bridge. 

Let’s update our flowchart based on the categories we have learned so far:

2.3 Centralized Validation

2.3.1 Externally Verified Bridge

This is a type of bridge where a 3rd party verifies the transactions. These bridges rely on an external set of Validators who can be incentivized in a variety of ways, for the source of truth (i.e. Validators who are not part of either source or destination chains). Validators can be implemented in various ways. They may use multisig, consensus algorithms (typically based on propose-and-vote schemes), threshold signature schemes, SGX (Intel® Software Guard Extensions), or any other technique. Examples include Wormhole, Multichain, Axelar, DeBridge, Synapse, Stargate. External validator set type bridges could be less secure than the two types of natively verified ones. In the natively verified bridges, the trust was on the two blockchains. With an external validator set, the trust lies on the bridge itself acting as an intermediary. The important considerations here then become, how many validators does this bridge have? Who are the validators? What is the stake distribution amongst them? How many signers does the multisig have? Etc.

It might sound odd but centralized exchanges such as Binance and Coinbase can act as bridges. For example, if you swap from USDC on Ethereum, to USDC on Polygon using Coinbase, you're technically bridging USDC, though the method is externally verified we are unsure of the method as it is something centralized and non-transparent. Ronin bridge can also be categorized as somewhat centralized, although it was 5/9 multisig, but four of the multisig parties were stored by one operator essentially making it 2/9 for hackers.

Securing centralized bridges can be relatively straightforward if best practices from traditional cybersecurity are followed. Key management is a critical component of this, which is applicable to both DeFi and traditional systems. Private keys, which are more prevalent in DeFi, must be properly secured through access management, logging, auditing, and other measures.

Most established best practices for traditional cybersecurity are already in place. If qualified talent can be found from reputable organizations such as banks or tech companies that prioritize security, the centralized bridge can be as secure as possible. Although centralized bridges are relatively easy to secure, there is an issue with Web 3.0 - the traditional security aspect has been neglected. Audits and formally verifying smart contracts have become the focus, while private key management and conventional security, in general, has been left on the backburner. This is how Ronin Bridge was hacked - their smart contracts were sound, with good audits and quality code, but the traditional security foundation was lacking. In our conversations with security engineers from Hacken, it was evident that many notable bridges, specifically the ones utilizing external verification, prioritize smart contract security over conventional ones. It is essential that, while new technology is being implemented in the Web 3.0 world, the underlying tech stack remains secure.

The Avalanche bridge is another example of a centralized bridge, which can be broken down into two main parts: the SGX application and a set of third-party indexers and verifiers called “Bridge Nodes.” The Bridge Nodes are responsible for indexing the Avalanche and Ethereum blockchains and submitting eligible transactions to the enclave for processing. The SGX application requires 6 of 8 Bridge Nodes to submit the same transaction before generating the signed transaction to process the Bridge transfer on the other network. It’s important to note that each Bridge Node communicates directly with the secure SGX enclave for submitting eligible transactions and are being operated by four wardens Ava Labs, HALBORN, BWARELABS and AVASCAN. The security parameters of this bridge are entirely reliant on Web 2.0 security, which can be further secured with the implementation of traditional cyber security measures. This eliminates the need for the Web 3.0 component and focuses solely on traditional cyber security.

Another variation of externally validated bridges is a Proof of Stake (PoS) bridge. This gives a decent level of compromise on decentralization (depending on numbers of validators) while being practical. Building a Proof-of-Stake (PoS) bridge can be a complex process. Smart contracts must be employed to manage staking, selecting validators and a voting system to ensure that validators are voting on the correct items. A proposed bridging transaction is put to a vote among the PoS environment participants, with a pre-determined majority needed for the transaction to be accepted. This ensures that the security of the bridge is dependent on the majority of participants, providing a secure compromise. The Polygon bridge, for example, has 100 validators, so compromising it would require compromising at least 51 of these validators, a difficult task due to the participants having their own native tokens at stake. Another example is Portal Token Bridge  built on top of Wormhole (a message passing protocol) where the validation process takes place in an external network called the Guardian Network. Nodes in the network, called Guardians, observe the Core Contract on each supported chain and produce VAAs (Verified Action Approvals, essentially signed messages) when those contracts receive an interaction. Based on the VAA user can withdraw funds on the other end of the bridge. For a successful transfer, 2⁄3 guardians need to sign the message.

2.4 Hybrid

And finally there are other teams that are experimenting with a combination of the above mentioned validation methods. 

Here’s the updated flowchart:

2.5 Token Bridges

Coming back to bridge categories based on applications, the most widely used one is a token bridge. A token bridge is a protocol that allows you to send tokens from one chain to another. Token bridges can be further split into two categories:

2.5.1 Message-based Token Bridges

These allows tokens to flow across chains through messages. A typical transaction flow would be locking an asset on chain A and minting the asset on chain B. And while exiting back, burning the asset on chain B, and unlocking the asset on chain A. Upon locking or burning an asset on a source chain, they typically mint assets on a destination chain. Examples: Polygon PoS bridge, Avalanche Bridge, Portal (Wormhole), Harmony, Nomad etc. 

Avalanche bridge provides an example of a message based token bridge, in which tokens are locked/burned on one chain and minted/unlocked on the other. This type of bridge has the advantage of allowing virtually limitless minting and burning (provided 6/8 nodes submit the same transactions to the SGX Enclave to sign), thus improving user experience by ensuring an absence of liquidity issues. However, this approach is also more vulnerable to exploitation by hackers, who may mint as many tokens as they desire and dump them on the market. For centralized bridges, a single entity is responsible for verifying the burn process. For decentralized bridges, a decentralized approach is used to affirm the message indicating that the asset has been burnt on one side and minted on the other. While Mint and Burn bridges are beneficial in terms of user experience, they do not provide the same level of security as liquidity-based bridges. 

2.5.2 Liquidity Networks Based Token Bridges

Message-based bridges can sometimes take a long time to complete a cross-chain transfer. For example, it takes around 7 days to exit an optimistic rollup. Hence, some token bridges can also have another layer called ‘liquidity networks’ on top of the message based bridge. Liquidity networks are systems that allow you to swap these tokens from one chain to another. So when you use a liquidity network, you basically swap out an already minted asset rather than sending a message to mint a token on the destination chain. Liquidity networks thus act as a crosschain DEX such that they allow you to swap tokens for a small fee. An example of a liquidity network in production right now are protocols like Hop and Connext. People use liquidity network based token bridges for faster transfers by bypassing the native bridge’s delay. This concept of liquidity network based bridging designs started to come up when Arbitrum and Optimism went live, because using the native bridge for moving assets from these rollups back to Ethereum was tediously long (due to the 7 day challenge period). 

One problem with liquidity networks is that the liquidity can dry up and the user will have to wait longer. If there is a bridge connecting Ethereum and Polygon, and USDC is being bridged from Ethereum to Polygon, the process requires a counterparty who has either provided liquidity on the Polygon side of the bridge or has locked their USDC on the Polygon side to exit on Ethereum. This ensures the availability of USDC on Polygon. However, if a new yield farm is created on Polygon and there is a surge in the movement of USDC from Ethereum to Polygon, there may be insufficient liquidity on the Polygon side of the bridge. To address this, bridges offer incentives to add liquidity on both sides. However, in the complete absence of liquidity, the bridge defaults to message passing based token bridge which takes longer to complete the same transaction.

According to L2BEAT’s L2Bridge Risk Framework, crosschain swapping with liquidity networks can be accomplished using three different mechanisms and the risk associated with each is different:

• HTLC: An HTLC, or Hash Timelock Contract, can be used to atomically swap assets between two parties across different blockchain platforms. The user is usually required to take two actions - one to lock the assets and one to unlock them. If the swap fails, the user's funds are locked for a fixed period of time. Some examples of platforms that use HTLCs are Connext and Liquality.
• Conditional Transfers: A conditional transfer allows a Liquidity Provider (LP) to bypass a message bridge by providing funds instantly to the end user and accepting funds from the message bridge whenever they are bridged. If the LP is unavailable, a slow path is activated and the user needs to wait for the message bridge to unlock the funds. Some examples of platforms using conditional transfers are Hop, Connext Amarok, MakerDAO Teleport and Across V2
• External Validator: The external validator allows users to transfer funds to a trusted bridging provider. The provider promises to release the funds on the other side, but if they fail to do so, the user's funds can be lost. 

2.6 Bridge Aggregators

Users have the option to choose from various bridges for their specific task, each with its own pros and cons such as speed, TVL, efficiency, and cost. To assist with this decision, aggregators offer a platform for users to compare different bridges and select the one that fits their requirements the best. By combining the features of multiple bridges, aggregators may have a unique advantage in the bridge sector.

One such bridge aggregator LiFi’s has written a section on Bridge Aggregation Protocols while contributing to the Crosschain Risk Framework. According to them, bridge aggregators work similarly to Decentralized Exchange (DEX) aggregators by bringing together multiple bridges to provide users with the most efficient option for their crosschain asset transfers and exchanges, taking into consideration factors like cost, speed, slippage, and security. As bridges typically only support a limited set of tokens, bridge aggregators also incorporate DEXs and DEX aggregators, expanding the range of assets available for exchange across chains. For instance, if a user wants to exchange USDC on Arbitrum for ETH on Ethereum, they would require a bridge aggregator that integrates DEXs. This aggregator would transfer USDC from Arbitrum to Ethereum and then utilize a DEX to convert it to ETH.

2.6.1 Two components of Bridge Aggregators for handling crosschain transactions

The Off-chain Component: The off-chain component of an aggregator uses a routing algorithm to determine the most efficient route for a crosschain exchange by evaluating quotes from various liquidity sources for a given trade. The algorithm filters, ranks, and suggests routes based on established rules and user preferences, and communicates this information to front-end components via an API. These front-end components then display the routes to the user. Although this component is centralized, it is crucial as quotes and routes for bridges are only available off-chain. Additionally, computing the optimal routes off-chain reduces costs and enhances efficiency and user experience. 

The On-chain Component: Once a user has chosen a route, the aggregator's smart contracts, which integrate the contracts of the various bridges, DEXs, and DEX aggregators supported by the bridge aggregator, execute the crosschain transaction. The smart contracts of the bridge aggregator simplify the complexities of working with multiple bridges and DEXs, but also introduce another layer of smart contract risks.

• The Off-chain Component: The off-chain component of an aggregator uses a routing algorithm to determine the most efficient route for a crosschain exchange by evaluating quotes from various liquidity sources for a given trade. The algorithm filters, ranks, and suggests routes based on established rules and user preferences, and communicates this information to front-end components via an API. These front-end components then display the routes to the user. Although this component is centralized, it is crucial as quotes and routes for bridges are only available off-chain. Additionally, computing the optimal routes off-chain reduces costs and enhances efficiency and user experience. 

• The On-chain Component: Once a user has chosen a route, the aggregator's smart contracts, which integrate the contracts of the various bridges, DEXs, and DEX aggregators supported by the bridge aggregator, execute the crosschain transaction. The smart contracts of the bridge aggregator simplify the complexities of working with multiple bridges and DEXs, but also introduce another layer of smart contract risks.

2.6.2 Categorization based on the Aggregator’s interaction with users

Indirect Interaction through dApps: In these systems, bridge aggregation protocols operate in the background and do not have direct contact with end users. Instead, the bridge aggregation protocols are integrated into a dApp's crosschain service offering. For instance, in MetaMask Bridges, crosschain transfers are executed through two bridge aggregation protocols, LI.FI and Socket.

From the dApp’s perspective, utilizing bridge aggregators offers the following benefits:

• Access to liquidity from multiple sources, including bridges, DEXs, and DEX aggregators.
• Connectivity with a greater number of blockchains.
• No single point of failure, as bridge aggregators provide alternative solutions in the form of backup bridges.
• Improved user experience as users receive the optimal route for crosschain swaps.
• Bridge aggregators bear the cost of integrating and maintaining multiple bridges.
• Assessing bridges is a complex and time-consuming process, as various factors such as speed, cost, security, trust assumptions, and others must be considered. Bridge aggregators relieve dApps of this burden by providing access to multiple bridges, allowing them to inherit each bridge's strengths and mitigate their weaknesses.

Directly via their front-end: With direct front-end interaction, bridge aggregation protocols communicate directly with end-users through front-ends run by them. For instance, TransferTo.xyz and Bungee allow users to access LI.FI and Socket's bridge aggregation services directly.

The advantages for users include:

• Access to multiple bridges, DEXs, and DEX aggregators in one platform, saving time and money.
• Availability of multiple bridges and DEXs without the need to assess and choose each one.
• Optimal route and quote for crosschain swaps determined by routing algorithms.
• Option to compare and select preferred routes.

2.6.3 Considerations before using bridge aggregators

The use of bridge aggregators that allow for multi-step or multi-hop bridging increases the likelihood of a transaction failure. These aggregators incorporate various protocols, including different bridges and DEXs, each with their own security features and risks. As a result, users must trust the aggregators to provide a carefully selected set of options with minimal risk. Additionally, the use of aggregators adds an extra layer of risk to the implementation process.

Some questions users must consider before using an aggregator are: 

1. How does the aggregator address transactions that do not complete successfully?
2. What framework does the aggregator use to choose which bridges to integrate?
3. How does the aggregator communicate security and risk information to users?
4. Does the aggregator require trust beyond what is necessary for the original bridge? If so, what are these requirements and in what situations do they apply?
5. What happens if the off-chain parts of the aggregator experience issues? Can this affect a user's funds?

To conclude, bridges can be categorized in many ways, we’ve seen the categorization by validation method and the categorization by the applications built on top of the messaging infrastructure. Depending on the application, they can be a Token, NFT, Governance, Lending or an ENS bridge. Token bridges can be further classified into Lock and Mint type or Liquidity Network type. In regards to the validation method, bridges can be designed to validate messages in a decentralized, centralized manner or a hybrid version of the two. Decentralized validation can be natively verified or optimistically verified. Native verification can be achieved by light clients validating either the state transitions or the consensus on the source chain. Centralized validation is done by multi-sig, EOAs, SGXs, threshold signature schemes or some form of consensus algorithms. Finally we discussed the role of bridge aggregators in making crosschain transactions more efficient, secure and user friendly. 

In the next section we explore the reason why bridges break and aim to highlight the different security aspects of importance in bridges.

3.0 Why and How Do Bridges Break?

The main challenge with bridge validation is that blockchains are designed to be consistent and validatable. This means that a blockchain can only trust and know information that is produced by the blockchain itself. Any external information is hard to validate since the blockchain has no way of knowing what is happening in the outside world or on other chains. As we saw, different bridges use different mechanisms to ensure that the message being relayed is valid, which then allows users to receive their tokens. However, if for example a bridge introduces new and unsafe tokens to the destination chain by minting, then these assets are only as secure as the bridge itself. This can jeopardize even the security of the blockchain it connects to. 

3.1 Reasons why bridges get hacked

According to the blockchain data platform Chainalysis almost $2 billion has been stolen from bridges over the past two years, with close to 15 incidents reported. This data from Chainalysis reveals that bridge hacks constitute a significant proportion of the total funds stolen in DeFi in 2022, amounting to an alarming 69% of the total.

Why is that? According to Chris Winfrey from Hop Protocol, there are 3 core reasons: 

1. Technology is new

These bridges are connecting a lot of new L1 chains, L2 scaling solutions, each having different technologies on top of the bridges themselves having new technologies. Different bridges continue to try different ways to interoperate and naturally things are going to break down as we experiment on various models. However as time goes on, we will figure out which design patterns are more secure, technology will get more proven and this problem will be solved to a large extent. 

2. The attack surface area is large 

Some bridges connect just two blockchains, other bridges connect a lot of blockchains at the same time, which exposes them to a large number of attack vectors. This problem seems to get worse as the bridges try to expand to newer and less proven blockchains making them the target for attackers. 

3. There is a lot of value at stake

It is clear that more and more DeFi participants prefer to move their funds across different chains to chase the yields and so the bridges are going to need to transfer growing amounts of value as time passes. As Ethereum’s Layer-2 ecosystem grows in addition to the multi L1-chains, bridges become a great honeypot for the exploiters. 

But in order to understand how they break, we need to focus on the three main pillars of bridge security. Each of these pillars can have multiple ways of attacking. 

‍

3.2 Three main pillars of Bridge Security 

According to Layne Haber, co-founder of Connext, bridge security has three main pillars, Economic security, Implementation security and Environment security. In this section, we will dive into the three main pillars, how they can be compromised and compare three bridge models (Natively verified, Externally verified and Optimistically verified) against each other in these three pillars. 

3.2.1 Economic Security: 

The question here is ‘How much would it cost to corrupt your system i.e. to corrupt the validators?’ The higher the cost to gain control over the majority validators, the better is the economic security. The quickest way to compromise economic security is by stealing the private keys of the validators (i.e. the signer keys). The most number of dollars lost are to hacks due to compromised signer keys. In this case, you have a trusted party like a multisig and they lose their keys to hackers. This has resulted in over a billion dollars lost. 

For natively verified bridges, you would have to corrupt the underlying domain’s validator set. Meaning you would have to execute a 51% attack on the underlying domain’s validators to be able to violate economic security. For externally verified bridges, you just have to corrupt the bridge validator set (such as in the case of Ronin Bridge hack). For optimistically verified bridges there are a few different ways you can corrupt, one being corrupting the entire watcher set. Meaning you would have to prevent the watchers that are online from disconnecting any transaction or proving any fraud. You could also sensor the home chain, where disputes are initiated and fraud is proven. You can also prevent the fraud proof from actually being submitted on the origin chain and finally you can compromise the destination domain so that even if the watchers are honest, cannot actually disconnect the domains. Thus if we compare the three  bridge security models, in terms of economic security, starting with the most secure, #1 is Natively verified, #2 is Optimistically verified and #3 is Externally verified.

3.2.2 Implementation Security: 

The question here is ‘How complex is the implementation of your system?’ In many cases upgrading the smart contracts of a messaging layer to fix bugs, improve speed, or launch new technology can introduce risk vectors that can compromise the security of the bridges and dApps using the messaging layer. Bridges’ Implementation needs to be simple. This is the basic rule of coding, to keep your code as simple and extensible as possible. Simplicity can be described in multiple ways; faster response times in case of an ongoing hack, continuous monitoring, code being well auditable, and having extensive test coverages etc. Some checks and balances that can be implemented could be to have additional verification requirements for transactions that want to transfer over a certain % of bridge funds (such as 90% of the funds locked on the bridge). 

The easiest way to compromise Implementation Security is to find Smart Contract Vulnerabilities. Most bridge hacks have been due to smart contract vulnerabilities. These can be mitigated by getting the code audited by multiple 3rd parties and introducing bug bounty programs but are extremely difficult to eliminate. 

Another way to compromise Implementation Security is to compromise the RPC endpoints that the bridge uses. For a bridge, the RPC endpoints are like a custodian of funds just like their private keys. So in the case where the message relayer isn’t running their own nodes but rather using the RPC provider, if the RPC provider gets hacked, they can launch false events and cause your bridge to get drained. In a trustless system, the bonders are facilitating the crosschain messaging and fully collateralizing the funds by taking the risks on just themselves. Even if they outsource their RPC to a 3rd party, they are only risking their own funds. But in a trusted bridge like a Multisig bridge, and if they outsource their RPC to a 3rd party provider, your trust assumptions increase. For example you have to assume not only that the multisig committee are good people and they have world class security, but also assume that the third party RPC providers too have a very secure infrastructure. It is worth mentioning that there are challenges associated with projects running their own nodes. To ensure the integrity of such nodes, it's necessary to consider implementing strong access policies, maintaining availability, establishing a base of trusted and diverse peers to reduce the risk of an "eclipse attack," applying security patches, and performing protocol upgrades. Additionally, it's advised to rely on multiple independent sources of data by using both self-owned and third-party nodes verifying the integrity of the information they provide.

Natively verified bridges tend to rely deeply on the consensus of the underlying domain, which means you need unique implementations for each domain that the bridge is connecting. This makes it very difficult to implement. Externally verified bridge, you can have the same set of implementation logic as it is not tied to the consensus of any of the connecting domains, however you would need to have some complex off-chain coordination between all the validator sets. This can present a unique set of security challenges, so it’s essential to maintain the same level of security of off-chain components as that of smart contracts. It can be achieved by getting the code audited by multiple independent 3rd parties and introducing a bug bounty program. With Optimistically verified bridges, you are able to port the same implementation to multiple different domains as it is again not deeply dependent on the consensus of any of the connecting domains, and you have isolated agents (watchers) who don’t need to communicate with each other. So we have the updater (similar to a sequencer in a roll-up), who have their stake on the line and are responsible for ensuring the integrity of the messages and then we have a series of isolated watchers who are there to prove fraud. So if we compare the three bridge security models, in terms of implementation security, starting with the most secure, #1 is Optimistically verified, #2 is Externally verified and #3 is Natively verified. 

3.2.3 Environment Security

The question here is ‘How can your system prevent 51% attacks on the underlying domain?’

This is all about ensuring that you maintain the high integrity of the environments that have really high economic value. Bridges are essentially an oracle of information and state from one chain to another. We can have two chains with completely different levels of economic security at the base layers, connected to each other.

One example of a weak environment security would be, connecting a less secure blockchain to a more secure one such as Cardano to Ethereum. Cardano is probably easier to corrupt and sensor than Ethereum is but the bridge is basically what would allow a malicious state on Cardano to be transferred to Ethereum and break that integrity of Ethereum. Environment security in this case would be to ensure that Ethereum didn’t react to Cardano's fraud. 

Another example of compromised environment security might be Re-Org Attacks. You have a message that is initiated on the source chain and then it is completed on the destination chain, but we need to make sure that the source chain has reached finality. For L1s this is a standardized process but for Rollups, this get a bit trickier. On a rollup, users make a transaction, submit it to the sequencer and the sequencer puts it on the L1 block. That block is waiting for finality before you can complete the message to the destination knowing that it is not going to be reversed on the source chain. Another version of re-org attack could include, a malicious fraud proof can be inserted allowing the attacker to roll back the rollup even after the L1 block reaches finality. 

The Natively verified bridges do not defend against this very easily because the only way you can prevent this is by taking advantage of asynchronous models and making sure that somebody off-chain is validating that there is no underlying 51% attack happening (example could be pre crime from Layer Zero). For externally verified systems, it is easy to add delay and off-chain verification but not necessarily required for the bridge. It isn’t built into such models but can easily be added as an additional degree of security.  Some security auditors, such as Hacken, consider this an important security measure. And for Optimistically verified bridges, they have a delay built in the bridge model itself which means that these types of risks can be easily detected and reacted to, without having to change any fundamental bridge design. So if we compare the three bridge security models, in terms of Environment security, starting with the most secure, #1 is Optimistically verified, #2 is Externally verified, and #3 is Natively verified. 

3.3 Analysis of the top 5 most expensive bridge exploits

In this section, let’s analyze the top 5 most expensive bridge exploits to answer two key questions for each exploit: Why the exploit happened and which Bridge Security Pillar did it compromise. 

3.3.1 Axie Infinity Ronin bridge hack

In March 2022, Ronin Network suffered a hack where the attackers were able to steal around $624 million. The attack went unnoticed for six days, and it was only when a user reported that they were unable to withdraw their funds that the project team became aware of it. The breach was enabled by compromised private keys. Ronin Network uses a group of 9 validator nodes for transaction approval on the bridge. A deposit or withdrawal requires approval by a minimum of 5 of these nodes. The attacker gained access to Sky Mavis's computer, who is the creator of the blockchain NFT game Axie Infinity, by offering a job using a malicious PDF (i.e. a phishing attack). This gave the attacker control over 4 validators managed by Sky Mavis and a fifth one controlled by the Axie DAO, as the DAO temporarily permitted Sky Mavis to sign transactions and failed to revoke this permission. As a result, the attacker had the power to produce valid signatures for 5 out of the 9 Ronin Network validators.

The risk pillar that was compromised in this case was ‘Economic Security’ meaning the cost to gain control over the validators was not sufficiently high. The attack highlights the importance of sufficient decentralization of validator key storage, revoking temporary permissions on time, and having continuous monitoring in place that could detect the hack as soon as it happens. 

3.3.2 Wormhole token bridge hack

In February 2022, Wormhole, a token bridge between Ethereum and Solana, was the victim of one of the most expensive DeFi hacks to date. The attacker exploited the use of a deprecated, insecure function to bypass signature verification. The attackers signatures were believed to have been properly verified which then enabled the attacker to mint the stolen ETH. 

The risk pillar that was compromised in this case was ‘Implementation Security’, as the use of a deprecated function led the attacker to bypass verification of signatures giving the attacker the authority to mint new tokens. This hack demonstrates the importance of secure coding practices and an in-depth security audit. 

3.3.3 Nomad bridge hack

In August 2022, Nomad suffered a chaotic hack where multiple individuals exploited an error in an update to drain over $190 million in value. A successful crosschain transaction involves two steps: validation of the transaction and its processing.The hack occurred because the transactions to the bridge only executed the process() within Replica.sol without first verifying its validity. The validity of a message is proven by verifying the associated root and the roots of untrusted messages are 0x00 by default. While upgrading Nomad, the team initialized the value of trusted roots to 0x00, which is the value for an untrusted root and thus all messages were automatically viewed as proven. 

The risk pillar that was compromised in this case was ‘Implementation Security’, as upgrading the base layer smart contract introduced a new bug, compromising the security of the bridge. The attack highlights the significance of thoroughly reviewing smart contract code before deploying it. This type of error could have been detected through testing methods such as fuzzing.

3.3.4 Horizon Bridge Exploit

On June 23, 2022, the Horizon Bridge was targeted in an attack in which the perpetrators were able to access the assets bridged to the protocol by compromising at least two out of the four private keys used by the bridge validators. It was a centralized bridge with a validation process consisting of multi-signature scheme with five validators for approving transactions. However, the bridge only employed a 2 out of 5 validation system, making it possible for an attacker to approve any malicious transaction they desired by compromising just two of the validators. 

The risk pillar that was compromised in this case was ‘Economic Security’ as it was easy to gain control over two validators, effectively gaining control over the bridge validation process. This attack highlights the importance of using a highly secure way of storing the private keys of the validators (essentially a Web 2.0 security practice) making it economically infeasible for the attackers to gain access. 

3.3.5 BSC Token-Hub Bridge hack

In October 2022, the BSC Beacon crosschain bridge was the victim of an attack. The attack exploited a vulnerability in the underlying code by forging a merkle proof for a specific block. The BSC Beacon Bridge implemented a modified version of a core Cosmos code repository and it was here that the bug was identified. The merkle proof in this particular version didn’t verify the data sufficiently and the attacker was able to insert malicious data in addition to the legitimate data to make it seem validated.

The risk pillar that was compromised in this case was ‘Implementation Security’, as there was insufficient testing conducted on the modified Cosmos code of the merkle tree proofs. It's crucial for software development to prioritize security measures throughout the entire development process, including providing education and training for engineers, as well as incorporating security checks into new or modified smart contracts.

Out of the top five most expensive hacks, three were due to compromised ‘Implementation Security’ and two were due to compromised ‘Economic Security’. It is interesting to note that none have been due to compromised ‘Environment Security’ although this could happen in theory.

In conclusion, it is clear that there are several reasons why bridges are the main target for attackers, and that there are multiple ways to exploit them. Depending on the economic security, implementation security, and environment security, hackers can start with the easiest attacks, such as stealing signer keys, to trying more sophisticated attacks by submitting fraudulent proofs and exploiting vulnerabilities in the code. Now that we know why and how bridges get hacked, let's move on to the next section where we discuss how to mitigate these exploits, how to respond after a hack has occurred, and we will dive into the risk assessment and scoring framework to compare bridge safety. 

4.0 What Can Be Done Moving Forward To Analyze and Mitigate Bridge Risks?

In this final section of our report, we will discuss how to prevent bridge attacks through threat mitigation, and reduce their effects through an effective threat response system, as well as present a Bridge Risk Assessment Framework for users to make informed decisions about their bridge selection. Let's dive in!

4.1 Threat Mitigation

Bridges handle large amounts of value and must be designed and implemented in a way that ensures their security and reliability. Threat mitigation is a set of practices and techniques that are used to identify and reduce the risks associated with smart contracts, such as vulnerabilities that could be exploited by attackers. By implementing effective threat mitigation measures, developers can help ensure that their bridge contracts function as intended and protect the assets that they manage. Threat mitigation is generally considered to be more important than threat response when it comes to hacks in blockchain bridges. This is because threat mitigation focuses on preventing hacks from occurring in the first place, while threat response deals with the aftermath of a hack. By implementing effective threat mitigation measures, developers can reduce the likelihood of their blockchain bridges being hacked, which can help prevent the loss of assets and damage to the network. In contrast, threat response only becomes relevant after a hack has occurred, and its effectiveness is limited by the amount of damage that has already been done. Therefore, it is generally considered to be more important to focus on preventing hacks from happening in the first place, rather than trying to clean up the mess after the fact. Here are the key aspects of threat mitigation:

4.1.1 Follow Best Code Practices

One way to achieve threat mitigation in smart contract code is to follow smart contract best practices. This includes coding contracts bug-free and keeping them simple. This reduces the chances of vulnerabilities and exploits in the code. Additionally, it is important to perform thorough testing and audits of the code to identify and fix any potential issues before deployment. Regular security updates and patches can also help to prevent threats and vulnerabilities. It is also important to monitor the contracts and the network for any suspicious activity or potential attacks. One such tool is called ‘Forta’, which is a real-time detection network for security & operational monitoring of blockchain activity. Given timely and relevant alerts about the security and health of owned or dependent systems, protocols and investors can react quickly to neutralize threats and prevent or minimize loss of funds.

4.1.2 Independent Code Audit 

By having security experts review the source code, it’s possible to identify vulnerabilities and security flaws that may not have been apparent during development. Once identified, these issues can be addressed before they have had a chance to be exploited. In addition, they can provide insights into the system and identify potential attack vectors. This information can then be used to implement effective controls and safeguards, reducing the likelihood of successful attacks. As a bonus, an audit can improve the overall quality of the source code, making it more resilient to common errors and oversights.

4.1.3 Avoid Trusted Third Parties

If you are using a multisig bridge (trusted bridge), you are not just trusting the people behind the multisig but also trusting that they have the highest level of security to protect their hot keys. And it is important to note that these multisig keys are not like the multisig wallet keys in DeFi where a group of people are holding ledger keys. These are hot keys that run on servers that are receiving and propagating information, upgrading things etc. 

4.1.4 Prevent Contamination/ Horizontal Scaling

This includes expanding to new chains without exposing the existing users to the risks of the new chain. As a bridge supports more and more networks, it increases the probability of being exploited. Let’s take a look at this example by Chris Winfrey from Hop Protocol in his presentation at the Stanford  DeFi Security Summit (all the illustrations are from Chris’ presentation)

In this illustration we have a bridge that supports Ethereum, Optimism, Polygon and Arbitrum. Let’s say the bridge decides to connect with Doge-chain in the future as shown in this illustration below:

In this case, if Doge-chain were to be compromised and the attacker wants to use the bridge to exit the funds, the bridge exposes all the liquidity providers of all chains to the hacker allowing them to drain the entire bridge.

‍

To prevent this scenario, the Hop Protocol uses what they call a Hub and Spoke model as shown in this illustration below:

In this case, if the bridge decides to extend compatibility to Doge-chain, and if Doge-chain gets compromised, only the funds of LPs that choose to support the Doge-chain will be affected. The LP funds are compartmentalized to prevent contamination. Meaning, the smart contracts for the liquidity providers are separate for each bridge pair and hence hacking one contract doesn’t affect the others. 

‍

‍

4.1.5 Use Pre-Crime (Layer Zero)

Layer zero  implements something called Pre-Crime. Currently in smart contracts, when there is an actual exploit, because everything is atomic, attackers are able to steal funds in one single transaction. With messaging, you lose this atomicity and there is a gap in time, where block confirmations need a certain threshold before the message is sent to the destination chain. Pre-Crime takes all the chains involved in the messaging, forks them, delivers the message, and then checks them against a set of invariants. The invariants could be for example the total supply of a token has to be a billion and it can check that all the chains the token exists on, have the total supply to 1 billion before and after the delivery of the message. This is how it works in Stargate. So basically the chains are forked, invariants are run and the message is not delivered if those invariants don’t hold true. Thus protocols building on top of Layer Zero also have this added benefit thus preventing a crime before it happens.

4.1.6 Optional Upgrades From Messaging Layer

As discussed earlier, upgrading the smart contracts of a messaging layer to fix bugs, improve speed, or launch new technology can introduce risk vectors that can compromise the security of the bridges and dApps using the messaging layer. Consider the recent Wormhole bridge bug, where if a hacker was going to be malicious, they could have forged messaging for everything built on top of Wormhole that was secured before the upgrade, making it no longer secure. They ended up paying a $10M bounty for that bug. We also saw a similar incident with the Nomad hack where everything was working fine until the upgrade where they initialized one of the parameters to 0 allowing hackers to forge messages. LayerZero proposes a different approach called ‘Library Upgrades’. The concept is that applications cannot be forced into any upgrades that LayerZero implements. Every upgrade is optional. One can auto-opt into the upgrades but they don’t have to. Applications built on top of LayerZero’s messaging can wait till the upgrades stand the test of time and the benefits of accepting the upgrades are now worth. So let’s assume that a hacker gets access to LayerZero admin key and decides to introduce a bug in the messaging system, they can only affect the applications that accept the upgrade. 

4.1.7 Open-sourcing Codebase

Open sourcing code and offering bug bounties can be a great way to help keep bridges secure. With closed source software, whitehats (good actors) are not likely to look for bugs and exploit vulnerabilities. Bad actors, however, are still likely to reverse engineer the code to find bugs, as there is an incentive for them to do so. Open sourcing the code base, on the other hand, provides an incentive for whitehats and other security engineers to look through the code and find bugs, which is the best outcome. In this way, open-sourcing the code is a beneficial way to help mitigate potential hacks. We can formally verify invariants in the code too. The tricky thing about bridges is that we can formally verify the source side and the destination side of it, but we can't formally verify the working between those two because that happens off-chain. The message passing between the source chain and the destination chain of a bridge happens off-chain. So we can't formally verify that component because it's beyond the scope of what a formal verifier can see. The solution is to manually verify or audit that section.

4.2 Threat Response

Although threat mitigation is generally considered to be more important than threat response when it comes to hacks in blockchain bridges, threat response is still an important part of any security strategy. This is because even with the best threat mitigation measures in place, it is still possible for a hack to occur. In these cases, having a well-defined threat response plan in place can help minimize the damage and recover lost assets. A good threat response plan should include steps for detecting a hack, assessing the extent of the damage, and taking steps to contain and remediate the situation. By having a well-defined threat response plan, developers can help ensure that their blockchain bridges are able to recover quickly and efficiently from a hack and reduce the extent of the damage. 

4.2.1 Shorter Response Time

The most important factor in a threat response is the response time. The faster your response, the safer the bridge in terms of recovering users’ funds. Let’s look at a few of the previous hacks to understand the importance of Threat Response mechanisms. ChainSwap was one of the first hacks back in 2020, where users reported issues and nodes were shut down within 30 mins, limiting the losses to less than $800k. On the other hand Ronin Bridge hack went unnoticed for 6 days and resulted in a loss of $650M. More recently the Nomad Bridge got hacked which lasted for a few hours during which a lot of whitehats tried to drain the funds only to return them later. This timely response by the whitehats saved Nomad around $32M. However, had the whitehats stepped in within minutes of the hack, they would have been able to protect way more funds. This shows that the threat response time makes a huge difference in the amount of funds recovered. 

Smart contract state monitoring services offered by third parties or features like Challenge window period found in rollup bridge designs inherently have a benefit in response time to hacks. The duration of the challenge window is very important. For example, Optimistic Rollups use a 7-day challenge window which means that the transactions are not final until the 7-day period ends. Thus if there is a hack, the team would have 7-days to reverse the hack. Hop Protocol uses a 24-hour challenge window. Then there are others that are experimenting with 30-min to 2-hours challenge windows which makes the bridge riskier in comparison to the longer period ones but more efficient. The duration should be sufficiently long to allow humans to respond if something were to go down.

4.2.2 Continuous Monitoring Systems

Another important factor in a threat response is having monitoring systems in place. They act as health checkers and notify in case of any security invariances instantaneously. This can inherently reduce your response time. If the bridge hack is noticed late, in which case the funds themselves cannot be recovered on the bridge itself, it is still important to notify the exchanges, the stablecoin issuers, get the address labeled on Etherescan etc. Attackers typically have not been perfect at laundering money, they make mistakes too as they probably didn’t think of all the situations they would get themselves involved in. For example in the $610M Poly Network hack, the attackers swapped some of the stolen funds to Tether and the issuers of Tether were able to freeze around $33M and return it to the network later. In other cases the centralized exchanges have frozen attacker funds by blacklisting their wallets and then later return the fund to the team. In short, recovering funds doesn’t stop at the bridge level but also extends to exchanges and the teams behind the stablecoins as well.

4.3 Looking into the future: Bridge Risk Assessment Framework 

Standardized Risk frameworks are necessary in choosing the right bridge because they provide a systematic approach to analyzing and evaluating potential security and risks involved in using it. It can also be used by Bridge Liquidity Providers to identify and assess potential risks and make more informed decisions while searching for yield generating opportunities. Without a standard risk framework, it would be very difficult to compare the different bridge models based on the raw information, which can lead to poor choices. Certain risks are unique to specific bridge designs and moreover the risks for one type of user may not be the same for another type of user. Meaning that retail users might prefer a fully permissionless model, whereas institutions might want to use a permisionned and OFAC compliant one. Nonetheless, we can attempt to create a framework that can be slightly modified for each user profile. 

The team at Socket together with the L2 Beat community has done an incredible job of putting together one such framework. The framework is fairly broad and can be used as a good starting point. Below are the 5 major categories that make up this framework: 

1. Security
2. Performance 
3. Extractable Value 
4. Connectivity
5. Capability

Vaibhav Chellani (Socket, Bungee Exchange), who wrote this framework has a Video Seminar centered around building the risk framework for Bridge Security where he discusses these 5 categories in details. Joel John, a writer for Decentralised.co, who collaborated on this framework with the Socket team and has written a detailed piece titled ‘Assessing Blockchain Bridges’, expanding on each of these 5 categories. We recommend readers to use these two resources to fully understand their framework. 

Additionally, it’s worth exploring other frameworks like the one developed by Hacken that can be used for reviewing off-chain components of externally verified bridges. Here is the link to the methodology. It expands on well-known conventional security concepts and uses domain-specific application weakness classification to provide a good analysis value.

At Coinchange we have built DeFi Risk Assessment Frameworks for DEXes, Money Market protocols and Blockchains. Each framework is divided into two parts: 1. Data Gathering and 2. Risk Scoring. In the Data Gathering section we answer several questions to gather the relevant data points needed for the Risk Scoring section. The Risk Scoring section is a set of questions that scores each of the four risk pillars (Operational Risk, Governance Risk, Smart Contract Risk and Liquidity Risk) relevant to Coinchange, on a scale of 0-100%, where 0% is the worst score and 100% is the best score. Finally an aggregate score is derived by issuing proper weighting methodology such as 20% weight for Operational Risk, 30% weight for Smart Contract Risk and so on. In this section we will build a similar framework. 

4.3.1 Data Gathering

This process is the heart of our Bridge Risk Assessment. First, we gather all the relevant information about the protocol by answering a set of questions. The questions are designed to uncover information on: Bridge Design and Validation Methods, Bridge Usage/ Liquidity Metrics, Tokenomics, Company/ Team Background, Counterparties used by the protocol, Liquidity Rebalancing Incentives & Model, Security & Audits, Ease of Integration with Coinchange Infrastructure, and lastly Governance & Protocol Upgrade Management. Let’s look at 25 such questions that we can consider for this step of the framework:

1. Which messaging infrastructure/layer is it using? (LayerZero, Axelar, Wormhole etc.)
2. Does the messaging layer offer ‘optional upgrades’ or are the upgrades forced on the bridges and apps built on top?
3. Are the messaging layer smart contracts upgradeable? 
4. What do the bridge applications need to implement in order to use this messaging layer?
5. Which use cases does the bridging protocol support? (Token transfers, NFTs, Governance, Crosschain Collateralized Lending etc)
6. How can we categorize the bridge in terms of validating a crosschain message? (centralized, decentralized or hybrid)?
7. If the bridge is decentralized
   a. Is it Natively Verified or Optimistically Verified?
   b.If the bridge is natively verified, is the light client verifying the validity of the state or only verifying the consensus?
   c.If the bridge is optimistically verified, how long is the challenge window period? 
8. If the bridge is centralized, 
   a. What is the setup of their external verification method (multisig, consensus algorithms (typically based on propose-and-vote schemes), threshold signature schemes, SGX (Intel® Software Guard Extensions), or any other technique)?
   b. How many validators does this bridge have? 
   c. Who are the validators? 
   d. What is the stake distribution amongst them? 
   e. Do the validators have access to user funds?
   f. How many signers does the multisig have? If it use a multisig scheme
9. Does the bridge have continuous monitoring, alerting, and anomaly detection?
10. Is the token bridge a Lock-mint-burn-unlock type or does it involve liquidity networks? 
11. How is the crosschain swapping with liquidity networks accomplished (HTLC, Conditional Transfers or External Validator)?
12. Does the bridge have an isolated security model for every chain? What will happen with the liquidity of the bridge if there is a vulnerability/consensus problem in any supported chain/layer2 that enables an attacker to mint arbitrary assets?
13. What is the recovery mechanism/threat response of the bridge in case of a hack?
14. How will the bridge make the users whole in cases of liveliness failures, validator consensus failures etc.? (post to L1, force validator?) 
15. Does the bridge have the capability to freeze stolen funds? 
16. Does the bridge have an insurance fund? Is it in the native bridge tokens or an established one such as USDC?
17. How is the liquidity rebalancing process?
18. How is the bridge operator selection process? Permissioned or permissionless?
19. Can the operator censor your bridging transaction? (This question can be considered in two ways, one for a user who believes in decentralized world and other for an institution who wants to comply with the regulations.)
20. How many chains does it support? (This question can also be considered in two ways, the more chains the better connectivity but bigger attack surface and potentially weaker security) 
21. Does it support Contract Call? Can the state of a smart contract be accessed across the bridge? (the ability of a bridge to interact with a smart contract on the recipient chain.)
22. Does the bridge allow users to send and swap at the same time, meaning the user wants to bridge USDC but wants to receive some other token on the other chain?
23. How many security audits did the project pass? Who are auditors, is there any bug bounty program live?
24. Are there any preventive measures (such as multi-sig or time-lock) against arbitrary changes to key parameters?
25. How secure are the blockchains that the bridge connects to? ( a less secure blockchain creates a potential for attacker to attack the bridge through this chain)

These are just a few of many questions that can be asked to gather the initial data and the answers can be sourced from third party platforms such as DeFiLlama and Token Terminal or the analytics page and the developer docs written by the bridge team themselves. 

4.3.2 Risk Scoring

The second part of the framework can consist of scoring questions that require the data gathered in Part 1. Some questions that can be included in this section include:

1. How long is the challenge period/dispute window? 
   a. 0% = Less than 2 hours
   b. 25% = more than 2 hours but less than 24 hours
   c. 50% = 24 hours d. 75% = 1 day to 7 day
   e. 100% = no such requirement
2. Does the bridge have an insurance fund? Is it in the native bridge tokens or an established one such as USDC?
   a. 0% = No insurance fund
   b. 25% = Native token insurance covers partial loss
   c. 50% = Native token insurance covers complete loss
   d. 75% = Third party insurance fund covers partial loss
   e. 100% = Third party insurance fund covers complete loss
3. How is the liquidity rebalancing process? (this goes in Liquidity Risk section)
   a. 25% = LP needs to manually provide liquidity to rebalance
   b. 50% = LP provides liquidity but the bridge automatically rebalances itself
   c. 100% = Does not need rebalancing as it is not a liquidity based bridge
4. Smart contract risks:
   a. 25% = Mint and Burn type bridge because hackers can steal unlimited funds
   b. 75% = Liquidity based bridges as hackers can only steal locked funds
5. What types of chains does the bridge support?
   a. 0% = It is a Native bridge supporting only two chains. 
   b. 25% = It supports multiple chains but is only across L1 or only across L2
   c. 50% = It supports EVM based chains across L1 and L2
   d. 75% = It supports EVM and Non-EVM based chains across L1 and L2
   e. 100% =  It supports EVM and Non-EVM based chains across L1 and L2 and non-smart contract based chains
6. How many chains does it support? (user’s perspective)
   a. 0% = 2 chains
   b. 25% = 3 to 4 chains
   c. 50% = 5 to 6 chains
   d. 75% = 7 to 8 chains
   e. 100% = 8+ chains
7. How many chains does it support? (from attack surface perspective, non linear)
   a. 100% = 2 to 4 chains
   b. 50% = 5 chains
   c. 25% = 6 to 8 chains
   d. 0% = 8+ chains
8. The number of days the contracts have existed and the number of calls that have been made to the primary smart contract. (Helps us understand the maturity and robustness of the core smart contract for the protocol)
   a. 100%=  The contract is active for more than 500 days and has more than 50B total volume.
   b. 80%= The contract is active for more than 365 days and has more than 30B total volume.
   c. 50%= The contract is active for less than 365 days and has more than 10B total volume.
   d. 30%= The contract is active for less than 365 days and has more than 1B total volume.
   e. 0%= The contract is active for less than 365 days or has less than 1B total volume.
9. Scoring based on number of audits and quality of the audit(s). (if the team audits their protocol before launching it to the mainnet then there is less chance of exploits. Also if there have been multiple audits by reputed auditors, it increases the credibility of the protocol.)
   a. 100% - Multiple Audits performed before deployment and after deployment, the audit findings are public and implemented or not required.
   b. 90% - Single audit performed before deployment and audit findings are public and implemented or not required
   c. 80% - Multiple audits performed after deployment and no changes required. The Audit report is public.
   d. 70% - Single audit performed after deployment and no changes required. The Audit report is public.
   e. 65% - Code is forked from an already audited protocol and a changelog is provided explaining why forked code was used and what changes were made. This changelog must justify why the changes made do not affect the audit.
   f. 50% - Audit(s) performed after deployment and changes are needed but not implemented. 
   g. 30% - Audit(s) performed are low-quality and do not indicate proper due diligence.
   h. 20%= No audit performed
   i. 0%= Audit Performed after deployment, existence is public, report is not public OR smart contract address' not found.
10. Is the TVL sufficiently high? (a high TVL typically shows the strength of the protocol and less slippage costs)
    a. 100%= TVL is close to 500M or higher
    b. 80%= TVL is from 250M up to a 500M
    c. 50%= TVL is from 100M to 250M
    d. 20%= TVL is less than 100M

Although preliminary, these questions should be an integral part of a Bridge Risk Assessment, enabling the researchers to provide a standardized way to assess the risks associated with the bridge and determine its overall level of security. Users can then make the choice to use a specific bridge depending on their needs and informed compromise on different levels of security.

In conclusion, developers must take proactive measures to ensure the security and reliability of their blockchain bridges. This includes following smart contract best practices, testing, audits, security updates, monitoring, and using the Forta tool or others for real-time detection. Additionally, developers should avoid using trusted third parties, prevent contamination by horizontal scaling, use pre-crime, make messaging layer upgrades optional, and open-source the code. Even with the best threat mitigation measures in place, it is still possible for a hack to occur, so having a well-defined threat response plan is essential. Finally, a standardized risk assessment framework should be used to guide users and applications to the right bridge for their transaction requirements and desired level of security.

Conclusion

To summarize, Interoperability is becoming an increasingly important feature of any blockchain to facilitate the exchange of value with other blockchains. Without interoperability, the assets would be fragmented resulting in isolated chains with limited use cases. Bridges are the solutions to ease fragmentation and allow users to hop from one blockchain to another seamlessly. 

Bridges which enable interoperability between different blockchains, rely on a messaging infrastructure that enables data transfer across chains. Bridges are applications built on top of this infrastructure. The type of bridge used can vary based on its purpose, such as token bridges, NFT bridges, governance bridges, lending bridges, and ENS bridges.
The way crosschain messages are validated can also determine the type of bridge, including decentralized, centralized, or hybrid validation. Decentralized validation is the most secure, but also the most complex to build, whereas centralized validation is less secure but easier to build. Hybrid validation seeks to find a balance between security and complexity. Bridge aggregators provide a solution for efficient crosschain transfers by combining multiple bridges under the same UI and considering factors such as cost, speed, slippage, and security, similar to Decentralized Exchange aggregators. 

Bridges however, present a challenge when it comes to trust and validation of external information. Various trust assumptions need to be minimized to verify the validity of the message, making fully secure bridges one of the most difficult to develop in the Blockchain ecosystem. Bridge hacks have constituted a substantial ~70% of total funds stolen in the DeFi sector over the past two years, mainly due to the novel technology, vast attack surface, and high value at stake.

The security of bridges is based on three main elements: Economic Security (cost of attack), Implementation Security (design security), and Environment Security (safety of connected chains). These can be vulnerable in many ways such as stealing signer keys, collaborating with validators, maliciously updating smart contracts, exploiting smart contract bugs, compromising RPC endpoints, or undergoing re-org attacks, among others. Out of the most expensive five hacks, three were due to inadequate Implementation Security and two due to inadequate Economic Security. Notably, none have been caused by compromised Environment Security so far. 

The frequency of bridge hacks is rising as they are becoming a popular target for attackers. However, there are certain steps developers can take to prevent these attacks and respond promptly in case of a hack, while users of the bridge can assess the safety of a bridge by evaluating its risk score.

Hence, in order to safeguard the security and reliability of blockchain bridges, developers must implement proactive threat prevention strategies. This involves adopting best practices such as conducting smart contract testing and audits, implementing security updates, monitoring for real-time threats, avoiding reliance on third parties, and utilizing transaction simulation methods. Threat mitigation can also be enhanced through horizontal scaling, making messaging layer upgrades optional, and open-sourcing code for white-hat security.

Despite these measures, a hack may still occur, so having a well-planned response is crucial. This includes quick response time through continuous monitoring and maximizing chances of recovering lost assets. Finally for users, we propose a two-part risk assessment framework to help choose the right bridge based on their transaction needs and desired security level. The first part of the framework entails gathering relevant information about the protocol, while the second part involves scoring questions based on that information. 

This effort by Coinchange Research Team is an ongoing one, where we are collaborating with some of the most prominent Interoperability players in the space, helping educate developers and users about the risks, building industry standard risk frameworks and participating in brainstorming conversations with key enterprise players to help build the most secure version of the Interoperability space.

Bibliography:

1. Cross-Chain Transfer Protocol by Circle
2.  Cross-Chain Interoperability Protocol (CCIP) by Chainlink
3.  Socket WIP Bridge Evaluation Framework
4. Zero Knowledge Podcast with Vaibhav Challani from Socket
5. Hop Protocol Presentation by Chris Winfrey from Stanford DeFi Security Summit 2022
6. Vulnerabilities in Cross-chain Bridge Protocols Emerge as Top Security Risk. A report by Chainalysis
7. L2Bridge Risk Framework 
8. Mudit Gupta’s lecture on Bridge Security at DeFi Security Summit Stanford (not available online)
9. LayerZero Labs
10. Breaking Down Bridge Security Models, Layne Haber - DeFi Security Summit 2022  
11. How bridges break. Breaking Bridges - An Incomplete Sampler of Bridges Hacks, Yoav Weiss - DeFi Security Summit 2022
12. How To Understand Blockchain Bridges Through Four Questions. An article by Consensys
13. Your Crypto Needs A Secure Way To Travel. Here's Why. An article by Consensys
14. EEA Crosschain Security Guidelines
15. Crosschain Risk Framework- Bridge Aggregation Protocols
16. Connext Bridge Trilemma Blog Article
17. Navigating Arbitrary Messaging Bridges: A Comparison Framework. A LI.FI Blog
18. Ingonyama Medium Article