Skip to article
Degrees of SatoshiFollow the connections.
SearchTrace an address
Degrees of Satoshi/ Encyclopedia

Encyclopedia Ethereum · Entry 116

Delegatecall: whose code runs, and whose storage changes?

AI-assisted research · separate automated verificationCorrections

Theme
Ethereum
Sources
4 cited records
Reading time
About 3 minutes
Automated verification
Substantive update
In this article

At a glance

Key facts

Key facts for Delegatecall: whose code runs, and whose storage changes?
FactDetailSource
CodeThe target supplies code, not a separate storage context.[1]
StateStorage writes affect the calling context.[1]
Caller informationmsg.sender and msg.value are preserved rather than replaced as in an ordinary nested call.[1]
01

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.

02

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.

03

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.

Direct answers

Questions people ask

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.

Inspect the evidence

The answer and key facts have stable claim links. These records retain the scope and qualification when reused.

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: Ethereum · data through 2026-10-02. Verification: verified · 2026-10-02T18:12:41.505Z.

Link to this claim
Code: The target supplies code, not a separate storage context.

Scope: Ethereum · data through 2026-10-02. Verification: verified · 2026-10-02T18:12:41.505Z.

Link to this claim
State: Storage writes affect the calling context.

Scope: Ethereum · data through 2026-10-02. Verification: verified · 2026-10-02T18:12:41.505Z.

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

Scope: Ethereum · data through 2026-10-02. Verification: verified · 2026-10-02T18:12:41.505Z.

Link to this claim
Revision history
  1. — First publication after primary-source research and independent automated verification.

Source register

Sources and references

Retrieval dates and locators are recorded individually.
  1. Solidity: Delegatecall and LibrariesSolidity 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 · Version / scope: Solidity 0.8.30 documentation · Retrieved: 2026-10-02T17:03:42.822ZOpen source
  2. Layout of State Variables in Storage and Transient StorageSolidity contributors

    Persistent storage slots, packing and mappings.

    Locator: Layout of State Variables; Mappings and Dynamic Arrays · Version / scope: Solidity 0.8.30 documentation · Retrieved: 2026-10-02T17:03:42.820ZOpen source
  3. Proxy contractsOpenZeppelin

    Proxy implementation slots, delegated execution and upgrade authority.

    Locator: TransparentUpgradeableProxy; UUPSUpgradeable; ERC1967Proxy · Version / scope: OpenZeppelin Contracts 5.x · Retrieved: 2026-10-02T17:03:43.024ZOpen source
  4. Geth built-in tracersGo Ethereum

    Nested EVM call traces and the distinction between tracing and top-level transactions.

    Locator: callTracer; prestateTracer · Retrieved: 2026-10-02T17:25:58.908ZOpen source
How this article was made

Research and drafting use AI assistance. A separate automated review checks claims against primary sources; no external expert or named human review is implied. Publication, substantive editing, source retrieval and verification are recorded separately. This version was independently checked by an automated reviewer on 2 October 2026.

Editorial method and corrections

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/