Introduction

When developers first learn Solidity, they quickly encounter the "big four" function call types: call, staticcall, delegatecall, and callcode. Most tutorials gloss over delegatecall with a simple warning: "it's dangerous, avoid it unless you know what you're doing." But here's the secret that separates intermediate developers from experts: delegatecall isn't just dangerous—it's the architectural foundation of some of the most innovative patterns in Web3, from upgradeable proxies to modular smart contracts.

What Makes Delegatecall Different?

When you use call, the receiving contract executes code in its own context. Its state variables, msg.sender, and msg.value all refer to that contract's state.

But delegatecall is different. It's like saying: "Execute this code, but pretend you're still me. Use MY state variables. Treat MY caller as the true msg.sender."

// In Contract A
delegatecall(targetContract.code);

The key insight that most developers miss: the storage layout remains the same. Contract A's storage slots are preserved, even though you're executing Contract B's bytecode.

The Proxy Pattern: Architecture Innovation

This quirk is the magic behind the Proxy Pattern, which solved Ethereum's immutability problem:

// PROXY CONTRACT
pragma solidity ^0.8.0;

contract Proxy {
    address public implementation;
    address public admin;
    
    constructor(address _implementation) {
        implementation = _implementation;
        admin = msg.sender;
    }
    
    fallback() external payable {
        (bool success,) = implementation.delegatecall(msg.data);
        require(success);
    }
    
    function upgrade(address newImplementation) external {
        require(msg.sender == admin);
        implementation = newImplementation;
    }
}

// IMPLEMENTATION V1
contract LogicV1 {
    uint256 public counter;
    
    function increment() external {
        counter++;
    }
}

// IMPLEMENTATION V2
contract LogicV2 {
    uint256 public counter;
    
    function increment() external {
        counter += 2; // Enhanced logic!
    }
}

Users interact with the Proxy. The Proxy delegates calls to Logic contracts. When you upgrade to LogicV2, the counter's value persists because it's stored in the Proxy's contract storage, not the Logic contract's storage.

This is why upgradeable smart contracts exist on Ethereum. Without delegatecall, you couldn't separate code from state.

The Lesser-Known Detail: Storage Collision Vulnerability

Here's where it gets interesting. Because delegatecall uses the caller's storage, there's a critical vulnerability that catches developers off-guard:

// PROXY
contract Proxy {
    address implementation;  // Slot 0
    address admin;           // Slot 1
}

// LOGIC (BROKEN)
contract Logic {
    address owner;           // Slot 0 - COLLISION!
    
    function setOwner(address newOwner) external {
        owner = newOwner;    // Actually modifies Proxy's implementation!
    }
}

If the Proxy and Logic contracts have misaligned storage layouts, the Logic contract can accidentally—or maliciously—overwrite critical Proxy state.

This is why the industry settled on the UUPS (Upgradeable Universal Proxy Standard) and Transparent Proxy Pattern, where careful storage layout is maintained.

The Mind-Bending Fact

Here's the part that blows most developers' minds: delegatecall changes what this means.

contract A {
    function whoAmI() external view returns (address) {
        return address(this);  // Returns A's address!
    }
}

contract B {
    function callWhoAmI(address a) external {
        (bool success, bytes memory data) = a.delegatecall(
            abi.encodeWithSignature("whoAmI()")
        );
        // Returns A's address, not B's
    }
}

In a delegatecall context, address(this) still refers to the calling contract (where the state is). This creates a strange duality where the code executes in one contract's context but the storage comes from another.

Real-World Application: ERC-1967 Standard

The Ethereum community standardized delegatecall usage through ERC-1967, which defines exactly how proxies should store their implementation address:

// Implementation stored at a specific slot to avoid collisions
bytes32 private constant IMPLEMENTATION_SLOT = 
    0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

By using pseudo-random storage slots, developers ensure that Logic contracts can never accidentally overwrite critical Proxy state.

Conclusion

delegatecall transforms Solidity from a language where code is immutable into one where it's upgradeable. It's the foundation of nearly every sophisticated smart contract architecture you see in production: OpenZeppelin's Proxy Contracts, Uniswap's upgradeability systems, and countless Layer 2 solutions.

The developers who truly understand delegatecall—not just how to use it, but why it works the way it does and what dangers hide within—are the ones building the infrastructure of Web3.

The real lesson? Sometimes the most overlooked features are the most powerful.