Jupiter JUP

Claim: Solana L1 Ed25519 dependency is publicly documented by multiple independent sources; Jupiter token-specific admin key inventory is visible on-chain but no formal inventory has been published by the Jupiter team.

Coverage basis: Inherited from Solana L1 (Token Inheritance Rule 7.2); token-specific admin keys are transparent on Solscan but undocumented by Jupiter.

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: Solana L1 has extensive public cryptographic documentation from multiple independent sources (Solana Foundation, Helius/Jump Crypto, Quantum Canary, Blueshift, Project Eleven). Jupiter has not published its own inventory of admin keys, multisig configurations, or governance key exposure. Token admin keys are verifiable on-chain via Solscan but not formally documented.

Scored at 0.50 because Solana L1's Ed25519 dependency is well-documented by ecosystem research (Helius, Jump Crypto, Quantum Canary, Blueshift), but Jupiter has published zero project-specific cryptographic inventory. The on-chain visibility of admin keys provides partial transparency but does not constitute a formal inventory with threat modeling.

• https://solana.com/news/quantum-readiness
• https://www.helius.dev/blog/solana-post-quantum-cryptography
• https://www.quantumcanary.org/insights/is-solana-ever-going-to-become-quantum-secure
• https://jumpcrypto.com/resources/quantum-migration-paths-for-solana
• https://solscan.io/token/JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN
• https://blueshift.gg/research/quantum-proofing-solana

Claim: Solana ecosystem has code references, specifications, transaction examples, and independent research. Jupiter token data is verifiable on Solscan. No Jupiter-specific quantum evidence compilation exists.

Coverage basis: Inherited from Solana L1; Jupiter token state is verifiable on-chain.

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: none · Score treatment: score-reducing

Assurance: Solana L1 evidence record is strong with code, specs, and independent research. Jupiter's GitHub repos contain client SDKs and swap tools but no quantum-specific evidence. Token state is verifiable on-chain.

Scored 0.50: Solana L1 has strong public evidence, but Jupiter has not compiled or published any quantum-specific evidence record for its token or protocol.

• https://github.com/jup-ag
• https://solscan.io/token/JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN
• https://github.com/anza-xyz/agave
• https://github.com/firedancer-io/firedancer

Claim: All JUP token transfers and all Solana transactions use Ed25519 signatures exclusively. No PQC or hybrid-PQC spend authorization exists on Solana mainnet.

Coverage basis: Inherited from Solana L1; JUP has no independent spend authorization mechanism.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Active production spend authorization remains entirely Ed25519-only. Cap: 40.

Assurance: Multiple independent, current sources confirm Ed25519-only spend authorization on Solana mainnet as of June 2026. No conflicting evidence exists. High confidence.

This is the primary quantum-critical vulnerability. All JUP transfers depend on Ed25519. Solana's Falcon-512 implementation exists only on GitHub/testnet and is explicitly not activated for mainnet. The Solana Foundation states 'no change is required today or likely anytime soon.'

• https://www.quantumcanary.org/insights/is-solana-ever-going-to-become-quantum-secure
• https://www.helius.dev/blog/solana-post-quantum-cryptography
• https://solana.com/news/quantum-readiness

Claim: Solana exposes Ed25519 public keys directly on-chain for all accounts. Unlike Bitcoin (hashed P2PKH) or Ethereum (hashed addresses until first transaction), Solana accounts have long-exposure public keys visible from genesis.

Coverage basis: Inherited from Solana L1 architecture.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: 100% of Solana accounts (and thus JUP holders) have long-exposure Ed25519 public keys on-chain, enabling offline quantum key-recovery with no time constraint.

Assurance: Project Eleven CEO Alex Pruden confirmed: 'In Solana, 100% of the network is vulnerable. A quantum computer could pick any wallet and immediately start trying to recover the private key.' This is independently verified by Blueshift research and Helius technical documentation. High confidence.

