Crosschain Interoperability
and Security

Abstract

Without interoperabilitythe liquidity of assets is fragmented. In order to facilitate the exchange of value between different blockchainsinteroperability is essentialand 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 applicationsuch as token bridgesNFT bridgesgovernance bridgeslending bridgesand ENS bridges. They can also be categorized by the way in which crosschain messages are validated: decentralizedcentralizedor hybrid. Each of these types has varying trust assumptions and in order to evaluate the security of each typewe 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 keyscolluding with validatorsmaliciously upgrading contractsexploiting code vulnerabilitiescompromising RPC endpointsand re-org attacks. To mitigate such threats one should  follow smart contract best practicestest  their codeconduct auditsimplement security updatesmonitor for real-time detection  of threats avoid trusted third partiesprevent contamination by horizontal scaling (compartmentalized liquidity pools)validate the invariants on a forked version before executionmake messaging layer upgrades optional (to prevent forced malicious upgrades) and open-source code so white-hats can secure it. Additionallya good threat response plan should include a faster response time once the attack has begun . And lastlyhaving 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 blockchainsenabling the moving and swapping of assets and sharing of data by aggregating infrastructure solutions including cross-chain bridgesrelevant data sourcesand decentralized exchangeswhich 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 experiencehundreds of blockchain partnersand thousands of secured crypto projectsHacken 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 reportswe aim to shed light on sectorsprotocolsand various aspects of the crypto space to allow a broad spectrum of newand existing participants to easily understand the trendsthe 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 processfeel 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: [email protected]

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 securitytransparency and trustallowing users to securely store and transfer digital datasuch as cryptocurrencyin a distributed and immutable manner. In order to facilitate the exchange of value between different blockchainsinteroperability is essential. Without interoperabilitythe 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 chainsfacilitating various transfers (e.g. LayerZeroAxelarWormholeCCIP) Bridges are applications built on top of this messaging layer and can be categorized based on their application or utilitysuch as token bridgesNFT bridgesgovernance bridgeslending bridgesand ENS bridges. (e.g. StargateAptosSatellitePortal) Bridges can also be categorized based on the way in which crosschain messages are validatedwhich can be done in a decentralizedcentralizedor 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 exchangestaking into consideration factors like costspeedslippageand 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 technologya large attack surface areaand the high value of funds at stake. There are three main pillars of bridge securityEconomic 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 keyscolluding with validatorsmaliciously upgrading smart contractsexploiting smart contracts vulnerabilitiescompromising the RPC endpointsre-org attacks etc. Out of the top five most expensive hacksthree 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. Thusbridge hack is a growing problemas bridges are a common target for attackers and we will discuss how developers can mitigate these attacksrespond to a hackand 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 occurrather than dealing with the aftermath of a hack. By taking this proactive approachdevelopers can protect the assets that their bridges handle and reduce the likelihood of their network being damaged. Following smart contract best practicestestingauditssecurity updatesmonitoring for real-time detection for threat mitigationavoiding trusted third partiespreventing 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 placeit 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 timewhich can be achieved by using continuous monitoring tools that alert you. The sooner the responsethe 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 questionsand 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 securitytransparency and trustallowing users to securely store and transfer digital datasuch as cryptocurrencyin a distributed and immutable manner. Bitcoin was the world’s first and oldest publicpermissionless 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 fastermore efficient blockchain compared to Bitcoin. With the introduction of composability on Ethereum and building of smart contract protocols for various DeFi applicationsthe number of use cases grewand Ethereum's initial design was no longer scalable. In order to relieve the Ethereum Mainnet from data and execution loadmany Layer-2 blockchains were built on top of Ethereum. Additionally alternative Layer-1 blockchains were built with different consensus mechanismsto tackle scalability and faster transaction throughput. 

In a world where blockchains are becoming increasingly popular and widespreadthe need for interoperability is greater than ever. With so many different blockchains in operationeach with its own design implementationdifferent consensus mechanismsdifferent coding languages and hence different token standardsinteroperability has become essential in order to facilitate the exchange of value between different blockchains. Without interoperabilitythe 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 2023they 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 nutshellwhenever 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 sensea bridge is a rules based protocolfundamental for a scaling solution. 

1.2 What Is A Bridge?

