Admin/upgrade transaction in mempool

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

Evidence summary #

Admin/upgrade tx in mempool signal (T-09 v1 phase 2). Solana does not have an EVM-equivalent persistent public mempool — transactions propagate directly to validators. Program upgrade on Solana is executed via BPFLoaderUpgradeable Upgrade instruction and is visible on-chain (Solscan) after confirmation, not pre-confirmable via EVM-style mempool monitoring. The EVM mempool listener stack (Flashbots, Blocknative, geth txpool) is architecturally specific to EVM chains and cannot be deployed against Solana. A Solana-native equivalent (monitoring Solana tx gossip or Solscan for BPFLoaderUpgradeable Upgrade instructions targeting PERPHjGBqRHArX4DySjwM6UJHiR3sWAatqfdBS2qQJu) is technically feasible but is not covered by the T-09 EVM-spec. Upgrade authority UNVERIFIED (pipeline null), compounding the monitoring gap.

Sources #

URL
Solscan — Jupiter Perps ProgramSolscan perps program — BPFLoaderUpgradeable program; upgrade history visible on-chain but requires Solana-native monitoring, not EVM mempool.retrieved 2026-05-16
Internal
Phase-2 shared briefing U10 + governance topology §6Solana BPFLoaderUpgradeable upgrade mechanism — no EVM mempool equivalent. Upgrade authority unverified. Briefing §15 U10.retrieved 2026-05-16

Methodology #

Detect an admin-role or upgrade transaction appearing in the mempool before confirmation.

See the full factor methodology and distribution across all protocols →

rubric_version v1.7.0 protocol jupiter-perps factor RD-F-102 score not_applicable collected_at 2026-05-16 01:53:11