Security Stack-Up: How Bridges Compare

Intro

Bridges, both in the physical world and in the crypto context, are designed to connect two places that are separated by obstacles. Physical bridges connect land across valleys, water, and other natural barriers, while crypto bridge protocols connect chains that otherwise have no means of communicating and syncing on state. The importance of bridges is conveyed best by what happens when they fail and the well-documented history of catastrophic bridge failures in the physical world indicates both how critical they are and how fraught with danger poorly designed or constructed ones can be.

As crypto matures, the same maxim is becoming increasingly true about bridge protocols. In terms of security risk, bridges are a big target. From the perspective of smart contract exploit potential and attack size, bridges present a quadratic risk surface: as the number of chains connected by a bridge increases, the number of smart contracts required to maintain the bridge’s operations increases quadratically (at least in the point-to-point model). More smart contracts written in different run times according to bespoke configurations also increases bridge risk rapidly. In the hub-and-spoke model, a single vulnerability related to the hub chain or network can similarly lead to incommensurate damage.

A single bug can lead to the loss of most or all of the bridge’s funds, as shown in the recent Nomad hack. Though the bug in question was not a unique bridge-related vulnerability, it likely stemmed from an operational failure. In the case of the Ronin bridge, poor operational security measures led to a phishing attack through which an attacker gained access to a majority of the validators securing the network and was thereby able to abscond with over half a billion in funds. Meanwhile, Wormhole’s February exploit took place due to the absence of a validation check that enabled the exploiter to create a false signature and steal over $320M.

Without a focus on security, it is inevitable that more oversights, and therefore exploits and losses, will occur. The immense TVL held by bridges make them more attractive targets than ordinary protocols. In each of the aforementioned cases, the vulnerability exploited was not related to the bridging logic of the protocol, but instead to smart contract bugs and operational oversights. Even the most carefully written code and best audit practices are bound to miss bugs as the number of chains onboarded and the number of features enabled increase. For that reason, bridges need to be configured to work securely not just on an amortized basis, but more importantly under the worst conditions.

Users care about several features when using bridges: good user experience, low slippage and efficiency, and safety of their assets. Of these, security is not just another consideration to be made when evaluating bridges; rather, it must be the most important feature of comparison.

With that in mind, let’s see how security stacks up across the different bridges. Below, we discuss and compare bridge security along three axes:

1. Trust Assumptions
2. Code Quality
3. Safety Features

The first two relate to how well a bridge factors out sources of vulnerability in its trust layer and its source code. The last corresponds to whether a protocol acknowledges it can and will inevitably have vulnerabilities—no matter how careful it is—and builds in additional safeguards to minimize the potential for user harm.

And for full transparency, before we get into the weeds, Jump Crypto does operate as a Guardian for the Wormhole project and is one of the core contributors to Wormhole.  In this piece, however, we will do our best to remain objective in our assessment, and fully accept and welcome feedback on how we can improve this piece to show a true breakdown of the differences between bridges.

Trust Assumptions

At its core, a bridge can be broken into 3 components:

1. The smart contracts that emit/receive messages from each chain
2. An oracle that verifies if the message did indeed come from the source chain
3. A relayer that submits the message to the target chain.

In practice, bridges can vary quite a bit with regard to their implementations of how consensus (around whether messages are valid) is achieved in the oracle, which also informs the requirements for the relayer.

Before we dive deeper, here’s a quick overview of the consensus mechanisms used by some of the most popular bridges in the space:

Axelar

Axelar runs on a Cosmos-based proof-of-stake network, where validators are elected by token holders and given voting rights on a pro-rata basis, weighted by the stake delegated to them. Cross-chain messages are verified by the Axelar network via a (t,n)-threshold signature scheme where the voting power of the signers, normalized to n, must be greater than t, the protocol threshold, to sign a message. The Axelar network currently has a maximum of 50 validators and must exceed a 66.67% voting majority to sign messages (both of these variables can be modified via a governance vote).

Although the theoretical max number of validators is unbounded, in practice, it seems that voting power is skewed because validators are not required to run nodes for every supported chain. In Axelar’s current validator list, while there are a total of 47 validators, only 20 hold meaningful voting power and for any given chain that number is lower. For example, if we solely consider nodes validating Aurora, 8 are needed to successfully send a message and only 4 need to collude to censor a message.

