What it is. Tron is a public blockchain, live since 2018, whose dominant asset is a single dollar-pegged token: about 91 billion dollars of it held across roughly 76 million addresses.
What we found. Tron has published a real engineering plan and its own figures for what the change would cost, about ten times the data per transaction and a top transaction rate roughly a tenth of today's.
Why it matters. Until that cost is paid on the live network, every balance there stays behind protection a future quantum computer could break, and Tron has not said what happens to the money nobody moves in time.
Tron mainnet accepts no post-quantum signature and signs every transaction and block under ECDSA secp256k1: mainline java-tron's Tron.proto carries no PQ field, and live queries on 2026-08-20 return 79 mainnet chain parameters with no PQ key and a node codeVersion of 4.8.2.1 with no PQ suffix. The whole PQ program is TIP-899 (Draft, filed 2026-07-01), which selects FN-DSA-512 (Falcon-512, NIST-selected 2022-07-05, no draft FIPS 206 published) as preferred scheme with ML-DSA-44 per FIPS 204 as hedge and is governance-active for FN-DSA-512 on the Nile testnet only, while mainnet activation sits behind two chain-parameter proposals gated on a third-party audit with no stated plan and a Super Representative vote with no date, so mainnet PQC traffic is 0%, the mainnet-traffic cap holds QRI at or below 60 against a raw 22, and Gate 1a-Sig fails on strictly single-scheme block production and relay handshakes.
Summary
QRI 22 ± 4, Band 3 Planning, Migration Stage 2. Mainnet signing is ECDSA secp256k1 alone, with SHA-256 signature targets, Keccak-256 address derivation, and a shielded TRC-20 pool on Groth16 over BLS12-381 (TIP-135/137) left out of migration scope. TIP-899 (Draft, filed 2026-07-01) picks FN-DSA-512 (Falcon-512, NIST-selected, no draft FIPS 206 published) as preferred scheme, ML-DSA-44 per FIPS 204 as hedge, excludes SLH-DSA per FIPS 205 on signature size (7,856 B against 617-667 B), keeps the 21-byte address format, adds a PQAuthSig field to Transaction, BlockHeader and HelloMessage, and puts five TVM precompiles behind two reversible chain-parameter proposals under hard-fork version VERSION_4_8_2_PQ1. The code ships only in the Nile testnet client as tagged PQ1 builds; live queries on 2026-08-20 return getAllowFnDsa512 = 1 on Nile, ML-DSA-44 inactive, and no PQ parameter among the 79 on mainnet. Mainnet PQC traffic is 0% and activation waits on a third-party audit with no stated plan plus a Super Representative vote with no date. Block production and relay handshakes are strictly single-scheme and the account-layer 2-of-2 option carries no combiner analysis, so Gate 1a-Sig fails; no KEM is in scope, so Gate 1a-KEM fails; the PQ portfolio is lattice-only, so the Cryptographic-Diversity Cap fires.
Forge. Forge-dominant: this chain secures value and operations with signatures, so the principal quantum risk is forgery of spends and attestations once Shor breaks secp256k1. There is no harvest-now component for forgery, the public key alone enables it, and Tron's account model reveals the public key on first spend. Decrypt and harvest-now-decrypt-later apply only to transport and RPC confidentiality, where the P2P layer is unencrypted and the RPC edge is classical TLS 1.2 over ECDH P-256.
2 announced → 0 shipped on mainnet under a named primitive. narrative-only (>5.0) under the rubric's mainnet-shipped definition. announced_count is a verified floor, not a media census: it counts the announcement artifacts we could independently confirm, the founder's 2026-04-14 X post as reported and the trade-press report of it, both of which state that TRON will adopt NIST-standardized post-quantum signatures on mainnet. Zero mainnet bytes have shipped under any named PQ primitive as of 2026-08-20, so the ratio is unbounded and the tag stands however the announcement side is counted. The character has changed since July 2026: a Draft TIP naming exact primitives (FN-DSA-512, ML-DSA-44), PQ code merged and released in the Nile testnet client, and a live Nile FN-DSA-512 activation now exist, delivered with no accompanying press we could locate, so recent engineering outruns recent announcement, but the mainnet claim itself remains unshipped and undated..
What the gates say
- Gate 1a, Hybrid signature: FAIL , TIP-899 documents an account-level 2-of-2 option, a permission set holding an ECDSA secp256k1 key at weight 1 and an FN-DSA-512 or ML-DSA-44 key at weight 1 with threshold 2 so both must sign, and the permission machinery is live on mainnet under TIP-16 with the PQ key type active on the Nile testnet, so the composition limb is satisfied on paper and constructible on a public testnet. The gate still fails on three counts: no combiner security analysis exists, no SUF-CMA-preservation or non-malleability argument for the combined authorization, and the TIP's own Test Cases section requires that the verification cache compare both the ECDSA and pq_auth_sig fields to stop a forged PQ signature sharing the same txid from inheriting an already-verified flag, so the handling is txid-relevant; block production (BlockHeader.pq_auth_sig) and relay handshakes (HelloMessage.pq_auth_sig) are strictly single-scheme, mutually exclusive with the legacy ECDSA field, so a Super Representative or node that switches runs pure FN-DSA-512 or ML-DSA-44 with no classical fallback; and the account layer leaves a classical-only path open by default (threshold-1 configurations are accepted and labelled 'same as the status quo'), with PQ-only named as the strongest configuration and a future FORBID_ECDSA_SIGN proposal listed as the end state, which is pure-PQ replacement. Nothing is on mainnet. Consequence: QRI cap 60, Stage cap 4
- Gate 1a, Hybrid KEM: FAIL , no KEM of any kind in the PQ scope: the netty pipeline in TRON's official P2P networking library attaches a 60-second read-timeout handler, TCP traffic statistics, protobuf varint length prepender and frame decoder, and a message handler, with no SslHandler and no cipher handler, so inter-node gossip is plaintext protobuf over TCP; classical TLS exists only where gateways terminate HTTPS for RPC, and both TRON public gateways negotiate TLS 1.2 with ECDHE-RSA-AES128-GCM-SHA256 over ECDH P-256 (checked 2026-08-20), a fully classical key exchange; TIP-899 adds PQ authentication to the relay handshake but no ML-KEM and no hybrid X25519+ML-KEM combiner anywhere
- Gate 1b, Commit-to-hash: COND , no OR-composition of a committed classical+PQ key pair is declared; TIP-899's scheme-enum dispatch adds or substitutes keys per permission entry rather than composing two schemes under one committed public key, so Gate 1b does not attach
- Gate 2, Evidence reconstruction: PASS , every sub-score reconstructible from public artifacts within 48 hours: the Draft TIP and its public comment thread, the TIPs registry, mainline java-tron release history and protocol definitions, the Nile testnet client repository's branch, pull-request, tag and release history, java-tron source for the shielded pool and the official P2P library source for the transport pipeline, the public npm registry entry for the independent SDK, TRON's official developer documentation, the USDT TRC-20 contract's on-chain ABI and total supply, and live chain-parameter, node-info, witness-list and genesis-block responses from TRON's official public mainnet and Nile RPC gateways, reproducible by any third party issuing the same standard calls
- Gate 3, Primitive naming: PASS , every sub-score names exact primitives: ECDSA secp256k1, SHA-256, Keccak-256, FN-DSA-512 / Falcon-512, ML-DSA-44 per FIPS 204, SLH-DSA per FIPS 205 where discussed-and-excluded, ECDHE over NIST P-256 with AES-128-GCM and SHA-256 at the RPC edge, and Groth16 over BLS12-381 with Jubjub-curve note keys for the shielded TRC-20 pool, the last reconstructed from java-tron client source because TRON's own TIP-135/137 text does not name the proving system or curve
Burn-vs-rescue policy on file
Declared option f, Undeclared. Tron Foundation has not published a policy on what happens to unmigrated balances after a quantum-motivated mainnet cutover. The April 14, 2026 founder announcement, as reported by trade press, committed TRON to adopting NIST-standardized post-quantum signatures on mainnet; we found no statement in it, and no statement anywhere else, setting out what becomes of balances that do not migrate, and no enforcement mechanism. The most consequential question, what happens to USDT TRC-20 balances held in unmigrated multisig vaults, exchange hot wallets, or smart-contract escrows, is unanswered. TIP-899 (Draft, 2026-07-01) declares no policy either: it adds FN-DSA-512 / ML-DSA-44 keys to the permission system and keeps the address format, and its 'Future Phases' list names three undated, unspecified ideas, two of which point in opposite directions, a FORBID_ECDSA_SIGN proposal under which the network would accept only PQ signatures (a freeze outcome for unmigrated ECDSA secp256k1 accounts) and a RecoverAccountByZkContract recovery path relying on post-quantum SNARKs (Plonky2 / STARK), neither with a spec, a date, or a statement of which legacy balances it would cover.
Seven dimensions
Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.
1 Cryptographic Exposure weight 15% 30 / 100
TIP-899 (Draft, filed 2026-07-01) names Tron's PQ primitives precisely, including canonical wire encodings and per-scheme length constraints enforced at verification: FN-DSA-512 preferred, ML-DSA-44 as hedge, SLH-DSA considered and excluded for signature size. Official developer documentation still lists only ECDSA secp256k1 (fetched 2026-08-20) and there is still no single canonical primitive-inventory document. The shielded TRC-20 pool (TIP-135/137, governance-enabled on mainnet, getAllowShieldedTRC20Transaction = 1 confirmed 2026-08-20) adds a pairing-based proof system whose curve and proving system are named nowhere in the TIP text; we reconstructed Groth16 over BLS12-381 from the java-tron client source (Sapling spend/output parameters loaded through a librustzcash JNI wrapper whose upstream Sapling prover is bellman::groth16 over bls12_381::Bls12, plus Jubjub point and scalar size constants in the shielded-pool parameters). Tron has not closed that inventory gap itself.
ECDSA over secp256k1 (account/transaction signing and Super Representative block signing; official developer documentation states the signature algorithm is ECDSA and the selected curve is SECP256K1) · SHA-256 (transaction and block signature targets: txid = SHA-256(Transaction.raw), blockHash = SHA-256(BlockHeader.raw) per TIP-899 §4) · Keccak-256 (address derivation: 0x41 prefix + last 20 bytes of Keccak-256 of the public key; TVM/EVM-compatible state and event hashing) · Groth16 over BLS12-381 with Jubjub-curve note keys (shielded TRC-20 pool per TIP-135 Shielded TRC-20 Contract + TIP-137 verification precompiles, both Final, created 2020-03-04 and 2020-03-09; Sapling-circuit lineage loaded through java-tron's librustzcash wrapper with Tron-specific parameter files; proving system and curve reconstructed from client source, not named in the TIP text) · ECDHE over NIST P-256 with AES-128-GCM and SHA-256 (TLS 1.2 at the public RPC gateway edge, mainnet and Nile, checked 2026-08-20) · FN-DSA-512 (Falcon-512; NIST-selected 2022-07-05, no draft FIPS 206 published; TRON wire format is the 896-byte untagged public polynomial h with the 0x09 reference header stripped, and a 617-667 byte headed compressed signature), TIP-899 preferred scheme, governance-active on Nile testnet only · ML-DSA-44 (Dilithium2, FIPS 204; 1,312-byte public key, 2,420-byte fixed signature), TIP-899 hedge scheme, specified but not active on any network Every primitive in active mainnet signing use remains Shor-vulnerable. The PQ-safe additions run only on the Nile testnet (FN-DSA-512) or exist only in the Draft spec (ML-DSA-44), and the mainnet shielded pool rests on pairing-based Groth16 over BLS12-381, which Shor breaks via the pairing curve, so the one confidentiality-bearing surface on mainnet is also quantum-vulnerable.
ECDSA secp256k1→ Shor-break-via-DL-without-pairings (100% of mainnet signing traffic)SHA-256→ Grover-weaken (256→128bit)Keccak-256→ Grover-weaken (256→128bit)Groth16 over BLS12-381 (shielded TRC-20 pool, TIP-135/137)→ Shor-break-via-pairings (proof soundness) plus Shor-break-via-DL on Jubjub for note key agreement; scored equivalent-to-ECDSA-exposure for the shielded surfaceECDHE over NIST P-256 (RPC gateway TLS 1.2)→ Shor-break-via-DL-without-pairings (transport confidentiality at the RPC edge only)FN-DSA-512 (Nile testnet only)→ PQ-safe lattice (NIST-selected, not finalized; tier-3b confidence discount)ML-DSA-44 (specified, inactive)→ PQ-safe lattice (FIPS 204, finalized)
0 PQ families deployed on mainnet (lattice 0, hash-based 0, code 0, isogeny 0). The TIP-899 portfolio is one family at the mathematical-foundation level: FN-DSA-512 and ML-DSA-44 are both lattice schemes, and adding Falcon alongside Dilithium adds no diversity. SLH-DSA (hash-based, FIPS 205) was excluded in the TIP body itself, which places it out of scope for excessive signature size (7,856 B against FN-DSA-512's 617-667 B); it was never raised as a fallback in the public comment thread, where a reviewer instead argued lattice security margins are tight and that cryptographic agility through the scheme registry is the right hedge, which the TIP author accepted. Agility is therefore the stated mitigation in place of a second family. The Cryptographic-Diversity Cap (lattice-monoculture with no hash-based or code-based fallback) now applies to Tron's PQ posture: QRI capped at 60 until a second family is deployed at the consensus-client level. Even once TIP-899 reaches mainnet, this sub-score sits at the lattice-only hard cap of 5.
Mainnet: ECDSA secp256k1 (128-bit classical, no NIST PQC category); SHA-256 and Keccak-256 (pre-PQC NIST hashes); Groth16 over BLS12-381 in the shielded pool (no PQC category). TIP-899's thread pins the categories for its selections: the TIP author states FIPS 204 classifies ML-DSA-44 as Category 2 except where key generation uses an RBG below 192-bit strength, and FN-DSA-512 targets Category 1 per the Falcon submission and has no finalized standard to certify against. Neither carries any mainnet weight yet, so no primitive in active mainnet use holds a NIST PQC category label.
Mainnet crypto unchanged: java-tron ECDSA secp256k1, no published dudect or constant-time validation, no independent cryptographic audit of the signing layer located. The PQ work now has a real reference implementation merged into the Nile testnet client (a crypto/pqc package wrapping BouncyCastle's FNDSA512 and MLDSA44, with FN-DSA-512 signature length constrained to 617-667 B and over-size resampling capped at 16 retries, plus bundled amd64/aarch64 native libraries, a central PQSchemeRegistry, five TVM precompiles with energy-cost calibration against the existing ValidateMultiSign 1500/sig anchor, and KAT vectors and signature-length boundary tests listed under Test Cases; the reference pull request carried 81 commits across 108 files, +12,827/-284 lines) plus third-party interoperability evidence (an independent gRPC SDK shipped FN-DSA-512 signing tested against Nile, publicly documenting key-tag, signature-length-convergence and transaction-versus-precompile encoding pitfalls). Held down because: no third-party audit of the PQ implementation is scheduled (author statement, 2026-07-20); cross-platform Falcon key-generation is stated in the TIP itself to be FFT-based and not bit-stable across JVMs or CPU architectures, mitigated by a recommendation to persist the full keypair rather than the seed rather than resolved; the provenance of the bundled native libraries is not stated and no reproducible build ties the deployed verifier to audited source; and FN-DSA-512 is cryptanalytic tier 3b (selected-but-not-final).
2 Quantum Recovery Exposure weight 10% 11 / 100
Tron's account model does not store the ECDSA public key on chain; nodes recover it from the signature on first outbound transaction, so any account that has ever spent has revealed its public key. USDT TRC-20 is the dominant on-chain asset: the Tether USD contract on Tron mainnet reports a total supply of 91,271,979,522.007211 USDT (6 decimals, about $91.27B) across 75,967,528 holders, independently reproduced against TRON's own RPC gateway and a public block explorer on 2026-08-20. Multisig vaults, exchange hot wallets, and active retail addresses all reveal public keys with each transaction.
Mainnet block 1 carries timestamp 2018-06-25T01:51:09Z, so roughly eight years of balances have accumulated behind ECDSA secp256k1. TIP-899's Motivation sizes the harvest-now risk using Bitcoin's exposed-public-key figure and publishes no Tron-specific equivalent, and we located no public dataset measuring dormant or exposed-public-key TRX or TRC-20 balances. The exposure is therefore unquantified on the Tron side: we can state that never-spent accounts keep their public key hidden behind the Keccak-256 address and that every spent account does not, but we cannot state what fraction of value sits in either group. Scored low and flagged as a measurement gap rather than credited for a concentration profile we cannot evidence.
Every historical TRX transaction is ECDSA-signed; signatures permanently embedded in the chain become forgeable post-Shor for any account whose public key is or becomes known. No protocol-level signature-rotation primitive exists; TIP-899's migration path is a permission update that adds a PQ key, not a rotation of the historical signature scheme.
TRON's official P2P networking library has no transport encryption. Its connection pipeline, read from the public source, attaches a 60-second ReadTimeoutHandler, TCP traffic statistics, a protobuf varint length prepender, a varint frame decoder and the message handler, with no SslHandler and no cipher handler of any kind; a repository-wide search for TLS, Noise, ECIES, AES and cipher returns no hits, so inter-node gossip is plaintext protobuf over TCP. Classical TLS exists only where gateways terminate HTTPS for RPC: both public gateways negotiate TLS 1.2 with ECDHE-RSA-AES128-GCM-SHA256 over an ECDH P-256 temp key (checked 2026-08-20), which is a fully classical, Shor-breakable key exchange with no hybrid ML-KEM. TIP-899 adds PQ authentication to the relay handshake (a PQAuthSig on HelloMessage) but no KEM of any kind, no ML-KEM, no hybrid combiner. On-chain payloads are public by design (transparent ledger), so the harvest-now-decrypt-later surface is transport metadata and captured RPC traffic.
3 Metadata, Anonymity & Confidentiality weight 13% 18 / 100
Pseudonymous transparent ledger; USDT TRC-20 transactions are fully observable on public explorers. One shielded surface exists: the TIP-135 Shielded TRC-20 pool (mint/transfer/burn operations hiding source address, destination address, and amount behind a Groth16 note design) is live and governance-enabled on mainnet (getAllowShieldedTRC20Transaction = 1, confirmed 2026-08-20). We located no published usage statistics for it and no evidence of material adoption, so graph visibility remains effectively total in practice. A separate de-anonymization pressure is verifiable on chain rather than asserted: the dominant asset's contract is issuer-controlled, exposing addBlackList, removeBlackList, getBlackListStatus, isBlackListed, destroyBlackFunds and pause in its published ABI, so address-level flagging and freezing of the largest value pool on Tron is an issuer capability that exists today, independent of the protocol.
TronGrid, TRON's own public gateway infrastructure, serves both the mainnet and Nile RPC endpoints used throughout this card and is the endpoint TRON's developer surface points at; no published market-share breakdown across Tron RPC providers exists, so this card makes no share claim. The consensus set is small and directly observable: 27 active Super Representatives out of 441 registered witness candidates (live query, 2026-08-20), which concentrates mempool observability at the block-producing layer regardless of RPC distribution. No publicly declared validator-metadata retention policy was located.
USDT is issued natively on both Ethereum and Tron by the same issuer, so moving USDT between them proceeds by issuance and redemption against a single issuer rather than by a trust-minimized bridge, which places source-to-destination correlation with that issuer by construction. The same issuer capability is verifiable in the contract itself: the Tron USDT TRC-20 ABI exposes owner-controlled addBlackList / removeBlackList / destroyBlackFunds and an isBlackListed query, so per-address action at the issuer level is a live function of the mainnet contract, not an inference. Beyond that, no public source ranks which bridges carry the most Tron flow, so this tile is scored on what is verifiable and marked down for the unverified remainder rather than resting on a named bridge list we could not confirm.
Shor on secp256k1 retroactively exposes any pseudonymous Tron address whose public key has been revealed, which is almost every active account, since public keys are recoverable from every broadcast signature. The one confidentiality-bearing surface, the TIP-135 shielded TRC-20 pool, rests on Groth16 over BLS12-381 with Jubjub-curve note key agreement (Sapling lineage): Shor on the pairing curve breaks proof soundness and Shor on Jubjub recovers the note-encryption shared secrets, so every harvested shielded note becomes readable and every shielded transfer traceable. TIP-899 explicitly scopes its PQ work to four signature channels (transactions, SR block production, node relay handshakes, and TVM), leaving the shielded pool's proof system and note encryption outside the migration plan.
An on-chain cryptographic hiding mechanism exists and is named. The TIP-135 Shielded TRC-20 Contract (a shielded note pool using NoteCommitment/nullifier/anchor semantics, proofs verified through the TIP-137 TVM precompiles, Groth16 over BLS12-381) has been Final since 2020 and governance-enabled on mainnet, confirmed active 2026-08-20. Scored 5 rather than 10-15 because it is computationally secure at best on a Shor-breakable pairing curve, has no mix-node infrastructure, cover traffic, or batch-ordering, publishes no usage data we could locate, and is excluded from the PQ migration scope.
4 Migration Architecture weight 10% 63 / 100
TIP-899 specifies a central PQSchemeRegistry (per-scheme seed length, signature length, public-key length, hash function, verify function, address-computation function) with scheme-enum dispatch over an algorithm-agnostic PQAuthSig envelope, reserves enum values 3 to 15 for future schemes, and the TIP author has publicly confirmed (2026-07-17) that new parameter sets or algorithm families can be added without changing the common signature envelope. Activation reuses TRON's production governance machinery: two independent, reversible chain-parameter proposals (ALLOW_FN_DSA_512 = 1000, ALLOW_ML_DSA_44 = 1001) behind hard-fork version VERSION_4_8_2_PQ1 (fork version 37), and this exact mechanism has been exercised on the Nile public testnet, where the FN-DSA-512 proposal is voted active and the ML-DSA-44 proposal is not. The TIP's 'Future Phases' list also sketches an SR emergency proposal channel (6-hour voting window, 22-of-27 threshold, immediate effect), undated and unspecified. Deductions: the registry exists only in a Draft TIP and the Nile testnet client, adding a scheme still requires a new TIP plus code plus governance, the version flag still requires a coordinated hard fork, and nothing is demonstrated on mainnet.
Credit rests on a key-rotation primitive that is live on mainnet. Tron's account model (TIP-13 Account System Standard, created 2018-12-21, and TIP-16 Account Multi-signature, created 2018-12-27, both Final and TIP-16 flagged hard-fork) separates the account address from its signing keys: owner, active and witness permissions each hold weighted keys with a threshold, and an AccountPermissionUpdateContract replaces or adds keys without changing the address, assets, contract bindings or whitelists. The machinery is confirmed live on mainnet by the chain parameter getAllowMultiSign = 1 (2026-08-20). TIP-899 cites this as the per-user opt-in migration path and documents it as 'Path 1 (Recommended): in-place permission replacement', a single permission update that adds an FN-DSA-512 or ML-DSA-44 key and rebalances weights so that no purely-ECDSA signing set can satisfy the threshold, with PQ key generation shipped in the Nile Toolkit (pq-key new) and in an independent SDK. Scored 11: there is no ERC-4337 or EIP-7702-class programmable account abstraction, no PQ key type exists on mainnet, wallet-side BIP-39/32-style HD derivation for PQ keys is intentionally left undefined in the TIP (author statement, 2026-07-07) and remains an Open Question, and no client-layer PQ path carries transaction volume anywhere.
Tron Foundation coordinates upgrades through java-tron releases, and the record is verifiable rather than asserted: twelve GreatVoyage releases published between 2023-10-25 (v4.7.3 Chilon) and 2026-07-31 (v4.8.2.1 Heraclitus), a steady cadence across the v4.7 and v4.8 lines with no competing mainnet client fork located. Consensus-affecting changes ship behind numbered version flags, of which TIP-899's VERSION_4_8_2_PQ1 is stated to be fork version 37. The cost is governance-centralization, not coordination failure.
The rubric asks whether hybrid classical-plus-PQ is architecturally possible rather than merely announced, and Tron now clears that bar at the account layer: TIP-899's Account Migration section documents a 2-of-2 configuration (keys = ECDSA secp256k1 weight 1 and FN-DSA-512 or ML-DSA-44 weight 1, threshold 2, tabulated as 'No (both required)' for whether ECDSA alone satisfies the threshold) as one of its accepted in-place migration configurations, the permission-weight machinery that enforces it has run on mainnet since TIP-16 and is confirmed live by getAllowMultiSign = 1, and the PQ key type is governance-active on the public Nile testnet, so a 2-of-2 hybrid account is constructible on a public network today. Scored 10 rather than higher because block production (BlockHeader.pq_auth_sig) and relay handshakes (HelloMessage.pq_auth_sig) are strictly single-scheme, mutually exclusive with the legacy field, so consensus and transport signing cannot be hybrid under this design; the TIP treats the 2-of-2 as one option among four tabulated configurations, names PQ-only as the strongest and keeps threshold-1 classical-satisfiable setups listed as 'same as the status quo'; no combiner security analysis (no SUF-CMA-preservation or non-malleability argument) is published; and the code lives in the Nile testnet client, not mainline java-tron.
Default for stateless schemes. Tron does not use stateful hash-based schemes (XMSS per RFC 8391, LMS, or leanXMSS) in any deployed or announced form; neither TIP-899 nor the TIPs registry contains any such scheme.
Tron's DPoS uses 27 Super Representatives with single-signer ECDSA secp256k1 block signing, and TIP-899 keeps this shape: BlockHeader.pq_auth_sig is a single signature, mutually exclusive with the legacy witness_signature field, with no BLS aggregation anywhere in consensus, and the TIP's Backwards Compatibility section states the PBFT module introduces no PQ signatures at this stage to minimize the impact surface. Per v3.1 rule, 4f is N/A for chains using non-aggregating signatures at consensus. Excluded from the Dim 4 denominator rather than treated as a zero. Not scored, so it is left out of the dimension total rather than counted as a zero.
5 Deployment Execution weight 22% 15 / 100
0% PQC mainnet signing traffic. No PQ primitive is deployed on mainnet: live chain-parameter and node-info queries against TRON's official public mainnet gateway (2026-08-20) return 79 chain parameters with no PQ-related key of any kind and a node codeVersion of 4.8.2.1 with no PQ suffix, whereas the Nile gateway returns 81 parameters including getAllowFnDsa512 = 1 and a codeVersion of 4.8.2.1.PQ1_build1. Since TIP-899 gates PQ signature acceptance on the activation proposals, an unactivated mainnet rejects PQ signatures by construction. All mainnet signing remains ECDSA secp256k1.
Zero PQ code merged in mainline java-tron, the production client. This is verified at the protocol definition rather than inferred from release notes: mainline java-tron's core Tron.proto on master contains no occurrence of pq_auth_sig, PQAuthSig, PQScheme, FN_DSA or ML_DSA, against 14 occurrences in the Nile testnet client's copy of the same file, and releases v4.8.1.1 (2026-06-02), v4.8.2 (2026-07-15), and v4.8.2.1 (2026-07-31) list no PQ items. The PQ implementation is real but lives in the Nile testnet client repository, a fork of java-tron maintained under the Nile testnet organization: the reference pull request (81 commits, 108 files, +12,827/-284 lines, opened 2026-06-24 against the release_v4.8.2_build2 line) was closed unmerged and superseded by a build branch merged into that repository's master branch on 2026-07-16, and the repository has published tagged releases GreatVoyage-Nile-v4.8.2-PQ1-build1 (2026-06-30), GreatVoyage-Nile-v4.8.2-PQ1-build2 (2026-07-16), and GreatVoyage-Nile-v4.8.2.1-PQ1-build1 (2026-08-03). The public Nile gateway node runs the last of these (codeVersion 4.8.2.1.PQ1_build1). Scored for live, versioned testnet-client code with the heavy testnet-only deduction the rubric requires.
Zero Super Representatives have PQC signing keys in active use on mainnet; consensus signing is ECDSA-only, and the localPqWitness configuration section TIP-899 defines is effective only after the corresponding activation proposal passes, which has not happened on mainnet.
Still voided per v3.1 (5a = 0). Independently of the void: TIP-899 names no dated mainnet milestone, mainnet activation is gated on a third-party audit whose plan the author stated on 2026-07-20 has not yet been determined, and on a Super Representative governance vote with no date. Track record on prior self-published dates: the Q2-2026 testnet target (stated 2026-05-21 in the originating feature issue) was missed by the letter, since the TIP was filed 2026-07-01 and the first tagged Nile PQ1 build is dated 2026-06-30 with the deployed build following in Q3; the mainnet target reported in April 2026 press has no TIP-backed date.
Announced: the 2026-04-14 founder announcement and its trade-press report, both claiming NIST-standardized PQ signatures on mainnet. Shipped, under the rubric's definition of mainnet bytes signed under the named primitive: zero, so the ratio is unbounded and the narrative-only tag stands. Scored above the floor because the claims now have real partial follow-through the ratio does not credit: a Draft TIP naming FN-DSA-512 and ML-DSA-44 exactly with canonical wire encodings, PQ code merged and released in the Nile testnet client under three tagged builds, and a live Nile FN-DSA-512 activation, delivered with no accompanying press we could locate through 2026-08-20, the inverse of the April pattern.
Disclosed, chain-specific figures now exist in TIP-899's published 500-run benchmark: an average TRX transfer grows from 175 bytes to about 1,668 bytes under FN-DSA-512 (about 9.5x) and to about 3,851 bytes under ML-DSA-44 (about 22x), with the TPS ceiling modeled to fall from about 3,809 to about 400 (10.5% of baseline) under full FN-DSA-512 adoption and about 173 (4.5%) under full ML-DSA-44 adoption. Verification CPU actually improves (91 microseconds for FN-DSA-512 and 165 for ML-DSA-44 against 962 for ECDSA), so the TIP correctly identifies transaction size, not verification cost, as the bottleneck. Phase 1 broadcasts the full public key per PQ transaction (896 B for FN-DSA-512, 1,312 B for ML-DSA-44); the Phase-2 public-key registry meant to remove that overhead is marked draft in the TIP and remains a tracked Open Question. The implementation caps PQ transactions per pending pool and per block (1,000 each) rather than de-penalizing them, and the fee model for PQ transactions is listed as Open Question 1. Scored in the 5-10x band for the preferred, testnet-active FN-DSA-512, reduced for the 22x ML-DSA-44 hedge, the unresolved Phase-2 overhead, and the absence of any aggregation, batching, or fee-de-penalization mechanism.
6 Supply Chain Vendor Readiness weight 22% 9 / 100
We located no PQC roadmap naming primitives or a migration timeline from any Tron wallet, including TronLink, the browser and mobile wallet most commonly integrated against Tron dApps. A developer identifying as being from Bearby, a web3 wallet that states in the public TIP-899 thread that it focuses on quantum resistance and has already implemented quantum-resistant key storage, reviewed TIP-899 on 2026-07-04 and flagged that BIP-39/32-style HD derivation for FN-DSA-512 / ML-DSA-44 keys is undefined; the TIP author confirmed on 2026-07-07 that this is intentionally still open pending the protocol-layer wire format. That is verified vendor engagement in the spec process, and it is the only positive artifact on this tile, so the tile stays near the floor. This card asserts no ranked top-3 wallet list, because no public source publishes one.
The one cross-chain mechanism we can evidence for Tron is issuer-side rather than a bridge protocol: USDT is natively issued on both Ethereum and Tron by the same issuer, so cross-chain movement is issuance and redemption, and no PQC migration commitment from that issuer was located. No public source establishes which bridge protocols carry material Tron flow, and a check of one widely-integrated general-purpose bridge's own supported-networks documentation did not list Tron, so it is not carried. This tile therefore rests entirely on the absence of any located PQC commitment across the Tron bridging surface, with no positive artifact behind it, and is flagged in the source-disagreement block as an evidence gap.
Custodian rankings and a statement of intent could not be verified and are not carried. What is verifiable: the largest single custodial surface on Tron is the Tether USD TRC-20 contract itself, holding 91,271,979,522.007211 USDT across 75,967,528 holders (2026-08-20), whose issuer has published no PQC migration plan for its multi-chain issuance infrastructure that we could locate. No public source publishes a ranked list of exchange custodians of TRX and TRC-20 USDT, and none of them publishes a PQC roadmap, so this tile is an absence check with no positive artifact and is flagged as an evidence gap.
TronGrid, TRON's own public gateway infrastructure, already serves the PQ-enabled surface: the Nile gateway exposes the FN-DSA-512 activation through the standard wallet/getchainparameters RPC as getAllowFnDsa512 = 1 (independently reproduced 2026-08-20), and the TIP author confirmed on 2026-08-12 that activation state is designed to be programmatically discoverable through that call without custom tooling. An independent SDK (a TypeScript gRPC client, v2.2.0 published to the public npm registry at 2026-07-13T13:22:58Z) shipped FN-DSA-512 signing its maintainers state was tested against Nile. Against that, the gateway TLS edge itself is fully classical (TLS 1.2, ECDHE-RSA-AES128-GCM-SHA256, ECDH P-256), and we located no PQC roadmap from any RPC provider, HSM vendor, or TEE attestation chain serving Tron, so the tile remains low.
7 Governance & Coordination weight 8% 30 / 100
27 active Super Representatives out of 441 registered witness candidates (live query, 2026-08-20), re-elected each maintenance cycle, which the chain parameter getMaintenanceTimeInterval sets at 21,600,000 ms, that is 6 hours. Block production is therefore concentrated in 27 signers at any time. TIP-899 states that PQ activation requires a 27-SR on-chain proposal vote to pass, one per scheme. We do not publish a Nakamoto-coefficient figure or a claim about the composition of the SR set: no primary source establishes a collusion threshold or a beneficial-ownership mapping, and the sub-score rests on the verified set size alone.
Foundation-coordinated hard forks ship on a steady cadence: twelve mainline java-tron releases published between 2023-10-25 and 2026-07-31, with consensus-affecting changes gated behind numbered version flags. Centralized coordination is a strength for execution velocity and a weakness for resilience under adversarial pressure on the foundation itself.
Named: Justin Sun (founder, public face); Tron DAO; Tron Foundation. New since May 2026, the PQ migration has a named de facto coordination lead: Tron Network engineer Federico Zhen, the author of record on TIP-899 and on TIP-135/137, filed the originating feature request on 2026-05-21 and TIP-899 on 2026-07-01, and has personally answered a sustained stream of external technical objections through 2026-08-12 across 30 public comments, covering cross-platform Falcon key-generation determinism, consensus-determinism of the native libraries, mempool txid-cache handling, wallet key derivation, third-party-audit status, NIST category assignment, and public-key storage trade-offs. Still no published mandate document or formally chartered PQ working group, and TIP-899 has not yet reached the All Core Devs agenda step its own process requires to move from Draft to Accepted: it remains an open issue, no tip-899.md exists in the TIPs repository, and it does not appear in the registry table.
Scored on the precedents that are sourceable. Tron has a verified record of routine coordinated upgrades (twelve mainline releases in the trailing three years, consensus changes behind version flags) and of governance-gated parameter activation, exercised on the public testnet for FN-DSA-512. No primary source records any precedent of Tron coordinating a cryptographic-primitive change, or any consensus change, while under adversarial or regulatory pressure; a regulatory action and an asset-freeze event are sometimes cited in this context, but neither is corroborable from a primary source, so neither is counted. The one adversarial-action capability that is verifiable is not Tron's: the dominant asset's TRC-20 contract exposes issuer-controlled blacklisting and fund destruction, which is operator-level control over token balances, not protocol-level cryptographic coordination. Scored on routine-coordination evidence only, with no adversarial precedent credited.
None located. No community honeypot, no rate-limited spending rule, no cryptographic tripwire embedded in consensus, and nothing of the kind in TIP-899 or the TIPs registry.
Source-disagreement disclosure
v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.
TIP-899 states the reference implementation is 'currently deployed on Nile Testnet' without distinguishing its two primitives. Live chain-parameter queries against TRON's official public Nile gateway (2026-08-20) show getAllowFnDsa512 = 1 and the node running codeVersion 4.8.2.1.PQ1_build1, while getAllowMlDsa44 returns no value, meaning that proposal is not active. An independent SDK vendor's 2026-07-13 release, which its maintainers state was tested against Nile with FN-DSA-512 active, corroborates. We therefore treat the testnet deployment as independently confirmed for FN-DSA-512 specifically and as specified-but-inactive for ML-DSA-44.
TIP-899 labels FN-DSA-512 as 'FIPS 206 draft' in its scheme enum, Abstract, Rationale and References. No draft FIPS 206 has been published: NIST's post-quantum project page describes Falcon as selected for ongoing standardization with that process still underway, and both the initial-public-draft and final publication paths for FIPS 206 return 404 (checked 2026-08-20), while FIPS 204 and FIPS 205 resolve. FN-DSA is NIST-selected (announced 2022-07-05) and a deployer today builds against the Falcon submission specification the TIP itself references. A public reviewer in the TIP thread made the same point on 2026-07-15, citing floating-point determinism concerns and advising against mainnet activation, and the TIP author's reply (2026-07-16) accepts that final FIPS 206 changes, especially key encoding and floating-point requirements, must be considered before mainnet activation. We score FN-DSA-512 as selected-but-not-final (tier 3b) and treat the TIP's label as a status error, not a standard.
TIP-899's candidate-size table names the excluded hash-based option 'SLH-DSA-128s' with a 32 B public key and a 7,856 B signature. FIPS 205 defines no parameter set by that name: its 128-bit small-signature sets are SLH-DSA-SHA2-128s and SLH-DSA-SHAKE-128s, which are distinct instantiations. The sizes quoted match the FIPS 205 128s shape, so we read this as an abbreviation rather than a substantive error, but the TIP does not state which hash family it costed and we do not infer one.
The originating feature issue (2026-05-21) and TIP-899 frame the goal as making Tron the first major public blockchain to complete a full PQ migration. This is Tron's claim about itself, not an independently verified fact, and the deployment record it implies does not yet exist (Draft TIP, one primitive active on testnet, zero mainnet deployment). We log the framing as evidence of stated ambition and score only the shipped record. LayerQu makes no ranking claim of its own here.
TRON's official developer documentation still states that the signature algorithm is ECDSA on curve SECP256K1, with no mention of post-quantum work, Falcon, FN-DSA, ML-DSA or Dilithium anywhere on the page (fetched 2026-08-20), while TIP-899 and the Nile testnet build are well ahead of it. This is consistent with the TIP's Draft status (no tip-899.md registry file exists yet in the TIPs repository, and TIP-899 does not appear in the registry table), but the lag means a third party reading only official documentation would find no trace of the PQ program.
The April 2026 announcement drew trade-press coverage within days; the substantive engineering that followed (TIP-899, the Nile client releases, the Nile FN-DSA-512 activation) drew no press coverage we could locate through 2026-08-20. The public press record therefore overstated Tron's PQ progress in April and understates it in August; this card scores the engineering record. We record this as a negative search result, not as proof that no coverage exists.
Two gaps we could not close from public sources. First, TIP-899's Motivation quantifies the harvest-now risk using Bitcoin's exposed-public-key figure and publishes no Tron-specific dormant-balance or exposed-address dataset; we located none elsewhere, so Dim 2's sizing rests on the account model (public keys are recovered from every broadcast signature) rather than on a measured Tron figure. Second, for the bridge and custodian vendor tiles no public source ranks which bridges and custodians carry the most Tron flow, so those tiles are scored purely on the absence of any located PQC commitment rather than on a ranked vendor set. Both are flagged rather than filled.
Delta-QRI under alternative weighting
Under a deployment-heavy weighting (Dim 5 raised to 27%, Dim 4 cut to 5%, other weights held), QRI falls to about 20, which sits exactly on the Band 2 / Band 3 boundary; under an architecture-heavy weighting (Dim 4 raised to 20%, Dim 5 cut to 12%), QRI rises to about 27, Band 3 unchanged. The cap structure is unaffected in both cases: the binding constraint is the raw score, not any cap.
Announcement-to-shipped ratio
Announced: 2. Shipped: 0. Ratio: 999.
Tag: narrative-only (>5.0) under the rubric's mainnet-shipped definition. announced_count is a verified floor, not a media census: it counts the announcement artifacts we could independently confirm, the founder's 2026-04-14 X post as reported and the trade-press report of it, both of which state that TRON will adopt NIST-standardized post-quantum signatures on mainnet. Zero mainnet bytes have shipped under any named PQ primitive as of 2026-08-20, so the ratio is unbounded and the tag stands however the announcement side is counted. The character has changed since July 2026: a Draft TIP naming exact primitives (FN-DSA-512, ML-DSA-44), PQ code merged and released in the Nile testnet client, and a live Nile FN-DSA-512 activation now exist, delivered with no accompanying press we could locate, so recent engineering outruns recent announcement, but the mainnet claim itself remains unshipped and undated.
Peers in the L1 profile
9 chains closest to Tron by Stage then QRI.