defirisk.co
rubric v1.7.0

Storage-layout collision risk across upgrades

A post-deploy hygiene & change mgmt factor in the v1.7.0 rubric. Measured per protocol on a s cadence.

Methodology how we score#

What this measures
This factor identifies whether a manual code review or the OpenZeppelin Upgrades Plugin storage-layout check has flagged any storage-layout collision risk between different implementation versions of an upgradeable proxy. A storage collision occurs when an upgrade adds, removes, or reorders storage variables in a way that causes previously-set variables to be misread or overwritten by the new implementation.

Why it matters
Storage layout collisions in upgradeable contracts are a silent corruption vulnerability: the deployed proxy continues to function normally in most code paths, but specific edge-case executions that access reordered storage slots produce unexpected results. The Raft protocol's 2023 loss ($3.3M) demonstrated a related delegatecall storage pattern where an uninitialized slot caused an unexpected fund routing outcome — even with four audits including Trail of Bits, the interaction between proxy patterns and storage state was not caught. The OpenZeppelin Upgrades Plugin automates detection of the most common collision patterns, but manual review is required for complex inheritance hierarchies and custom proxy patterns.

Green / Yellow / Red
Green is assigned when the OZ Upgrades Plugin or equivalent has been run against the current implementation and the prior implementation, returning no collision warnings, and this check is part of the protocol's upgrade process. Yellow covers cases where the check has been run but with manual overrides accepted, or where the check was performed on an earlier version pair and the current upgrade was not re-verified. Red is assigned when no storage layout check has been performed on the current upgrade pair, or when a known collision warning has been dismissed without a documented resolution.

Common gray cases
This factor is grayed when the protocol uses immutable contracts (no upgrade path means no collision risk), or when the proxy pattern is non-standard and incompatible with available automated tools.

Notable historical examples
No cross-hacked incidents currently linked in database for this factor.

Measurement what to look for#

Determine whether the OZ upgrades-plugin or manual review flags a storage-layout collision risk between implementation versions.

Data & output #

Data source
OpenZeppelin upgrades plugin (`hardhat-upgrades` or `foundry-upgrades`) storage layout check + curator inspection of implementation diffs
Output format
Green / Yellow / Red
Evidence artifact
OZ upgrades plugin output + storage layout diff + collision flag
Confidence signal
green = storage layout checks pass with no collision; yellow = minor layout additions in safe append positions; red = storage layout collision flagged; gray = protocol has no upgradeable proxies

Scored protocols 0 carry this factor#

No protocols have been scored for this factor yet.

Linked hacks no historical incidents linked#

No historical incidents are linked to this factor.
rubric_version v1.7.0factor RD-F-142category 9carried 0critical no