LayerZero

LayerZero is a cross-chain interoperability protocol that reduces the problem of trustless communication between chains to one of independence between two entities—its oracle and its relayer. The oracle forwards the block header to the target chain, while the relayer forwards the transaction proof, which together attest that the message is valid and was indeed committed to the source chain that it came from. User applications are given the flexibility to use LayerZero’s default oracle and relayer or create and run their own.

The default oracle is a Chainlink DON that uses a threshold signature scheme between three participants (FTX, Polygon, and Sequoia). At the time of writing, there is little visibility into its implementation, because of the closed-source nature of LayerZero’s codebase. With regard to application-specific versions of the oracle, LayerZero’s own Ackee audit points out that it is trivial for any application that creates and runs its own oracle and relayer to successfully submit an invalid transaction proof and block header. This modularity does however provide the benefit that any future vulnerabilities will be limited to solely those apps that are using the affected oracle-relayer pair.

The trust assumption for this bridge is dependent on the behavior of two entities—so long as the oracle and the relayer operate independently from each other, it should not be possible to send an invalid message. Conversely though, either component can omit data to censor messages at will since this system requires both to function properly to validate the messages.

Multichain

Multichain is a cross-chain messaging protocol derived from what was formerly Anyswap, a cross-chain token swap protocol. Multichain uses secure multi-party computation (SMPC) to run threshold signature schemes to create public keys and sign messages sent between chains. These nodes trustlessly control externally owned accounts (EOAs) with public addresses corresponding to the split private key. These accounts are used to store and transfer assets to the target chain which simply checks if the sender’s address is trusted rather than verifying the message itself.

The Multichain network currently consists of 24 SMPC nodes, run by different institutions, and requires a majority of nodes (what quantifies as a majority does not appear to be public) to come together to verify messages. As a result, the security of this protocol relies on the reputational security of the SMPC nodes, which assumes an honest majority of more than 1/2 of all nodes. 13 signatories are needed to send data cross-chain and 12 nodes need to collude to censor messages.

Nomad

Nomad is an EVM-focused cross-chain messaging protocol that uses an optimistic approach to validate messages, in which messages are added to a Merkle tree and hashed into a new root which is published onto the source chain by an Updater. Updaters must post bonds, incentivizing them to publish valid attestations and minimize downtime. Watchers are then given time to dispute the new root and submit a fraud proof. Once that timeframe passes, the Merkle root is considered valid and relayed to the target chain, where it is published, allowing the message itself (since the Merkle root is just a representation of the message) to be published onto the target chain.

This optimistic model requires just one honest Watcher to verify that an invalid update was published. The tradeoff with this security model is that Watchers are given ~30 minutes to submit their fraud proofs which delays the transmission of the messages by that same amount of time. Nomad uses a permissioned set of Watchers, specifiable by applications, because a Watcher can prevent messages from being processed by spamming target contracts with fake fraud proofs. The security of this protocol is derived from both the likelihood of at least one honest Watcher existing and the economic security from slashing the Updater for bad behavior.

Nomad smart contracts are upgradeable via a multi-sig governance model, with 3 out of 5 signers required to execute governance changes and handle recovery management.

It should be noted that the recent Nomad hack had nothing to do with the security of its consensus mechanism; it was an unfortunate contract config mistake that allowed undesirable behavior in the smart contract endpoints.

Wormhole

Wormhole utilizes a Proof-of-Authority Guardian network as an oracle and a permissionless relayer network to transmit messages cross-chain. Each of the 19 Guardians runs full nodes for each of Wormhole’s supported chains and listens for messages emitted by Wormhole’s core contracts on each chain. These Guardians verify and sign these messages and then gossip them to one another on a P2P network. Once a message has received signatures from more than 2/3 of the Guardians (at least 13), it’s relayed to the target chain. A byproduct of this design is that it allows for a completely trustless relayer network to land the message on the target chain. Because these messages are signed by the Guardians it is not possible to either change the contents of the message or censor it since anyone can run a relayer to submit any message.