This is a structural vulnerability in Solana's address derivation. Ed25519 public keys are stored in account state directly. This is worse than Bitcoin or Ethereum where public keys are only revealed on first spend. All JUP holder accounts that have ever received tokens are quantum-vulnerable at rest.

• https://www.helius.dev/blog/solana-post-quantum-cryptography
• https://blueshift.gg/research/quantum-proofing-solana
• https://www.quantumcanary.org/insights/is-solana-ever-going-to-become-quantum-secure

Claim: Solana validator identity, voting, and consensus authentication all use Ed25519 signatures. No PQC protection exists at the consensus layer.

Coverage basis: Inherited from Solana L1 consensus mechanism.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Multiple independent sources confirm Ed25519 for validator authentication. Consensus compromise could enable transaction censorship or reorganization affecting JUP holders. High confidence.

While consensus-layer compromise does not directly enable JUP theft, it could enable transaction censorship, double-spending of JUP, or manipulation of Jupiter protocol state. Scored as applicable per PoS chain guidance (Section 11.2).

• https://www.helius.dev/blog/solana-post-quantum-cryptography
• https://jumpcrypto.com/resources/quantum-migration-paths-for-solana
• https://www.quantumcanary.org/insights/is-solana-ever-going-to-become-quantum-secure

Claim: Solana uses SHA-256 for state merkleization (quantum-safe for collision resistance at current parameters). However, token supply-binding (mint authority) and program upgrade authority rely on Ed25519 signatures.

Coverage basis: Inherited from Solana L1; JUP token mint authority is Ed25519-controlled.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: SHA-256 for state hashing is quantum-safe for preimage and collision resistance at 256-bit output. However, JUP mint authority (held by Jupiter Team Cold Wallet per Solscan) is Ed25519-controlled. A quantum attacker compromising the mint authority could inflate JUP supply arbitrarily.

Scored 0.25 because state hashing uses quantum-safe SHA-256, but the JUP token supply-binding mechanism depends entirely on Ed25519 mint authority signatures. Supply integrity is not quantum-safe.

• https://solscan.io/token/JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN
• https://www.helius.dev/blog/solana-post-quantum-cryptography
• https://jup.ag

Claim: Jupiter and JUP token have no privacy layer, shielded transactions, ZK proofs, or confidential transfers.

Coverage basis: N/A — protocol has no privacy layer.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Verified from Jupiter GitHub repositories and on-chain token program analysis. No privacy features exist in the protocol.

Marked N/A per applicability rules. The protocol genuinely lacks a privacy layer. This is not a gap to be filled.

• https://github.com/jup-ag
• https://solscan.io/token/JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN

Claim: Solana P2P node identity uses Ed25519 keys that are also used for consensus voting. Node identity is consensus-critical on Solana.

Coverage basis: Inherited from Solana L1 P2P/consensus architecture.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Solana validator identity keys (Ed25519) serve dual purpose for P2P peer authentication and consensus voting. A quantum compromise of P2P identity could cascade to consensus manipulation. The satisfied-by-design exception does not apply because node identity IS consensus-critical on Solana.

Scored 0.00 because Solana's P2P node identity keys are the same Ed25519 keys used for consensus voting. Node identity compromise could affect JUP transaction inclusion and Jupiter protocol availability.

• https://www.helius.dev/blog/solana-post-quantum-cryptography
• https://jumpcrypto.com/resources/quantum-migration-paths-for-solana

Claim: Jupiter protocol treasury, admin keys, and multisig use standard Solana Ed25519 wallets (Squads multisig). No PQ wallet support, Winternitz Vault integration, or HSM PQC path exists for Jupiter's critical keys.

Coverage basis: Token-specific admin/governance keys (Token Inheritance Rule 7.2 evaluation).

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Jupiter protocol upgrade authority (Squads multisig with 12-hour timelock) and treasury are controlled by Ed25519 keys with no PQC custody path.

Assurance: Jupiter Lend's Squads multisig and 12-hour timelock are documented by Ethena Foundation protocol assessment (May 2026). Mint authority is verified on Solscan as Jupiter Team Cold Wallet. Blueshift Winternitz Vault exists on Solana but Jupiter has not adopted it for any critical keys.

