A Developers Blueprint to Prevent Reentrancy Attacks in DeFi

When crypto hit the headlines, headlines with dramatic headlines—"hack", "exploit", "loss"—often sounded so much like a movie script. I remember the night we were sipping gin and trying to explain why the DAO hack was not just a smart contract error but a profound lesson in how our digital investments behave. That was the moment I decided it was time to break apart reentrancy, the classic exploit that turned a promising yield farm into a hole in our collective trust.

Why Reentrancy Is a Pain in the Wallet

Reentrancy is a pattern where a function in a smart contract makes an external call to another contract, and during that external call, the receiving contract calls back into the original contract before the original call has finished. Think of a busy post office that has an “Open” sign. You come in, ask for a letter, the clerk hands you the letter, but before the clerk can tally the number of letters handed out, you slip back in and ask for another one. In the blockchain world, the clerk is your contract, the letter is your state change, and the caller is another contract that can exploit the timing confusion.

The classic case is the DAO hack, where an attacker repeatedly called the splitDAO() function before the contract updated the number of tokens the attacker was owed. Essentially, the attacker exploited a timing flaw to drain 3.6 million ether.

Every developer who writes DeFi protocols, whether building a DEX, a lending platform, or a yield aggregator, needs a toolbox that can catch these timing flaws. Reentrancy attacks are not about clever hacking; they’re about simple logic bugs. In other words, if you’re writing something that promises to be a safe store for people’s money, it has to follow a set of disciplined habits.

Let’s zoom out and examine the patterns

Most developers first think about reentrancy in terms of “call before state change.” That phrase turns into a guardrail: always modify your contract’s state before you make any external calls. It feels simple, and it is, but that intuition alone doesn’t keep an experienced attacker from slipping through other avenues.

One of the simplest ways developers lose sleep is when they forget that any external call is a potential reentering point. That includes ERC20 token transfers (transferFrom), calling fallback functions on other contracts, or even using receive() in your own contract’s fallback. The more external interactions you have, the greater the attack surface.

Below are the building blocks for a developer’s blueprint. I’ll walk you through them with a mix of code snippets, real-world analogies, and a sprinkle of plain English.

Checks–Effects–Interactions: The Golden Rule

Before you write a contract, say you want to allow a user to withdraw funds. The first step is to think: what needs to be checked? What state changes need to happen? Where do I make external calls?

Checks – Validate the transaction: is the user allowed? Did they deposit enough?
Effects – Update the contract’s internal state: reduce balances, log events.
Interactions – Call external contracts or transfer tokens.

The classic reentrancy fix looks like:

function withdraw(uint amount) external {
    require(balances[msg.sender] >= amount, "Not enough");
    balances[msg.sender] -= amount;
    // Interaction after state change
    (bool sent, ) = msg.sender.call{value: amount}("");
    require(sent, "Failed to send");
}

Why does this prevent reentrancy? Because the second msg.sender call happens after the state change. If the attacker tries to call withdraw again from the fallback, the require will fail.

I’ve seen developers get sloppy by putting the external call before the state change, and it turns into a nightmare to debug. Reverting to the checks–effects–interactions pattern feels like taking a breath in a crowded room; the code becomes quieter, and the potential for confusion reduces.

Pull over Push

When you make an external call, you either push funds directly to the user or let them pull them later. The pull pattern is safer because the user controls when the transfer happens.

Pull approach:

function deposit() external payable {
    balances[msg.sender] += msg.value;
}

function claim() external {
    uint amount = balances[msg.sender];
    require(amount > 0, "Nothing to claim");
    balances[msg.sender] = 0;
    (bool sent, ) = msg.sender.call{value: amount}("");
    require(sent, "Transfer failed");
}

Here, the user explicitly claims. During claim, we again follow checks–effects–interactions, wiping the balance before sending. The difference is that we are never sending in a place where the user’s logic could re-enter.

Pull is the natural analogue of a customer at a bank who requests a withdrawal by filling out a request form, instead of the bank handing cash on the same instant. We let the user decide when they take their funds.

Reentrancy Guard Modifier – The “One Call at a Time” Layer

If you’ve ever used locked or reentrancyGuard in a function that interacts with other contracts, that’s your first line of defense. The idea is simple: a boolean flag that locks the function while it’s running, preventing recursion.

You can import OpenZeppelin’s guard:

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract MyDeFi is ReentrancyGuard {
    function doSomething() external nonReentrant {
        // critical section
    }
}

Internally the guard looks like this:

modifier nonReentrant() {
    require(_notEntered, "ReentrancyGuard: reentrant call");
    _notEntered = false;
    _;
    _notEntered = true;
}

This pattern is effective for reentrancy from inside the same contract. Coupled with the checks–effects–interactions pattern, you get two layers.

