TRON TRX

Claim: TRON's official documentation and open-source java-tron repository describe ECDSA secp256k1 usage for all account operations and SR block signing; no formal quantum threat model has been published.

Coverage basis: Public documentation and source code serve as a de facto cryptographic inventory but do not constitute a formal quantum threat model covering attack assumptions, affected assets, or affected layers.

Implementation score: 0.25 · Evidence confidence: High

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

Quantum blocker: No formal quantum threat model exists; quantum risk is acknowledged only through public statements by Justin Sun without an evidence-backed assessment document.

Assurance: The ECDSA usage is well-documented in official sources and verifiable from source code. The absence of a formal threat model is the primary gap.

Public documentation effectively inventories ECDSA secp256k1 as the sole signature algorithm. No inventory of affected layers, attack assumptions, or quantum threat scenarios has been published by TRON DAO.

• https://tronprotocol.github.io/documentation-en/mechanism-algorithm/account/
• https://developers.tron.network/docs/account
• https://github.com/tronprotocol/java-tron
• https://developers.tron.network/docs/transaction-signature-validation

Claim: TRON maintains open-source code (java-tron), official documentation, and has undergone a ChainSecurity audit (2024), but none of these specifically support a quantum risk assessment.

Coverage basis: General development transparency provides evidence of classical cryptography usage but no quantum-specific assessment evidence.

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: ChainSecurity audit (September 2024) is stale but relevant for classical design; it has no quantum or PQC scope. Source code is publicly verifiable.

Evidence exists for classical cryptography implementation but none for quantum-specific assessment, migration planning, or PQC verification.

• https://github.com/tronprotocol/java-tron
• https://www.chainsecurity.com/security-audit/java-tron
• https://developers.tron.network/docs/concensus

Claim: All TRON transactions are signed with ECDSA secp256k1. Official documentation and source code (ECKey.java) confirm this. No PQC or hybrid signature path exists on mainnet.

Coverage basis: 100% of production transactions use ECDSA secp256k1; zero PQC or hybrid coverage.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: ECDSA secp256k1 signatures are vulnerable to Shor's algorithm; all spend authorization can be compromised by quantum key-recovery from exposed public keys.

Assurance: Classical ECDSA usage is confirmed by multiple independent official sources, source code, and the ChainSecurity audit. No dispute exists about the current production state.

TRON's account model mirrors Ethereum: addresses are Keccak-256 hashes of ECDSA public keys. Public keys are exposed on-chain upon first outgoing transaction.

• https://tronprotocol.github.io/documentation-en/mechanism-algorithm/account/
• https://developers.tron.network/docs/transaction-signature-validation
• https://github.com/tronprotocol/java-tron

Claim: TRON accounts use ECDSA secp256k1 key pairs with addresses derived via Keccak-256 of the public key. Public keys are exposed on-chain upon first transaction, creating long-exposure vulnerability.

Coverage basis: All ~380M accounts follow the ECDSA secp256k1 address model. No PQ/hybrid account type or address format exists.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Every active TRON account that has sent at least one transaction exposes its ECDSA public key on-chain, creating a long-exposure (at-rest) attack surface for offline quantum key-recovery.

Assurance: Address derivation and public-key exposure mechanics are well-documented and verifiable from source code and on-chain data.

Dormant accounts that have never sent a transaction have not exposed their public keys, but this is a minority of accounts by value given TRON's high-velocity stablecoin usage.

• https://developers.tron.network/docs/account
• https://tronprotocol.github.io/documentation-en/mechanism-algorithm/account/

Claim: TRON's DPoS consensus relies on 27 Super Representatives signing blocks with their ECDSA secp256k1 private keys. No PQC or hybrid validator signature mechanism exists.

Coverage basis: All 27 SRs use ECDSA secp256k1 for block signing. Zero PQC coverage in consensus authentication.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Quantum compromise of SR ECDSA keys would enable malicious block production, chain reorganization, transaction censorship, and consensus failure. SR keys are continuously exposed through block signing (long-exposure).

Assurance: DPoS consensus mechanism and SR block signing are documented in official sources and verifiable from source code and on-chain block data.

The 27-SR set concentrates consensus security. A quantum adversary would need to compromise only a subset of SR keys to disrupt or corrupt consensus.

• https://developers.tron.network/docs/concensus
• https://developers.tron.network/docs/dpos
• https://tronprotocol.github.io/documentation-en/mechanism-algorithm/dpos/

