# delegatecall executes code from another contract using the callers storage context The `DELEGATECALL` opcode executes code from a target address while preserving the calling contract's storage, `msg.sender`, and `msg.value`. This is the foundation of all proxy patterns: the proxy holds state while the implementation provides logic. Every state write lands in the proxy's storage slots, creating the requirement that [[storage layout must remain consistent across proxy implementation versions]]. Proxy and implementation share the same function namespace, so since [[function selector clashes between proxy and implementation can shadow critical admin functions]], collisions silently shadow admin functions. The four proxy architectures (transparent, UUPS, beacon, diamond) each resolve this differently; since [[proxy architecture choice determines the tradeoff between upgrade authority concentration selector routing cost and blast radius scope]], delegatecall is the shared primitive whose tradeoffs each pattern manages. The most direct attack: since [[restricting delegatecall to pre-verified logic contracts prevents arbitrary code execution]], any path where user-supplied addresses reach delegatecall without validation grants full storage control. The [[furucombo exploit demonstrated unrestricted delegatecall enabling storage approval manipulation|Furucombo exploit]] ($14M, 2021) demonstrated this. Delegatecall also enables [[selfdestruct in implementation contracts can permanently brick proxy systems|implementation destruction]], and in CPIMP attacks, since [[double-delegation chains in CPIMP attacks forward all calls to the legitimate implementation preserving normal protocol functionality while granting hidden attacker control]], two delegatecall hops create a hidden intermediary invisible in normal operation. The same storage-sharing semantics extend beyond proxies. Since [[ERC-7579 modules executing via delegatecall in account storage context allow malicious or buggy modules to overwrite arbitrary storage slots and brick or drain the account]], delegatecall modules in modular accounts gain unrestricted storage write access. EIP-7702 extends delegatecall semantics to EOAs; since [[EIP-7702 storage collision attacks occur when migrating between delegate contracts with incompatible layouts because existing EOA storage is not cleared on re-delegation]], re-delegation without storage clearing causes type confusion identical to proxy storage collisions. Since [[the Munchables exploit demonstrated that storage slot writes during a proxy upgrade can fabricate phantom balances that survive subsequent implementation swaps]], the storage-persistence property of delegatecall enables a two-phase insider attack: write via a transient malicious implementation, then upgrade to a clean implementation that inherits the fabricated state. This persistence is the corollary stated by [[proxy contracts preserve storage values written during malicious upgrades because delegatecall reads from the proxy's own storage independently of the active implementation]]: upgrading to a clean implementation does not sanitize storage, so even a perfectly audited replacement inherits fabricated values. --- Relevant Notes: - [[storage layout must remain consistent across proxy implementation versions]]: the storage consistency requirement this creates - [[unrestricted delegatecall allowing user-specified target addresses enables fund drainage and state manipulation]]: the primary attack when targets are unvalidated - [[restricting delegatecall to pre-verified logic contracts prevents arbitrary code execution]]: the primary defensive pattern for unrestricted delegatecall - [[selfdestruct in implementation contracts can permanently brick proxy systems]]: the destruction risk for proxy targets - [[double-delegation chains in CPIMP attacks forward all calls to the legitimate implementation preserving normal protocol functionality while granting hidden attacker control]]: the attack architecture that chains two delegatecalls to create a hidden intermediary - [[function selector clashes between proxy and implementation can shadow critical admin functions]]: consequence of the shared namespace delegatecall creates - [[proxy architecture choice determines the tradeoff between upgrade authority concentration selector routing cost and blast radius scope]]: the architectural comparison of how each proxy pattern manages delegatecall tradeoffs - [[furucombo exploit demonstrated unrestricted delegatecall enabling storage approval manipulation]]: real-world exploit of unrestricted delegatecall ($14M, 2021) - [[ERC-7579 modules executing via delegatecall in account storage context allow malicious or buggy modules to overwrite arbitrary storage slots and brick or drain the account]]: delegatecall storage risk in modular account abstraction - [[EIP-7702 storage collision attacks occur when migrating between delegate contracts with incompatible layouts because existing EOA storage is not cleared on re-delegation]]: delegatecall semantics extended to EOAs via EIP-7702 - [[the Munchables exploit demonstrated that storage slot writes during a proxy upgrade can fabricate phantom balances that survive subsequent implementation swaps]]: canonical exploit of the storage-persistence property via proxy upgrade; the two-phase attack (write via malicious implementation, drain via clean implementation) demonstrates how delegatecall's implementation-agnostic storage access converts upgrade authority into a deferred balance fabrication primitive Topics: - [[evm-internals]] - [[solidity-behaviors]]