Storage-layout collision risk across upgrades

Jupiter Perpetual Exchange's assessment for RD-F-142 — scored not_applicable on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.

Evidence summary #

Not applicable in Solana context. BPFLoaderUpgradeable uses account-based state storage, not EVM storage slots. The EVM-specific storage-layout collision concept (slot N in impl A occupied by different variable in impl B across transparent-proxy upgrades) does not translate to Anchor/Borsh account layouts which use explicit struct discriminators.

Sources #

Internal
SOLANA_GOVERNANCE.md + profile §3 (Solana substrate)SOLANA_GOVERNANCE.md: BPFLoaderUpgradeable is the upgrade mechanism; no EVM storage slots; Anchor/Borsh uses explicit struct discriminatorsretrieved 2026-05-16

Methodology #

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

See the full factor methodology and distribution across all protocols →

rubric_version v1.7.0 protocol jupiter-perps factor RD-F-142 score not_applicable collected_at 2026-05-16 01:53:11