What is a proxy storage collision?

An upgradeable contract splits into a proxy (holds the storage and funds, never changes) and an implementation (holds the logic, can be swapped). The proxy delegatecalls the implementation, so the implementation’s code reads and writes the proxy’s storage.

Storage is laid out by slot number in declaration order. If the proxy and implementation declare variables in different orders or the proxy uses early slots the implementation also uses, the same slot means two different things, and writing one clobbers the other. That is a storage collision.

Two collision patterns:

• Proxy vs implementation: the proxy stores its admin in slot 0, and the implementation also uses slot 0 for a normal variable. A user action that writes that variable overwrites the admin, an attacker sets themselves as admin and upgrades to malicious code.
• Upgrade layout drift: a new implementation inserts or reorders state variables, so existing storage now maps to the wrong fields, corrupting balances or permissions.

The fix pattern (EIP-1967) puts admin/implementation in pseudo-random slots to avoid overlap. Documented for defensive context.

• Use standardized storage slots (EIP-1967) for admin and implementation addresses so they never collide with logic variables.
• Use audited upgradeable proxy libraries rather than custom proxies.
• Keep storage append-only across upgrades: never reorder or remove existing variables, only add new ones at the end (use storage gaps).
• Run upgrade-safety checks that compare storage layouts between versions.
• Audit every upgrade for layout compatibility, not just the logic changes.