Delegatecall

The defining feature of delegatecall is that it executes the code of the target contract within the context of the calling contract. This means:

• Storage, msg.sender, and msg.value remain those of the original caller.
• The target contract's code acts as if it were part of the caller, enabling upgradeable contract patterns and library usage.
• It is the mechanism behind proxy contracts, where logic is separated from storage.

Delegatecall is one of three primary call operations in the EVM, each with distinct state-change permissions:

• call: Executes code in another contract's context. Can modify that contract's storage and transfer value.
• staticcall: A read-only call. Guarantees no state modification (introduced in EIP-214).
• delegatecall: Executes another contract's code but writes to the caller's storage. Cannot transfer native value (msg.value is preserved but cannot be sent).

Using delegatecall introduces critical security considerations:

• Storage Layout Collisions: The calling and target contracts must have identical storage variable layouts; mismatches can corrupt storage.
• Self-Destruct Vulnerability: If the target contract contains a selfdestruct opcode, it will destroy the caller contract, not itself.
• Delegatecall Proxy Pattern: This pattern, while enabling upgrades, concentrates trust in the logic contract and requires rigorous initialization guards.

The most significant application of delegatecall is in upgradeable proxy contracts. The system comprises:

• Proxy Contract: Holds all storage and user funds. Uses delegatecall to execute logic.
• Logic/Implementation Contract: Contains the business logic. Can be replaced without migrating storage.
• Proxy Admin: Controls the upgrade authorization. This pattern is foundational to major protocols like OpenZeppelin's UUPS and Transparent Proxy standards.

Delegatecall enables the creation of library contracts that provide reusable functions. Unlike regular internal libraries, these are deployed once and called by many contracts.

• Gas Efficiency: Code is deployed once, reducing deployment costs for users.
• Example: The canonical LibString or SafeMath (pre-Solidity 0.8) libraries use delegatecall to perform operations like string manipulation or safe arithmetic on the caller's data.
• The library contract must be deliberately written for delegatecall, typically using library keyword and internal functions.

When delegatecall is invoked, the EVM performs a specific sequence:

1. Context Load: The current msg.sender, msg.value, and storage pointers are preserved.
2. Code Execution: Jumps to the code at the target contract address and executes it.
3. State Modification: All storage writes (SSTORE) update the caller's storage slot, not the target's.
4. Return: Control returns to the caller with any return data from the executed function. The address(this) in the executed code refers to the caller.

A critical vulnerability demonstrated the dangers of delegatecall. The Parity multi-sig wallet library contract was accidentally self-destructed by a user. Because hundreds of user wallets used delegatecall to this library, they all became permanently unusable, freezing over 500,000 ETH. This incident highlighted the state context risk: a delegatecall to a compromised or self-destructed contract can brick all dependent proxies.

Using delegatecall requires strict security practices:

• Storage Layout: The calling and target contract must have identical storage layouts to prevent state corruption.
• Trusted Targets: Only delegatecall to immutable, audited contracts.
• msg.sender and msg.value: Understand that msg.sender and msg.value are preserved from the original call, which impacts access control and native token handling.
• Testing: Rigorously test upgrade paths and storage collisions.

A delegatecall executes logic in the context of the calling contract's storage. If the storage layout (variable order and types) between the calling contract and the target contract do not match exactly, it can lead to catastrophic storage collisions. This can corrupt critical state variables, such as owner addresses or token balances, because the delegatecalled function will read/write to the wrong storage slots.

• Example: A library expecting its first variable at slot 0 will instead write to the calling contract's first variable, which could be the contract owner.

This infamous 2017 exploit, resulting in a loss of over $30 million, was caused by a vulnerable delegatecall in a library contract. An attacker was able to call a public initialization function via delegatecall, making themselves the owner of the library's logic contract. Because multiple wallets delegatecalled to this library, the attacker became the owner of all dependent wallets, allowing them to drain funds. This highlights the risk of delegatecall to uninitialized or improperly permissioned logic contracts.

Unlike a regular call, delegatecall preserves the original msg.sender and msg.value. This can break access control if not carefully considered.

• A contract might use tx.origin or msg.sender checks in a function that is delegatecalled. Since the msg.sender is the original EOA or caller, not the intermediary contract, it can bypass intended permissions.
• Selfdestruct Risk: If the delegatecalled code contains a selfdestruct opcode, it will destroy the calling contract, not the target library, as the execution context is the caller's.

To safely use delegatecall, developers should enforce strict conventions and audits.

• Storage Layout Management: Use inherited storage contracts or structured storage (EIP-1967) to guarantee alignment between proxy and logic contracts.
• Validate Target Address: Only delegatecall to trusted, immutable contracts. Avoid letting users arbitrarily specify the target.
• Use Established Patterns: Rely on audited, standard upgradeability frameworks like OpenZeppelin's Transparent or UUPS proxies, which handle these risks.
• Explicit Visibility & Initializers: Mark initialization functions and protect them with initializer modifiers to prevent re-execution.

A delegatecall does not forward native value (ETH) from the caller. The msg.value in the context of the delegated code is the value sent with the original transaction to the proxy, not a value passed with the call itself. This is a critical difference from a standard call.

• Example: If a user sends 1 ETH to a proxy contract that delegatecalls to a logic contract, the logic contract's code executes as if it were the proxy, but the msg.value is 1 ETH, not a separate transfer.

The most critical aspect of delegatecall is that the executed code modifies the storage of the calling contract, not its own. The logic contract's code runs in the context of the proxy's state.

• Misconception: "The logic contract's storage is used."
• Reality: The logic contract's storage layout must align perfectly with the proxy's, or catastrophic storage collisions will occur, as the opcode uses the caller's storage slots.

The execution context (msg.sender, msg.value, block.* variables) is preserved from the original call to the proxy. The logic contract sees the original end-user (or caller) as msg.sender, not the proxy contract address.

This is why access control in upgradeable systems is often implemented in the proxy or via a dedicated function in the logic contract that checks permissions based on this preserved msg.sender.

While delegatecall is the backbone of proxy upgrade patterns (like UUPS and Transparent Proxies), it has other uses. It enables library contracts, where reusable code is deployed once and its logic is executed in the context of many different calling contracts.

• Key Difference: A library uses delegatecall to enable code reuse without copying it into every contract, while a proxy uses it to enable logic upgrades for a single contract instance.

All gas consumed by the logic executed via delegatecall is charged to the original external transaction's gas limit and payer. The proxy contract does not need its own ETH balance to pay for execution.

• Implication: Gas estimation for transactions involving proxies must account for the full execution path of the logic contract, as the gas is consumed from the top-level call.