TRON’s proposed quantum-signature system could leave some accounts able to make payments but unable to replace their keys if network governance later disables the signing method on which they rely.
A possible recovery route using a second quantum-resistant system would work only if the surviving keys could meet the account’s existing owner threshold – the minimum authority required to change permissions. A backup key authorised solely for payments would not provide that ability.
The issue sits at the centre of Justin Sun’s plan to make TRON the first quantum-resistant blockchain network. On 8 August 2026, @justinsuntron said the project was being tested on the Nile test network.
As of 12 September, TIP-899 remained a draft. Nile’s 30 June software release included Falcon-based FN-DSA-512 and ML-DSA-44, each controlled by a separate activation setting and each requiring governance approval before its signatures can be accepted.
A check of the Nile parameter endpoint on 12 September returned `getAllowFnDsa512` with a value of 1. The ML-DSA setting appeared without a value, so there was no affirmative indication that it was active. Neither setting appeared in the mainnet response. Developers said during their 15 July call that the timing of any mainnet activation had not been decided.
How the recovery problem arises
TIP-899 allows governance to enable or disable the proposed schemes independently. The decisions would be made through on-chain proposals by TRON’s 27 elected Super Representatives.
The settings use codes 1000 and 1001 in TIP-899 and the Nile implementation. Earlier migration discussions used 99 and 100; developers said on 1 July that the larger numbers were chosen to avoid conflicts with future mainnet numbering. The codes identify the settings, but do not activate them without a separate governance decision.
At account level, TRON assigns weights to keys and requires signatures to reach the threshold for the selected permission. A signature from a disabled scheme is rejected by the reference transaction verifier, meaning a fallback transaction must omit that signature even if the remaining keys have enough combined weight.
That can remove a signing route without changing the account’s threshold. Owner permission can authorise any contract type and alter permissions, while an active permission is restricted to assigned operations, such as transfers. Permission changes must be approved using the existing owner permission.
For example, an owner containing only a Falcon key with weight 1 and threshold 1 would lose its ability to authorise transfers or permission updates if Falcon were disabled. A separate active permission could still allow payments. Similarly, an owner with ECDSA weight 1, Falcon weight 1 and threshold 2 could no longer meet the threshold once Falcon was rejected.
By contrast, an owner with Falcon weight 1 and ML-DSA weight 1 and threshold 1 could continue using ML-DSA for both transactions and permission changes. With a threshold of 2, however, the account would again fail to meet the requirement. A viable ML-DSA active permission could permit only its assigned payments and could not repair a Falcon-only owner permission.
These are hypothetical outcomes based on the documented rules, not observed lockouts or rollback tests. They assume Falcon has been disabled, ML-DSA was configured beforehand, remains enabled and secure, and its keys remain available.
Audits and wallet support remain outstanding
Using two schemes with an “either key” threshold can preserve a recovery route after one is disabled, but it does not protect against a compromised scheme while that scheme remains authorised. An ECDSA-only route also removes the quantum-protection objective.
NIST finalised FIPS 204 for ML-DSA on 13 August 2024, while Falcon standardisation remains under way. TIP-899 calls for external cryptographic and implementation audits, public audit material and bug-bounty coverage before mainnet activation; no completed independent audit report is included in the reviewed proposal material.
The proposal also identifies work on wallet derivation, keystores, SDKs and hardware wallets. Testnet software and key-generation tools do not show that consumer wallets or custodians can already carry out every migration and recovery operation.
A meaningful test would disable a scheme, send transactions using only surviving signatures, identify which transfers remain authorised and test whether the existing owner can replace the affected keys.
If both quantum schemes were disabled and no valid signing set met the owner or relevant active threshold, the stated rules would provide no immediate ordinary route to spend funds or rotate keys. That would not prove permanent loss: governance reactivation or a later protocol change could offer another recovery route. Emergency channels and zero-knowledge recovery ideas are outside the current proposal.
For wallets and custodians, continued payment access is therefore only part of the issue. A migration must preserve both a way to move funds and an owner-authorised route to replace keys while maintaining its quantum-resistance objective.