Scored 0.00. Jupiter's critical admin keys represent high-value quantum targets. The 12-hour timelock on upgrade authority provides limited protection — a quantum attacker could potentially recover keys and execute malicious upgrades before detection. Blueshift's Winternitz Vault is available but not adopted.

• https://solscan.io/token/JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN
• https://jup.ag
• https://ethenafoundation.com
• https://blueshift.gg/research/quantum-proofing-solana

Claim: JUP market cap ~$610M (May 2026) with ~3.32B circulating supply. All JUP value resides on Solana mainnet with Ed25519-only protection. No migration has occurred. Winternitz Vault optional protection is not used by Jupiter for protocol funds.

Coverage basis: JUP token circulating supply and market cap; all value is Ed25519-dependent on Solana mainnet.

Implementation score: 0.05 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Less than 25% value-at-risk coverage. All ~$610M JUP market cap is Ed25519-dependent with long-exposure public keys.

Assurance: Market cap and supply figures from CoinStats AI (May 2026). Token supply verified on Solscan. 100% of JUP value is on Solana mainnet with no migration or PQC protection. Blueshift Winternitz Vault could theoretically protect JUP holders but adoption is unknown and Jupiter protocol funds are not using it.

Scored 0.05 (1/20) for <25% coverage. The Winternitz Vault provides optional quantum-resistant custody on Solana, but there is no evidence Jupiter or JUP holders use it at meaningful scale. Even if some individual holders use it, protocol-controlled value (treasury, liquidity pools, admin keys) is unprotected.

• https://coinstats.app/ai/a/fundamental-analysis-jupiter-exchange-solana
• https://solscan.io/token/JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN

Claim: No Jupiter critical wallets (treasury, admin keys, multisig signers, liquidity pool authorities) have been migrated to PQC or protected by Winternitz Vaults.

Coverage basis: Token-specific admin/governance evaluation.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Jupiter treasury, mint authority, and Squads multisig upgrade authority remain Ed25519-only.

Assurance: Mint authority verified on Solscan as 'Jupiter Team Cold Wallet.' Jupiter Lend upgrade authority documented as Squads multisig. No evidence of Winternitz Vault or other PQC adoption for any Jupiter-controlled keys.

Scored 0.00. Jupiter controls significant protocol value through Ed25519-only keys. The Blueshift Winternitz Vault is available on Solana for any user but Jupiter has not adopted it for protocol-critical keys.

• https://solscan.io/token/JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN
• https://ethenafoundation.com
• https://jup.ag

Claim: No Jupiter-specific inventory of vulnerable accounts, admin keys, or protocol-controlled value has been published. Solana L1 vulnerability is well-documented but Jupiter has not mapped its own exposure.

Coverage basis: Token-specific assessment.

Implementation score: 0 · Evidence confidence: Low

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: No Jupiter-published inventory exists. Admin keys can be partially inferred from on-chain data but no formal documentation or measurement has been published. Low confidence due to absence of Jupiter-specific evidence.

Scored 0.00. While Solana L1 vulnerability is well-characterized, Jupiter has not published any identification, measurement, or tracking of its own vulnerable value pools. On-chain data allows partial reconstruction but no official inventory exists.

Claim: Solana has a 3-step quantum roadmap (research → new wallet PQC → migrate existing). Jupiter has no token-specific migration roadmap.

Coverage basis: Inherited from Solana L1 roadmap; Jupiter has no token-specific roadmap.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: Solana Foundation published its 3-step quantum roadmap on solana.com/news/quantum-readiness (April 2026). The roadmap has no committed activation timeline or block height. Jupiter has not published any token-specific migration roadmap or coordination plan.

Scored 0.25 for the existence of Solana's L1 roadmap. This is a public design/proposal level only — no production migration. Jupiter's absence of a token-specific roadmap further limits the score. Roadmaps are not production protection per QRI rules.

