Reentrancy Attacks in Smart Contracts, Explained

A reentrancy attack occurs when a malicious smart contract exploits a vulnerability in a target contract by repeatedly calling back into it before the initial transaction is finished. By interrupting the target's execution flow, the attacker can repeatedly trigger functions, such as withdrawals, draining funds before the target contract can update its internal ledger. This remains one of the most critical vulnerabilities in decentralized finance.

The Mechanics of Contract Interaction

Smart contracts on networks like Ethereum ($ETH) communicate by sending messages and executing functions. When a contract sends Ether to an external address, it transfers control of the transaction execution to that receiving address ¹. If the receiving address is another smart contract, it can execute its own code upon receiving the funds.

This execution happens through a fallback function, a default set of instructions that run when a contract receives a transfer without specific function data ¹. Malicious actors program their fallback functions to call back into the sending contract's withdrawal function immediately. Because the first withdrawal has not yet finished executing, the sending contract does not know the funds have already left.

A Worked Example of a Drain

Consider a vulnerable lending contract holding 100 ETH in total deposits. An attacker deposits 10 ETH, meaning their recorded balance in the contract is 10 ETH.

The attacker then calls the contract's withdrawal function. The vulnerable contract processes the request in two steps: it sends 10 ETH to the attacker, and then it updates the attacker's balance to zero.

When the vulnerable contract sends the 10 ETH, control passes to the attacker's malicious contract. The attacker's fallback function immediately calls the withdrawal function a second time. The vulnerable contract checks the attacker's balance, sees it is still 10 ETH because the balance update step from the first call has not occurred yet, and sends another 10 ETH. This loop continues until the vulnerable contract is completely drained of its 100 ETH, at which point the final balance update records a zero balance, masking the theft of the other 90 ETH.

The DAO Hack of 2016

The most prominent example of this vulnerability occurred in 2016 with The DAO, an early decentralized venture capital fund on Ethereum. Attackers exploited a reentrancy flaw to drain approximately 3.6 million ETH, worth roughly $50 million at the time ¹.

The exploit threatened the viability of the nascent Ethereum ecosystem. The community ultimately decided to execute a hard fork to reverse the theft, restoring funds to the original investors. This controversial decision split the network into two distinct blockchains: Ethereum, which implemented the fork, and Ethereum Classic, which maintained the unaltered ledger ¹.

Defensive Programming Patterns

Developers mitigate this vulnerability by restructuring how functions execute. The industry standard defense is the checks-effects-interactions pattern ².

This architectural standard dictates that a function must complete all internal state changes before interacting with external contracts. In the withdrawal example, the contract first checks if the user has a sufficient balance (check). Second, it reduces the user's recorded balance to zero (effect). Third, it transfers the funds (interaction). If an attacker attempts to reenter the contract during the interaction phase, the subsequent check will fail because the internal balance has already been updated to zero.

Reentrancy Guards

Another common defense mechanism is the use of a mutex (mutual exclusion) lock, commonly known in the Ethereum development ecosystem as a reentrancy guard.

Frameworks like OpenZeppelin provide standardized contracts that developers can inherit. By adding a modifier like nonReentrant to a function, the contract checks a simple boolean flag before execution ². If the flag is locked, the function rejects any subsequent calls within the same transaction. The flag is only unlocked when the original execution fully completes.

Common Misconceptions

• Smart contract audits guarantee safety. Audits significantly reduce risk, but they do not eliminate it. Complex protocols can obscure reentrancy vectors across multiple interacting contracts, which automated tools and human auditors occasionally miss. Evaluating such protocols requires broader due diligence, as detailed in the DeFi Risk Checklist: Evaluating Smart Contracts, Oracles, Governance, and Custody.
• Reentrancy only affects native assets like ETH. While early attacks focused on native asset transfers, cross-function reentrancy can occur with any token standard or internal logic if state updates are delayed. Read-only reentrancy attacks, where attackers manipulate price oracles by reading intermediate states, are a modern variant that does not require direct asset transfers.

How This Connects to the Market

The persistence of reentrancy vulnerabilities directly impacts institutional adoption of decentralized finance. When protocols lose millions to fundamental coding errors, capital allocators apply steep risk premiums to yield farming and on-chain lending. Protocol developers increasingly rely on standardized, audited libraries and newer programming languages that attempt to eliminate reentrancy by design to build trust and secure deep liquidity.