Timelock on sensitive actions
Jupiter Perpetual Exchange's assessment for RD-F-033 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Squads v4 24h timelock confirmed on the upgrade authority path. Program changes via BPFLoaderUpgradeable routing through the Squads v4 multisig AxkJ8oH5... are subject to 86400-second delay. However: IDL instructions (withdrawFees2, setCustodyConfig, setPoolConfig, setPerpetualsConfig, transferAdmin) are admin-callable and whether these route exclusively through the Squads multisig (vs. a direct admin keypair) is not verifiable from closed source. Prior red (no timelock) corrected; scored yellow: upgrade path has 24h delay; all direct admin instruction routing through the timelock is unverifiable.
Sources #
- GitHubAnchor CPI client for Jupiter Perpetuals program (IDL analysis)Jupiter Perpetuals CPI IDL: setCustodyConfig, setPoolConfig, setPerpetualsConfig, withdrawFees2, transferAdmin — admin-callable instructions; no timelock account in instruction accounts list (closed-source: cannot confirm all route through Squads)retrieved 2026-05-16
- Squads v4 multisig config AxkJ8oH5 on SolscanOn-chain: Squads v4 multisig config AxkJ8oH5 time_lock=86400s; upgrade authority 5myNNm... is the Squads v4 vault — program upgrades require 4/7 approval + 24h delayretrieved 2026-05-16
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 →