Jupiter Aggregator v6 · authority risk 47/100, moderate

Can one person move the money in Jupiter Aggregator v6 on Solana? The authority score is 47 / 100 (moderate): a multisig without a real delay, the band where Bybit, WazirX and Radiant sat when they were drained.

In short. Upgrades sit behind a 4-of-7 Squads v3 multisig, and Squads v3 has no delay field, so an approved upgrade can land with no notice. A swap router holds no deposits between transactions, which limits what an upgrade could reach.

Exposure, not intent. The score counts what the keys could do, not what their holders will do, and says nothing about the odds of a loss. Re-read it yourself with a public RPC and curl: how.

Try a fix: drag the sliders Open the live dashboard re-read from the chain every 6 hours; this page is the snapshot of the build

The five readings

admin key55
multisig83
timelock0
price feed100
shared control40

Composite = 40% admin key + 30% multisig + 30% timelock, rounded. Price feed and shared control are read and shown, not folded in.

To move the money: keys and hours to react not read for this contract (never shown as zero).

Why this score

Upgrades sit behind a 4-of-7 Squads v3 multisig, and Squads v3 has no delay field, so an approved upgrade can land with no notice. A swap router holds no deposits between transactions, which limits what an upgrade could reach.

same authority upgrades 22 other ProgramData accounts

The upgrade authority is a PDA, resolved to authority index 1 of a Squads v3 multisig and re-derived offline on every run. All 7 members are plain on-curve keys. The same PDA is the upgrade authority of 22 other ProgramData accounts (a blast-radius note, not scored), and the same multisig is also the admin of Jupiter Perpetual Exchange. Other paths are bounded: a hardcoded close_token operator only reaches the program's own token accounts, and claim sweeps to a fixed wallet. The on-chain IDL has no oracle account, so the oracle sub-score is not applicable.

3 of 6 requirements met

Exit window: none: a change applies at once, the time a user has to leave after a harmful change is queued.

If a market used the example policy today (src/ExampleConsumer.sol: revert when stale, 0 under 60, 50% to 80% above): collateral factor 0 (score 47 is under MIN_SAFE_SCORE 60). Cheapest path to decent (60): admin key from 55 to 87, that is a stronger admin setup (admin power spread beyond one key, or checked by others), every other axis unchanged. This is the smallest step into the next band, not a fix for the weakness: the first requirement not met is A confirmed delay before changes apply, no bypass (changes can apply with no waiting time).

Show this score in your README
[![authority risk: Jupiter Aggregator v6](https://img.shields.io/endpoint?url=https%3A%2F%2Fraw.githubusercontent.com%2FRealSpap%2Fauthority-risk-oracle-showcase%2Fwatch-data%2Fbadge%2Fsolana-devnet%2FJUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4.json)](https://realspap.github.io/oracle/p/solana-JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4.html)

A live badge: the score is read from the published watch files every time the page that shows it loads. Change nothing but your own repository.

Not assessed for this contract: how many keys it takes to move it; the time anyone has to react; the money behind one key (no money figure, or no key count); the protocol's total value locked (no DefiLlama match).

Program or account: JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4 on the explorer ↗. Score pushed on-chain on 2026-10-13; stale on the oracle when older than 9 days (the watch re-reads it anyway). Read the score yourself: it lives in the account 65Zt5p…NZz2 on Solana Devnet (PDA, seeds ["score", target], program 5Vhi…Yh4W): byte 45 is the composite, bytes 46 to 53 the last update; stale once last_updated + Registry.max_staleness_seconds has passed. The target itself lives on mainnet. The score takes the weakest of every full-power authority path (program upgrade authority, config-account admins, reward or fee authorities); a Squads whose threshold is 1 counts as one key, so a site that reads only the upgrade multisig can show a higher number for the same protocol.

Read on 2026-10-15 18:53 UTC, methodology 0x4f8c4019b9c9e75b…. The score reads the authority path (keys, multisigs, timelocks, roles, price feeds); it does not audit the code for bugs, and it measures exposure, not the chance of being hit (see the backtest in the repository). Dispute this score with evidence, or read this page as JSON.

Read live: admin: a program-derived address (not a Squads v4 vault); delay: unknown.
Independent read of the admin: a program-derived address (no key can sign for it directly) CvQZZ23qYD…tipQ via program -> ProgramData 4Ec7Zx… -> upgrade authority (a program-derived address, off the curve: a Squads vault or a protocol PDA, no key can sign for it directly), consistent with the published admin-key score. Unchanged since 2026-10-10. Program last deployed at slot 454465850 on 2026-10-08 (ProgramData; an upgrade moves this slot and the watch says so). No verified build matching the deployed binary (OtterSec: none registered). (scripts/second_opinion.py: a reader that shares nothing with the scorer, re-run every 6 hours)

Follow this contract: Atom feed of its score moves, alerts and queued operations (nothing else).