EVM Proxies: Read the Right Source

caution

Core idea

Most production contracts are upgradeable proxies, so when you read an address on Etherscan you may be reading the proxy source rather than the implementation. Missing this layer leads to wrong findings about what a contract actually does.

Components

EIP-1967 proxies: implementation pointer stored at a fixed storage slot; Etherscan usually resolves automatically, showing both proxy and implementation.
Diamond pattern (EIP-2535): multiple “facets” implement different functions; inspect via the facets() view function.
Minimal proxies (EIP-1167 clones): 45-byte bytecode pointing at a shared implementation; read the implementation for behaviour.

When to use

Whenever analysing what a contract does before drawing a conclusion, always verify whether the address is a proxy and locate the real implementation.

Avoid when

Do not state findings about a contract’s behaviour from proxy source alone; read the implementation (or facets) or your conclusion may be wrong.

Example

An address appears benign on Etherscan, but it is an EIP-1967 proxy whose implementation holds the actual drainer logic, only reading the implementation reveals it.

EVM Event Logs & Decoding Calldata, Reading an EVM Transaction, ERC-20 Approvals: The Forgotten Attack Surface