Trace a proxy contract to its implementation and admin

Practical guide · prepared 19 September 2026. Sources were checked for this workflow; linked interfaces and policies can change. Research scope.

The address users call may not contain the rules

A proxy can hold balances and state while forwarding execution to another contract with delegatecall. Reading only the proxy's verified source can therefore miss the logic that currently runs. Begin with the exact chain and proxy address, then save the block number at which you are researching it. Implementation and admin addresses can change, so an undated screenshot is weak evidence.

Read the standard slots directly

For an ERC-1967-style proxy, query storage slot 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc. The final 20 bytes normally hold the implementation address. If it is zero, query the beacon slot 0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50; if populated, call the beacon's implementation(). Query the admin slot 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103 as well. An explorer's 'Read as Proxy' view is convenient, but a direct eth_getStorageAt read makes the result reproducible.

Next, inspect bytecode and verified source for the resolved implementation. For a UUPS proxy, upgrade authorization lives in the implementation; for a transparent proxy, an admin or ProxyAdmin controls upgrades; for a beacon, one beacon can redirect several proxies. OpenZeppelin's documentation distinguishes these patterns. The storage-slot result names a control path, not the humans behind it.

Follow control until it stops

1. Search proxy logs for Upgraded, BeaconUpgraded and AdminChanged; record addresses and blocks.
2. If the admin is a contract, identify whether it is a multisig, timelock, governor or another proxy.
3. For a multisig, record threshold and owner set. For a timelock, record the enforced delay and who can propose, cancel and execute.
4. Compare the current implementation's deployment or commit with the version covered by documentation and audits using the audit-scope workflow.

This turns the general upgrade-key concern in the rollup risk note into a repeatable inspection.

Repeat the slot reads at an earlier block when the RPC endpoint supports historical state. That cross-check can tie an Upgraded event to an actual before-and-after implementation value and expose a quiet admin rotation. Record the queried block and RPC method so another reader can reproduce the result. If archive state is unavailable, preserve the event evidence and mark the historical slot comparison unavailable rather than assuming continuity.

Hypothetical example and stop condition

Hypothetical: proxy 0xP… points to implementation 0xI2…. An explorer highlights an audit for 0xI1…. The admin slot points to 0xA…, a two-of-three multisig, with no timelock found. The supported conclusion is that current logic differs from the audited implementation and two listed signers can authorize an upgrade. It is not evidence that they will misuse that power.

If standard slots are empty, do not declare the contract immutable. It may use a diamond, clone, custom dispatcher or non-standard storage. Inspect runtime bytecode for forwarding behavior and project deployment records, or mark the pattern unresolved. Verification, a high signer count and a timelock reduce different risks; none proves bug-free code or benevolent governance.