Bridge rate-limiter / chain-pause as positive mitigant
Jupiter Perpetual Exchange's assessment for RD-F-185 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Jupiter Perps is Solana-only with no bridge surface — no per-window bridge outflow rate-limiter applies. The Squads v4 24h timelock (time_lock=86400s confirmed on-chain) is a positive mitigant for upgrade-based drains. setPerpetualsConfig allows disabling features (allowSwap, allowIncreasePosition) providing a partial protocol pause controlled by the Squads v4 4-of-7 multisig. Solana has validator-set chain-halt capability (chain-level emergency stop) but this is not a protocol-level control. No formal protocol-level rate-limiter confirmed. Scored yellow: Squads v4 24h timelock is a positive upgrade mitigant; feature-flag pause exists; no independent guardian role and no rate-limiter.
Sources #
- TxSquads v4 multisig config AxkJ8oH5 on SolscanOn-chain: Squads v4 multisig AxkJ8oH5 time_lock=86400s — 24h delay on any multisig-mediated action is a positive rate-limiter equivalent for the upgrade pathretrieved 2026-05-16
- Anchor CPI client for Jupiter Perpetuals programJupiter Perpetuals CPI IDL: setPerpetualsConfig instruction includes allow-flags (allowSwap, allowIncreasePosition, etc.) enabling partial feature disableretrieved 2026-05-16
Methodology #
Determine whether the bridge implements a per-window outflow rate-limiter (and at what cap), and whether the protocol team can trigger a chain-level or validator-set emergency pause.
See the full factor methodology and distribution across all protocols →