EVM Threat Models

0xF4-DELEGATECALL

22 min read

Opcode Summary

PropertyValue
Opcode0xF4
MnemonicDELEGATECALL
Gasaccess_cost + mem_expansion_cost (100 warm / 2600 cold for target address, plus memory expansion for args and return data, plus gas sent to callee)
Stack Inputgas, addr, argsOffset, argsLength, retOffset, retLength
Stack Outputsuccess (1 if the call succeeded, 0 if it reverted or failed)
BehaviorExecutes the code at addr in the caller’s context: the callee’s code runs against the caller’s storage, and msg.sender and msg.value are preserved from the parent frame. Unlike CALL, there is no value transfer parameter. ADDRESS inside the callee returns the caller’s address, not the callee’s. The callee can read and write the caller’s storage via SLOAD/SSTORE. Introduced in EIP-7 (Homestead, 2016) to replace the flawed CALLCODE semantics.

Threat Surface

DELEGATECALL is the foundation of every proxy pattern in the Ethereum ecosystem — Transparent Proxies, UUPS (EIP-1822), Diamond/Multi-Facet (EIP-2535), Beacon Proxies, and Minimal Proxies (EIP-1167). It enables upgradeability, shared libraries, and modular architectures by executing foreign code within the caller’s storage and identity context. This makes it THE most dangerous opcode for state corruption, storage collision, and access control bypass. Billions of dollars in TVL sit behind proxy contracts whose security depends entirely on correct DELEGATECALL usage.

The threat surface is dominated by four properties:

  1. Foreign code executes with full storage access. When contract A delegatecalls contract B, B’s code reads and writes A’s storage slots. If B’s storage layout disagrees with A’s even by a single slot, every read returns wrong data and every write silently corrupts A’s state. This is not a type error or a revert — it is silent, persistent corruption. There is no runtime check that prevents a delegatecalled contract from overwriting any storage slot in the caller, including the proxy’s admin address, implementation pointer, or any user balance.

  2. msg.sender and msg.value propagate unchanged. The callee sees the original external caller as msg.sender, not the proxy. This is the enabling property for transparent proxies, but it means any access control check in the implementation (e.g., require(msg.sender == owner)) operates on the external caller’s identity against the proxy’s storage. If the implementation’s owner slot maps to a different slot in the proxy due to storage collision, the check may pass for the wrong address or fail for the right one.

  3. The implementation contract itself is a live attack surface. Because DELEGATECALL only borrows the implementation’s code, the implementation contract also exists as a standalone contract with its own storage. If the implementation’s initialize() function was never called on the implementation itself (only on the proxy), anyone can call it directly, take ownership of the implementation, and potentially SELFDESTRUCT it — bricking every proxy that delegates to it.

  4. No value transfer parameter limits certain defenses. Unlike CALL, DELEGATECALL has no value parameter. ETH sent to the proxy remains in the proxy; the callee’s code that references msg.value sees the original transaction’s value. This means the implementation cannot independently receive ETH through the delegatecall — all ETH accounting must be done explicitly. This is correct by design but confusing when implementation code assumes msg.value corresponds to a fresh transfer.

Smart Contract Threats

T1: Storage Layout Collision Between Proxy and Implementation (Critical)

The single most common and most destructive DELEGATECALL vulnerability. When the proxy’s storage layout disagrees with the implementation’s, slot N in the proxy holds different data than what the implementation expects at slot N.

Classic scenario: A proxy stores its implementation address at slot 0. The implementation contract declares address public owner as its first state variable, which the Solidity compiler also places at slot 0. When the implementation runs via DELEGATECALL and reads owner, it actually reads the proxy’s implementation address. When it writes owner, it overwrites the proxy’s implementation pointer.

EIP-1967 mitigates but does not eliminate this. EIP-1967 standardized pseudo-random storage slots for proxy metadata (e.g., bytes32(uint256(keccak256("eip1967.proxy.implementation")) - 1)), making accidental collision with implementation variables astronomically unlikely. But:

  • Contracts that predate EIP-1967 (or don’t follow it) remain vulnerable.
  • If the implementation itself inherits from contracts with different storage ordering across upgrades, the implementation’s internal layout shifts — colliding with its own previous state.
  • Diamond proxies (EIP-2535) use multiple facets sharing one storage namespace, multiplying collision risk across every facet contract.

