Timelock duration on upgrades
Sanctum'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 independent on-chain timelock controller identified for program upgrades or sensitive actions. Squads V4 has an optional timelock feature but whether Sanctum enables it is unconfirmed. Futarchy governance has a ~7-day trading window but this is advisory and does not constrain multisig execution timing. No minimum delay between a governance decision and multisig execution is enforced on-chain. Profile §6 explicitly flags: 'Timelock (if any): Not identified in public documentation.'
Sources #
- DocsSquads: Managing Program Upgrades with MultisigProfile §6 explicitly states timelock not identified; Squads V4 timelock is optional feature not confirmed configuredretrieved 2026-05-04
- Cloud DAO governance and $Cloud utilitySanctum Research governance forum — futarchy is advisory; on-chain execution requires separate multisig actionretrieved 2026-05-04
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 →