Call and Delegatecall in Solidity

2025.11.08 · 5 min read

Solidity gives you regular function calls for most contract-to-contract interactions. But two low-level functions, call and delegatecall, let you go further. They bypass the usual function call safety checks and give you direct control over how code runs and where state is stored.

This post explains what each function does, how they differ, when to use them, and what can go wrong.

What call Does

call is a low-level function that triggers a function on another contract. The code runs in the target contract's context. That means the target contract's storage gets modified, the target's address is used as this, and any Ether sent goes to the target's balance.

Basic syntax:

1(bool success, bytes memory data) = targetAddress.call{value: amount}(
2    abi.encodeWithSignature("functionName(uint256)", argument)
3);

The function returns two values. success is true if the call worked and false if it failed. data holds the return value from the called function.

Here is a working example:

 1contract Receiver {
 2    uint256 public value;
 3
 4    function setValue(uint256 _value) public payable {
 5        value = _value;
 6    }
 7}
 8
 9contract Caller {
10    function callSetValue(address _receiver, uint256 _value) public payable {
11        (bool success, ) = _receiver.call{value: msg.value}(
12            abi.encodeWithSignature("setValue(uint256)", _value)
13        );
14        require(success, "Call failed");
15    }
16}

When Caller uses call to trigger setValue, the value variable inside Receiver gets updated. The Ether sent goes to Receiver's balance. Caller is not affected.

When to Use call

Use call in these situations:

Sending Ether to an address. It is the recommended method since transfer and send have a fixed gas stipend that can cause failures.
Interacting with a contract you do not have the interface or ABI for.
Building generic contract interactions where you need to forward all remaining gas.
Implementing proxy patterns.

1contract SendEther {
2    function sendViaCall(address payable _to) public payable {
3        (bool sent, ) = _to.call{value: msg.value}("");
4        require(sent, "Failed to send Ether");
5    }
6}

call does not revert automatically on failure. Always check the success boolean and handle failures explicitly. Ignoring it is a common source of bugs.

What delegatecall Does

delegatecall runs another contract's code inside your contract's context. The target contract provides the logic, but your contract's storage, address, and balance are used. The msg.sender and msg.value from the original transaction are also preserved.

This is the key distinction: call runs code in the target's world, while delegatecall borrows the target's code and runs it in your world.

call:
  Caller --> Target
             Target's storage is modified
             Target's address is `this`

delegatecall:
  Caller --> borrows Target's code
  Caller's storage is modified
  Caller's address is `this`

Here is a basic example:

 1contract Logic {
 2    uint256 public number;
 3
 4    function setNumber(uint256 _number) public {
 5        number = _number;
 6    }
 7}
 8
 9contract Storage {
10    uint256 public number;
11
12    function delegateSetNumber(address _logic, uint256 _number) public {
13        (bool success, ) = _logic.delegatecall(
14            abi.encodeWithSignature("setNumber(uint256)", _number)
15        );
16        require(success, "Delegatecall failed");
17    }
18}

When Storage calls delegateSetNumber, it runs Logic.setNumber using delegatecall. The number variable in Storage gets updated, not the one in Logic. The code from Logic runs, but it operates on Storage's data.

Storage Layout Must Match

This is the most important rule when using delegatecall. The calling contract and the logic contract must declare their state variables in the same order.

When delegatecall writes to number, it writes to slot 0 in storage. It does not know the variable name. It only knows the slot number.

Matching layout (correct):

 1contract A {
 2    uint256 public num;     // slot 0
 3    address public sender;  // slot 1
 4}
 5
 6contract B {
 7    uint256 public num;     // slot 0
 8    address public sender;  // slot 1
 9
10    function setVars(uint256 _num) public {
11        num = _num;
12        sender = msg.sender;
13    }
14}

Mismatched layout (dangerous):

 1contract A {
 2    address public owner;   // slot 0
 3    uint256 public value;   // slot 1
 4}
 5
 6contract B {
 7    uint256 public value;   // slot 0 -- mismatched
 8    address public owner;   // slot 1 -- mismatched
 9}

If you use delegatecall between A and B in the mismatched example, writing to value in the logic contract writes to slot 0 in A. That overwrites owner. Your storage gets corrupted silently.

Storage layout mismatch with delegatecall does not throw an error. The transaction succeeds, but the wrong variables get overwritten. This is one of the most dangerous bugs in Solidity.

The Proxy Pattern