Real-world impact: The Audius exploit ($6M, July 2022) was caused directly by storage collision between the proxy and governance implementation. The collision allowed the attacker to bypass the initialization guard and seize governance control.

T2: Uninitialized Implementation Contract Takeover (Critical)

Proxy patterns separate deployment from initialization: the proxy is deployed, then initialize() is called through the proxy to set up the implementation’s state (owner, parameters, etc.). The implementation contract itself is typically deployed without calling initialize() on its own storage.

This leaves the implementation contract in an uninitialized state. An attacker can:

  1. Call initialize() directly on the implementation contract (not through the proxy)
  2. Set themselves as the owner/admin of the implementation
  3. Call upgradeToAndCall() (UUPS pattern) on the implementation, delegatecalling into a contract containing SELFDESTRUCT
  4. The implementation is destroyed; all proxies pointing to it are bricked forever

Why UUPS is especially vulnerable: In Transparent Proxy patterns, the upgrade function lives in the proxy, so calling it on the implementation has no effect. In UUPS (EIP-1822), the upgrade function lives in the implementation itself. Once the attacker owns the implementation, they have full upgrade authority on it — including the ability to self-destruct it via upgradeToAndCall.

CVE-2021-41264 (CVSS 9.8): OpenZeppelin disclosed this exact vulnerability in their UUPSUpgradeable contract (versions 4.1.0-4.3.1). The iosiro security team reported preventing over 44M) and Rivermen NFT (~$6.95M). OpenZeppelin released patch 4.3.2 and ran remediation scripts for 170 contracts across multiple chains.

**Wormhole 10M bug bounty — the largest in DeFi history at the time.

T3: msg.sender and msg.value Preservation Enabling Phishing and Confused Deputy (High)

DELEGATECALL preserves msg.sender and msg.value from the parent context. This is essential for proxy transparency but creates a category of confused-deputy attacks:

  • Phishing via malicious implementation. If a proxy can be pointed at an attacker-controlled implementation (via upgrade takeover or governance exploit), the implementation sees the real user as msg.sender. It can call transferFrom(msg.sender, attacker, balance) on any token the user has approved to the proxy, because the proxy’s address is the one with approvals — and DELEGATECALL executes as the proxy.

  • msg.value double-spend in multicall. When a proxy implements multicall() using internal delegatecall, each subcall sees the same msg.value. An attacker can deposit ETH once but trigger multiple deposit functions in a single multicall, each seeing the full msg.value. This affected Sushiswap’s RouteProcessor2 in April 2023 (~$3.3M lost).

  • Library trust assumptions. A library designed to be delegatecalled may assume msg.sender is the user, but if the library is called from another intermediary contract, msg.sender is the intermediary, not the original user. The library may grant the intermediary’s permissions to an unintended party.

T4: Delegatecall to Untrusted or Arbitrary Code (Critical)

If user input can influence the addr parameter of DELEGATECALL, the attacker gains arbitrary code execution in the caller’s storage context. This is equivalent to arbitrary write access to every storage slot.

// CATASTROPHIC: user controls delegatecall target
function execute(address target, bytes calldata data) external {
    (bool success,) = target.delegatecall(data);
    require(success);
}

An attacker provides a target whose code writes the attacker’s address to the proxy’s owner storage slot, then drains all assets. There is no recovery from this — the attacker has full control of the contract’s state.

Why it matters: This is not a theoretical concern. The Parity Wallet library contract had a public function that delegatecalled user-supplied addresses. The attacker used this to set themselves as the wallet owner and drain funds.

T5: Function Selector Clashing Between Proxy and Implementation (Medium)

When a proxy contract defines admin functions (e.g., upgradeTo(address)), those function selectors may collide with selectors in the implementation contract. Solidity’s function selector is the first 4 bytes of keccak256(signature) — with only 2^32 possible values, collisions are rare but possible, and can be manufactured intentionally.

CVE-2023-30541: OpenZeppelin’s TransparentUpgradeableProxy (versions 3.2.0-4.8.2) had a vulnerability where clashing selectors caused the proxy’s ABI decoder to fail before the ifAdmin modifier could route the call, making the implementation function inaccessible through the proxy. Patched in 4.8.3.

