JUST JST

Claim: TRON founder has publicly acknowledged quantum risk and announced a post-quantum upgrade plan. No JST-specific cryptographic inventory has been published by the JUST team.

Coverage basis: Token inherits TRON L1 security model; TRON's ECDSA usage is publicly known. No formal inventory document exists for JST governance keys, admin paths, or protocol-controlled assets.

Implementation score: 0.25 · Evidence confidence: Low

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

Quantum blocker: No JST-specific cryptographic inventory exists; quantum risk to governance keys, admin paths, and protocol-controlled value is unassessed

Assurance: TRON's quantum-risk acknowledgment is via social media and secondary reporting only; no formal assessment or governance proposal has been published. JST team has not published any quantum-specific documentation.

Under Token Inheritance (7.2), JST shares TRON's base-layer risk profile. TRON has implicitly acknowledged ECDSA vulnerability through its upgrade announcement, but this does not constitute a formal cryptographic inventory for the JST token or its governance contracts.

• https://beincrypto.com/tron-quantum-resistant-mainnet-2026/
• https://crypto.news/justin-sun-sets-2026-timeline-for-tron-quantum-resistant-upgrade/
• https://www.just.network/
• https://docs.justlend.org/developers/supply_and_borrow_market/governance/

Claim: Evidence for quantum risk is limited to secondary news articles reporting TRON founder statements. No primary code references, specifications, transaction analyses, or reproducible analytics exist for JST quantum risk.

Coverage basis: No JST-specific evidence record. TRON-level evidence is limited to social media announcements and secondary reporting.

Implementation score: 0 · Evidence confidence: Very Low

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

Assurance: No primary-source evidence (code, specs, on-chain data, reproducible analytics) supports any quantum risk assessment for JST. All evidence is secondary reporting of unverified claims.

The Gate News article (April 17, 2026) explicitly states: 'Tron DAO has not released any formal governance proposals or technical documents; the related announcements are currently limited to Justin Sun's public statements.'

• https://beincrypto.com/tron-quantum-resistant-mainnet-2026/
• https://www.gate.com/news/detail/tron-launches-a-post-quantum-cryptography-upgrade-plan-detailed-roadmap-20381761

Claim: All JST transactions on TRON mainnet are authorized exclusively by ECDSA signatures. TRON's quantum-resistant upgrade is not deployed on mainnet.

Coverage basis: JST is a TRC-20 token inheriting TRON's ECDSA-based transaction signing. TRON mainnet uses ECDSA for all spend authorization.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All JST spend authorization is ECDSA-only — fully vulnerable to quantum key-recovery via Shor's algorithm

Assurance: TRON's reliance on ECDSA is well-established and publicly verifiable via Tronscan and protocol documentation. High confidence in the vulnerability claim.

TRC-20 token transfers require TRON account signatures. All TRON accounts use ECDSA key pairs. Public keys are exposed in every transaction, creating long-exposure attack surfaces.

• https://www.just.network/
• https://coinmarketcap.com/currencies/just/
• https://www.coingecko.com/en/coins/just

Claim: TRON addresses are derived from ECDSA public keys. Public keys are exposed on-chain with every transaction. No PQ/hybrid address scheme or key-derivation path exists.

Coverage basis: All JST holders use standard TRON addresses with ECDSA key pairs. Address reuse and long-exposure public keys are common.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: TRON's ECDSA-based address model exposes public keys on-chain, enabling offline quantum attacks on all transacted accounts

Assurance: High confidence — TRON's address derivation from ECDSA public keys is well-documented and publicly verifiable.

Long-exposure attack window: any JST holder who has ever sent a transaction has their public key permanently visible on-chain. This includes all governance participants, liquidity providers, and protocol-controlled addresses.

• https://coinmarketcap.com/currencies/just/
• https://www.just.network/docs/white_paper_en.pdf

Claim: TRON uses DPoS consensus with 27 Super Representatives. Validator authentication and block production rely on classical cryptographic signatures.

Coverage basis: JST inherits TRON's consensus security model. TRON DPoS uses classical signatures for block certification and validator authentication.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: TRON consensus authentication is classical — a quantum attacker could forge validator signatures and compromise finality for JST transactions

Assurance: High confidence — TRON's DPoS consensus mechanism and its reliance on classical cryptography is well-documented.

Under Token Inheritance (7.2), JST inherits TRON's consensus risk. A quantum compromise of TRON consensus would affect all JST transaction finality and governance execution.

