What is a reentrancy attack in smart contracts?

A reentrancy attack is a bug in smart contracts where an attacker's contract re-enters a victim contract in the middle of a transaction and repeats a withdrawal many times. It works because the victim sends funds out before it records that the funds have left. Reentrancy is one of the oldest and best-known flaws in Ethereum-style blockchains.

How does a reentrancy attack in blockchain work?

Ethereum's developer docs describe a simple case. A contract has a withdraw function that sends ether to the caller and only afterwards sets the caller's balance to zero. When ether arrives at another contract, that contract's code can run. The attacker writes a contract whose receiving code calls withdraw again straight away.

Because the balance has not yet been zeroed, the second call passes the check and sends more ether, which triggers the attacker's code again. The loop continues until the victim runs low on funds or the transaction runs out of gas. The attacker ends up taking far more than it deposited.

The Solidity documentation stresses that this is not only about ether. Any call from one contract to another hands over control, so the called contract can call back in before the first call has finished.

What was the DAO hack reentrancy?

The DAO was an early Ethereum investment fund. On June 17, 2016, the Ethereum Foundation said an attacker was exploiting a recursive calling flaw in its split function, which let the attacker collect ether many times in one transaction and move it into a child DAO. Ethereum.org puts the amount drained at about 3.6 million ETH.

The response split the community. On July 20, 2016, at block 1,920,000, a hard fork moved about 12 million ether from the attacker's and rescuers' DAO contracts into a recovery contract so holders could reclaim funds. The chain that refused the change became Ethereum Classic, covered in what is Ethereum Classic.

Reentrancy did not end there. In July 2023 a bug in the reentrancy lock of some versions of the Vyper programming language let attackers drain several Curve pools, as described in what is Curve Finance.

How do developers prevent reentrancy?

Ethereum.org and the Solidity docs describe three common defences.

• Checks, effects, interactions. Check conditions first, update the contract's own records next, and call outside contracts last. If the balance is already zero when funds go out, a callback finds nothing to take.
• Reentrancy guards. A lock, sometimes called a mutex, is switched on when a function starts and off when it ends, so any call that tries to re-enter during that window is rejected.
• Pull payments. Instead of the contract sending funds to many addresses, users withdraw their own funds, which limits how often the contract runs unknown code.

The Vyper case shows that a guard is only as reliable as the tools that build it. Testing and independent review, explained in what is a smart contract audit, are how projects look for these flaws before launch.