Research Summary: SoK: Not Quite Water Under the Bridge: Review of Cross-Chain Bridge Hacks


  • The paper reviews recent exploits on bridges, providing a concise reference for the exploits.
  • Exploits are described in generality, reference the specific issue, and are complemented by mitigation strategies when possible.

Core Research Question

How did previous blockchain bridges get exploited?


Sung-Shine Lee, Alexandr Murashkin, Martin Derka, Jan Gorzny: SoK: Not Quite Water Under the Bridge: Review of Cross-Chain Bridge Hacks. CoRR abs/2210.16209 (2022)


Bridges are systems to “move” data or digital assets from one blockchain to another. These systems have complex and varied implementations, involving both on-chain and off-chain components. Since digital assets cannot actually be moved from one chain to another, these systems must lock assets on one chain and mint or release representative assets on another chain. The result is a large surface area for attacks and various technical approaches to solving this problem.

In recent months, various such systems have been exploited to the tune of over $1 billion USD.

This arises from the complexity of both straightforward cross-chain asset transfers and the ability to support advanced features like cross-chain function calls. As a result, it is difficult to determine what to avoid for future bridge implementations; no single reference exists. Instead, developers and auditors need to be aware of previous exploits and find the specifics of them online in various disparate blog posts to avoid the same pitfalls. This is made even more confusing as there is no standard terminology for these systems as their components.