• https://solana.com/news/quantum-readiness
• https://news.bitcoin.com/solana-readies-quantum-defense-with-3-step-roadmap-and-falcon-implementation/

Claim: No PQ account creation, wallet tooling, or migration prompts exist for JUP token holders. Solana's Winternitz Vault is optional and not integrated with Jupiter.

Coverage basis: Token-specific evaluation.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Blueshift Winternitz Vault/Winterwallet exists as an optional Solana tool but is not integrated into Jupiter's UI, SDK, or documentation. No PQ account creation path exists for JUP. Jupiter GitHub repositories contain no migration tooling.

Scored 0.00. Users cannot create PQ-protected JUP accounts through Jupiter. The optional Winternitz Vault exists at the Solana L1 level but requires independent user action and is not surfaced through Jupiter's interface.

• https://blueshift.gg/research/quantum-proofing-solana
• https://github.com/jup-ag

Claim: No enforcement mechanisms, deprecation timelines, legacy signing restrictions, or exchange coordination exist for JUP or Solana quantum migration.

Coverage basis: Inherited from Solana L1; Jupiter has no independent enforcement.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Solana's roadmap explicitly defers activation: 'no change is required today or likely anytime soon.' No enforcement mechanisms, deprecation schedules, or exchange coordination plans exist. Jupiter has no independent enforcement capability.

Scored 0.00. No enforcement mechanisms exist at either the Solana L1 or Jupiter protocol level. Users can continue creating new Ed25519-only accounts by default with no warnings or restrictions.

• https://solana.com/news/quantum-readiness

Claim: No Jupiter-specific quantum incident response plan or emergency governance process exists. Solana ecosystem has general security contacts but no published quantum-specific IR.

Coverage basis: Token-specific governance evaluation.

Implementation score: 0 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: No published quantum-specific incident response plan or emergency governance process identified for Jupiter or Solana. The absence of a quantum-specific IR plan leaves uncertainty about how the protocol would respond to a quantum security event. However, per the Note-Only Caveat Rule (7.4), this is primarily an assurance caveat unless it leaves a current quantum-vulnerable path unresolved.

Scored 0.00 because no process exists. Per Section 7.4, the absence of a formal quantum-specific IR playbook is normally a note-only caveat, but it is scored here because the absence contributes to the broader pattern of no quantum preparedness at the Jupiter protocol level.

Claim: No PQC algorithms are in production use for JUP or its Solana base layer. Falcon-512 (NIST FIPS 206) has been selected by Solana client teams for future migration but is not deployed on mainnet.

Coverage basis: Production scope only; Falcon-512 exists in testnet/GitHub only.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Falcon-512 is a NIST-standardized PQC algorithm (FIPS 206) and Solana's selection by two independent client teams is a positive signal. However, Falcon code exists only on GitHub and testnet — not merged into any mainnet client build. This is a roadmap asset, not production protection.

Scored 0.00 because no NIST-standardized PQC algorithm is used in production for JUP transactions. Falcon-512 selection and testnet implementation earn credit in preparedness categories but do not constitute production cryptographic protection.

• https://solana.com/news/quantum-readiness
• https://news.bitcoin.com/solana-readies-quantum-defense-with-3-step-roadmap-and-falcon-implementation/
• https://thecryptocurrencypost.net/anza-and-firedancer-implement-falcon-to-protect-solana-against-future-quantum-computing-threats/

Claim: No quantum-specific audit exists for Jupiter. Existing audits (Offside Labs, Pashov, Code4rena) cover classical smart-contract security only. Solana's Falcon implementation has not been independently audited for production use.

Coverage basis: Audit scope is classical only; zero quantum coverage.

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Jupiter has multiple recent classical audits (Offside Labs Dec 2025, Pashov Dec 2025, Code4rena Feb-Mar 2026) covering JupUSD stablecoin and Jupiter Lend. None address quantum security, PQC implementation, or cryptographic migration. These audits support general assurance but provide zero quantum-specific verification. Per Section 6.4, audit absence for quantum-critical scope means this subfactor scores 0.00.