Claim: TRON uses classical cryptographic commitments for state integrity. Shielded transactions use zk-SNARKs with BLS12-381 pairings. No quantum-safe state-binding mechanism exists.

Coverage basis: State integrity relies on classical cryptographic assumptions throughout. Zero PQC coverage.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: BLS12-381 pairings used in shielded-transaction zk-SNARKs are quantum-vulnerable. A quantum adversary could forge proofs, break soundness, and compromise shielded state integrity.

Assurance: The shielded-transaction protocol is documented in TIP-135 and the TRONZ whitepaper. BLS12-381 pairings are explicitly referenced. No formal quantum-security analysis of the zk-SNARK system has been published.

Shielded transactions represent a small fraction of TRON's total value-at-risk but carry independent quantum vulnerability via pairing-based cryptography.

• https://developers.tron.network/v4.7.2/docs/tronz-implementation-details
• https://github.com/tronprotocol/tips/blob/master/tip-135.md

Claim: TRONZ shielded transactions use Groth16 zk-SNARKs with BLS12-381 pairings and Jubjub elliptic curve. Note encryption, viewing keys, and shielded state are all quantum-vulnerable.

Coverage basis: The entire shielded-transaction privacy stack depends on quantum-vulnerable cryptographic assumptions.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: Quantum computers can break BLS12-381 pairings and Jubjub discrete log, compromising zk-SNARK soundness, deanonymizing shielded transfers, and enabling forged privacy transactions.

Assurance: The shielded-transaction protocol is specified in the TRONZ whitepaper and TIP-135. No independent quantum-security audit of the privacy layer has been identified.

The privacy layer vulnerability is independent of ECDSA spend authorization. Even if base-layer signatures were migrated to PQC, the shielded-transaction privacy guarantees would remain quantum-vulnerable.

• https://www.tronz.io/Shielded%20Transaction%20Protocol.pdf
• https://tronprotocol.github.io/documentation-en/mechanism-algorithm/shielded-transaction/
• https://github.com/tronprotocol/tips/blob/master/tip-135.md

Claim: TRON's P2P networking layer (migrated to libp2p v1.2.0) uses classical cryptographic mechanisms for node identity and transport security.

Coverage basis: P2P layer relies on classical cryptography. No evidence of PQC integration in the networking stack.

Implementation score: 0 · Evidence confidence: Low

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

Assurance: P2P cryptography is not separately documented in official sources. The assessment is based on the java-tron release notes referencing libp2p and general lack of PQC in the networking stack.

P2P identity compromise is less critical than spend authorization or consensus authentication compromise, but quantum-vulnerable P2P could enable node impersonation and eclipse attacks that facilitate other quantum exploits.

• https://github.com/tronprotocol/java-tron/releases/tag/GreatVoyage-v4.8.1

Claim: No TRON wallet, custody provider (Anchorage Digital, BitGo, Zerohash), or HSM is known to support PQC or hybrid signing for TRX or TRC-20 assets.

Coverage basis: All wallet and custody workflows depend on ECDSA secp256k1. Zero PQC support in the custody ecosystem.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: Institutional custody providers (Anchorage, BitGo) use ECDSA secp256k1 for TRON asset control. No PQC custody path exists for institutional or retail TRX/TRC-20 holdings.

Assurance: Custody providers publicly document TRON support using standard ECDSA address formats. No provider has announced PQC custody support for TRON assets.

Anchorage Digital added TRON custody in 2026 but uses standard ECDSA secp256k1 address/key formats. No PQC custody path is documented.

• https://www.anchorage.com/insights/anchorage-digital-adds-support-for-tron-with-institutional-custody-and-staking-infrastructure
• https://developers.bitgo.com/docs/tron

Claim: Approximately $90.9B in stablecoin supply (USDT), ~$26B in TVL, and ~$30B TRX market cap across ~380M accounts. Zero percent of this value is protected by PQC or hybrid cryptography.

Coverage basis: 0% of total value-at-risk is quantum-protected. All value depends on ECDSA secp256k1.

Implementation score: 0.05 · Evidence confidence: High

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

Quantum blocker: Substantially all of TRON's ~$90.9B stablecoin supply and ~$26B TVL is quantum-vulnerable with no migration or protection path. The network processes ~$23B in daily USDT transfers, all ECDSA-only.

Assurance: Value-at-risk figures are independently verifiable from TRONSCAN, DefiLlama, Nansen Q1 2026 report, and CoinDesk Research. The 0% PQC coverage is unambiguous.