Important terminology used and introduced by the paper:

  • Bridges: Bridges are complex, cross-chain systems that “move” digital assets or data from one blockchain or distributed ledger to another.
  • Source Chain: A blockchain where a bridge transaction originates.
  • Destination Chain: A blockchain where a bridge transaction terminates.
  • Custodian: A (smart-contract based) system on the source chain that receives and holds an asset on the source blockchain (a.k.a. “debt”).
  • Debt Issuer: A (smart-contract based) system on the destination chain that issues representations of an asset on the source blockchain (a.k.a. “debt”).
  • Communicator: An off-chain component which passess messages between the Custodian and Debt Issuer.


  • Several key components, like the key terminology above, are identified and defined. They enable a common language to discuss various aspects of bridges, including which parts failed in specific instances. The relationships between these components are also defined.
  • Previous exploits are summarized in the context of the language above. Each exploit is categorized according to the primary component exploited within the bridge. Each exploit is first described at a high level and then described at the implementation level. Exploit descriptions are sourced from disparate post-mortem blog posts but are cleaned up to use consistent language and focus on the relevant parts, and are complemented by techniques to mitigate the exploit whenever possible.
  • In all cases where real-world examples are used, exploits and issues are reported not to defame or insult the relevant projects, but to add legitimacy to the issues and to enable researchers to find exploits based on project names. In some cases, bridge operators were able to correct issues prior to their exploitation, and secure the bridges before any harm was done. These efforts are also described when relevant.
  • Three custodian-based exploits are described: the PolyNetwork Bridge exploit, Polygon/Matic Ethereum/Plasma Bridge, and the Meter Bridge.
  • One debt-issuer based exploit is described: the Wormhole Bridge.
  • One real-world communicator based exploit is described: the pNetwork pBTC-on-BSC Bridge. Another hypothetical attack, for proof-of-work chains, is described.
  • Two exploits based primarily on the interfaces of (ERC-20) tokens supported by bridges are also described: an early version of the Multichain Bridge and the Polygon Bridge Zap.
  • A collection of related work is presented, though none provide a concise reference handbook for prior attacks like the work summarized here. Nonetheless, they may provide other interesting models and analyses of bridges and their components.


  • Each real world example has its own subsection within the section dealing with the primary component of the bridge exploited. Within each subsection, an introduction to how the exploit could be problematic is provided, before describing the generalized approach to the exploit. This generalized approach includes a description of the assumptions required to execute the exploit and the steps necessary to exploit the bridge component under these assumptions.
  • The description follows post mortem blog posts found online. These sources are the exploited bridge project blogs or security researchers who studied the exploits. The relevant details from the post mortem are included in the paper, along with links to the sources. Relevant details have been distilled to focus on the key problems for each exploit. Diagrams are included in order to help readers follow the exploit. This provides a concise reference to understand the exploits included in the paper.
  • One exploit for bridges on Proof-of-Work chains is hypothetical. For this exploit, we provide an analysis for the exploit’s feasibility.
  • In all cases, exploits are complemented by mitigating strategies. Often, these are specific things to check for in the smart contract implementations of the bridges, but also include more general strategies for bridge feature design when possible.


  • The PolyNetwork Bridge’s custodian exploit is described. This exploit occurred because the bridge supported cross-chain function calls and did not properly check the caller when such calls were made. Critically, a clever attacker was able to fool the bridge’s custodian into passing a call onto the destination chain that changed the privileged actors of the bridge’s debt issuer. This occurred due to a partial hash collision of the Ethereum function selector and the ability to “replay” signed messages on the destination change.
  • Next, the authors summarize how the Polygon/Matic Ethereum/Plasma Bridge’s custodian could have been exploited. In this case, the exploit was possible because the “proof-of-burn”, a token given to an actor, was not correctly verified by the bridge’s custodian contract. As a result, these tokens could be modified partially and resubmitted, resulting in actors being able to withdraw more from the custodian than they were originally entitled to. The issue was detected and patched before the exploit was executed.
  • The Meter Bridge exploit is also studied. This is exploit was a result of the bridge custodian handling so-called “wrapped” assets differently than “unwrapped” assets. This implementation-level error resulted in the custodian emitting events (which were in turn picked up by the bridge’s relayer and sent to the debt issuer) in all cases, but only transferring a user’s funds to the custodian in the wrapped asset case.
  • One debt-issuer based exploit is described: the Wormhole Bridge exploit. In this situation, the debt issuer was constructed in such a way as to allow custom verification logic for the messages it received from the bridge’s relayer. This exploit occurred because such logic was able to be replaced with logic that accepted any message as valid. As a result, attackers were able to withdraw more funds from the debt issuer than they were entitled to, and could then bridge the asset back to the source chain.
  • One real-world communicator based exploit is described: the pNetwork pBTC-on-BSC Bridge. This exploit occurred because the communicator was watching for all events with a particular name, but without regard for the contract that emitted the event. An attacker was able to call the custodian’s deposit function via a smart contract call which mimicked the events emitted. The communicator observed both the real and imitated events, and signaled the debt issuer to issue debt for all events, not just the real ones.
  • Another hypothetical attack, for proof-of-work chains, is described. This exploit relies on a short-term 51% attack on an underlying source chain. The exploit describes a method by which a bridge that does not carefully pay attention to chain re-orgs may be problematic in the event that a malicious actor can muster the resources to acquire 51% of the chain’s hash power for a couple of hours.
  • Next, the paper turns to exploits that target interfaces of (ERC-20) tokens supported by bridges. The first example is an exploit of an early version of the Multichain Bridge. Honest users would often provide an “infinite approval” of ERC-20 tokens to bridge custodians, in order to save gas an allow the custodian to transfer tokens at the user’s request. However, an attacker exploited the fact that this bridge could make arbitrary function calls, and made a call to “transferFrom” on ERC-20 tokens from honest users who provided an infinite approval. Since the bridge itself was calling the function, and it had been approved, the attacker was able to take these funds from honest users.
  • Finally, the Polygon Bridge Zap exploit is also described. This exploit is also a result of the supported token interfaces. In this case, some ERC-20 tokens supported optional functionality of EIP-2612, which enables token holders to hand out “permits” for others to spend their tokens. However, if other ERC-20 tokens have a fallback function that never reverts – that is, the default function called by Ethereum, and it never fails to execute, there may be problems for the bridge’s users. In this case, attackers exploited an ERC-20 token with a non-reverting fallback function and a bridge that supported the use of permits. The attacker would claim to have a permit for a ERC-20 token that did not support the permit functionality, so the non-reverting fallback function would succeed, and the bridge understood that it incorrectly had the right to spend funds on behalf of the attacker.

Discussion and Key Takeaways

  • The exploits described above are naturally categorized into the component whose failure resulted in an exploit. These components appear across all the bridges studied, and the language above can be used to discuss bridge architecture with ease.
  • The previous findings are crucial to understand when developing and reviewing new bridges. Each component of a bridge introduces a large surface area for exploitation and these findings can ensure that the issues of the past are not repeated.