Before we define a bridgewe 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 examplea token bridge is an application on top of this messaging protocol that allows you to send tokens across chainsan 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 speakingbridges 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 USDCcan 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. SimilarlyCentralized Exchanges (CEX) can also act as bridges although the infrastructure might be opaque to the end user. For exampleone 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. Insteadthey 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 tokenswhich then completes the transaction. Thereforeblockchain bridges must be able to verify the validity of these messages. 

Now that we understand what a bridge is and why we need itin 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 bridgesan 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. Additionallysome bridges use a hybrid modelfurther blurring the distinctions between the types. For examplePolygon 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 lecturespresentations and personal talks with various organizations such as L2BEATPolygonConnextHopLayerZero LabsHacken 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 chainsfacilitating various transfers. Bridges are applications built on top of this messaging layer. So the hierarchy is a messaging layerthen bridge applications on top of it. 

One example of a messaging infrastructure is LayerZerowhich is a generalized data messaging protocol that describes itself as an “omni-chain” solution. By using gas-efficientnon-upgradable smart contractslightweight messages can be carried across chains. User applications building with LayerZero simply need to implement two functions — send and receive. As its name impliesLayerZero is a ground-level piece of infrastructure that can power liquidity networksyield aggregatorslending protocolsand many other DApps that build out unique and fascinating multichain crypto applications. For exampleStargate 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 Networkand 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 chainand 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 tradinglendingpaymentsNFTsgaming etc. It is built by Circlewhich 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. CCIPwhich is the Cross-Chain Interoperability Protocol built by Chainlinkalso provides a universalopen infrastructure for developers to build secure services and applications that can send messagestransfer tokensand initiate actions across multiple networks. 

Based on the application or the utility of the bridgethere can be several types of bridges such as Token bridgesNFT bridgesGovernance bridgesLending bridgesENS bridges etc. Additionallybridges can be categorized based on the different ways of validating a crosschain message. The validation could be achieved in 1. A decentralized way2. 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 bridgeOptimism and Arbitrum rollups use a decentralized validation model. Although the sequencers a.k.a the nodes that collect the transactionsare in some cases centralizedtheir 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 chainon the destination chain. Rollups on Ethereumsuch 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 Polygonfor exampleis dependent upon the security of the Ethereum chain and not on that of Polygon. Several companies are currently building ZK bridgesincluding StarkWareZK Scrolland ZK Sync. Polygon's ZK EVMwhich was announced at ETH CC earlier this summeris the first open-source ZK EVM implementation and is considered the most advanced of these. Howeverother 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 usersmaking it potentially simpler for them to transition their assets to the ZK bridge than to a newly developed bridge from another community. Neverthelesscompetition is essential to ensure both teams strive to create bettermore secureand faster solutionsultimately 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 casethe 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-maliciousthen 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 isthere 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 messagewe 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 fraudthe destination chains can be disconnected by a trustworthy watcher.

In generalwith optimistic bridgingif a transaction is initiatedthe process assumes the correct amount and details have been submitted. There is then a challenge period of typically seven daysduring which nodes can contest the accuracy of the details if they have cause to believe they are incorrect. If a challenge is acceptedthe bridging transaction will failand if no challenge is madethe 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 madeand a node attempts to censor itusers 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 monitoringalertingand anomaly detectionthe majority of any bugs discovered are likely to be caught in this seven-day periodthereby ensuring that funds are released securely.

Examples include Hop ProtocolConnext AmarokAcrossNomad 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 waysfor 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 multisigconsensus algorithms (typically based on propose-and-vote schemes)threshold signature schemesSGX (Intel® Software Guard Extensions)or any other technique. Examples include WormholeMultichainAxelarDeBridgeSynapseStargate. External validator set type bridges could be less secure than the two types of natively verified ones. In the natively verified bridgesthe trust was on the two blockchains. With an external validator setthe trust lies on the bridge itself acting as an intermediary. The important considerations here then becomehow 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 exampleif you swap from USDC on Ethereumto USDC on Polygon using Coinbaseyou're technically bridging USDCthough 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 centralizedalthough it was 5/9 multisigbut 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 thiswhich is applicable to both DeFi and traditional systems. Private keyswhich are more prevalent in DeFimust be properly secured through access managementloggingauditingand 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 securitythe centralized bridge can be as secure as possible. Although centralized bridges are relatively easy to securethere is an issue with Web 3.0 - the traditional security aspect has been neglected. Audits and formally verifying smart contracts have become the focuswhile private key management and conventional securityin generalhas been left on the backburner. This is how Ronin Bridge was hacked - their smart contracts were soundwith good audits and quality codebut the traditional security foundation was lacking. In our conversations with security engineers from Hackenit was evident that many notable bridgesspecifically the ones utilizing external verificationprioritize smart contract security over conventional ones. It is essential thatwhile new technology is being implemented in the Web 3.0 worldthe underlying tech stack remains secure.

