The Persistent Threat: Why Reentrancy Attacks Remain a Challenge in Web3

The Web3 community needs to adopt comprehensive runtime protection mechanisms to effectively mitigate reentrancy attacks.

4 min read
Table of contents


Reentrancy attacks exploit vulnerabilities in smart contracts, allowing attackers to call the contract multiple times before it finishes its initial execution. This manipulation can drain funds, manipulate state variables, and disrupt intended functionality. These attacks have plagued the Web3 ecosystem, causing significant financial losses.

One infamous example of a reentrancy attack is The DAO hack of 2016, where attackers exploited a vulnerability in The DAO's smart contract to siphon off over $60 million worth of ETH. In a read-only reentrancy attack, attackers don't steal funds directly but manipulate data or trigger unintended actions. An example of this type of attack is the Sentiment platform hack of April 2023. In this incident, attackers leveraged a vulnerability in the protocol's smart contract to manipulate data fed into the system. This manipulation allowed them to steal nearly $1 million worth of cryptocurrency.

While developers have proposed various solutions to address reentrancy vulnerabilities, completely eliminating the threat remains a challenge.

And for those of you who think the reentrancy attack is a thing of the past, check Github:

Reentrancy Attack List
Not an exhaustive list Reentrancy Attack List

The Limitations of Reentrancy Solutions

1. Manual Code Review and Audits:

  • The Flaw of Human Error: Thorough code review and security audits are crucial for identifying reentrancy vulnerabilities. However, these processes are time-consuming and expensive. Additionally, human error can always lead to vulnerabilities slipping through the cracks.

2. Reentrancy-Safe Patterns:

  • Limited Scope: Design patterns like the "checks-effects-interaction pattern" aim to structure code to prevent reentrancy. While these patterns are valuable tools, they can be complex to implement and may not cover all potential attack vectors.
  1. Reentrancy Guards: A Double-Edged Sword:
  • Reentrancy guards seem like a straightforward solution, adding a lock mechanism to functions to prevent them from being re-entered during execution. However, they place significant reliance on the developer's  correct implementation:
Reentrancy Guards

  • While reentrancy guards offer a layer of protection, they are not a foolproof solution. They require careful consideration and integration within the overall security strategy of the smart contract.

The Persistence of the Problem

These limitations highlight why reentrancy attacks continue to plague the Web3 ecosystem. The complexity of smart contracts is growing, many smart contracts involve intricate logic and interactions with external systems.  Ensuring every possible scenario is accounted for and reentrancy-safe is difficult. While the industry is constantly evolving with better development practices and security tools,  achieving absolute reentrancy-proof code remains a challenging goal. The Road Ahead: Let’s not reinvent the wheel.


The current solutions, while valuable, function more like manual security checks for traditional applications – necessary but not foolproof.  Imagine deploying an API in Web2 without any runtime protection – every request would be vulnerable to manipulation. This is essentially the current state of affairs with Web3 smart contracts. The Web3 community needs to move beyond these reactive measures and embrace a more comprehensive approach of Runtime Protection similar to Web2, runtime protection mechanisms integrated into the smart contract that can halt suspicious transactions from within the smart contracts.

About the author

Eyal Fine
Head of Engineering

Eyal has many years of experience in software development, cyber security and more. Before joining spherex technologies as Head of Engineering. Eyal served 10 years in the Israeli intelligence doing software development, cyber research and leading teams, projects and groups.

Continue your reading with these value-packed posts
Go back to blog