Implications and Follow-Ups

  • Additional exploits could be studied and collected. Unfortunately, these systems continue to be exploited, and the paper is incomplete with respect to the most recent issues.
  • Additional preventative measures could be studied. Some attacks are implementation dependent, but others may be avoided by a framework or set of standards. As mentioned in the paper, custodian or debt issuer standards may reduce errors with cross-chain calls or decrease erroneous event emissions. Such standards could be similar to the ERC-20 or ERC-721 standards.
  • The development of a wishlist of specific properties for security would guide new developers, auditors, and end-users. This would avoid the case where attacks listed in this paper fade into obscurity and become unknown to new community members.


This work describes these real-world exploits in a consistent language categorized according to the main component exploited. Exploit descriptions are sourced from various post-mortem blog posts and are cleaned up to use focus on the relevant parts, and are complemented by techniques to mitigate the exploit whenever possible. The result is a handbook that can be used by auditors to look for specific attack vectors and developers to avoid the pitfalls of the past. This work may also be particularly valuable in guiding future tooling to detect issues within bridge codebases automatically. As Ethereum (and other blockchains) move toward a rollup-centric future, the number of bridges will increase. It is important that these bridges do not repeat the failures of the past.


Hey @jgorzny, I find your work very interesting. I haven’t really seen a paper on cross chain bridges and their exploits here on the forum (If anyone has, please point me to it).

This caught my attention. Can you give further insight on what moved you to make this kind of test. There is probably more to it.

1 Like

@jgorzny, excited to see this foundational research on cross-chain bridge security here!

Interoperability is an important primitive that should be given good attention. What’s the essence of building different blockchains without a meeting point? More problems for finance.

So even in the competition, there should be unity, a meeting point, else the center (blockchain technology) collapses or becomes nearly useless.

I’m interested in the Custodian-Based and Debt-Issuer exploits. These two exploits resulted from the systems being single points of failure.

Can these systems not be decentralized? Just like decentralized oracle netoworks. It will be complicated, but it will surely provide some solutions. What do you think?

Also, recently the Nomad Bridge was exploited probably after this paper had been published. Where can we classify this exploit considering the groups of exploits you have established?


@Yeoriton56 That attack, described fully in the paper, relates to coordinating a 51% attack on a source chain of a bridge to enable a double spend of tokens/assets. Essentially, you rent enough hash power to be able to reorganize the chain after several hours. I think it’s unlikely in practice, unless there are not many miners on a network. The analysis simply takes the estimated cost of renting such hash power, from a web resource.


@Ulysses I think it may be possible to deentralize most aspects, but doing so will add complications and requires great care. I don’t have any suggestions for how to do that, and I am not sure we are looking into such approaches right now.

As for the Nomad bridge, I believe our yet-to-be-published follow up work would classify it an exploit of the custodian, as the root cause was wrong validation for some withdrawals. A full explanation should appear in the future, but I can’t comment on a timeline.

1 Like

This a topic I’d love to keep up with. I hope you share with us the follow up research you’re working on when its ready!

For the decentralization part, its good to know you share that same belief. Perhaps, in the future, some other researcher could pick it up since its outside the scope of your work.


@jgorzny I’m fascinated by your work and would like to share my ideas on how past blockchain bridges were exploited.

So, what exactly are blockchain bridges? Blockchain bridges are technologies that enable multiple blockchain networks to interface with one another, allowing assets and information to be transferred across them. There have been cases when blockchain bridges have been exploited, either owing to flaws in the bridge itself or because criminal actors used the bridge to undertake unlawful acts.

In 2016, hackers used a weakness in the Ethereum Classic blockchain bridge to launch a “double spend” attack. In a double spend attack, a bad actor can spend the same cryptocurrency twice, thereby counterfeiting it. The attackers were able to carry out the attack by producing a large number of fraudulent transactions on the Ethereum Classic blockchain, causing the Ethereum Classic blockchain bridge to become congested and preventing valid transactions from being executed.

In 2017, hackers exploited a weakness in the Parity Wallet software, which was used to manage Ethereum-based assets, including those held on the Ethereum Classic network. By exploiting the flaw, the hackers were able to steal nearly $30 million in Ethereum-based assets.

It is crucial to note that these instances are not necessarily indicative of all blockchain bridges, and that depending on their design and execution, individual blockchain bridges may be more or less vulnerable to exploitation. It is always critical to properly assess the security of any technology before implementing it, and to take adequate precautions to safeguard your assets and information.

1 Like