Transparent Proxy pattern mitigation: The Transparent Proxy (EIP-1967) solves selector clashing by routing all admin calls through a separate ProxyAdmin contract. If msg.sender == admin, the proxy handles the call locally (upgrade functions). If msg.sender != admin, all calls delegate to the implementation. This eliminates selector ambiguity but adds gas overhead (extra CALLER check on every call) and means the admin can never interact with the implementation directly.

Diamond proxies amplify this risk: EIP-2535 Diamond Proxies route calls to different facets based on selectors. If two facets register the same selector, the second registration silently overwrites the first. Selector management becomes a governance-critical operation.

Protocol-Level Threats

P1: 63/64 Gas Forwarding Rule (Medium)

EIP-150 (Tangerine Whistle, 2016) stipulates that a CALL-family opcode (including DELEGATECALL) forwards at most 63/64 of the remaining gas to the callee, retaining 1/64 for post-call execution. For deeply nested delegatecall chains (e.g., Diamond proxies routing through multiple facets), gas attenuation compounds:

  • Depth 1: callee receives 63/64 * gas_available
  • Depth 2: callee receives (63/64)^2 * gas_available
  • Depth 10: callee receives (63/64)^10 ≈ 85.5% of original gas

If a delegatecalled implementation makes further external calls that rely on receiving a minimum gas amount (e.g., for ERC-20 transfers or callback execution), the 1/64 retention at each level may cause the innermost call to run out of gas unexpectedly. The delegatecall returns success = 0, but the proxy may not check this, silently swallowing the failure.

P2: Cold/Warm Access Pricing (Low)

DELEGATECALL to a cold address costs 2600 gas (EIP-2929); subsequent calls to the same address in the same transaction cost 100 gas. For standard proxy patterns where the implementation address is called on every transaction, the first transaction touching the proxy in a block pays the cold access cost. This is well-understood and correctly priced. The risk is in contracts that delegatecall to dynamically determined addresses (e.g., Diamond proxy facet lookup) where many cold addresses may be touched in a single transaction.

P3: Return Data Handling (Low)

After DELEGATECALL, the return data from the callee is written to the caller’s memory at [retOffset, retOffset + retLength). If retLength is smaller than the actual return data, the data is truncated silently. If the proxy’s fallback function incorrectly sizes the return buffer, callers receive truncated or zero-padded data. Most modern proxy implementations use assembly { returndatacopy(0, 0, returndatasize()) } to avoid this, but legacy proxies may have hardcoded return sizes.

P4: DELEGATECALL Across Hard Forks (Low)

Key history:

  • EIP-7 (Homestead, 2016): Introduced DELEGATECALL to replace CALLCODE’s flawed msg.sender behavior.
  • EIP-150 (Tangerine Whistle, 2016): 63/64 gas forwarding rule; prevents gas-based griefing.
  • EIP-2929 (Berlin, 2021): Cold/warm access pricing for the target address.
  • EIP-6780 (Dencun, 2024): SELFDESTRUCT neutered (code only cleared in same-tx-as-deployment). Reduces but does not eliminate implementation destruction risk for UUPS.

DELEGATECALL semantics (storage context, msg.sender/msg.value preservation, ADDRESS returning caller) have never changed since introduction.

Edge Cases

