External Call Risk

This risk involves ignoring the success/failure status of low-level calls (e.g., call(), send(), delegatecall()). A failed call can be treated as successful, leading to incorrect state assumptions.

• Example: Using send() or call() without checking the return value. The send() function forwards a fixed 2300 gas stipend and returns a bool. If it fails, the transaction does not revert unless explicitly checked.
• Mitigation: Always check the return value of low-level calls, or use higher-level abstractions like transfer() (which reverts on failure) or pattern (bool success, ) = addr.call{value: x}(""); require(success);.

External calls forward a limited amount of gas, creating risks of failed executions that can leave contracts in an inconsistent state.

• Stipends: The transfer() and send() functions forward a fixed 2300 gas stipend, which is often insufficient for contracts with complex fallback functions, causing the call to fail.
• Unbounded Operations: Using call() without a gas limit on an untrusted contract can lead to gas griefing, where the callee consumes all gas, causing the entire transaction to fail.
• Best Practice: Use call() with explicit gas limits for complex interactions and design contracts to be resilient to failed external calls.

The delegatecall opcode executes code from another contract in the context (storage) of the caller. This is a powerful but extremely dangerous form of external call.

• Risk: Malicious or compromised logic called via delegatecall can arbitrarily modify the caller's storage, including owner variables and balances, leading to complete compromise.
• Context Preservation: msg.sender and msg.value are preserved, but the executed code acts on the caller's state.
• Critical Use Case: Used in upgradeable proxy patterns. The mitigation is to never delegatecall to untrusted or user-supplied addresses and to rigorously audit the implementation contract.

Interacting with an external contract invokes its fallback or receive function, which can contain malicious logic designed to exploit the caller.

• Attack Vectors: The fallback function can:
  • Execute a reentrancy attack.
  • Revert intentionally to block certain operations (e.g., in a withdrawal pattern).
  • Consume all forwarded gas to cause an out-of-gas revert.
• Defense: Assume any external call can fail or behave maliciously. Implement pull-over-push patterns for payments, where users withdraw funds themselves, removing the need for the contract to initiate transfers to untrusted addresses.

An external call can trigger a series of other calls that eventually modify state relied upon by the original function, leading to logic errors or invalid assumptions.

• Example: Calling an external token contract's transfer function may trigger a callback to the original contract (if it implements hooks like tokensReceived), potentially executing code that reads intermediate, inconsistent state.
• Related Pattern: This is a broader category that includes the Cross-Function Reentrancy attack, where a call to Contract B re-enters a different function in Contract A.
• Mitigation: Use mutex locks (reentrancy guards) and adhere strictly to the Checks-Effects-Interactions pattern across all functions that share state.

The primary defensive coding standard developed in response to reentrancy attacks like The DAO. It mandates a strict order of operations within a function:

1. Checks: Validate all conditions and inputs (e.g., require statements).
2. Effects: Update all internal state variables before making external calls.
3. Interactions: Perform external calls to other contracts or EOAs.

This pattern ensures state is finalized before interaction, eliminating simple reentrancy risk.

A widespread technical mitigation that uses a mutex lock (nonReentrant modifier) to prevent recursive calls. When a function with this modifier is entered, a boolean flag is set to true and is only cleared after execution, blocking reentry.

• Implementation: Common in libraries like OpenZeppelin's ReentrancyGuard.
• Limitation: Protects against single-function reentrancy but not against more complex cross-function or cross-contract attacks. It is a complement to, not a replacement for, the Checks-Effects-Interactions pattern.

A fundamental defensive coding pattern to prevent reentrancy and other state inconsistencies. It mandates a strict order of operations within a function:

1. Checks: Validate all conditions and inputs (e.g., balances, permissions).
2. Effects: Perform all updates to the contract's internal state (e.g., updating balances).
3. Interactions: Make external calls to other contracts or addresses last. This ensures the contract's state is in a consistent and finalized condition before any potentially dangerous interaction occurs.

A design pattern that mitigates external call risk by shifting the burden of initiating transfers. Instead of a contract pushing funds to users via transfer() or send() (which triggers external code), users pull their owed funds by calling a withdrawal function. This:

• Eliminates the contract's need to make external calls to untrusted recipients.
• Prevents failures in recipient contracts from blocking other users' transactions.
• Is a core principle behind systems like Ethereum's Withdrawal Pattern and many airdrop contracts.

External calls can fail or behave unpredictably due to gas constraints. The legacy transfer() and send() functions forward a fixed 2300 gas stipend, which is only enough for logging and is insufficient for modern contract logic, leading to failed transfers. Key considerations:

• Using call() for transfers provides more gas but reintroduces reentrancy risk.
• A recipient's fallback or receive function can execute arbitrary code, potentially consuming all forwarded gas or reverting.
• This makes gas estimation and management a critical part of handling external calls safely.

A subtle vulnerability where logic that should execute after an external call can be bypassed if that call fails or manipulates control flow. For example, a contract that increments a user's withdrawal count only after sending funds could allow unlimited withdrawals if the send fails and reverts, but the state change was incorrectly placed before it. This reinforces the Checks-Effects-Interactions pattern, ensuring all critical state changes are irreversible before any external interaction.