Storage slot collision is when two variables, usually from different smart contracts or inherited code, are assigned the same storage location in blockchain execution. In Ethereum-style systems, this can overwrite state unexpectedly during upgrades or delegate calls, so storage layouts and proxy patterns must be planned carefully.
How Storage Slot Collision Happens
storage slot collision occurs when two state variables resolve to the same storage location in an EVM-style contract layout. That overlap can happen through inheritance, proxy upgrade patterns, or delegate call execution, where one contract writes into storage that another contract assumes it owns.
The issue is not the Solidity type itself, but the compiled storage layout. Variables are assigned slots by ordering and inheritance rules, so a small change in field order, base contracts, or layout assumptions can shift state in ways that are invisible until a write lands on the wrong slot.
Why It Matters in Upgradeable Contracts
Collision is especially dangerous in upgradeable systems because the logic contract can change while the proxy keeps the same persistent storage. If a new implementation introduces a variable that conflicts with existing layout, it can corrupt balances, ownership flags, initialization state, pause controls, or other critical contract state without any obvious runtime error.
That is why storage gaps, reserved slots, and strict layout discipline are common in proxy designs. The risk is not theoretical, since delegate call execution intentionally runs new code against old storage, and any mismatch between versions can turn an upgrade into an unplanned state rewrite.
For a practical reference on proxy patterns, storage layout, and upgrade safety, see the Smart Contract Upgradeability and Proxy Security Guide.
Where the Collision Comes From
Inheritance is a common source of confusion because parent and child contracts contribute to one combined layout. Adding, removing, or reordering variables in a base contract can shift downstream slots and silently break assumptions in derived contracts or proxy-backed deployments.
Delegate call patterns create a second hazard: the code that executes may belong to one contract, while the storage belongs to another. In that setup, a harmless-looking state write in the implementation can overwrite an unrelated proxy variable, because both sides are reading and writing the same persistent store.
Tooling, compiler metadata, and storage layout checks help reduce this risk, but they do not replace design discipline. The safest approach is to treat layout as part of the contract interface, not as an internal detail that can change freely between versions.
How Teams Prevent and Detect It
Teams prevent slot collision by locking storage order, using standardized upgrade patterns, and reviewing layout changes before deployment. They also inspect compiler storage layouts during upgrades, compare old and new implementations, and reject changes that introduce incompatible state placement.
Detection is usually indirect. Symptoms include corrupted variables, broken permissions, unexpected ownership changes, failed initialisation logic, or state that changes in ways the code path does not explain. After an upgrade or delegate call, any suspicious state drift should be treated as a layout problem until proven otherwise.
If a collision is suspected in production, the safest response is to pause further upgrades, review the deployed storage map, and validate whether any sensitive state has already been overwritten. In systems that hold value or control privileges, post-upgrade integrity review is as important as the upgrade itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Covers architecture and code-design flaws that create unsafe state handling. |
| Recommendation — Review implementation changes for storage-layout compatibility before deploying upgraded contract code. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Requires controlled review of changes that can alter system behaviour and integrity. |
| Recommendation — Require formal change review for contract upgrades that modify persistent storage assumptions. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Addresses secure software design and change review for application logic that can corrupt state. |
| Recommendation — Validate upgrade-safe storage design as part of application security review. | ||