Coverage score of 0.05 (1/20) reflects the <25% coverage threshold per QRI spec. Even the minimum score overstates actual protection, which is zero.

• https://trondao.org/research/tron-q1-2026-quarterly-report
• https://nansen.ai/post/tron-q1-2026-report
• https://www.coindesk.com/research/tron-network-q1-2026

Claim: No TRON treasury, foundation wallet, exchange custody wallet, bridge contract, or major protocol wallet has been migrated to PQC or hybrid cryptography.

Coverage basis: Zero critical wallets are quantum-protected.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Tron Inc. holds ~681M TRX (~$200M) in treasury, all ECDSA-controlled. No critical wallet migration has occurred or been announced.

Assurance: Tron Inc. public filings confirm TRX treasury holdings. No evidence of PQC migration for any critical wallet.

SR operator wallets, exchange hot/cold wallets, JustLend DAO, and USDD protocol-controlled wallets all remain ECDSA-only.

• https://tronscan.org/#/sr/representatives
• https://www.stocktitan.net/sec-filings/TRON/10-q-tron-inc-quarterly-earnings-report-b38dfd724592.html

Claim: No program exists to identify, measure, deprecate, freeze, or migrate quantum-vulnerable accounts or balances on TRON.

Coverage basis: Zero legacy-pool identification or management.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No mechanism exists to identify, freeze, deprecate, or migrate quantum-vulnerable legacy accounts. All ~380M accounts would need to self-migrate with no protocol-level enforcement or assistance.

Assurance: Absence of legacy-pool management is confirmed by the lack of any TIP, governance proposal, or documentation addressing this topic.

TRON's account model (similar to Ethereum) means all accounts that have sent transactions have exposed public keys. No protocol-level mechanism exists to address dormant, lost, or unresponsive vulnerable accounts.

Claim: Justin Sun announced a PQC roadmap on X (April 2026) targeting Q2 2026 testnet and Q3 2026 mainnet deployment of NIST-standardized algorithms (ML-DSA, FN-DSA, SLH-DSA). No formal governance proposal, TIP, or technical specification has been published.

Coverage basis: Roadmap announcement exists as a public statement but lacks sequencing, activation criteria, dependencies, and formal governance backing.

Implementation score: 0.25 · Evidence confidence: Very Low

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

Quantum blocker: The roadmap is an unsubstantiated public statement with no supporting code, TIP, formal governance, or technical specification. It does not materially reduce quantum risk for current production users.

Assurance: All evidence for the roadmap derives from Justin Sun's social media posts and news coverage. TRON DAO has not released any formal governance proposal or technical documentation. Evidence confidence is Very Low.

As of the evaluation date, the planned GreatVoyage-v4.8.2 (Pyrrho) release (Q2 2026) lists no PQC-related TIPs in its published scope on the tronprotocol/pm repository.

• https://news.bitcoin.com/justin-sun-unveils-tron-post-quantum-plan-as-crypto-security-debate-grows/
• https://crypto.news/justin-sun-sets-2026-timeline-for-tron-quantum-resistant-upgrade/
• https://beincrypto.com/tron-quantum-resistant-mainnet-2026/

Claim: No PQC/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist for TRON users.

Coverage basis: Zero migration accessibility.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No user-facing migration path exists. Users cannot create PQ accounts, sign with PQ keys, or migrate existing assets to quantum-safe addresses.

Assurance: Absence of migration tooling is confirmed by the lack of any wallet, SDK, or documentation supporting PQC account operations.

TRON's wallets (TronLink, Wallet-cli) and SDKs support only ECDSA secp256k1 key operations.

Claim: No enforcement mechanisms exist for deprecation, freeze, disabled legacy signing, restricted withdrawals, or mandatory migration. No exchange, custody, bridge, or wallet coordination for quantum-safe migration has occurred.

Coverage basis: Zero migration enforcement or ecosystem coordination.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No enforcement or coordination mechanism exists. All accounts, exchanges, and custody providers remain on ECDSA-only paths with no plan or ability to restrict quantum-vulnerable transactions.

Assurance: Absence is confirmed by the lack of any TIP, governance proposal, exchange announcement, or protocol feature addressing migration enforcement.

TRON DAO's governance process (TIP-based, SR voting) has not been used to propose or discuss any quantum-migration enforcement measures.

Claim: No quantum-specific incident-response process, disclosure policy, or emergency governance procedure has been published by TRON DAO or the java-tron core development team.

