Tron Is Testnet-Only: Three Post-Quantum Migration Paths Compared

Executive Summary

No major L1 in this comparison has a protocol-level post-quantum signature scheme live on mainnet in our sources as of 13 October 2026. Tron has working code on its Nile testnet, where FN-DSA-512 has been activated by a committee proposal. Its mainnet proposal, TIP-899, is still a draft awaiting an external audit and a Super Representative vote. Describing Tron as ahead can confuse working testnet code with a deployed, protected network. A conflict in the sources over Algorand's status (native Falcon-based accounts versus plans for 2027) is unresolved, so we make no "first" claims for any chain.

The binding constraint is not the choice of algorithm. It is migrating legacy accounts and absorbing much larger transactions. Tron's own tracking issue puts an average TRX transfer at about 9.5 times its current size with Falcon-512 and about 22 times with ML-DSA-44. Signature verification, by contrast, benchmarks faster than ECDSA.

The more useful comparison is between three migration philosophies. Tron proposes opt-in coexistence on a live chain. Solana, Ethereum and Bitcoin follow conditional, programme-based or draft-stage roadmaps. Starknet is considering a new L1 so it can rebuild the stack. The reality is a gap between testnet code, draft proposals and 2029-era targets. Readers should treat headline dates as intentions, not deployments.

Market Context

The 13 October snapshot is below. In the snapshot of 13 October 2026, about 10:01-10:02 UTC (DefiLlama/CoinGecko), BTC traded near $83,574 with a market cap of $1.68 trillion. ETH was $2,513 ($306.85 billion), SOL $107 ($63.02 billion) and TRX $0.3295 ($31.30 billion). STRK was $0.0887 with a market cap of $657.74 million (10:08 UTC).

Value at stake is uneven. DefiLlama chain TVL on the same day was $51.58 billion on Ethereum, $6.11 billion on Solana, $5.60 billion on Tron, $4.49 billion on Bitcoin and $165.72 million on Starknet. Ethereum's chain TVL is roughly nine times Tron's (DefiLlama, 13 October 2026). Starknet's ambitions matter for design lessons more than for the value it secures.

Tron's rollout matters mainly because of stablecoins. Total stablecoin supply was $312.90 billion on 13 October, of which USDT was $184.02 billion (58.8%). Much USDT activity runs on Tron, but the snapshot has no per-chain USDT figure, so we do not quote a Tron-specific stablecoin total.

The Tron news is recent. Justin Sun posted on X on 10 October that Tron's post-quantum cryptography is live on testnet and that mainnet can follow "at any time". He also said Tron is set to be one of the few major blockchains that is quantum-resistant before "Q-Day". The post followed Starknet's 8 October statement that it is considering becoming an L1.

Where Post-Quantum Security Stands on 13 October 2026

The state of play is a ladder of maturity, and no chain is on the top rung. The table in the data section sets out each chain's status and target. The evidence shows four stages.

• Testnet code: Tron's Nile testnet runs two post-quantum signature schemes. Ethereum client teams run weekly interoperability devnets. BIP-360 was reported running on BTQ Technologies' quantum testnet.
• Draft proposals: Tron's TIP-899 and Bitcoin's BIP-360 and BIP-361 are drafts, not activated rules.
• Conditional roadmaps: Solana's official post commits to research now and adoption only if the threat becomes credible.
• Intentions to rebuild: Starknet says it is "actively considering becoming an L1" and targets 2027 for being fully quantum-resistant.

Nothing in that list protects a mainnet account today. Tron's own reporting is explicit: mainnet assets remain protected only by the existing ECDSA system until a separate upgrade occurs. Our sources show no protocol-level post-quantum signature scheme live on mainnet for Ethereum, Solana or Bitcoin. Solana has an opt-in Winternitz Vault, which is an ecosystem feature rather than a protocol change.

The practical consequence is a split timeline. Tron's latest statement is undated (earlier year-end 2026), Starknet targets 2027, Ethereum around 2029 and Bitcoin has no activation date. Readers should compare these on what is built, not what is announced.

Tron: What Exists on Testnet and What TIP-899 Still Needs

What was built

Tron's Nile testnet deployed build GreatVoyage-v4.8.2-PQ1-build1 on 30 June 2026. It supports two post-quantum signature schemes: FN-DSA-512 (Falcon-512 based) and ML-DSA-44 (Dilithium based). They cover user transactions, block signing, peer-to-peer handshakes and smart-contract verification through new TVM precompiles. FN-DSA-512 was activated on Nile through Committee Proposal 20628 on 2 July 2026.

