# ERC-1967: Proxy Storage Slots

Source: https://www.eipsfordesigners.com/standards/ERC-1967
Agent brief: https://www.eipsfordesigners.com/standards/ERC-1967/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-1967
Last reviewed: 2026-09-18
Last updated: 2026-09-18

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Infrastructure |
| Journey stages | Infrastructure |
| Detailed guide | Yes |
| Official specification | https://ercs.ethereum.org/ERCS/erc-1967 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-1967 |

## UX Impact

Proxy metadata can help explorers resolve the implementation and expose upgrade risk. The admin slot is optional: Transparent, UUPS and beacon proxies have different authorization paths. Show the verified controlling roles or an unknown state, and never infer renounced upgrade rights from an empty admin slot.

## Summary

ERC-1967 standardizes where proxy contracts store their implementation address. This lets block explorers like Etherscan show "Read as Proxy" so users see actual functions instead of confusing wrapper code. Essential for making upgradeable contracts usable.

## For Designers

- You can design UI that delivers explorer detects proxy, shows implementation interface.
- You can standard slot, anyone can verify implementation address.
- You can standard slots: all tools work universally.

## Applicability

### When to Use

- Your product explains proxy implementations or upgrade authority.
- An explorer needs to resolve a supported proxy pattern.

### When to Avoid

- You cannot identify the proxy pattern or authorization path; show unknown instead of a safety claim.
- You need ERC-1967 alone to prove an upgrade is safe or irrevocably disabled.

## Problems It Solves

### Block explorers show proxy bytecode, not real functions

Impact: critical

Old way: User sees confusing proxy code, can't interact

New way: Explorer detects proxy, shows implementation interface

### Can't verify what code proxy is running

Impact: critical

Old way: Trust that proxy points to claimed implementation

New way: Standard slot, anyone can verify implementation address

### Different proxies store implementation differently

Impact: high

Old way: Each proxy pattern needs custom detection

New way: Standard slots: all tools work universally

### Admin address hidden or unpredictable

Impact: high

Old way: Who can upgrade this? Check code manually

New way: The optional admin slot is one clue; determine the actual authorization path for this proxy pattern

## Anti-Patterns

### Showing proxy bytecode as "contract source"

Severity: critical

Users can't understand or verify what code runs

Instead: Detect proxy, show implementation source

### Hiding admin address

Severity: critical

Users don't know who can change the contract

Instead: Show the actual upgrade authority and permissions, including implementation or beacon roles

### No upgrade notifications

Severity: high

Users surprised by changed behavior

Instead: Notify users when implementation changes

### Single EOA as admin

Severity: high

One compromised key = protocol compromised

Instead: Show warning when admin is single address

### Not linking to implementation on explorer

Severity: medium

User can't verify the actual code

Instead: Always provide clickable link to implementation

## UI Components

### ProxyBanner

Banner indicating contract is a proxy
States: proxy-detected, not-proxy, unknown
Props: implementationAddress, adminAddress, proxyType

### ImplementationViewer

Shows what implementation proxy points to
States: loading, verified, unverified, error
Props: proxyAddress, implementationAddress, isVerified

### AdminAnalyzer

Analyzes who controls proxy upgrades
States: eoa, multisig, timelock, verified-no-upgrade-path, unknown
Props: adminAddress, adminType, signers[], timelockDuration

### UpgradeNotification

Alert showing contract was upgraded
States: pending, executed, cancelled
Props: oldImplementation, newImplementation, changelog

### ProxyReadWrite

Interface for interacting via proxy
States: loading, ready, submitting
Props: proxyAddress, abiFromImplementation, onCall

## Key Takeaways

- ERC-1967 = standardized storage for proxy info
- Enables "Read as Proxy" on block explorers
- Show the resolved implementation and actual upgrade authority; disclose unknowns
- Warn users about admin trust assumptions
- Notify on upgrades so users aren't surprised

## UX Patterns

### Block Explorer Proxy View

Etherscan "Read as Proxy" interface

User flow:

- User visits proxy contract on explorer
- Sees "This is a Proxy Contract" banner
- Views implementation address
- Sees the verified upgrade authority for this proxy pattern, or an unknown state
- Clicks "Read as Proxy" for real functions
- Interacts with actual interface

Mockup registry key: `generic/token-approval` (React UI on the live standard page).

### Contract Upgrade Notice

Inform users about proxy upgrade

User flow:

- Protocol upgrades implementation
- Users notified of change
- See what changed (new features/fixes)
- Review the new implementation, authority and potential effect on assets
- Can verify upgrade transaction

Mockup registry key: `concept/permit-approval` (React UI on the live standard page).

### Proxy Trust Verification

Help users verify proxy safety

User flow:

- User pastes contract address
- System detects ERC-1967 proxy
- Fetches implementation from standard slot
- Checks verification and audit status
- Identifies Transparent, UUPS or beacon authorization and verifies the controlling roles
- Shows overall risk assessment

Mockup registry key: `concept/verify-safety` (React UI on the live standard page).

### Upgrade Governance

Admin interface for proposing upgrades

User flow:

- Admin enters new implementation address
- System runs verification checks
- Warns about missing requirements
- Admin proposes upgrade
- Other signers approve
- Timelock countdown begins
- Upgrade executes after delay

Mockup registry key: `concept/proxy-pattern` (React UI on the live standard page).

## Technical Notes

ERC-1967 defines implementation, beacon and optional admin storage slots. Resolve a beacon proxy through its beacon to find the implementation. An admin slot can describe Transparent proxy administration, but UUPS upgrade authorization is implemented in the implementation contract, and beacon authority is separate. An empty admin slot does not prove that upgrades are disabled or ownership is renounced. Inspect the actual proxy pattern and authorization code before displaying control or safety claims.