In this track: Execution traces and low-level calls
advanced · 4 MIN READ
Inspect a delegatecall trace
Track code source and state owner as separate columns.
LET’S PICTURE IT
A borrowed manual can run at your desk under your current visitor context.
SEE IT FOR YOURSELF
Pack small values into Solidity storage slotsStep 1 / 4
In this simple default-layout example, two uint128 values come before one uint256. Each slot holds thirty-two bytes.
In this simple default-layout example, two uint128 values come before one uint256. Each slot holds thirty-two bytes.The first sixteen-byte value occupies the low-order half of slot zero. Low-order bytes are shown on the right.The second uint128 fits in the remaining sixteen bytes. Both values now share slot zero.C needs a complete thirty-two-byte slot, so it begins at slot one. Two packed small values plus C use two slots.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
Identify the proxy entry
In a simple User to Proxy call, the proxy receives the immediate caller and value. Those fields provide the starting context for delegation.
Change the code source
The implementation supplies executed code during DELEGATECALL. That change does not move the application state into the implementation’s own storage.
Preserve the delegated fields
The delegated frame keeps the proxy context’s msg.sender and msg.value. A normal CALL would establish different immediate-caller behavior.
Interpret writes and logs correctly
Slot writes and emitted logs use the delegated execution’s address context. Review storage compatibility and event attribution under that context.
Follow the execution
Frame code source storage owner msg.sender
Proxy entry Proxy Proxy User
Delegated Implementation Proxy User
A local conceptual trace with explicit assumptions; this is not a trace of a live transaction.
QUICK CHECK · NO PRESSURE
Where do typical delegated proxy state writes land?