Reentrancy

A contract holding balances receives a withdrawal request. It checks the caller has funds, sends the funds, and then sets the caller balance to zero. Three steps in that order, and the second one hands control to an address the contract does not control.

If the receiving address is a contract, the transfer invokes its code. That code can call back into the withdrawal function before the first call has finished. The balance has not been zeroed yet, because that line has not executed, so the check passes again. And again, until the pool is empty.

In plain terms: the contract is answering a question about a balance it is in the middle of changing, and the attacker asks repeatedly during the window where the answer is still the old one.

The DAO lost a third of its holdings to this in 2016. The mechanism has not changed since.

Not because the mechanism is obscure. Every competent Solidity developer can describe it. It persists because the handover of control is frequently invisible at the call site.

A native value transfer to a contract address runs that contract receive or fallback function. An ERC-721 safe transfer calls a handler on the recipient by design, so the recipient can reject tokens it cannot process. Some token standards, ERC-777 among them, notify the recipient on every transfer. None of these reads as an external call when scanning the line; each one is.

The same applies to anything that touches an unfamiliar integration. A call into a router, a vault, a reward distributor or a bridge adapter is a call into code written by someone else, which may itself call back.

In plain terms: the question is not whether a line looks like it transfers control. It is whether any address in that line could be a contract. If it could, assume it runs code, because it does.

Single-function reentrancy is the textbook case: the attacker re-enters the same function they are already inside. This is the variant a mutex stops, and the one most teams have in mind when they say the contract is protected.

Cross-function reentrancy re-enters a different function that shares the same state. The withdrawal is in progress and its guard is held, so the attacker calls transfer instead, moving a balance that is about to be zeroed but has not been. A guard on one function does nothing here unless the same lock covers both.

Cross-contract reentrancy exploits two contracts that read each other. Contract A updates its own state last, and contract B reads A mid-operation and acts on a figure that is briefly wrong. Neither contract is individually incorrect; the composition is.

Read-only reentrancy takes nothing directly and is the one most likely to be live in a system today. It is treated separately below.

A view function cannot change state, so for years it was treated as safe to call from anywhere. That reasoning holds for the function and fails for the system around it.

During a withdrawal, a pool is briefly inconsistent: tokens have left, and the supply figure that accounts for them has not been updated yet. A view function reading that state mid-operation returns a number that is arithmetically correct and economically false. Any contract using it as a price source acts on the false figure.

The attacker does not re-enter the vulnerable protocol at all. They re-enter a lending market, or a different pool, that quotes the first one. Nothing in the protocol being read is broken, and the protocol doing the reading has no defect of its own.

In plain terms: a guard protects the functions it is placed on. Nobody places guards on view functions, because a view function cannot be attacked in the ordinary sense. This variant attacks what reads them.

The defence is on the consuming side: do not price against a value that can be observed mid-operation, and where a protocol must be quoted, check whether its own locks are held before trusting the figure.

Checks, effects, interactions. Validate the request, write every state change the call implies, and only then make the external call. Applied consistently, the class stops existing: when control is handed over, the accounting already reflects the operation, so a re-entrant call finds nothing to exploit.

A reentrancy guard is the other approach, and it is a lock rather than a correction. It prevents the same function, or any function sharing the lock, from being entered while held. It is useful and it is not equivalent.

In plain terms: a guard blocks the attack. Ordering removes the condition that makes an attack possible. A system relying only on guards is one unguarded function away from the same loss, and that function is usually one somebody added later.

Three practical consequences. A guard that covers only the obvious entry point leaves the cross-function variant open. A guard cannot help across contract boundaries, because the second contract has its own lock. And no guard is placed on view functions, which is why the read-only variant exists at all.

Systematically, rather than by intuition. The procedure is to enumerate every point where control can leave the contract, then ask what state is inconsistent at that moment.

That enumeration includes the lines that do not look like calls: native transfers, token transfers under standards with recipient hooks, NFT safe transfers, and any call into an integration. For each, the reviewer establishes which state variables are mid-update and which functions read them.

Then the same question is asked outward: which other contracts read this one, and would any of them be wrong if they read during this window. That second pass is what catches the cross-contract and read-only variants, and it is the pass that gets skipped when a scope covers one contract in isolation.

In plain terms: this is why coverage is what an audit sells. A reviewer checking every external call will find reentrancy wherever it exists. A reviewer looking for clever bugs will find the ones they happen to think of.

Four questions, answerable by your engineers without a review.

Where does control leave our contracts, including the places it does not look like it does? A list of every transfer, hook and integration call.

At each of those points, what state has not yet been written? That is the exploitable window, and it should be empty.

Which of our functions share state, and does a single lock cover all of them? Cross-function reentrancy lives in the gap between two separately guarded functions.

Who reads our view functions as a price or supply source, and could they read during an operation? If the answer is a lending market, that is a read-only reentrancy exposure in someone else code caused by yours.