• https://coinmarketcap.com/currencies/just/
• https://tron.guide/ecosystem/just/

Claim: TRON's state integrity (Merkle Patricia tree, block hashing) relies on classical hash functions (SHA3/Keccak). TRC-20 token balances are maintained in contract storage secured by classical cryptography.

Coverage basis: JST token state (balances, allowances) is stored in TRON contract storage. TRON's state binding uses classical hash functions.

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: Medium confidence — TRON's state-integrity mechanisms are documented but the quantum vulnerability of hash-based commitments (Grover's algorithm) is less severe than ECDSA breaks (Shor's). Classical hash functions retain meaningful quantum security with sufficient output length.

Hash-based state integrity is less immediately quantum-vulnerable than ECDSA-based spend authorization. SHA3-256 provides approximately 128-bit quantum security against Grover's algorithm, which may be adequate in the near term. However, no formal quantum assessment of TRON's specific hash constructions exists.

• https://www.just.network/docs/white_paper_en.pdf

Claim: JST is a transparent TRC-20 governance token with no privacy features. No shielded transactions, ZK proofs, or note encryption apply.

Coverage basis: JST has no privacy layer. All balances and transactions are publicly visible on TRON.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

N/A — JST has no privacy architecture to evaluate.

• https://www.just.network/
• https://coinmarketcap.com/currencies/just/

Claim: TRON's P2P layer uses classical cryptography for node identity and peer authentication. No PQ P2P protection exists.

Coverage basis: JST inherits TRON's P2P security model. TRON nodes use classical authentication.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: P2P-layer quantum vulnerability is less critical than spend authorization or consensus — P2P identity compromise does not directly enable asset theft or consensus corruption, though it could facilitate eclipse attacks.

While TRON P2P node identity uses classical cryptography, the QRI spec notes that P2P is satisfied by design when 'network identity is not consensus, spend, bridge, or custody-critical.' TRON's P2P authentication is not directly consensus-critical (DPoS block production is separate). However, as no formal design review confirms this separation, scored conservatively at 0.

Claim: No evidence of PQ-enabled wallet, custody, or hardware-wallet support for JST or TRON. All wallet workflows use ECDSA.

Coverage basis: No JST or TRON wallet supports PQ signing paths. TronLink, custodial solutions, and hardware wallets use classical ECDSA.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No wallet or custody solution supports PQ signing for JST — all user and institutional holdings are secured by quantum-vulnerable ECDSA keys

Assurance: High confidence — TRON ecosystem wallets (TronLink, etc.) are well-known to use standard ECDSA. No PQ wallet integration has been announced or evidenced.

The JustLend documentation describes wallet integration via TronLink and agent-based signing, all using classical ECDSA. Governance voting requires JST→WJST wrapping and ECDSA-signed transactions.

• https://www.just.network/
• https://docs.justlend.org/llms-full.txt

Claim: 0% of JST value-at-risk is quantum-protected. All ~$768M market cap and ~$6.9B JustLend DAO TVL reside on ECDSA-only TRON mainnet.

Coverage basis: JST circulating supply: ~8.54B tokens. Market cap: ~$768M. JustLend DAO TVL: ~$6.91B. All value is on classical TRON mainnet with zero PQ protection.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: 100% of JST value-at-risk (~$768M market cap, ~$6.9B TVL) is quantum-vulnerable with no production protection

Assurance: Market data from CoinMarketCap and CoinGecko (June 2026). TVL data from JUST DAO Q1 2026 letter.

Coverage is <25%, scoring 0 under Section 9.3.1 thresholds. The JustLend DAO Q1 2026 letter confirms $6.91B TVL and 482,248 users — all fully quantum-exposed.

• https://coinmarketcap.com/currencies/just/
• https://www.coingecko.com/en/coins/just
• https://justfoundation.medium.com/a-letter-to-jst-holders-b7bdffd8702c

Claim: No JST critical wallets (treasury, JustLend DAO, Timelock, exchange listings) have been migrated to PQ protection. All remain on ECDSA-based TRON addresses.

Coverage basis: JUST DAO treasury, Timelock (TRWNvb15NmfNKNLhQpxefFz7cNjrYjEw7x), and GovernorBravoDelegator (TEqiF5JbhDPD77yjEfnEMncGRZNDt2uogD) all use standard TRON ECDSA addresses.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: JustLend DAO treasury (~$83.6M net reserves), Timelock, and governance contracts are all quantum-vulnerable with no migration path

Assurance: Contract addresses confirmed via JustLend documentation. Treasury reserves of $83.6M confirmed in Q1 2026 DAO letter.

Critical addresses: GovernorBravoDelegator (TEqiF5JbhDPD77yjEfnEMncGRZNDt2uogD), Timelock (TRWNvb15NmfNKNLhQpxefFz7cNjrYjEw7x), JST token (TCFLL5dx5ZJdKnWuesXxi1VPwjLVmWZZy9). All are standard TRON ECDSA addresses.

• https://docs.justlend.org/llms-full.txt
• https://justfoundation.medium.com/a-letter-to-jst-holders-b7bdffd8702c

Claim: No legacy vulnerable JST pools, accounts, or contracts have been identified, measured, or deprecated by the JUST team. No quantum-vulnerable value inventory exists.

Coverage basis: No JST-specific quantum-vulnerability inventory or deprecation program has been published.

Implementation score: 0 · Evidence confidence: Very Low

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

Assurance: No evidence of any effort to identify, measure, or deprecate quantum-vulnerable JST holdings.

All 8.54B JST in circulating supply are held in quantum-vulnerable TRON accounts. No freeze, deprecation, burn, or migration mechanism exists for quantum-vulnerable JST positions.

Claim: TRON founder Justin Sun announced a quantum-resistant upgrade roadmap: testnet Q2 2026, mainnet Q3 2026. NIST algorithms (ML-DSA, SLH-DSA) named. No formal governance proposal or technical specification published.

Coverage basis: TRON-level roadmap applies to all TRC-20 tokens including JST. No JST-specific migration roadmap exists.

Implementation score: 0.25 · Evidence confidence: Low

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

Assurance: Roadmap is based on founder social-media posts and secondary reporting. No formal governance proposal, technical specification, or implementation plan has been published by Tron DAO as of the evaluation date.

Implementation Score 0.25 reflects 'Public design, draft specification, roadmap, ZIP/EIP/BIP-style proposal, or research plan.' The roadmap has sequencing (testnet→mainnet) and algorithm selection but lacks formal activation criteria, dependency analysis, and governance approval.

• https://beincrypto.com/tron-quantum-resistant-mainnet-2026/
• https://crypto.news/justin-sun-sets-2026-timeline-for-tron-quantum-resistant-upgrade/
• https://www.gate.com/news/detail/tron-launches-a-post-quantum-cryptography-upgrade-plan-detailed-roadmap-20381761

Claim: No PQ account creation, wallet tooling, transaction paths, custody support, user warnings, or migration prompts exist for JST. All user interactions default to ECDSA.

Coverage basis: No PQ infrastructure exists in the TRON or JST ecosystem.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No user-facing PQ migration path exists — all JST users are locked into quantum-vulnerable ECDSA workflows

Assurance: High confidence — JST ecosystem (JustLend, JustStable, TronLink) exclusively supports classical ECDSA workflows.

Governance voting requires JST→WJST wrapping and ECDSA-signed transactions. No PQ voting path is available or planned at the token level.

• https://www.just.network/
• https://docs.justlend.org/llms-full.txt

Claim: No migration enforcement mechanisms exist. No legacy signing deprecation, freeze capabilities, or exchange coordination for quantum-safe migration has been evidenced.

Coverage basis: No enforcement mechanisms at TRON or JST level.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The TRON roadmap announcement does not address enforcement, deprecation, or coordination mechanisms.

No evidence of coordination with exchanges (Binance, etc.), custodians, or wallet providers for a quantum-safe migration of JST.

Claim: No quantum-specific incident-response process, emergency disclosure mechanism, or governance procedure exists for JST or the JUST ecosystem.

Coverage basis: No evidence of quantum-specific emergency processes.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: JustLend documentation mentions security contact ([email protected]) and a Timelock-enforced governance process (~5-day minimum cycle), but no quantum-specific incident-response playbook exists. Per Note-Only Caveat Rule (7.4), absence of a formal quantum-specific IR playbook is note-only unless it leaves a current quantum-vulnerable path unresolved.

Note-only caveat: the absence of a formal quantum-specific IR playbook does not by itself create or worsen a quantum-vulnerable path. The existing Timelock provides a minimum 48-hour delay on governance execution.

• https://docs.justlend.org/llms-full.txt

Claim: TRON's announced quantum-resistant upgrade references NIST-standardized algorithms: ML-DSA (FIPS 204) as primary and SLH-DSA (FIPS 205) as backup. No implementation exists.

Coverage basis: Algorithm selection is at the proposal/announcement level only. No code, specification, or testnet implementation verifies the claim.

Implementation score: 0.25 · Evidence confidence: Low

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

Assurance: Algorithm claims are from secondary sources only. No primary technical documentation from TRON confirms the algorithm selection. ML-DSA and SLH-DSA are legitimate NIST standards (August 2024), lending credibility to the claim.

Implementation Score 0.25 reflects proposal-level algorithm selection. ML-DSA (FIPS 204, CRYSTALS-Dilithium) and SLH-DSA (FIPS 205, SPHINCS+) are appropriate NIST-standardized choices for blockchain transaction signing.

• https://coira.io/news/tron-post-quantum-cryptography-nist-mainnet
• https://www.gate.com/news/detail/tron-launches-a-post-quantum-cryptography-upgrade-plan-detailed-roadmap-20381761

Claim: No independent cryptographic audit exists for TRON's quantum-resistant implementation (not yet built). CER.live audit of JST smart contracts is a standard DeFi security audit, not quantum-specific.

Coverage basis: No quantum-critical implementation exists to audit. CER.live audit covers JST contract security only.

Implementation score: 0 · Evidence confidence: Low

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

Assurance: CER.live audit is scope-mismatched for quantum readiness — it addresses standard smart-contract security, not post-quantum cryptography or key migration. No quantum-specific audit exists because no quantum implementation exists.

Score 0.00 because no quantum-critical implementation exists to audit. The CER.live audit provides baseline DeFi contract assurance but is irrelevant to quantum-readiness assessment.

Claim: TRON (java-tron) is open-source, but no quantum-resistant code exists in the repository. No PQ implementation is available for review or reproduction.

Coverage basis: No PQ code exists in TRON repositories as of the evaluation date.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: TRON is generally open-source, but the quantum-critical implementation does not exist and therefore cannot be verified as open-source or reproducible.

Score reflects absence of any quantum implementation, not closed-source concerns. If/when TRON publishes PQ code, this subfactor should be re-evaluated.

Claim: TRON's announcement mentions using multiple NIST algorithms (ML-DSA primary, SLH-DSA backup), suggesting some parameter agility thinking, but no formal documentation exists.

Coverage basis: Algorithm flexibility is implied by multi-algorithm selection in secondary sources but not formally documented.

Implementation score: 0 · Evidence confidence: Very Low

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

Assurance: Multi-algorithm mention appears only in secondary reporting. No primary documentation of parameter agility, upgrade path, or cryptographic agility design exists.

Score 0.00 because no formal parameter agility or upgrade documentation exists. The mention of backup algorithm (SLH-DSA) is encouraging but unverifiable.

• https://coira.io/news/tron-post-quantum-cryptography-nist-mainnet

Claim: No quantum implementation exists, so stateful-signature safety considerations (e.g., for XMSS/LMS) are not yet applicable in production. TRON's proposed algorithms (ML-DSA, SLH-DSA) are stateless.

Coverage basis: ML-DSA and SLH-DSA are stateless NIST standards, avoiding stateful-signature risks like XMSS/LMS. No implementation exists to evaluate for side-channel or custody risks.

Implementation score: 0 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: ML-DSA and SLH-DSA are stateless by design, eliminating the state-management risks associated with XMSS/LMS. However, side-channel and fault-injection risks for these algorithms in blockchain contexts have not been analyzed for TRON's specific deployment.

Note-only caveat: algorithm choice (stateless NIST standards) avoids the most severe stateful-signature risks. No implementation exists to evaluate for side-channel or custody-specific risks.

• https://coira.io/news/tron-post-quantum-cryptography-nist-mainnet

Claim: General awareness exists that PQC signatures are ~10x larger than ECDSA, but no TRON-specific performance analysis, block-validation impact study, gas/fee market analysis, or node hardware assessment has been published.

Coverage basis: Secondary sources mention the 10x signature size challenge generically. No TRON-specific analysis exists.

Implementation score: 0 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Gate News article notes the 10x signature size challenge and TRON's high USDT transaction volume as a concern, but this is journalistic analysis, not a TRON-published performance study. Per Note-Only Caveat Rule (7.4), lack of formal performance benchmark is note-only.

Note-only caveat: the absence of a formal performance benchmark does not by itself create a quantum-vulnerable path. However, TRON's high transaction volume (billions in USDT daily) makes PQC performance analysis especially important for safe deployment. This should be monitored.

• https://www.gate.com/news/detail/tron-launches-a-post-quantum-cryptography-upgrade-plan-detailed-roadmap-20381761