Scored 0.00 because no independent audit of quantum-critical implementation exists. The existing audits are current and high-quality for their classical scope but are completely scope-mismatched for quantum security assessment.

• https://github.com/code-423n4/2026-02-jupiter-lend
• https://jupusd.money/homepage/audits/offsidelabs.pdf
• https://jupusd.money/homepage/audits/pashov.pdf

Claim: Jupiter's swap aggregator core is partially closed-source. Solana's Falcon implementation is open-source on GitHub (Anza, Firedancer). No PQC implementation exists in Jupiter's production scope.

Coverage basis: Mixed: Jupiter partially closed, Solana PQC code open but not in production.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Jupiter's GitHub organization contains client SDKs, APIs, and some protocol code, but core aggregator logic is reportedly closed-source per community reports. Solana's Falcon-512 code is open-source on Anza and Firedancer GitHub repositories. Partial credit for open-source components and Solana L1 PQC code.

Scored 0.25 for partial open-source availability. Jupiter's partially closed-source core limits independent verification of any future PQC integration. Solana's Falcon implementation is open-source but not in production scope.

• https://github.com/jup-ag
• https://github.com/anza-xyz/agave
• https://github.com/firedancer-io/firedancer
• https://www.reddit.com/r/solana/comments/1hhgxnv/why_is_jupiter_source_code_private/

Claim: No parameter agility or upgrade path documentation exists for Jupiter. Solana's Falcon migration path is documented at a high level but lacks specific parameters, activation criteria, or upgrade procedures.

Coverage basis: Token-specific: no documentation. Solana L1: high-level only.

Implementation score: 0 · Evidence confidence: Low

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: Solana's quantum readiness blog post describes a 3-step roadmap but provides no specific parameters, activation thresholds, block heights, or upgrade procedures. Jupiter has no documented upgrade path at all. Low confidence due to absence of detailed documentation.

Scored 0.00. Neither Jupiter nor Solana has published detailed parameter agility documentation, algorithm selection criteria with thresholds, or concrete upgrade procedures for quantum migration.

• https://solana.com/news/quantum-readiness

Claim: No stateful signatures (XMSS/LMS) are in use. Winternitz Vault uses hash-based one-time signatures with address rotation — state management is handled by the vault design.

Coverage basis: N/A — no stateful signatures in Jupiter production scope. Winternitz Vault is an optional external tool.

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: No stateful signatures are used in Jupiter's production scope. The Winternitz Vault's state management is handled by its own design (one-time use with explicit address rotation) and is outside Jupiter's scope.

Marked N/A per applicability rules. Jupiter's production scope does not include stateful signature schemes.

• https://blueshift.gg/research/quantum-proofing-solana

Claim: Project Eleven's Solana PQC testnet demonstrated ~90% throughput degradation with post-quantum signatures. Jupiter has not conducted its own performance analysis.

Coverage basis: Inherited from Solana L1 ecosystem analysis; no Jupiter-specific analysis.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: Project Eleven's testnet analysis (Dec 2025, reported April 2026) documented 20-40x larger signatures and ~90% slower throughput. This is an ecosystem-level analysis, not Jupiter-specific. Jupiter, as a DEX aggregator, would be particularly sensitive to throughput degradation but has not published its own impact assessment.

Scored 0.25 for the existence of Solana ecosystem performance analysis (Project Eleven). The 90% throughput degradation finding is significant for Jupiter as a high-frequency DEX aggregator, but no Jupiter-specific analysis exists. Per Section 7.4, missing formal benchmarks are note-only caveats unless they prevent safe use — here the analysis exists at ecosystem level.

• https://www.coindesk.com/tech/2026/04/04/solana-s-quantum-threat-readiness-reveals-harsh-tradeoff-security-vs-speed
• https://www.prnewswire.com/apac/news-releases/project-eleven-to-advance-post-quantum-security-for-the-solana-network-302642878.html