Official MASTR logo MASTR Support the work
Contents
← Wiki home

Technical reference

ERC-1967: finding the implementation behind a proxy address

The address users recognise can remain unchanged while the code they execute changes.

Source-based reference · Updated 12 September 2026

Research articles and reference entries are published in English. Navigation is available in seven languages.

In this article
  1. Three important storage locations
  2. Snapshot the code that actually ran
  3. Authority is a separate investigation
  4. Sources

Three important storage locations

ERC-1967 specifies storage locations for implementation, beacon and administrator information used by compatible proxies. These slots help tools discover delegated code without relying solely on a frontend label. A beacon-based proxy obtains its implementation through the beacon, adding another contract to inspect.

Snapshot the code that actually ran

A finding should record the chain, proxy address, block and implementation active at that block. Reviewing today's implementation against yesterday's transaction can produce a false explanation. Upgrade-related events are useful leads, but the corresponding state and executed call path matter too.

Authority is a separate investigation

Knowing the implementation does not identify every person able to replace it. Follow ownership, access-control roles, timelocks and any upgrade mechanism in the relevant contracts. The proxy standard gives a storage convention, not a guarantee of decentralised administration or an audit of the implementation. An unchanged token address is therefore not proof of unchanged behaviour.

Sources

Related reading

security

Proxy-upgrade rugs

A proxy delegates calls to implementation code replaceable by an administrator.

MASTR

Support independent research

The investigations, original evidence and guides here are free to read. Voluntary donations help fund the research and keep MASTR’s tools available.

Open wallet