Timelock duration on upgrades

Save (formerly Solend)'s assessment for RD-F-032 — scored red on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.

Evidence summary #

No on-chain upgrade timelock exists. Solana BPFLoaderUpgradeable has no built-in timelock. Squads v3 (treasury) has no time_lock field by design. Squads v4 LM multisig has time_lock_seconds = null (confirmed in data cache). The upgrade authority single EOA can push new bytecode in a single transaction with 0-hour delay.

Sources #

Internal
SOLANA_GOVERNANCE.md — timelock architectureSOLANA_GOVERNANCE.md — Squads v3 has no time_lock field; Squads v4 time_lock_seconds decoded from multisig accountretrieved 2026-05-17
Internal
Save data cache — LM Squads v4 time_lock = null.research/protocols/save/00-data-cache.json solana_multisigs[2] time_lock: nullretrieved 2026-05-17

Methodology #

Read the timelock delay (in hours) between a queued upgrade proposal and its executable state.

See the full factor methodology and distribution across all protocols →

rubric_version v1.7.0 protocol save factor RD-F-032 score red collected_at 2026-05-17 15:20:15