Timelock duration on upgrades

Meteora'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 #

Squads v3 multisig has no on-chain time_lock field by design. Timelock duration = 0 hours for program upgrades. Any claimed Meteora timelock is off-chain policy only and not enforceable. This is a structural characteristic of Squads v3 (no time_lock field in borsh layout), confirmed by SOLANA_GOVERNANCE.md. Peers using Squads v4 (e.g., Kamino 12h) have on-chain timelocks; Squads v3 peers (Jupiter, Raydium, Sanctum Unstake) also have 0h on-chain delay.

Sources #

Internal
Meteora Protocol Profile — timelock note.research/protocols/meteora/00-profile.md §6 — squads_v3_timelock_seconds: null; squads_v3_timelock_note: Squads v3 has NO on-chain time_lock fieldretrieved 2026-05-16
Internal
Solana Governance Verification Methodology — Squads v3 timelock absenceSOLANA_GOVERNANCE.md — Squads v3 borsh layout has no time_lock field; v3 cannot have on-chain timelockretrieved 2026-05-16

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 meteora factor RD-F-032 score red collected_at 2026-05-16 10:03:05