Coverage basis: General security processes may exist but no quantum-specific process is documented.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: operational/product caveat · Score treatment: note-only

Assurance: TRON may have internal security processes through TRON DAO governance, but no quantum-specific incident-response framework is publicly documented. This is treated as note-only since a formal playbook's absence does not independently create a quantum-attack path.

The absence of a quantum-specific IR playbook is an operational gap rather than a direct quantum vulnerability. It would become score-reducing if it prevented verification of a migration or protection capability.

Claim: TRON's production system uses only ECDSA secp256k1. No NIST-standardized PQC algorithms (ML-DSA, SLH-DSA, FN-DSA) are implemented in production, testnet, or published code.

Coverage basis: Zero PQC algorithm usage in any production or test environment.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No NIST-standardized or broadly reviewed PQC algorithm is implemented in any TRON production or test environment.

Assurance: Absence of PQC algorithms is verifiable from the java-tron source code, release notes, and official documentation. The roadmap mentions NIST algorithms but no implementation exists.

Justin Sun's announcement named ML-DSA (FIPS 204), FN-DSA (Falcon), and SLH-DSA (FIPS 205) as targeted standards, but this is a roadmap claim only with no supporting implementation.

• https://github.com/tronprotocol/java-tron
• https://github.com/tronprotocol/java-tron/releases/tag/GreatVoyage-v4.8.1

Claim: No independent audit of any PQC implementation exists because no PQC implementation exists. The ChainSecurity audit (2024) covers classical components only.

Coverage basis: Zero PQC audit coverage.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The ChainSecurity audit is stale (September 2024) and has no quantum or PQC scope. It provides assurance for the classical design only. No PQC audit exists to evaluate.

Audit absence is a direct consequence of no PQC implementation existing. This would become a higher-priority gap if/when PQC code is developed.

• https://www.chainsecurity.com/security-audit/java-tron

Claim: java-tron is fully open-source (LGPLv3) and its ECDSA implementation is publicly verifiable. No PQC implementation exists to be open-source or reproducible.

Coverage basis: Classical implementation is open-source. PQC implementation is nonexistent.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: The classical java-tron codebase is open-source and buildable. This subfactor would receive credit if/when a PQC implementation exists and is open-source.

Open-source classical implementation earns no credit in this quantum-focused subfactor since no PQC code exists.

• https://github.com/tronprotocol/java-tron

Claim: No documented parameter agility or PQC upgrade path exists for TRON's cryptographic parameters. The system is hard-coded to ECDSA secp256k1.

Coverage basis: Zero parameter agility for quantum migration.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The java-tron codebase hard-codes secp256k1 as the signature algorithm. No plugin architecture or algorithm negotiation mechanism is documented.

The roadmap announcement suggests intent to upgrade but provides no technical detail on how cryptographic agility would be achieved at the protocol level.

Claim: No PQC signature implementation exists to evaluate for stateful-signature safety (XMSS/LMS anti-reuse), side-channel resistance, or custody integration risks.

Coverage basis: Not applicable — no PQC implementation exists.

Implementation score: 0 · Evidence confidence: None

Issue classification: none · Score treatment: not applicable

Assurance: This subfactor cannot be evaluated because no PQC implementation exists. The roadmap mentions SLH-DSA (SPHINCS+, a stateless hash-based scheme) and ML-DSA/FN-DSA (lattice-based), none of which have the stateful-signature concerns of XMSS/LMS.

If SLH-DSA is adopted, stateful-signature safety is not a concern (SPHINCS+ is stateless). If ML-DSA is primary, side-channel and fault-injection considerations for lattice-based signatures would need evaluation.

Claim: No performance or resource-impact analysis has been published for PQC signature deployment on TRON. PQC signatures are estimated to be ~10x larger than ECDSA, which could materially affect TRON's ~10M daily transaction throughput.

Coverage basis: No performance analysis exists.

Implementation score: 0 · Evidence confidence: Very Low

Issue classification: operational/product caveat · Score treatment: note-only

Assurance: The ~10x signature size increase is a well-known property of NIST PQC standards and is cited in multiple news sources covering the TRON announcement. TRON DAO has not published any analysis of how this would affect block size, throughput, storage, or fee markets.

This is treated as note-only because the absence of a performance analysis does not independently create a quantum-attack path. It would become score-relevant when a PQC implementation exists and resource constraints could prevent safe deployment.