The Avalanche bridge is another example of a centralized bridgewhich 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 LabsHALBORNBWARELABS and AVASCAN. The security parameters of this bridge are entirely reliant on Web 2.0 securitywhich 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 stakingselecting 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 participantswith 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 participantsproviding a secure compromise. The Polygon bridgefor examplehas 100 validatorsso compromising it would require compromising at least 51 of these validatorsa 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 networkcalled Guardiansobserve the Core Contract on each supported chain and produce VAAs (Verified Action Approvalsessentially 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 transfer2⁄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 applicationsthe 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 backburning the asset on chain Band unlocking the asset on chain A. Upon locking or burning an asset on a source chainthey typically mint assets on a destination chain. Examples: Polygon PoS bridgeAvalanche BridgePortal (Wormhole)HarmonyNomad etc. 

Avalanche bridge provides an example of a message based token bridgein 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. Howeverthis approach is also more vulnerable to exploitation by hackerswho may mint as many tokens as they desire and dump them on the market. For centralized bridgesa single entity is responsible for verifying the burn process. For decentralized bridgesa 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 experiencethey 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 exampleit takes around 7 days to exit an optimistic rollup. Hencesome 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 networkyou 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 livebecause 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 Polygonand USDC is being bridged from Ethereum to Polygonthe 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. Howeverif a new yield farm is created on Polygon and there is a surge in the movement of USDC from Ethereum to Polygonthere may be insufficient liquidity on the Polygon side of the bridge. To address thisbridges offer incentives to add liquidity on both sides. Howeverin the complete absence of liquiditythe bridge defaults to message passing based token bridge which takes longer to complete the same transaction.

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

• HTLC: An HTLCor Hash Timelock Contractcan 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 failsthe 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 unavailablea 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 HopConnext AmarokMakerDAO 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 sidebut if they fail to do sothe user's funds can be lost. 

2.6 Bridge Aggregators

Users have the option to choose from various bridges for their specific taskeach with its own pros and cons such as speedTVLefficiencyand cost. To assist with this decisionaggregators 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 bridgesaggregators 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 thembridge 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 exchangestaking into consideration factors like costspeedslippageand security. As bridges typically only support a limited set of tokensbridge aggregators also incorporate DEXs and DEX aggregatorsexpanding the range of assets available for exchange across chains. For instanceif a user wants to exchange USDC on Arbitrum for ETH on Ethereumthey 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 filtersranksand suggests routes based on established rules and user preferencesand 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 centralizedit is crucial as quotes and routes for bridges are only available off-chain. Additionallycomputing the optimal routes off-chain reduces costs and enhances efficiency and user experience. 

The On-chain Component: Once a user has chosen a routethe aggregator's smart contractswhich integrate the contracts of the various bridgesDEXsand DEX aggregators supported by the bridge aggregatorexecute the crosschain transaction. The smart contracts of the bridge aggregator simplify the complexities of working with multiple bridges and DEXsbut 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 filtersranksand suggests routes based on established rules and user preferencesand 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 centralizedit is crucial as quotes and routes for bridges are only available off-chain. Additionallycomputing the optimal routes off-chain reduces costs and enhances efficiency and user experience. 

• The On-chain Component: Once a user has chosen a routethe aggregator's smart contractswhich integrate the contracts of the various bridgesDEXsand DEX aggregators supported by the bridge aggregatorexecute the crosschain transaction. The smart contracts of the bridge aggregator simplify the complexities of working with multiple bridges and DEXsbut 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 systemsbridge aggregation protocols operate in the background and do not have direct contact with end users. Insteadthe bridge aggregation protocols are integrated into a dApp's crosschain service offering. For instancein MetaMask Bridgescrosschain transfers are executed through two bridge aggregation protocolsLI.FI and Socket.

From the dApp’s perspectiveutilizing bridge aggregators offers the following benefits:

• Access to liquidity from multiple sourcesincluding bridgesDEXsand DEX aggregators.
• Connectivity with a greater number of blockchains.
• No single point of failureas 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 processas various factors such as speedcostsecuritytrust assumptionsand others must be considered. Bridge aggregators relieve dApps of this burden by providing access to multiple bridgesallowing them to inherit each bridge's strengths and mitigate their weaknesses.

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

The advantages for users include:

• Access to multiple bridgesDEXsand DEX aggregators in one platformsaving 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 protocolsincluding different bridges and DEXseach with their own security features and risks. As a resultusers must trust the aggregators to provide a carefully selected set of options with minimal risk. Additionallythe 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 sowhat 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 concludebridges can be categorized in many wayswe’ve seen the categorization by validation method and the categorization by the applications built on top of the messaging infrastructure. Depending on the applicationthey can be a TokenNFTGovernanceLending or an ENS bridge. Token bridges can be further classified into Lock and Mint type or Liquidity Network type. In regards to the validation methodbridges can be designed to validate messages in a decentralizedcentralized 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-sigEOAsSGXsthreshold signature schemes or some form of consensus algorithms. Finally we discussed the role of bridge aggregators in making crosschain transactions more efficientsecure 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 sawdifferent bridges use different mechanisms to ensure that the message being relayed is validwhich then allows users to receive their tokens. Howeverif for example a bridge introduces new and unsafe tokens to the destination chain by mintingthen 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 yearswith 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 2022amounting to an alarming 69% of the total.

Why is that? According to Chris Winfrey from Hop Protocolthere are 3 core reasons: 

1. Technology is new

These bridges are connecting a lot of new L1 chainsL2 scaling solutionseach 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 onwe will figure out which design patterns are more securetechnology 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 blockchainsother bridges connect a lot of blockchains at the same timewhich 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-chainsbridges become a great honeypot for the exploiters. 

But in order to understand how they breakwe 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 Haberco-founder of Connextbridge security has three main pillarsEconomic securityImplementation security and Environment security. In this sectionwe will dive into the three main pillarshow they can be compromised and compare three bridge models (Natively verifiedExternally 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 validatorsthe 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 caseyou 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 bridgesyou 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 bridgesyou 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 corruptone 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 chainwhere 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 honestcannot actually disconnect the domains. Thus if we compare the three  bridge security modelsin terms of economic securitystarting 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 bugsimprove speedor 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 codingto keep your code as simple and extensible as possible. Simplicity can be described in multiple ways; faster response times in case of an ongoing hackcontinuous monitoringcode being well auditableand 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 bridgethe 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 providerif the RPC provider gets hackedthey can launch false events and cause your bridge to get drained. In a trustless systemthe 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 partythey are only risking their own funds. But in a trusted bridge like a Multisig bridgeand if they outsource their RPC to a 3rd party provideryour trust assumptions increase. For example you have to assume not only that the multisig committee are good people and they have world class securitybut 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 nodesit's necessary to consider implementing strong access policiesmaintaining availabilityestablishing a base of trusted and diverse peers to reduce the risk of an "eclipse attack," applying security patchesand performing protocol upgrades. Additionallyit'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 domainwhich means you need unique implementations for each domain that the bridge is connecting. This makes it very difficult to implement. Externally verified bridgeyou can have the same set of implementation logic as it is not tied to the consensus of any of the connecting domainshowever you would need to have some complex off-chain coordination between all the validator sets. This can present a unique set of security challengesso 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 bridgesyou 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 domainsand 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 modelsin terms of implementation securitystarting 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 layersconnected to each other.

One example of a weak environment security would beconnecting 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 chainbut we need to make sure that the source chain has reached finality. For L1s this is a standardized process but for Rollupsthis get a bit trickier. On a rollupusers make a transactionsubmit 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 includea 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 systemsit 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 auditorssuch as Hackenconsider this an important security measure. And for Optimistically verified bridgesthey have a delay built in the bridge model itself which means that these types of risks can be easily detected and reacted towithout having to change any fundamental bridge design. So if we compare the three bridge security modelsin terms of Environment securitystarting with the most secure#1 is Optimistically verified#2 is Externally verifiedand #3 is Natively verified. 

3.3 Analysis of the top 5 most expensive bridge exploits

In this sectionlet’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 2022Ronin Network suffered a hack where the attackers were able to steal around $624 million. The attack went unnoticed for six daysand 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 computerwho is the creator of the blockchain NFT game Axie Infinityby 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 DAOas the DAO temporarily permitted Sky Mavis to sign transactions and failed to revoke this permission. As a resultthe 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 storagerevoking temporary permissions on timeand having continuous monitoring in place that could detect the hack as soon as it happens. 

3.3.2 Wormhole token bridge hack

In February 2022Wormholea token bridge between Ethereum and Solanawas the victim of one of the most expensive DeFi hacks to date. The attacker exploited the use of a deprecatedinsecure 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 2022Nomad 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 Nomadthe team initialized the value of trusted roots to 0x00which 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 bugcompromising 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 232022the 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. Howeverthe bridge only employed a 2 out of 5 validation systemmaking 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 validatorseffectively 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 2022the 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 processincluding providing education and training for engineersas well as incorporating security checks into new or modified smart contracts.

Out of the top five most expensive hacksthree 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 conclusionit is clear that there are several reasons why bridges are the main target for attackersand that there are multiple ways to exploit them. Depending on the economic securityimplementation securityand environment securityhackers can start with the easiest attackssuch as stealing signer keysto trying more sophisticated attacks by submitting fraudulent proofs and exploiting vulnerabilities in the code. Now that we know why and how bridges get hackedlet's move on to the next section where we discuss how to mitigate these exploitshow to respond after a hack has occurredand 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 reportwe will discuss how to prevent bridge attacks through threat mitigationand reduce their effects through an effective threat response systemas 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 contractssuch as vulnerabilities that could be exploited by attackers. By implementing effective threat mitigation measuresdevelopers 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 placewhile threat response deals with the aftermath of a hack. By implementing effective threat mitigation measuresdevelopers can reduce the likelihood of their blockchain bridges being hackedwhich can help prevent the loss of assets and damage to the network. In contrastthreat response only becomes relevant after a hack has occurredand its effectiveness is limited by the amount of damage that has already been done. Thereforeit is generally considered to be more important to focus on preventing hacks from happening in the first placerather 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. Additionallyit 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 systemsprotocols 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 codeit’s possible to identify vulnerabilities and security flaws that may not have been apparent during development. Once identifiedthese issues can be addressed before they have had a chance to be exploited. In additionthey can provide insights into the system and identify potential attack vectors. This information can then be used to implement effective controls and safeguardsreducing the likelihood of successful attacks. As a bonusan audit can improve the overall quality of the source codemaking 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 informationupgrading 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 networksit 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 EthereumOptimismPolygon and Arbitrum. Let’s say the bridge decides to connect with Doge-chain in the future as shown in this illustration below:

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

‍

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

In this caseif the bridge decides to extend compatibility to Doge-chainand if Doge-chain gets compromisedonly the funds of LPs that choose to support the Doge-chain will be affected. The LP funds are compartmentalized to prevent contamination. Meaningthe 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 contractswhen there is an actual exploitbecause everything is atomicattackers are able to steal funds in one single transaction. With messagingyou lose this atomicity and there is a gap in timewhere block confirmations need a certain threshold before the message is sent to the destination chain. Pre-Crime takes all the chains involved in the messagingforks themdelivers the messageand 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 onhave 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 forkedinvariants 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 earlierupgrading the smart contracts of a messaging layer to fix bugsimprove speedor 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 bugwhere if a hacker was going to be maliciousthey could have forged messaging for everything built on top of Wormhole that was secured before the upgrademaking 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 systemthey 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 softwarewhitehats (good actors) are not likely to look for bugs and exploit vulnerabilities. Bad actorshoweverare still likely to reverse engineer the code to find bugsas there is an incentive for them to do so. Open sourcing the code baseon the other handprovides an incentive for whitehats and other security engineers to look through the code and find bugswhich is the best outcome. In this wayopen-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 itbut 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 bridgesthreat response is still an important part of any security strategy. This is because even with the best threat mitigation measures in placeit is still possible for a hack to occur. In these caseshaving 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 hackassessing the extent of the damageand taking steps to contain and remediate the situation. By having a well-defined threat response plandevelopers 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 responsethe 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 2020where users reported issues and nodes were shut down within 30 minslimiting 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. Howeverhad the whitehats stepped in within minutes of the hackthey 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 exampleOptimistic 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 hackthe 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 latein which case the funds themselves cannot be recovered on the bridge itselfit is still important to notify the exchangesthe stablecoin issuersget the address labeled on Etherescan etc. Attackers typically have not been perfect at laundering moneythey 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 hackthe 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 shortrecovering 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 frameworkit would be very difficult to compare the different bridge models based on the raw informationwhich 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 modelwhereas institutions might want to use a permisionned and OFAC compliant one. Nonethelesswe 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 (SocketBungee 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 Johna writer for Decentralised.cowho 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. 

Additionallyit’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 DEXesMoney 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 RiskGovernance RiskSmart Contract Risk and Liquidity Risk) relevant to Coinchangeon 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 Risk30% 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. Firstwe 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 MethodsBridge Usage/ Liquidity MetricsTokenomicsCompany/ Team BackgroundCounterparties used by the protocolLiquidity Rebalancing Incentives & ModelSecurity & AuditsEase of Integration with Coinchange Infrastructureand 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? (LayerZeroAxelarWormhole 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 transfersNFTsGovernanceCrosschain Collateralized Lending etc)
6. How can we categorize the bridge in terms of validating a crosschain message? (centralizeddecentralized or hybrid)?
7. If the bridge is decentralized
   a. Is it Natively Verified or Optimistically Verified?
   b.If the bridge is natively verifiedis the light client verifying the validity of the state or only verifying the consensus?
   c.If the bridge is optimistically verifiedhow long is the challenge window period? 
8. If the bridge is centralized, 
   a. What is the setup of their external verification method (multisigconsensus algorithms (typically based on propose-and-vote schemes)threshold signature schemesSGX (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 monitoringalertingand 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 (HTLCConditional 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 failuresvalidator consensus failures etc.? (post to L1force 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 waysone 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 waysthe 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 timemeaning 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 auditorsis 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 perspectivenon 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 auditorsit increases the credibility of the protocol.)
   a. 100% - Multiple Audits performed before deployment and after deploymentthe 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 deploymentexistence is publicreport 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 preliminarythese questions should be an integral part of a Bridge Risk Assessmentenabling 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 conclusiondevelopers must take proactive measures to ensure the security and reliability of their blockchain bridges. This includes following smart contract best practicestestingauditssecurity updatesmonitoringand using the Forta tool or others for real-time detection. Additionallydevelopers should avoid using trusted third partiesprevent contamination by horizontal scalinguse pre-crimemake messaging layer upgrades optionaland open-source the code. Even with the best threat mitigation measures in placeit is still possible for a hack to occurso having a well-defined threat response plan is essential. Finallya 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 summarizeInteroperability is becoming an increasingly important feature of any blockchain to facilitate the exchange of value with other blockchains. Without interoperabilitythe 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 blockchainsrely 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 purposesuch as token bridgesNFT bridgesgovernance bridgeslending bridgesand ENS bridges.
The way crosschain messages are validated can also determine the type of bridgeincluding decentralizedcentralizedor hybrid validation. Decentralized validation is the most securebut also the most complex to buildwhereas 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 costspeedslippageand securitysimilar to Decentralized Exchange aggregators. 

Bridges howeverpresent 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 messagemaking 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 yearsmainly due to the novel technologyvast attack surfaceand 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 keyscollaborating with validatorsmaliciously updating smart contractsexploiting smart contract bugscompromising RPC endpointsor undergoing re-org attacksamong others. Out of the most expensive five hacksthree were due to inadequate Implementation Security and two due to inadequate Economic Security. Notablynone 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. Howeverthere are certain steps developers can take to prevent these attacks and respond promptly in case of a hackwhile users of the bridge can assess the safety of a bridge by evaluating its risk score.

Hencein order to safeguard the security and reliability of blockchain bridgesdevelopers must implement proactive threat prevention strategies. This involves adopting best practices such as conducting smart contract testing and auditsimplementing security updatesmonitoring for real-time threatsavoiding reliance on third partiesand utilizing transaction simulation methods. Threat mitigation can also be enhanced through horizontal scalingmaking messaging layer upgrades optionaland open-sourcing code for white-hat security.

Despite these measuresa hack may still occurso having a well-planned response is crucial. This includes quick response time through continuous monitoring and maximizing chances of recovering lost assets. Finally for userswe 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 protocolwhile the second part involves scoring questions based on that information. 

This effort by Coinchange Research Team is an ongoing onewhere we are collaborating with some of the most prominent Interoperability players in the spacehelping educate developers and users about the risksbuilding 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 ModelsLayne Haber - DeFi Security Summit 2022  
11. How bridges break. Breaking Bridges - An Incomplete Sampler of Bridges HacksYoav 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