Reentrancy Guard

The core mechanism uses a boolean state variable (e.g., _locked, _notEntered) that acts as a mutex. The function checks and sets this flag upon entry, then resets it upon exit. This prevents any nested call from re-entering the same function or a set of protected functions while the lock is active.

• Before Execution: require(!locked, "ReentrancyGuard: reentrant call"); locked = true;
• After Execution: locked = false; (in a finally-like pattern).

The guard enforces the Checks-Effects-Interactions pattern by structurally preventing deviations. It ensures all state changes (effects) are completed before any external calls (interactions) are made, eliminating the window where an attacker's callback could manipulate an inconsistent state.

• Check: Validate conditions and inputs.
• Effects: Update all internal contract state.
• Interactions: Perform external calls (e.g., transfer, call).

In Solidity, the guard is typically implemented as a function modifier. This provides a reusable and clean way to protect any function. The OpenZeppelin ReentrancyGuard contract's nonReentrant modifier is the standard implementation, used by prefixing a function definition: function withdraw() public nonReentrant { ... }.

A single guard can protect multiple functions that share sensitive state. The lock is contract-wide for the modifier's scope, meaning a reentrant call to any function using the same nonReentrant modifier will be blocked. This is crucial for contracts where multiple entry points (e.g., deposit, withdraw, claim) manipulate the same balance mappings.

The guard adds minimal gas overhead—typically one SSTORE to set the lock (~20,000 gas) and one to clear it. Modern implementations like OpenZeppelin's use uint256 instead of bool and != constants to optimize gas. The cost is negligible compared to the financial risk of a reentrancy attack, which has led to losses exceeding $500 million (e.g., The DAO, Fei Protocol).

A reentrancy guard does not protect against:

• Cross-function reentrancy between one guarded and one unguarded function.
• Read-only reentrancy, where a state is read during a callback before it's updated.
• Attacks via delegatecall or other contracts in the same inheritance hierarchy. It must be combined with secure architectural patterns, thorough testing, and audits.

A reentrancy guard is a state variable (often a boolean flag) that is set before a function's critical logic executes and cleared afterward. This creates a mutual exclusion lock (mutex) for the function. The most common implementation is the Checks-Effects-Interactions pattern, which dictates:

• Checks: Validate all conditions and inputs.
• Effects: Update all internal contract state.
• Interactions: Make external calls to other contracts or addresses. This order ensures state is finalized before any external interaction that could trigger a reentrant call.

The critical importance of reentrancy guards was demonstrated by The DAO hack in 2016, which led to the loss of 3.6 million ETH and caused the Ethereum chain to split (hard fork). The exploit occurred because the vulnerable contract sent ETH to an attacker's contract before updating its internal balance state. The attacker's contract had a fallback function that recursively called back into the vulnerable withdraw function, draining funds in a loop. This event is the canonical example of a reentrancy attack and directly led to the development of the reentrancy guard pattern.

While the nonReentrant modifier protects against single-function reentrancy, developers must guard against more sophisticated variants:

• Cross-function Reentrancy: An attacker re-enters a different function that shares state with the vulnerable one. Protection requires guarding all functions that share critical state.
• Read-Only Reentrancy: An attacker exploits a protocol's view of another protocol's state during a callback, before that state is updated. This requires careful design of oracle and price feed integrations.
• Delegatecall Reentrancy: In proxy or upgradeable contract patterns, ensuring guards are in the correct implementation context.

Reentrancy protection is embedded throughout the smart contract toolchain:

• Static Analysis: Security tools like Slither and MythX automatically detect potential reentrancy vulnerabilities by analyzing control flow and state changes.
• Testing Frameworks: Developers write specific unit tests (e.g., in Foundry or Hardhat) simulating an attacker contract to verify guard effectiveness.
• Formal Verification: High-assurance systems use tools to mathematically prove the absence of reentrancy under all conditions.
• Audit Checklists: Reentrancy is a top-tier item on every smart contract security audit report.

Implementing a guard has a minor gas cost for setting and clearing the lock, which is negligible compared to the security benefit. Best practices include:

• Apply Guards Judiciously: Use the nonReentrant modifier on any function that makes an external call and modifies state. Avoid using it on view or pure functions.
• Combine with CEI: Always follow the Checks-Effects-Interactions pattern even when using a guard, as it provides defense-in-depth.
• Clear Documentation: Comment why a guard is applied to a specific function for future maintainers.
• Regular Updates: Keep imported library versions (like OpenZeppelin) up-to-date to benefit from security improvements.

A foundational design pattern to prevent reentrancy by structuring function logic in a specific order:

• Checks: Validate all conditions and inputs first.
• Effects: Update the contract's internal state before making external calls.
• Interactions: Perform external calls to other contracts or addresses last. This ensures state is finalized before any potential re-entry, making it a manual alternative to a guard.

A key architectural choice for mitigating reentrancy risk:

• Push Payments: The contract actively sends funds (e.g., transfer, send, call). This is vulnerable if state isn't updated first.
• Pull Payments: Users withdraw funds themselves from the contract using a separate function. The contract only updates an internal balance ledger, separating the state change from the transfer. This pattern, used by many protocols, significantly reduces attack surface.

An advanced attack where a malicious contract re-enters a different function in the victim contract, not the same one.

• Vulnerability: Occurs when two or more functions share state (e.g., a shared balance variable) and one function lacks protection.
• Defense: The nonReentrant modifier from libraries like OpenZeppelin often protects against this by using a single, contract-wide lock, not a per-function lock.

The historic event that made reentrancy attacks infamous and led to the Ethereum hard fork.

• Mechanism: The attacker's fallback function recursively called the vulnerable splitDAO function before the contract's internal balance was updated.
• Impact: Drained 3.6 million ETH, demonstrating the catastrophic financial consequences of this vulnerability.
• Legacy: Cemented reentrancy guards and the Checks-Effects-Interactions pattern as mandatory security practices.

In early Ethereum, the transfer and send functions had a fixed gas stipend of 2300 gas. This acted as a weak reentrancy guard by limiting the computational work an attacker's fallback function could perform, often preventing complex reentrant logic. With the removal of this stipend in later network upgrades (e.g., EIP-1884), this implicit protection vanished, making explicit guards like ReentrancyGuard even more critical.