TRON's draft quantum-signature design could create a configuration problem for migrated accounts: some may retain the ability to send payments while losing the ability to update their security keys after network governance disables the signing scheme they rely on.
The issue centers on how TRON assigns permissions to cryptographic keys. The network requires keys to meet a specified weight threshold to authorize different account operations, including payments and permission changes. If a signing scheme is disabled through governance, a signature from that scheme is rejected—even if other keys carry enough weight for the transaction.
The core problem: owner versus payment permissions
Owner permission in TRON can authorize any contract type and change account settings. Active permissions are limited to specific operations like transfers. A key authorized only for payments cannot replace account keys because permission updates must be signed under the existing owner permission.
Consider a scenario where an account's owner permission contains only a Falcon key with weight 1 and threshold 1. If Falcon is disabled, that owner permission cannot authorize a transfer or permission update. A separate active permission might still permit transactions, leaving the account able to spend but unable to repair its keys.
Similarly, an account with ECDSA weight 1, Falcon weight 1, and threshold 2 would lose owner authorization after Falcon disablement because the remaining ECDSA weight cannot meet the threshold of 2.
The proposed recovery route
TIP-899, TRON's draft proposal, includes a possible recovery path through a second quantum-resistant signature scheme. To use it, the account holder would need surviving keys that independently meet the owner threshold. A backup key authorized only for payments does not restore this repair power.
ML-DSA is presented as an alternative to Falcon, partly because NIST finalized the ML-DSA standard (FIPS 204) on August 13, 2024, while Falcon's standardization remains ongoing. An account with both Falcon and ML-DSA keys could recover key replacement authority if either key independently meets the owner threshold—but only if the configuration was set that way before Falcon was disabled.
Current testnet status
TRON testing on the Nile test network included implementations of Falcon-based FN-DSA-512 and ML-DSA-44 following a June 30 software release. As of September 12, TIP-899 remains labeled Draft. Each scheme requires separate governance approval before the network accepts its signatures. The mainnet timing remains undecided, according to developer statements from July 15.
What remains incomplete
Before mainnet activation, TIP-899 calls for external cryptographic auditing, public audit material, and bug-bounty coverage. Testnet implementation and key-generation tools do not establish that consumer wallets or custodians can perform every migration and recovery operation. A useful testnet demonstration would disable a scheme, construct transactions using only surviving signatures, and verify which transfers and key-replacement operations remain available for different account configurations.
For wallets and custodians, ensuring payment continuity alone would leave the central recovery question unanswered. A migration configuration needs both a surviving owner-authorized path to replace keys and a way to move funds, with both paths preserving quantum resistance.
