# Delegatecall: whose code runs, and whose storage changes?

DELEGATECALL executes code from another address in the calling contract’s context. Storage, address and balance remain those of the caller, while msg.sender and msg.value are preserved from that context. This enables proxies and libraries, but delegated code can act on the caller’s state with substantial authority.

Evidence: [Solidity: Delegatecall and Libraries](https://docs.soliditylang.org/en/v0.8.30/introduction-to-smart-contracts.html)

Canonical: https://degreesofsatoshi.com/encyclopedia/delegatecall-explained/
Published: 2026-10-02
Substantively modified: 2026-10-02
Independently verified by an automated reviewer: 2026-10-02T18:12:41.505Z
Data current through: 2026-10-02

AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied.

## Key facts

- **Code:** The target supplies code, not a separate storage context. ([Solidity: Delegatecall and Libraries](https://docs.soliditylang.org/en/v0.8.30/introduction-to-smart-contracts.html))
- **State:** Storage writes affect the calling context. ([Solidity: Delegatecall and Libraries](https://docs.soliditylang.org/en/v0.8.30/introduction-to-smart-contracts.html))
- **Caller information:** msg.sender and msg.value are preserved rather than replaced as in an ordinary nested call. ([Solidity: Delegatecall and Libraries](https://docs.soliditylang.org/en/v0.8.30/introduction-to-smart-contracts.html))

## One instruction changes which storage is edited

Suppose a proxy delegates to logic that writes an owner field. That write changes the proxy’s storage slot under the implementation’s layout assumptions. It does not simply edit an independent owner field at the implementation address.

If layouts disagree, a write intended for one variable can corrupt another. This is a code-and-state compatibility issue, not merely a display problem.

Evidence: [Solidity: Delegatecall and Libraries](https://docs.soliditylang.org/en/v0.8.30/introduction-to-smart-contracts.html); [Layout of State Variables in Storage and Transient Storage](https://docs.soliditylang.org/en/v0.8.30/internals/layout_in_storage.html)

## Choosing code can amount to choosing policy

An authority that can select a new delegated implementation may change transfer rules, permissions and asset-handling behavior within the design’s constraints.

The security boundary includes the implementation-selection mechanism. Reviewing only the currently selected logic leaves future authorized changes out of the analysis.

Evidence: [Proxy contracts](https://docs.openzeppelin.com/contracts/5.x/api/proxy)

## Read delegated calls differently from ordinary calls

A trace labels DELEGATECALL separately because its target identifies the code source. It should not automatically be read as an ETH payment to that target.

To understand the outcome, follow storage context, call type and any subsequent external calls. The presence of a target address alone is insufficient.

Evidence: [Geth built-in tracers](https://geth.ethereum.org/docs/developers/evm-tracing/built-in-tracers); [Solidity: Delegatecall and Libraries](https://docs.soliditylang.org/en/v0.8.30/introduction-to-smart-contracts.html)

## Questions

### Is delegatecall always a vulnerability?

No. It is an intentional EVM mechanism used by libraries and proxies. Its safety depends on trusted code selection, compatible storage and correctly enforced authority.

Evidence: [Solidity: Delegatecall and Libraries](https://docs.soliditylang.org/en/v0.8.30/introduction-to-smart-contracts.html); [Proxy contracts](https://docs.openzeppelin.com/contracts/5.x/api/proxy)

## Claims and scope

### delegatecall-explained-quick-answer

DELEGATECALL executes code from another address in the calling contract’s context. Storage, address and balance remain those of the caller, while msg.sender and msg.value are preserved from that context. This enables proxies and libraries, but delegated code can act on the caller’s state with substantial authority.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

### delegatecall-explained-fact-code

Code: The target supplies code, not a separate storage context.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

### delegatecall-explained-fact-state

State: Storage writes affect the calling context.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

### delegatecall-explained-fact-caller-information

Caller information: msg.sender and msg.value are preserved rather than replaced as in an ordinary nested call.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

## Sources

- [Solidity: Delegatecall and Libraries](https://docs.soliditylang.org/en/v0.8.30/introduction-to-smart-contracts.html) — Solidity contributors. Execution uses another contract’s code in the caller’s context and storage. Locator: Delegatecall and Libraries; Storage, Memory and the Stack; Logs; Message Calls. Retrieved: 2026-10-02T17:03:42.822Z.
- [Layout of State Variables in Storage and Transient Storage](https://docs.soliditylang.org/en/v0.8.30/internals/layout_in_storage.html) — Solidity contributors. Persistent storage slots, packing and mappings. Locator: Layout of State Variables; Mappings and Dynamic Arrays. Retrieved: 2026-10-02T17:03:42.820Z.
- [Proxy contracts](https://docs.openzeppelin.com/contracts/5.x/api/proxy) — OpenZeppelin. Proxy implementation slots, delegated execution and upgrade authority. Locator: TransparentUpgradeableProxy; UUPSUpgradeable; ERC1967Proxy. Retrieved: 2026-10-02T17:03:43.024Z.
- [Geth built-in tracers](https://geth.ethereum.org/docs/developers/evm-tracing/built-in-tracers) — Go Ethereum. Nested EVM call traces and the distinction between tracing and top-level transactions. Locator: callTracer; prestateTracer. Retrieved: 2026-10-02T17:25:58.908Z.

## Revision history

- 2026-10-02: First publication after primary-source research and independent automated verification.

## Cite this entry

Degrees of Satoshi editorial project. “Delegatecall: whose code runs, and whose storage changes?.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/delegatecall-explained/