Edge CaseBehaviorSecurity Implication
DELEGATECALL to an EOA (no code)Returns success = 1, no code executes (equivalent to STOP)Silent success; proxy appears to work but no logic runs. If the implementation is destroyed or the address is wrong, all calls “succeed” with no effect — funds can be locked permanently
DELEGATECALL to a destroyed contract (post-SELFDESTRUCT, pre-Dencun)Returns success = 1, no code executesSame as EOA case; all proxies pointing to the destroyed implementation are bricked. This is the UUPS attack endgame
DELEGATECALL to a destroyed contract (post-Dencun, EIP-6780)Code persists unless SELFDESTRUCT ran in the same tx as deploymentReduces implementation destruction risk on L1; does NOT apply to L2s that haven’t adopted EIP-6780
msg.sender inside the calleeReturns the original external caller, not the proxyAccess control in the implementation operates on the external caller’s identity; this is correct for proxies but breaks if the same contract is used both standalone and via delegatecall
msg.value inside the calleeReturns the original transaction’s ETH valueNo new ETH is transferred by DELEGATECALL; implementation code that checks msg.value sees the original value even if no ETH is being transferred at this level
ADDRESS inside the calleeReturns the proxy’s (caller’s) address, not the implementation’saddress(this) in the implementation returns the proxy address. Token approvals, self-referencing state, and event emissions all use the proxy’s identity
SLOAD/SSTORE inside the calleeReads/writes the proxy’s (caller’s) storageAny storage operation in the implementation affects the proxy’s state. Storage layout must match exactly
DELEGATECALL with gas = 0May still execute with the 2300 gas stipend on some clients; behavior is implementation-dependentNot a reliable way to limit callee execution
Nested DELEGATECALL (A → delegatecall B → delegatecall C)C runs in A’s context: A’s storage, A’s address, original msg.senderDeep nesting preserves the outermost context through all levels; gas attenuates at each level per 63/64 rule
DELEGATECALL to a precompileBehavior is undefined/client-dependent; generally returns success = 0Precompiles are not designed for delegatecall context; results are unreliable

Real-World Exploits

Exploit 1: Parity Wallet — 150M Frozen (July/November 2017)

Root cause: Public initWallet() function on a shared library contract with no re-initialization guard, combined with DELEGATECALL context preservation.

Details (July 2017): Parity’s multi-sig wallet used a two-contract architecture: a thin “Wallet” proxy that delegatecalled all function calls to a shared WalletLibrary contract. The library’s initWallet() function set the wallet’s owner based on msg.sender. Because of DELEGATECALL’s msg.sender preservation, when a user called the proxy, the library saw msg.sender as the user (not the proxy) — correct behavior for proxy patterns.

The critical flaw: initWallet() was publicly callable with no guard against re-initialization. The proxy’s fallback function blindly delegatecalled any function to the library, including initWallet(). An attacker called initWallet() through three ICO wallets (Edgeless Casino, Swarm City, æternity), setting themselves as owner, then drained 153,037 ETH (~$30M).

**November 2017 follow-up (150M) were permanently bricked. The funds remain locked to this day.

DELEGATECALL’s role: The proxy’s unconditional delegatecall(msg.data) forwarding was the attack surface. DELEGATECALL’s msg.sender preservation let the attacker become owner by calling through the proxy. The library’s destruction via SELFDESTRUCT bricked all proxies because DELEGATECALL to an empty address returns success silently.

Impact: 150M permanently frozen. This incident catalyzed the development of EIP-1967 (standardized proxy storage slots), EIP-1822 (UUPS), and the Initializable pattern.

References:

Exploit 2: Audius Governance Takeover — $6M (July 2022)

Root cause: Storage layout collision between the proxy and its governance implementation allowed an attacker to bypass the initialization guard and seize governance control.

Details: Audius used an upgradeable proxy pattern for its governance contract. A storage collision between the proxy’s variables and the implementation’s Initializable guard meant that the storage slot tracking whether initialize() had been called was overwritten by a different proxy variable. The implementation believed it was uninitialized even though the proxy had been initialized years earlier.

The attacker exploited this to call initialize() on the governance proxy, appointing themselves as the sole guardian. With guardian privileges, the attacker submitted and approved a malicious governance proposal that transferred 18.6 million AUDIO tokens (~1.08M.

DELEGATECALL’s role: DELEGATECALL’s core property — executing the implementation’s code against the proxy’s storage — is what makes storage collision possible. The implementation’s initialized flag was at one slot offset, but the proxy’s storage had a different value at that slot, so the guard always read false.

Impact: 18.6M AUDIO tokens stolen (~$6M). Audius used the same vulnerability to patch and regain control.

References:

Exploit 3: OpenZeppelin UUPS Implementation Takeover — CVE-2021-41264 ($50M+ Prevented)

Root cause: Uninitialized UUPS implementation contracts could be taken over and self-destructed, bricking all proxies.

Details: In September 2021, security researchers independently discovered that OpenZeppelin’s UUPSUpgradeable contract (versions 4.1.0-4.3.1) left the implementation contract’s initialize() function callable. The UUPS pattern places the upgrade logic (upgradeToAndCall) in the implementation, not the proxy. An attacker could:

  1. Call initialize() directly on the uninitialized implementation contract
  2. Gain upgrade authority over the implementation
  3. Call upgradeToAndCall() on the implementation, delegatecalling to a contract containing SELFDESTRUCT
  4. The implementation self-destructs; all proxies delegatecalling to it are permanently bricked

The iosiro security team reported preventing over 44M) and Rivermen NFT (~$6.95M). OpenZeppelin released patch 4.3.2 and ran remediation across 170 contracts on multiple chains. The fix: _disableInitializers() in the implementation’s constructor, which sets the initialized flag on the implementation’s own storage.