This is real engineering across four layers. TIP-899 covers user transactions, Super Representative block production, node-to-node authentication and TVM signature verification. The two algorithms have separate governance switches. The java-tron tracking issue gates them by proposal 99 (ALLOW_FN_DSA_512) and proposal 100 (ALLOW_ML_DSA_44); the Nile activation used Committee Proposal 20628, and we have not reconciled the numbering. The Account structure is left unchanged.

The issue excludes SLH-DSA from the first cycle because its signatures are too large.

What is still missing

TIP-899 remains in draft as of 12 October 2026. Before activation it requires an external cryptographic and implementation audit, publication of an audit summary before the Super Representative vote, and bug-bounty coverage for the new components. None of these is reported as complete.

The tracking issue also lists unresolved engineering items.

• Storage and database write-amplification impact is described as an open question with no conclusion yet, needing stress testing before mainnet.
• TVM precompile energy pricing is not finalized.
• Any block-size increase would need a separate TIP.
• Audit sequencing was still under discussion.

In our view, these open items could extend the schedule. The stated timeline has already moved. BeInCrypto reported testnet activation in Q2 2026 and mainnet in Q3 2026. In August, Tron DAO and Sun were reported as targeting completion "by year-end". On 10 October, Sun gave no date. The timeline has moved from Q3 2026 to year-end to undated, which is not proof of failure but gives no firm date.

One more reading caution applies. Crypto Briefing reports that Tron released a "quantum-resistant address solution" in the first half of 2026. We could not reconcile it with TIP-899, so we do not treat it as mainnet protection.

Standards footing

The two schemes sit on different standards footings. ML-DSA-44 was standardized by NIST in 2024 as FIPS 204. Falcon-512 is being developed as FN-DSA under FIPS 206, which Tron's own issue still labels draft. We did not open a NIST page to confirm FIPS 206's status, so we rely on Tron's issue and FinanceFeeds. The issue describes ML-DSA-44 as the finalized hedge against the still-draft FN-DSA standard. That is a sensible design choice, and it also means Tron's mainnet activation could precede a final standard for one of its two schemes.

The Size Tax: Why Transaction Bytes, Not Verification Speed, Bind

Verification speed is not the constraint. Verification is faster with post-quantum signatures. In Tron's benchmarks (a 500-run average), ECDSA verification takes 962 μs, Falcon-512 takes 91 μs and ML-DSA-44 takes 165 μs. In these benchmarks, post-quantum verification is not slower than ECDSA verification.

Size is the problem. The key and signature sizes in Tron's issue are below. We use the issue's Falcon-512 signature figure of up to 752 B. Crypto Briefing cites a cap of 667 B, and the discrepancy is unresolved.

Table: key and signature sizes as listed in java-tron issue #6793, 13 October 2026.

Tron's design carries the post-quantum public key inside each transaction (the issue's Option B). Post-quantum schemes lack ECDSA-style key recovery, so the key cannot be derived from the signature. Option A, storing keys on chain, was rejected as higher-risk and "virtually irreversible" once shipped. The cost is that an average TRX transfer grows from 175 B to about 1,668 B with Falcon-512 (about 9.5x) or about 3,851 B with ML-DSA-44 (about 22x).

The throughput effect follows from the byte count. The issue's ceiling model puts the baseline at about 3,809 TPS with pure ECDSA. At 10% Falcon-512 adoption it falls to about 2,055 TPS, a drop of roughly 46% (our calculation). At 100% Falcon-512 it is about 400 TPS, roughly a tenth of baseline (our calculation). At 100% ML-DSA-44 it is about 173 TPS.

These are Tron's own modelled figures, not measured mainnet results. They matter because even partial adoption has a visible cost, since mixed blocks carry the larger transactions. Larger blocks are possible only through a separate TIP, which adds another governance step.

The lesson generalizes. Any chain retrofitting post-quantum signatures onto an account-and-transaction format built around compact ECDSA signatures faces the same arithmetic. The algorithm choice (Falcon versus ML-DSA) moves the multiple from about 9.5x to about 22x. It does not remove the problem.

Three Migration Philosophies

Philosophy 1: opt-in coexistence on a live chain (Tron, proposed)

Tron's proposed approach would keep the chain running and let each account migrate when it chooses. Path 1 is an in-place permission update that adds a post-quantum-derived key and keeps the old address. Path 2 is moving all assets to a new post-quantum account. For staked or frozen assets, path 2 means unfreezing and waiting out the unlock window first.

The benefit is continuity: no flag day, and addresses can stay the same. The cost is that safety depends on user behaviour. Tron's issue says the rebalancing step is mandatory. If the ECDSA key alone can still meet the signing threshold, an attacker who breaks that key still controls the account. Adding a post-quantum key then provides no real protection.