I used to think adding nonReentrant was a band-aid that gave me peace. Over time, I've learned that it also prevents a class of bugs where a function makes multiple external calls that each might call back into the same function—a form of nested reentrancy. By locking, you guarantee a flat call stack.

Storage Layout: Where the Attack Often Begins

Reentrancy isn’t only about how you write functions; it’s also about how you lay out storage. In Solidity, struct packing can lead to unexpected order if you change the struct definitions after deployment. A malicious contract could overwrite a function selector or manipulate the storage layout to bypass checks.

The safest practice is to:

1. Lock the order of your storage layout: define all state variables at the top of your contract.
2. Use storage instead of memory for structs that are passed around.
3. Keep a /// @custom:storage-position comment next to each variable so you know its slot.

For example:

struct UserInfo {
    uint256 balance;
    uint256 rewardDebt;
}
mapping(address => UserInfo) public userInfo;

If you later add a uint256 pendingRewards field, you must move it above older fields or create a new version of the contract. Upgrades should be considered carefully.

Defensive Testing – “Try, Fail, Fix”

Unit tests that simulate reentrancy are often overlooked. A simple unit test that calls the withdrawal function from a malicious contract can reveal a flaw before the code hits production. Tools like Hardhat or Truffle allow us to write these tests in JavaScript or TypeScript.

Below is a quick test that creates a malicious contract that tries to call withdraw recursively.

contract Malicious {
    DeFi public target;
    address public owner;
    constructor(address _target) {
        target = DeFi(_target);
        owner = msg.sender;
    }
    function attack() external payable {
        target.deposit{value: msg.value}();
        target.withdraw(msg.value);
    }
    receive() external payable {
        if (address(target).balance > 0) {
            target.withdraw(msg.value);
        }
    }
}

In your test suite, you can deploy Malicious to the same network as DeFi, deposit some ETH, and then call attack. If the withdraw function fails or is locked by a guard, the test passes; otherwise, you’ve found a vulnerability.

Code Review and Audit – The Last Layer of Defenses

Even with all these patterns, no code is foolproof. Code reviews should be a collaborative, open process. I’ve found that pairing less experienced devs with senior reviewers often brings out hidden smells. The “code is a contract” mindset works best when combined with an audit from a reputable firm or community audits through testnets.

I encourage you to:

• Keep the audit team blind to your commit history; let them inspect the code fresh.
• Provide clear, concise comments for each function.
• Use require messages that are explicit.

An audit often catches state bugs or misuse of libraries rather than reentrancy per se.

Continual Monitoring – Your Last Chance to Stop a Leak

Once a contract is live, nothing is guaranteed. Gas costs change, new ERC20 standards appear, and external contracts may evolve. We can’t make a one‑and‑done fix. That’s where monitoring comes in.

Deploy an event listener that watches for repeated fallback calls to contracts that could signal reentrancy attempts. Services like Tenderly or Chainlink Keepers can be configured to alert you if an abnormal pattern emerges.

An example:

• Listen to Withdraw events.
• Correlate with Transfer events to the same address.
• If the ratio of Transfer to Withdraw is abnormally high, raise an alarm.

You can also lock the contract manually via a governance vote if you suspect an exploit. The ability to pause can buy time to audit and release a patch.

One Takeaway – The Simple Habit

Across all the patterns, the core idea is simple: Never trust that state changes will stay the same after you execute external calls. Treat every external interaction as a potential reentry point.

When you’re writing a function that modifies state and calls a token transfer, start with it in the comments: “This function may call an external contract – check state before calling.” Keep the nonReentrant modifier on any function that interacts with other contracts. Run tests that attempt to hit each vulnerable function from a malicious contract.

Think of your code as a garden. You can’t expect the soil to stay the same if a rogue animal (or in this case, a rogue contract) keeps eating and rearranging it before you finish planting. By locking the garden beds with a fence, watering only after the plants are planted, and checking the soil before adding compost, you reduce the chance of an unwanted intruder.

In Practice – A Two‑Line Checklist

1. State Update First: In every function, update your internal state before making any external calls.
2. Single Responsibility: For any function that interacts externally, mark it nonReentrant.

If you can, run a quick test for each function with a mock malicious contract. That takes a few minutes and can save millions of dollars.

Final Thought – You’re Not Alone

Reentrancy attacks turned a handful of well‑intentioned developers into cautionary tales on the blockchain. You might feel that these patterns are tedious, but they’re the same kind of discipline we use every day in portfolio construction – small disciplined steps that compound over time.

Keep watching, keep testing, and keep learning. Your users are trusting you with their savings; they deserve a contract that respects the same principles they place in a diversified portfolio: transparency, rigor, and a little patience.