Timelock on sensitive actions

Jupiter's assessment for RD-F-033 — scored red on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.

Evidence summary #

No documented timelock for any sensitive action category (mint/pause/rescue/setOracle/upgrade). JUP mint authority is burned (eliminates that risk). All other admin operations: Squads multisig threshold is the only control — no time delay. Realms governance had no post-vote execution timelock. During pause, team makes decisions with no on-chain delay.

Sources #

URL
Solana DEX Jupiter Pauses DAO Votes | CoinDeskGovernance pause — no on-chain constraint on team operational decisionsretrieved 2026-04-29
Docs
JUP Minting and Accountability | Jupiter Research ForumData cache governance fields — timelock_address: null, timelock_delay_seconds: nullretrieved 2026-04-29

Methodology #

For each sensitive action category (mint / pause / rescue / setOracle / upgrade), determine whether execution requires going through the declared timelock.

See the full factor methodology and distribution across all protocols →

rubric_version v1.7.0 protocol jupiter factor RD-F-033 score red collected_at 2026-04-29 11:51:25