This is a technical point. A permission set where either key can sign is only as strong as the weaker key. Accounts that never rebalance remain exposed, and so do accounts that add a key and forget the old one. The migration is opt-in per account, not automatic for users. The scale of unprotected value at the end of any opt-in window is the open question, and no data on it exists yet.

Philosophy 2: conditional, programme-based and draft-stage roadmaps

Three chains sit here, with different degrees of commitment.

Solana has the most explicitly conditional plan. Its official "Solana's Quantum Readiness" post sets three steps: continue research and keep evaluating Falcon and its alternatives; if quantum becomes a credible threat, adopt a post-quantum scheme for new wallets; then migrate existing wallets. It also credits the Blueshift Solana Winternitz Vault as an ecosystem path to quantum resilience. The vault uses Winternitz One-Time Signatures, a hash-based scheme that generates a new key for each use, and is opt-in rather than a protocol change. One outlet says Solana "has selected Falcon". Solana's own wording says it will keep evaluating Falcon and alternatives, and we use the latter.

In our analysis, a trigger-based plan that migrates new wallets first and existing wallets afterwards leaves older wallets exposed until the later step.

Ethereum treats the problem as a multi-year engineering programme. The Ethereum Foundation formed a dedicated Post-Quantum Security team, led by Thomas Coratger, in January 2026. A biweekly post-quantum breakout call was added to the All Core Developers process. On 25 March 2026 it launched pq.ethereum.org, and more than 10 client teams were running weekly interoperability devnets. CoinDesk describes a years-long migration across execution, consensus and data layers that aims to avoid a disruptive cutoff.

A secondary write-up (DEV Community) describes the Lean Ethereum roadmap as replacing consensus-layer BLS signatures with leanXMSS compressed by leanVM, targeting 2029 for foundational post-quantum infrastructure. Treat that detail as secondary. The 2029 date is for core infrastructure, not a completed migration of every account.

Bitcoin splits into two drafts. BIP-360 (Pay-to-Merkle-Root, P2MR) was published in February 2026. It introduces a new output type that removes Taproot's quantum-vulnerable key-path spend. Cointelegraph notes it adds no new post-quantum signature scheme and gives no automatic upgrade: old UTXOs stay vulnerable until users manually move funds. CryptoSlate reports that BIP-360 was already running on BTQ Technologies' quantum testnet.

BIP-361 is a follow-on draft that builds on BIP-360 and is deliberately coercive. Its Phase A, three years after activation of a quantum-resistant address type, blocks new sends to vulnerable address formats. CryptoSlate frames the choice as one between "frozen" and "stolen" coins. Neither draft has a mainnet activation date in our sources.

For scale, Tron's issue claims that over 6.9 million BTC (about one-third of supply) sit at addresses whose public keys are already exposed. That is Tron's motivation text, not an independent audit. Circulating BTC supply is about 20.1 million, per DefiLlama.

Philosophy 3: start a new chain so the stack can be rebuilt (Starknet)

Starknet said on 8 October 2026 that it is "actively considering becoming an L1" and is targeting 2027 to become fully quantum-resistant. StarkWare CEO Eli Ben-Sasson tied the proposal to controlling its own security upgrades instead of waiting on Ethereum, whose roadmap targets core post-quantum infrastructure around 2029. Yahoo Finance's summary says he called for "bunker mode": the right cryptography, frictionless upgradeability and possibly its own L1.

The logic is that a new L1 has no legacy accounts to migrate and can choose its transaction format around post-quantum signatures from day one. The size tax is then a design input, not a retrofit cost. The proposal also reduces dependence on another chain's governance calendar.

This is "actively considering", not a decision, and we do not know whether Starknet will become an L1. Starknet's TVL is small next to the chains it compares itself with. A new L1 also has to rebuild security, liquidity and users, which is a different kind of migration cost. Outlets reported the STRK price reaction to the announcement over different windows with different magnitudes, so we cite only the snapshot price above.

Data: The Gap Between Targets and Deployment

The table summarizes where each chain stands. Dates are those reported in the fact sources, and "mainnet PQ live" reflects the sources reviewed through 13 October 2026.

Table: migration status by chain, sources as cited in the text, 13 October 2026.

The value-at-stake context, from DefiLlama on 13 October 2026, is below.

Table: TVL and token data from DefiLlama/CoinGecko, snapshot of 13 October 2026, about 10:01-10:02 UTC (STRK at 10:08 UTC).