The most common use of delegatecall in production is the upgradeable proxy pattern. The idea: users interact with a proxy contract, but the actual logic lives in a separate implementation contract. You can upgrade the contract by pointing the proxy to a new implementation, without changing the address users interact with.

 1contract Proxy {
 2    address public implementation; // slot 0
 3    uint256 public value;          // slot 1
 4
 5    constructor(address _implementation) {
 6        implementation = _implementation;
 7    }
 8
 9    fallback() external payable {
10        address impl = implementation;
11        assembly {
12            calldatacopy(0, 0, calldatasize())
13            let result := delegatecall(gas(), impl, 0, calldatasize(), 0, 0)
14            returndatacopy(0, 0, returndatasize())
15            switch result
16            case 0 { revert(0, returndatasize()) }
17            default { return(0, returndatasize()) }
18        }
19    }
20}
21
22contract Implementation {
23    address public implementation; // slot 0 -- must match Proxy
24    uint256 public value;          // slot 1 -- must match Proxy
25
26    function setValue(uint256 _value) public {
27        value = _value;
28    }
29}

Any call to Proxy that does not match a defined function falls through to the fallback, which forwards the call to Implementation using delegatecall. The proxy's storage is modified, not the implementation's.

To upgrade, deploy a new implementation contract and update implementation in the proxy. Users never need to change the address they call.

Real-world proxy patterns like OpenZeppelin's UUPS and Transparent Proxy use more sophisticated storage slot management (EIP-1967) to avoid layout collisions between proxy admin variables and logic variables.

Key Differences Side by Side

Property	call	delegatecall
`msg.sender`	Calling contract's address	Original transaction sender
`msg.value`	Value sent with the call	Original transaction value
`this`	Target contract	Calling contract
Storage modified	Target contract's storage	Calling contract's storage
Typical use	Sending Ether, generic calls	Proxy patterns, upgradeable contracts

Security: The Difference Matters

The distinction between call and delegatecall has direct security implications. Consider this:

 1contract Target {
 2    address public owner; // slot 0
 3
 4    function changeOwner(address _newOwner) public {
 5        owner = _newOwner;
 6    }
 7}
 8
 9contract Victim {
10    address public owner; // slot 0
11
12    function doCall(address _target) public {
13        // call: changes Target's owner, Victim is unaffected
14        (bool s1, ) = _target.call(
15            abi.encodeWithSignature("changeOwner(address)", address(this))
16        );
17
18        // delegatecall: changes Victim's owner, Target is unaffected
19        (bool s2, ) = _target.delegatecall(
20            abi.encodeWithSignature("changeOwner(address)", address(this))
21        );
22    }
23}

The call version modifies Target.owner. The delegatecall version modifies Victim.owner. If an attacker controls the logic contract passed to a delegatecall, they can overwrite any storage slot in your contract, including ownership and access control variables.

Never use delegatecall with an untrusted address.

Error Handling

Neither call nor delegatecall reverts automatically on failure. Both return a success boolean. If you ignore it, your contract continues executing after a failed call, which leads to subtle and hard-to-debug bugs.

 1contract ErrorHandler {
 2    function safeCall(address target) public {
 3        (bool success, bytes memory returnData) = target.call(
 4            abi.encodeWithSignature("someFunction()")
 5        );
 6
 7        if (!success) {
 8            if (returnData.length > 0) {
 9                // Bubble up the revert reason from the failed call
10                assembly {
11                    revert(add(returnData, 32), mload(returnData))
12                }
13            } else {
14                revert("Call failed without reason");
15            }
16        }
17    }
18}

The assembly block re-throws the original revert reason from the failed call. Without it, you lose the reason and get a generic error instead.

Gas Forwarding

Before Solidity 0.6.2, you had to manually specify gas when using call. Now it forwards all available gas by default. You can still override this when needed.

 1// Forwards all available gas (default since 0.6.2)
 2target.call(data);
 3
 4// Forwards all gas with Ether
 5target.call{value: 1 ether}(data);
 6
 7// Explicit gas limit
 8target.call{gas: 10000}(data);

Forwarding all gas is usually what you want. Setting an explicit gas limit can cause calls to fail if the target needs more gas than you allowed.

A Practical Pattern: MultiCall

One common real-world use of call is batching multiple contract interactions into a single transaction:

 1contract MultiCall {
 2    function multiCall(
 3        address[] calldata targets,
 4        bytes[] calldata data
 5    ) external returns (bytes[] memory) {
 6        require(targets.length == data.length, "Length mismatch");
 7
 8        bytes[] memory results = new bytes[](targets.length);
 9
10        for (uint256 i = 0; i < targets.length; i++) {
11            (bool success, bytes memory result) = targets[i].call(data[i]);
12            require(success, "Call failed");
13            results[i] = result;
14        }
15
16        return results;
17    }
18}

This pattern is used in DeFi protocols to batch reads or writes, reducing the number of round trips from the client.

Summary

Use call for standard contract interactions, sending Ether, and interacting with contracts you do not have an interface for. It runs code in the target's context and keeps your state isolated.

Use delegatecall when you need to borrow logic from another contract while keeping state in your own contract. The proxy upgrade pattern is the primary use case. When you use it, storage layout between contracts must match exactly, and the logic contract must be trusted code you control.

Both functions skip automatic revert on failure. Always check the returned success value.