DELEGATECALL’s role: The UUPS pattern puts upgradeToAndCall in the implementation specifically so it runs via DELEGATECALL in the proxy’s context. But when called directly on the implementation, upgradeToAndCall runs in the implementation’s own context — and SELFDESTRUCT destroys the implementation’s code. All subsequent DELEGATECALL attempts from proxies hit an empty address and silently succeed with no execution.

Impact: CVE-2021-41264, CVSS 9.8 Critical. 10M bounty for the same vulnerability pattern in their bridge contract (February 2022).

References:

Exploit 4: Parity Wallet Library Destruction — $150M Permanently Frozen (November 2017)

Root cause: The shared WalletLibrary contract was itself a live contract with its own storage, and its initialization + self-destruct functions were publicly accessible.

Details: This is the second phase of the Parity incident. After the July 2017 hack was patched (by fixing re-initialization on the proxy), the underlying library contract remained uninitialized on its own storage. On November 6, 2017, a GitHub user (devops199) called initWallet() directly on the WalletLibrary contract address — not through any proxy. Because this was a direct call (not delegatecall), the library’s own storage was modified, and devops199 became the library’s owner. They then called kill(), which executed SELFDESTRUCT, destroying the library contract’s code.

Every Parity multi-sig wallet proxy delegatecalled to this single WalletLibrary address. After destruction, all DELEGATECALL instructions hit an address with no code, returning success = 1 with no execution — effectively a no-op. All 587 wallets holding approximately 513,000 ETH (~$150M at the time) were permanently frozen. No recovery mechanism existed because the proxy’s fallback function could not be upgraded.

DELEGATECALL’s role: DELEGATECALL to a codeless address returns success (equivalent to STOP). The proxies didn’t check for the implementation’s code existence before delegatecalling, so every call silently succeeded with no state changes. The wallet appeared “alive” but was completely inert.

Impact: ~$150M permanently frozen. Funds remain locked. This directly motivated EIP-1967 (proxy storage standardization) and the Initializable library pattern. Also contributed to the EIP-6780 decision to neuter SELFDESTRUCT.

References:

Attack Scenarios

Scenario A: Storage Layout Collision — Proxy Takeover

// Proxy: implementation address stored at slot 0
contract NaiveProxy {
    address public implementation; // slot 0
    address public admin;          // slot 1
 
    fallback() external payable {
        (bool s,) = implementation.delegatecall(msg.data);
        require(s);
    }
}
 
// Implementation: owner stored at slot 0 -- COLLIDES with proxy's implementation
contract ImplementationV1 {
    address public owner; // slot 0 -- reads proxy's implementation address!
 
    function initialize(address _owner) external {
        require(owner == address(0), "already initialized");
        owner = _owner; // OVERWRITES proxy's implementation pointer!
    }
 
    function withdraw() external {
        require(msg.sender == owner, "not owner");
        payable(msg.sender).transfer(address(this).balance);
    }
}
 
// Attack:
// 1. Proxy is deployed, implementation is set to ImplementationV1
// 2. initialize() is called: owner = _owner writes to slot 0
//    This OVERWRITES the proxy's implementation address!
// 3. All subsequent calls delegatecall to _owner's address
//    If _owner is the attacker, they now control all delegatecall routing

Scenario B: Uninitialized UUPS Implementation Destruction