Two features stand out. First, no row has a mainnet "live" status. Second, the chain with the nearest stated target (Tron) is not the chain that secures the most value, and the chain securing the most value (Ethereum) has the furthest-dated target. Bitcoin's chain TVL is not its market cap, and the two should not be added together.

Algorand outlined plans to introduce quantum-resistant accounts by 2027, per Cointelegraph. FinanceFeeds says it already has native Falcon-based accounts. We could not reconcile the two, so Algorand is excluded from the table.

Standards and Regulation: What Applies and What Does Not

The honest regulatory picture is thinner than headlines suggest. The dates that dominate post-quantum coverage apply to US government systems, not to public blockchains.

NIST IR 8547 proposes deprecating RSA, ECDSA, ECDH and DH for federal use by 2030 and disallowing them by 2035. It targets migration to FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) and the draft FIPS 206 (FN-DSA). Secondary sources conflict on whether IR 8547 is still draft or final, and we did not check csrc.nist.gov. We therefore describe it only by what it proposes.

The NSA's CNSA 2.0 requires new National Security System acquisitions to be compliant by 1 January 2027, according to Keyfactor. This is the one hard 2027 government date we found. It applies to US national security systems, not to public blockchains.

These dates matter indirectly. They shape which algorithms vendors, custodians and auditors treat as standard, and Tron's issue describes ML-DSA-44 as a hedge against the still-draft FN-DSA standard. They do not oblige any chain to act by any date.

We could not verify direct government or regulator pressure on public chains to adopt post-quantum cryptography. Our review did not reach EU, UK NCSC, CISA or SEC sources, so this report claims neither the presence nor the absence of such action. Some aggregator sites cite further US executive deadlines. We could not confirm them against a primary source, and we exclude them.

The same caution applies to the threat timeline. Tron's issue cites arXiv 2603.28846 for a roughly 2029 quantum-threat threshold, and a secondary write-up cites a Google Quantum AI estimate of roughly 1,200 logical qubits to break 256-bit elliptic-curve cryptography. We did not open either primary paper.

Retroactive Migration Versus a New Chain: The Trade-offs the Evidence Supports

No verified dollar cost for retroactive migration exists in our sources. The only sourced costs are the size and throughput penalties above. The trade-offs below are our analysis, built on those numbers and on the design facts.

Retrofit on a live chain has three costs, which are the real binding constraints.

1. Legacy accounts. Someone must move them or rebalance their permissions, and abandoned or lost-key accounts cannot act. Bitcoin's BIP-361 confronts this directly by contemplating frozen coins. Tron's opt-in design, as described, does not protect accounts whose owners do not act.
1. Transaction size. Every migrated transfer carries the larger key and signature. Throughput falls as adoption rises, and block-size changes need extra governance.
1. Governance and audit. Tron's two separate governance switches, audit and Super Representative vote add steps.

A new chain avoids the first cost and designs around the second. It adds a different set of costs: rebuilding trust, liquidity and integrations, plus a bridge or migration path for existing users and assets. Starknet's small TVL suggests the value at stake in that bet is modest today.

Wallet-layer approaches try to lower friction. CoinDesk reported on 28 July 2026 that security firm AmericanFortress published a Cryptography ePrint proposal, not yet peer-reviewed, to add post-quantum protection to wallets without users moving funds, rotating keys or changing addresses. It remains only a proposal. Tron's in-place permission swap is the shipped analogue, but it protects only accounts that actively rebalance.

Our reading is that the philosophies trade risk types. Opt-in coexistence trades speed for residual exposure. Trigger-based plans trade early cost for timing risk. Programmes trade urgency for coordination. A new chain trades legacy for rebuild risk. None is dominant, and the best choice depends on how soon one believes the threat arrives.

Risks

• Mainnet slippage (High). Tron's target has moved from Q3 2026 to year-end to undated. Triggers: audit findings, unresolved storage and energy-pricing questions, or a failed Super Representative vote. Further delay would widen the testnet-to-mainnet gap.
• Opt-in exposure (High). Accounts that add a post-quantum key without rebalancing permissions stay as vulnerable as before. Trigger: low voluntary rebalancing after activation. The share of value that migrates is unknown.
• Throughput degradation (Medium). Tron's model shows throughput falling as post-quantum adoption rises. Trigger: wide uptake of larger transactions before block-size or storage questions are resolved. The figures are modelled, not measured.
• Standards risk (Medium). FIPS 206 was still described as draft by Tron's issue and FinanceFeeds. Trigger: changes to the final FN-DSA standard after a chain has committed to Falcon-512.
• Reactive migration (Medium to High). Solana's trigger-based plan assumes warning time. Trigger: a credible threat arriving faster than the sequence of new-wallet adoption, then migration of existing wallets, can run.
• Bitcoin coordination (High). BIP-360 adds no new signature scheme, and BIP-361 is a coercive draft that would eventually block sends from vulnerable formats. Trigger: failure to reach consensus on forcing migration, leaving the frozen-versus-stolen question open.
• Narrative risk (Medium). Headlines such as "live on testnet" can be read as mainnet protection. Trigger: market or user decisions based on that reading.
• Starknet execution (Medium). The L1 idea is only under consideration. Trigger: no commitment, or a design that cannot reach 2027.
• Evidence risk (Medium). The threat estimates in circulation (the roughly 2029 threshold, the logical-qubit estimate) rest on sources we could not open. Trigger: a primary paper that revises them.

