Timelock duration on upgrades
Jupiter Perpetual Exchange's assessment for RD-F-032 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Squads v4 time_lock field decoded from multisig config AxkJ8oH5aDu4ZRWfsujPtxdb6Vhq4gDehpoReBgrUUSm: 86400 seconds = 24 hours. This is a real on-chain timelock enforced by the Squads v4 program, not an off-chain policy. Prior assessment (red, assumed Squads v3/no timelock) corrected by on-chain derivation. Note: Jupiter aggregator uses Squads v3 (no timelock field); the perps program uses Squads v4 with a 24h timelock. 24 hours is functional but short; best practice for $691M TVL is 48h+. Scored yellow: timelock is real and on-chain; duration is at the lower acceptable threshold.
Sources #
- InternalSOLANA_GOVERNANCE.md Squads v4 Multisig layoutSOLANA_GOVERNANCE.md Step4 Squads v4 layout: time_lock at bytes 74-78 (u32 LE); Squads v3 has no time_lock field — the perps program's v4 timelock distinguishes it from the Jupiter aggregator (v3)retrieved 2026-05-16
- Squads v4 multisig config AxkJ8oH5 on SolscanOn-chain borsh decode of Squads v4 multisig config AxkJ8oH5aDu4ZRWfsujPtxdb6Vhq4gDehpoReBgrUUSm: time_lock field (bytes 74-78 per SOLANA_GOVERNANCE.md Step4 Squads v4 layout) = 86400 seconds (24 hours)retrieved 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 →