// UUPS Implementation with upgrade logic
contract VulnerableUUPS is Initializable, UUPSUpgradeable {
    address public owner;
 
    function initialize(address _owner) external initializer {
        owner = _owner;
    }
 
    function _authorizeUpgrade(address) internal override {
        require(msg.sender == owner, "not owner");
    }
}
 
// Attack contract with SELFDESTRUCT
contract Destructor {
    function destroy() external {
        selfdestruct(payable(msg.sender));
    }
}
 
// Attack sequence:
// 1. Implementation is deployed but initialize() was only called via the proxy
// 2. Attacker calls initialize(attacker) directly on the implementation
//    -- The implementation's own storage has initialized = false
//    -- Attacker becomes owner of the IMPLEMENTATION (not the proxy)
// 3. Attacker calls upgradeToAndCall(destructor, "destroy()")
//    on the IMPLEMENTATION directly
// 4. upgradeToAndCall delegatecalls destructor.destroy()
//    SELFDESTRUCT executes in the implementation's context
//    Implementation code is destroyed
// 5. All proxies pointing to this implementation are bricked
//    delegatecall to empty address returns success with no execution

Scenario C: msg.value Reuse in Multicall via DELEGATECALL

// Vulnerable: multicall uses delegatecall, preserving msg.value
contract VulnerableRouter {
    mapping(address => uint256) public deposits;
 
    function deposit() external payable {
        deposits[msg.sender] += msg.value;
    }
 
    function multicall(bytes[] calldata calls) external payable {
        for (uint256 i = 0; i < calls.length; i++) {
            // delegatecall preserves msg.value for EACH subcall
            (bool success,) = address(this).delegatecall(calls[i]);
            require(success);
        }
    }
}
 
// Attack:
// 1. Attacker sends 1 ETH with multicall containing 10x deposit() calls
// 2. Each delegatecall subcall sees msg.value = 1 ETH
// 3. deposits[attacker] += 1 ETH is executed 10 times
// 4. Attacker's balance: 10 ETH. Actual ETH sent: 1 ETH.
// 5. Attacker withdraws 10 ETH, draining other users' deposits.

Scenario D: Delegatecall to Untrusted Address — Arbitrary State Corruption

// Vulnerable: wallet allows delegatecall to arbitrary targets
contract VulnerableWallet {
    address public owner;
    mapping(address => uint256) public balances;
 
    function execute(
        address target,
        bytes calldata data
    ) external {
        require(msg.sender == owner, "not owner");
        // DANGEROUS: delegatecall to user-supplied address
        (bool success,) = target.delegatecall(data);
        require(success);
    }
}
 
// Attacker deploys this contract
contract StorageOverwriter {
    // Matches VulnerableWallet's slot 0 layout
    address public owner;
 
    function overwrite() external {
        owner = msg.sender; // Overwrites VulnerableWallet's owner!
    }
}
 
// If the attacker can get the current owner to call:
// wallet.execute(storageOverwriter, abi.encodeWithSignature("overwrite()"))
// The delegatecall runs overwrite() in the wallet's context,
// setting the attacker as the new owner.
// Even if the owner is a multisig, a single phished signer could
// propose this as a "harmless library call."

Mitigations

ThreatMitigationImplementation
T1: Storage layout collisionUse EIP-1967 standardized storage slots for proxy metadataAll proxy admin variables stored at pseudo-random slots (e.g., keccak256("eip1967.proxy.implementation") - 1); use OpenZeppelin’s ERC1967Proxy
T1: Layout drift across upgradesStorage layout compatibility checkingUse @openzeppelin/upgrades-core with --unsafeAllow flags; Foundry’s forge inspect for layout comparison; never reorder or remove state variables in upgrades
T2: Uninitialized implementationDisable initializers on the implementation constructorCall _disableInitializers() in the implementation’s constructor; OpenZeppelin Initializable >= 4.3.2 supports this natively
T2: UUPS self-destructPrevent SELFDESTRUCT in upgrade pathPost-Dencun (EIP-6780), SELFDESTRUCT only clears code in same-tx-as-deployment; use initializer modifier + _disableInitializers()
T3: msg.value reuse in multicallDo not use delegatecall for multicall with payable functionsUse call instead of delegatecall for multicall subcalls when ETH is involved; or track msg.value consumption across subcalls
T3: Confused deputyVerify caller context explicitlyAdd onlyProxy and notDelegated modifiers to distinguish direct vs. delegated call contexts
T4: Delegatecall to untrusted codeNever delegatecall to user-supplied addressesHardcode or governance-control the implementation address; whitelist allowed targets if dynamic dispatch is required
T5: Selector clashingUse Transparent Proxy pattern or ProxyAdminTransparent Proxy routes by msg.sender == admin vs. non-admin, eliminating selector ambiguity; upgrade to OpenZeppelin >= 4.8.3
T5: Diamond selector managementEnforce selector uniqueness at registration timediamondCut() should revert if a selector is already registered to a different facet
General: Proxy brickingVerify implementation has code before delegatecallrequire(implementation.code.length > 0) in the fallback; though this adds gas cost per call
General: Defense in depthTimelocks and multi-sig on upgrade authorityUse TimelockController + Gnosis Safe for upgradeTo calls; emit events for off-chain monitoring