Outlook

The following probabilities are our estimates for the next three to six months (to roughly April 2027). They reflect the reasoning above: drafts, audits and votes rarely compress, and the Tron timeline has already moved from Q3 to year-end to undated.

Base case (60%): the gap persists. No chain in this comparison has a post-quantum signature scheme live on mainnet by April 2027. Tron publishes progress on its audit and the schedule keeps shifting. Ethereum continues devnets, Bitcoin's BIP-360 and BIP-361 stay in draft, Solana stays in the research phase, and Starknet continues to consider an L1.

Upside case (20%): Tron reaches mainnet. The audit completes, the summary is published, and the Super Representative vote passes with both algorithms gated by their own proposals. Even then, protection would reach only accounts that rebalance permissions, and transaction-size costs would begin to show on mainnet.

Downside case (20%): delay with a rushed response. Audit findings or the open storage questions force redesign, and Tron's timeline slips into mid-2027 or later. Credible new threat evidence then pushes chains with trigger-based plans toward reactive migration. This case would favour chains with programmes already underway.

For traders: treat "live on testnet" headlines as weak signals for TRX and STRK. Watch for the audit summary and a scheduled Super Representative vote, which are checkable events. Do not trade on date claims alone, because dates have moved.

For builders: design for transaction sizes of several kilobytes and for accounts that hold multiple key types. If you build on Tron, plan for explicit permission rebalancing, not just adding a key. If you build on Ethereum or Solana, follow pq.ethereum.org and Solana's quantum readiness post for trigger changes.

For investors: ask each chain three questions. What is live on mainnet today? What happens to dormant accounts? What does the size cost do to throughput and fees? A chain that answers all three with data is ahead of one that answers with a date.

Key items to watch into 2027: the Tron audit summary and Super Representative vote; any finalization of FIPS 206; progress on BIP-360 and BIP-361; Starknet's decision on becoming an L1; and Ethereum's devnet milestones toward its 2029 target.

Sources

• Cointelegraph via TradingView: Justin Sun's 10 October post, Strategy-led $15 million pledge, Algorand 2027 plans, AmericanFortress proposal
• Crypto Briefing: Sun's fireside chat and end-of-2026 target
• Crypto Briefing: Nile testnet build and Tron initiative announcement
• FinanceFeeds: CP 20628, TIP-899 scope, draft status, audit requirements, NIST footing
• tronprotocol/java-tron issue #6793: key sizes, transaction sizes, benchmarks, TPS model, migration paths, open questions
• BeInCrypto: Tron's shifting mainnet timeline
• TokenPost: Starknet's L1 consideration and 2027 target
• Decrypt: Ben-Sasson's 2027 versus end-2029 comparison
• The Quantum Insider: Ethereum Foundation Post-Quantum Security team
• CoinDesk: pq.ethereum.org launch and Ethereum devnets
• DEV Community (basisdesk): Lean Ethereum roadmap, secondary source
• Solana: Solana's Quantum Readiness conditional roadmap
• The Quantum Insider: Solana Winternitz Vault
• Cointelegraph: BIP-360 and what it does not change
• CryptoSlate: BIP-361 and the frozen versus stolen choice
• Keyfactor: NIST IR 8547 dates and NSA CNSA 2.0 January 2027 requirement
• CoinGecko via DefiLlama: BTC price, market cap and supply, 13 October 2026
• CoinGecko via DefiLlama: ETH price and market cap
• CoinGecko via DefiLlama: SOL price and market cap
• CoinGecko via DefiLlama: TRX price and market cap
• CoinGecko via DefiLlama: STRK price and market cap
• DefiLlama: Tron chain TVL
• DefiLlama: Ethereum chain TVL
• DefiLlama: Solana chain TVL
• DefiLlama: Bitcoin chain TVL
• DefiLlama: Starknet chain TVL
• DefiLlama Stablecoins: total supply and USDT share