Security-Council threshold reduction (RT)
Jupiter Perpetual Exchange's assessment for RD-F-182 — scored not_applicable on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Security-Council threshold-reduction real-time signal (batch-24, Cat 6B). Jupiter Perps does not have a named Security Council architecture analogous to Drift's 3/5 Security Council structure. The JUP DAO operates via Realms token voting (paused since 2025-06-20), not a Security Council model. The program upgrade authority (Squads multisig if off-curve per SOLANA_GOVERNANCE.md derivation) would be the closest functional analogue, but: (1) the upgrade authority is UNVERIFIED — pipeline returned solana_multisigs=[]; (2) the DAO pause means no governance queue exists through which a threshold reduction would be proposed and visible; (3) even if the upgrade authority uses Squads, threshold changes would be observable on-chain but no monitoring baseline exists without knowing the current threshold. Signal cannot engage because the Security Council architecture is absent and the upgrade authority identity is unverified. This is an architectural absence (not a suppression condition).
Sources #
- InternalPhase-2 shared briefing §15 U10 + §6 governance topologyBriefing §15 U10: 7 Solana-non-translating Cat 6 signals. §6 governance topology: DAO paused; upgrade authority UNVERIFIED (solana_multisigs=[]). No Security Council architecture.retrieved 2026-05-16
- Solscan — Jupiter Perps ProgramSolscan — program PERPHjGBqRHArX4DySjwM6UJHiR3sWAatqfdBS2qQJu; upgrade authority unresolved via public OSINT.retrieved 2026-05-16
Methodology #
Detect in real-time whether the bridge/protocol Security Council multisig executes a threshold reduction (e.g. 3/5 → 2/5), timelock removal, or new-signer addition within ≤14 days of either of those events.
See the full factor methodology and distribution across all protocols →