Compiler/EIP-Based Protections

  • EIP-1967 (2019): Standardized storage slots for proxy admin, implementation, and beacon addresses. Eliminates accidental storage collision between proxy metadata and implementation variables.
  • EIP-1822 / UUPS (2019): Moved upgrade logic into the implementation, reducing proxy bytecode size and gas costs. Requires careful initialization management.
  • EIP-2535 / Diamond (2020): Multi-facet proxy standard with selector-based routing. Powerful but complex; requires rigorous selector management and shared storage discipline.
  • EIP-6780 (Dencun, 2024): SELFDESTRUCT only clears code in the same transaction as deployment. Dramatically reduces the risk of implementation destruction attacks on L1, though L2s may not enforce this.
  • OpenZeppelin Initializable >= 4.3.2: _disableInitializers() in constructors prevents implementation takeover. initializer and reinitializer(n) modifiers enforce one-time initialization.
  • Foundry / Hardhat upgrades plugins: Automated storage layout compatibility checking catches collision bugs before deployment.

Severity Summary

Threat IDCategorySeverityLikelihoodReal-World Precedent
T1Smart ContractCriticalHighAudius ($6M, 2022), countless proxy storage bugs
T2Smart ContractCriticalHighParity (50M+ prevented), Wormhole ($10M bounty)
T3Smart ContractHighMediumSushiswap RouteProcessor2 ($3.3M, 2023), meta-transaction spoofing
T4Smart ContractCriticalMediumParity first hack ($30M stolen, 2017)
T5Smart ContractMediumLowCVE-2023-30541 (OpenZeppelin TransparentUpgradeableProxy)
P1ProtocolMediumLowGas exhaustion in deep Diamond proxy chains
P2ProtocolLowLow—
P3ProtocolLowLowLegacy proxies with hardcoded return buffer sizes
P4ProtocolLowLow—
OpcodeRelationship
CALL (0xF1)Standard external call. Sets msg.sender to the calling contract and msg.value to the specified value. Does NOT share storage context — the callee operates on its own storage. Use CALL when you want isolation; use DELEGATECALL when you want shared context.
CALLCODE (0xF2)Deprecated precursor to DELEGATECALL (pre-Homestead). Executes callee’s code in the caller’s storage context but sets msg.sender to the calling contract (not the original caller). DELEGATECALL preserves msg.sender from the parent frame, which is why it replaced CALLCODE for proxy patterns.
STATICCALL (0xFA)Read-only variant of CALL. Prevents all state modifications (SSTORE, CREATE, SELFDESTRUCT, LOG, value transfer). Cannot be used for proxy patterns that need to write state. Useful for safely querying external contracts without risking reentrancy-induced state changes.
SLOAD (0x54)Reads a 32-byte value from storage. In a DELEGATECALL context, SLOAD reads from the caller’s (proxy’s) storage, not the callee’s (implementation’s). This is the mechanism behind storage layout collision vulnerabilities.
SSTORE (0x55)Writes a 32-byte value to storage. In a DELEGATECALL context, SSTORE writes to the caller’s (proxy’s) storage. Any write by the implementation modifies the proxy’s state, making storage layout agreement between proxy and implementation absolutely critical.

Graph View

Latest updates

Backlinks