Storage-layout collision risk across upgrades
Save (formerly Solend)'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 #
Solana BPF programs use a flat account model (program-owned state accounts with serialized data), not the EVM storage slot model. The EVM storage layout collision risk when upgrading UUPS/Transparent proxies does not exist in the Solana BPF upgrade pattern. When a Solana program is upgraded, the bytecode is replaced and existing account state is preserved in its current layout — no storage layout pointer collision risk.
Sources #
- InternalSOLANA_GOVERNANCE.md — Solana BPF account modelSOLANA_GOVERNANCE.md — Solana BPF program account model vs EVM storage slot modelretrieved 2026-05-17
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 →