What Is A Reentrancy Attack, Explained Simply?
A reentrancy attack sounds like something out of a heist movie, and in a sense it is one — just aimed at code instead of a vault. The trick exploits a timing gap in how a smart contract processes a withdrawal, and understanding that gap explains why this remains one of the most closely audited risks in decentralized software.
The short answer
A reentrancy attack happens when a smart contract sends funds to an external address before it finishes updating its own internal record of that address’s balance. If the receiving address is itself a contract built to call back into the original one during that brief window, it can trigger the same withdrawal function again and again before the balance is ever reduced. What looks like a single withdrawal request can quietly become dozens, all processed against a balance that was never actually adjusted.
How a withdrawal is supposed to work
In a well-ordered contract, a withdrawal follows a simple sequence: confirm the requester has funds available, update the internal ledger to reflect the withdrawal, and only then send the money out. As long as the balance is zeroed out before the funds leave, there’s nothing left to withdraw a second time even if something unusual happens during the transfer itself.
Where the gap opens up
The vulnerability appears when that order gets reversed — when a contract sends funds first and updates its records afterward. Sending funds to another contract can hand over a small window of execution to that contract’s own code before the transaction finishes. If the receiving contract is written to immediately call the withdrawal function again the moment it receives control, and the original balance hasn’t been updated yet, the request looks valid every single time it’s repeated.
A simplified example
Imagine a contract holds 10 tokens on behalf of a user and sends those tokens out before setting the internal balance to zero. If the receiving contract’s code calls the withdrawal function again the instant it gets the first payment, and the balance still reads 10, it can be paid a second time — then a third, then a fourth — until the contract’s available funds run out or the transaction hits its processing limit. None of this requires guessing a password or breaking encryption; it simply exploits the order in which two ordinary steps happen.
Why lending and pooled contracts are common targets
Contracts that hold large pooled balances are especially attractive targets because the payoff from repeated withdrawals scales with how much sits in the pool. This is part of why platforms that explain how collateral backs a crypto loan tend to undergo heavy scrutiny before launch — a pool that lets many users borrow against shared liquidity is exactly the kind of contract where a reentrancy flaw becomes expensive fast. It’s a different failure mode than a contract being fed bad information, such as when an oracle reports the wrong price, but both share a common thread: the contract trusted an external interaction more than it protected its own internal state.
What protects against it today
- Reordering state changes. Contracts written to update internal balances before sending funds close the gap entirely, since there’s nothing left to claim on a second call.
- Reentrancy locks. A simple flag that blocks a function from being re-entered while it’s already mid-execution, regardless of what the receiving contract tries to do.
- Independent audits. Third-party code review specifically hunts for this exact pattern before a contract is trusted to hold real funds, and reputable projects typically publish those audit results.
None of these protections are visible to an everyday user interacting with an app’s interface, which is part of why understanding what permissions a wallet grants an app matters — the contract’s internal logic is invisible, but the scope of access it’s given is not, and limiting that access limits potential exposure.
The takeaway
Reentrancy is fundamentally a question of sequencing: does the code protect its own records before it hands over control to the outside world, or after? It’s a different concern from the layered integrity checks covered in how hashing secures blockchain data, which protect a record after it’s written — reentrancy is about protecting logic while it’s still executing. For anyone interacting with smart contracts, it’s a reminder that not all crypto risk is about market swings; some of it lives quietly in code that either was, or wasn’t, audited for this exact pattern.