Reentrancy Guard

The core mechanism uses a boolean state variable (e.g., _locked, _notEntered) that acts as a mutex (mutual exclusion lock). The function checks this flag at entry, sets it to a "locked" state, executes the critical logic, and only resets the flag at the very end. This prevents any nested call from re-entering the same function path.

• Standard Implementation: Uses a modifier like nonReentrant.
• Key Property: Ensures all state changes (e.g., balance updates) are finalized before the lock is released.

While not the guard itself, this is the complementary practice a guard protects. It mandates a specific, safe order of operations within a function:

1. Checks: Validate all conditions (e.g., sufficient balance).
2. Effects: Perform all state updates first (e.g., deducting the user's internal balance).
3. Interactions: Make external calls to other contracts or addresses last.

The reentrancy guard ensures this order is enforced even if an external call attempts a recursive attack.

Guards protect against two attack vectors:

• Single-Function Reentrancy: An attacker re-enters the same function they just called (e.g., withdraw calling withdraw again). This is the primary target of a standard guard.
• Cross-Function Reentrancy: An attacker uses an external call from Function A to re-enter a different but state-sharing Function B (e.g., withdraw -> transfer). A standard guard on each function may not prevent this, requiring more sophisticated design using a single lock for multiple functions.

A basic guard is not a silver bullet. Key limitations include:

• Read-Only Reentrancy: An attack that doesn't re-enter the vault contract but exploits other protocols that read the vault's intermediate, inconsistent state via on-chain price oracles.
• Cross-Contract State Assumptions: If Contract A's guard is lifted before it updates a shared state in Contract B, an attack may still be possible.
• Delegatecall & CREATE2: Advanced attacks can bypass guards using low-level calls and contract creation tricks, requiring deeper security audits.

The necessity of reentrancy guards was catastrophically demonstrated by The DAO hack in 2016, which led to the loss of 3.6 million ETH and the Ethereum network's hard fork.

• Vulnerability: The DAO's splitDAO function performed an external call to send ETH before updating the user's internal token balance.
• Attack: The attacker's fallback function recursively called splitDAO, draining funds in a loop before the balance was ever deducted.
• Legacy: This event is the canonical case study that made the Checks-Effects-Interactions pattern and reentrancy guards fundamental to smart contract security.

A reentrancy attack occurs when a function makes an external call to an untrusted contract before updating its own internal state. The attacker's contract uses the fallback or receive function to call back into the original function, exploiting the unchanged state to withdraw assets multiple times. The infamous DAO hack in 2016, which resulted in the loss of 3.6 million ETH, was a classic example of this exploit.

This is the foundational coding practice that prevents reentrancy without a dedicated guard. Developers must strictly order operations:

• Checks: Validate all conditions (e.g., balances, permissions).
• Effects: Update all internal state variables (e.g., deducting a balance).
• Interactions: Perform external calls (e.g., transferring ETH or tokens). By updating state before the external call, subsequent reentrant calls will fail the initial checks.

While effective, guards add a small gas overhead for storing and checking the lock state. Best practices include:

• Applying the nonReentrant modifier only to functions that perform external calls.
• Using the Checks-Effects-Interactions pattern as a primary defense, with the guard as a secondary safety net.
• Being aware that reentrancy guards do not protect against cross-function reentrancy, where an attacker re-enters a different function; this requires careful architectural design.

Reentrancy detection is a top priority for smart contract security tools and auditors. Static analyzers like Slither and MythX flag potential vulnerable patterns. Formal verification tools can prove the absence of reentrancy. Manual audit reports consistently list reentrancy as a critical finding, and its prevention is considered a baseline requirement for any contract handling value.

The most famous reentrancy attack, which led to the theft of 3.6 million ETH and the Ethereum hard fork. The attacker exploited a vulnerable withdraw function in The DAO's smart contract. The flaw allowed the malicious contract's fallback function to recursively call withdraw before the contract's internal balance was updated, draining funds in a loop. This event is the primary historical catalyst for the widespread adoption of reentrancy guards.

A code ordering principle that is a logical, non-library defense against reentrancy. Developers structure functions in this strict sequence:

1. Checks: Validate all conditions and inputs (e.g., balances, permissions).
2. Effects: Update all internal state variables before any external calls.
3. Interactions: Perform external calls to other contracts or addresses. By updating state before interacting with external contracts, any reentrant call will see the updated state (e.g., a zero balance), making the attack ineffective.

A design pattern that mitigates reentrancy risk by shifting the responsibility for fund transfers.

• Push Payments: The contract actively sends funds (e.g., transfer). This is risky if done before state updates.
• Pull Payments: The contract tracks owed amounts in a mapping and allows users to withdraw their allocated funds via a separate function. This separates the logic that determines the owed amount from the actual transfer, making reentrancy attacks far more difficult as the attacker cannot re-enter the core logic.

Standard reentrancy guards are not a silver bullet. Advanced attack vectors include:

• Cross-function Reentrancy: Re-entering a different function that shares state with the vulnerable one.
• Read-Only Reentrancy: Exploiting a protocol that reads another protocol's state mid-transaction, where that state is temporarily inconsistent due to a reentrant call elsewhere. Defenses require careful state isolation and using reentrancy locks that span an entire transaction or protocol module.

The Checks-Effects-Interactions (CEI) pattern is a fundamental secure coding practice that prevents 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 changes are finalized before any potential reentrant callback, making the state "unfavorable" for an attacker.

The Pull Payment pattern mitigates reentrancy by separating the logic of entitlement from the transfer of funds. Instead of a contract actively "pushing" funds to a recipient (which can trigger a callback), it allows users to "pull" their entitled funds via a separate function.

• The contract records a user's withdrawal allowance in its state.
• A user calls a withdraw() function to claim their balance. This pattern removes the external call from the core logic flow, eliminating a key attack vector.

A function modifier is a reusable piece of code that can be attached to functions to change their behavior. In the context of reentrancy, a nonReentrant modifier is the standard implementation of a reentrancy guard.

• It uses a boolean state variable (e.g., locked) that is set to true on entry and false on exit.
• Any reentrant call will fail the initial check, reverting the transaction.
• This is the mechanism used by OpenZeppelin's popular ReentrancyGuard contract.

The DAO Hack in 2016 was a seminal event that demonstrated the catastrophic impact of a reentrancy vulnerability. An attacker exploited a flaw in The DAO's splitDAO function.

• The function sent Ether to the attacker before updating its internal token balance.
• The attacker's fallback function recursively called splitDAO again, draining funds in a loop.
• This resulted in the loss of 3.6 million ETH, leading to the Ethereum hard fork that created Ethereum Classic (ETC).

Understanding state variables and gas is crucial for reentrancy. The attack relies on manipulating the order of state changes.

• State Variables: Persistent storage on the blockchain (like balances). Changing them costs gas.
• Gas Limits: Each transaction has a gas limit. Complex reentrant loops can hit this limit, which acts as a secondary, unreliable defense.
• Gas Stipends: A fixed 2300 gas is forwarded with .transfer() and .send(), which is often insufficient for a malicious callback to perform meaningful state changes, making these methods safer than .call{value:}().

Cross-function reentrancy is a more subtle variant where an attacker re-enters a different function in the same contract that shares state with the vulnerable function.

• Example: Function A updates state X and makes an unsafe call. Function B also reads/uses state X.
• An attacker's callback invokes Function B, which operates on the not-yet-updated state X, leading to inconsistencies.
• A simple nonReentrant guard on Function A may not protect Function B. Defense requires careful state management or guarding all related functions.