The security guarantee of this protocol comes from the reputational authority of the Guardians. In Wormhole’s case, this is a group of 19 of the largest staking and infrastructure providers in Web3. 13 Guardians would need to collude to sign a false message, and 7 Guardians would need to collude to censor a message. Moreover, the existing Guardian set has the ability to vote to remove or replace Guardians.

Code Quality Assurance

Code quality assurance refers to the level of caution and prudence paid before deploying code on-chain. This can relate to, among other practices:

• Auditing—getting multiple independent quality audits of core and new features that have been made public
• Bounties—having compelling bounty rewards to incentivize responsible disclosure of bugs and a reputation for paying those large bounties
• Testing—having as much of the protocol stack tested on every single code change to detect regressions in an ever-growing software ecosystem
• Deployment Safety—building in the open, required reviews to merge, contract bytecode verification, upgrade simulations

The following table summarizes the five bridge protocols in these four areas. We delve deeper into each of the bridges below.

Axelar

Axelar has several public and reputable audits and runs a fairly strong (albeit relatively inactive in recent months) testing suite: continuous integration (CI) and continuous delivery (CD) running, bash build scripts, and checksum verification. It does have an active Immunefi bug bounty program which boasts a healthy bounty of $1M for critical severity bugs though bounties for most other severity levels are much smaller. The Axelar repo features regular contributor activity, and its PRs require at least 1 reviewer’s approval.

LayerZero

LayerZero’s measures around code deployment appear somewhat opaque. While there are several public audits from high-quality reviewers, there is a lack of public CI and CD processes. Code is seemingly pushed publicly all at once en masse, rather than an agile development flow, and the testing that does exist seems to be relatively out of date and limited to JavaScript tests. Pull requests do not appear to have a mandatory peer review component. LayerZero did make an announcement about a $15M bug bounty program with Immunefi in April; however, no such program has been publicly released to date, and there are no instructions on how to submit bugs to the bug bounty.

Multichain

Multichain has several public audits and a $2M max bounty program with Immunefi. Multichain testing measures appear stagnant and seem limited to a generic ABI and simple transfer testing. The deployment process appears to be largely manual, though there is CI and CD running and limited unit- and integration testing. Multichain’s repo features somewhat regular contributor activity but appears to require only 1 party to merge code (original developer can merge their own code).

Nomad

Nomad has a recent public audit from Quantstamp and an Immunefi bug bounty program with a maximum bounty of up to $1M. Nomad’s testing suite includes a few tests around routing and messaging that leverage Foundry, and similar to Axelar, has bash build scripts to build and verify bytecode. Nomad’s repo features regular contributor activity, and its PRs require at least 2 parties to merge code (original developer + 1 independent reviewer).

Wormhole

Wormhole’s security page highlights completed and in-progress audits from industry-leading audit firms.  Wormhole has a $10M bounty program on Immunefi and since the February hack has paid out $11M+ in bug bounties, including a $10M payment to a white hat hacker in May. The Wormhole repo utilizes a mix of unit and integration testing, has an extensive CI and CD suite, and runs a collection of simulations to verify upgrade backward compatibility and future upgradeability. In addition, Wormhole is building in the open with active commits and contributor activity, which allows transparent code review and responsible disclosure. Wormhole PRs require at least 3 parties to merge code (original developer + 2 independent reviewers).

Noticeably, protocols’ code quality assurance practices can dramatically improve after experiencing a critical security incident. For example, after its hack, Wormhole’s code quality assurance practices quickly improved. Similarly, it is likely that following the Nomad incident from this week, the protocol will adopt additional code quality assurance practices in the near future. Embracing these practices before an incident occurred is always preferred—but not always prioritized.

Safety Features

As seen above, the stakes are incredibly high for bridge security, and the above code quality assurance components are essential to a bridge provider's security program. In this section, we’ll take a closer look at the in-protocol safety features either in development or deployed by each bridge to understand how these bridges are approaching defense in depth when core trust assumptions and code quality assurance are simply not enough.

Axelar

In its whitepaper, Axelar describes a pool of funds allocated by the network to serve as governance-controlled insurance and a fall-back mechanism to provide users recovery governance guidance in the scenario that Axelar stalls. In such a crisis, an “emergency unlock key” which is housed by the threshold contracts (managed by the Axelar validators) is shared with a secondary recovery set of users. This cohort can potentially scale to thousands of individuals and institutions if need be, who can collectively can control the network to:

• Set the rate limit for the amount of funds that can be transferred in/out of a particular chain
• Dictate what happens to wrapped forms of the chain’s native asset

These features appear to be proprietary and are not currently open source. Additionally, these proposed features do not provide passive security to limit risk, but instead are activated in an existential crisis.

LayerZero

LayerZero’s bridging model includes a requirement by which the application of the transaction picks the relayer on the destination chain. As a result, the logical place where in-protocol safety features can scale in this model is within the relayer itself.

In April, the LayerZero team announced their approach for in-protocol safety features referred to as “the dome” and “pre-crime”. Little is public at this point on the dome feature, but clues are offered in the blog post about how pre-crime is intended to operate. The pre-crime model essentially allows a User Application (UA) to define a specific set of states that the relayer must verify against and if those states are not verified, the relayer will simply not relay the transaction.

It’s important to note that these features appear to be proprietary in nature and currently are not open source, and although conceptually strong, it is difficult to independently assess their effectiveness.

Multichain

Multichain, in a recent post, provided disclosure of some of their security practices, including mention of a few safety features of their bridge configuration:

• Transaction Amount Limit and Total Volume Limit - This feature allows blockchains with higher transaction sizes to be capped at a specific limit. Additionally, for chains with low overall volume, a total volume limit approach is adopted.
• On-Chain Monitoring - This pattern involves monitoring software and on-chain watchdogs to detect abnormal behavior and trigger incident response activities.
• Suspension of Products - This feature allows the suspension of all products and effectively put them on pause while conducting incident response activities.
• Security Fund - This is effectively an insurance fund that takes out 10% of all cross-chain fees to compensate users for assets lost in special circumstances.

Nomad

Nomad makes use of an optimistic verification model whereby messages are signed on the original chain and there is a built-in time window that is enforced on the destination chain. In a way, we can observe this similar to “open this letter no earlier than this time”. This period of time is useful to implement “automatic circuit breakers” and stop the transfer of assets before the Merkle root has been deemed valid. This has been mentioned as a concept on Nomad’s docs and seems to be in-progress.

Wormhole

Wormhole’s messaging model is multi-cast, whereby messages are notarized by the Guardian/Oracle network from the origin chain and is distrusting of the relayer that brings that message to the destination chain. This model essentially requires a very robust Oracle network where in-protocol safety features are able to scale.

The Wormhole project has three major in-protocol safety features in development: Governor, Accounting, and Emergency Shutdown. These features are being built in the open, which allows us insights into how they will eventually operate. These features are pending completion of development and adoption by guardians.

• Governor - This feature, implemented in the Guardian/Oracle, allows the Guardians to monitor notional amounts of value movement from any governed chain within a time window. This effectively allows the Guardians to set an acceptable ceiling per chain that when hit, prevents additional notional value transmission from that chain.
• Accounting - This feature, implemented in the Guardian/Oracle, allows Guardians to maintain their own blockchain (aka “wormchain”), which can serve as a cross-chain ledger between disparate chains. Using this ledger, the Guardians function as validators for the chain and implement an Accounting plugin such that if a cross-chain transaction is attempted but the origin chain doesn’t have sufficient funds (verified independently of the smart contract logic), the Guardians will refuse to honor those transactions until the origin chain is reconciled.
• Shutdown - This feature, implemented on-chain, allows the Guardians with awareness of an existential threat to the token bridge to build consensus to temporarily disable value movement on the token bridge.  The current implementation allows this to be accomplished via on-chain function calls in the proposed implementation.

Parting thoughts

In the coming months and years, we believe that security will become the differentiating feature among bridges. Those bridges that prioritize security are more likely to survive their worst days, but bridges that do not are likely to be vulnerable to existential risks that may eventually put the bridge and its funds in jeopardy. Security may once have been just a source of competitive advantage; however, it must now become the top feature that every bridge should prioritize, and we hope that all bridges will collaborate on ways to improve the state of the art in bridging security.

Our views on bridge security are still developing, and if we missed something, we encourage you to let us know: @claudijd, @anihamde, @heyitaki, @ewokafloka.

As noted above, Jump Crypto operates one of the nineteen Guardians in the Wormhole Network and is a core contributor to the project.