TRON draft could leave migrated accounts unable to replace keys

TIP-899, a draft proposal for TRON’s quantum-signature migration, would add two quantum-resistant signature schemes to the Nile testnet. The proposal would let governance enable or disable each scheme independently, a design that can allow transfers to continue while removing a route to change owner keys.

The two implementations on Nile are a Falcon-based FN-DSA-512 and ML-DSA-44. Nile’s June 30 release included both implementations, each controlled by its own activation flag. A check of Nile parameters on Sept. 12 returned getAllowFnDsa512 with a value of 1; the ML-DSA flag showed no affirmative activation. Neither flag appears on mainnet. Developers discussed on July 15 that mainnet timing remained undecided. TRON’s 27 elected Super Representatives would enable or disable each scheme through on-chain governance proposals.

The migration uses TRON’s existing permission model of key weights and thresholds. The reference transaction verifier rejects signatures produced by a scheme that governance has disabled. Turning off a scheme can therefore remove an acceptable signing route without changing an account’s configured threshold, and the switch does not automatically grant authority to another key.

Owner permissions control permission changes and have authority above active permissions, which can be limited to transfers. If an owner permission relies only on a signing scheme that governance later disables, that owner permission cannot authorize permission updates even if a separate active permission still allows transfers. For example, an owner configured with a single Falcon key at weight 1 and threshold 1 would lose the ability to update permissions while Falcon is disabled, even if an active permission remains functional. An owner that requires two signatures, such as ECDSA and Falcon with weights of 1 and a threshold of 2, would also lose owner authority if Falcon were disabled, because the remaining ECDSA signature could not meet the threshold alone.

A two-scheme owner configuration preserves a recovery route only if either key can by itself meet the owner threshold. Requiring both schemes to sign makes the owner dependent on both schemes staying enabled. The proposal cautions that simply adding a quantum-resistant key does not provide quantum resistance if an existing ECDSA-only route can still meet the owner threshold.

The proposal presents ML-DSA as an alternative while Falcon’s standardization is pending. NIST finalized FIPS 204 for ML-DSA on Aug. 13, 2024; Falcon’s standardization is still in progress. TIP-899 calls for external cryptographic and implementation audits, public audit materials and bug-bounty coverage before any mainnet activation. The reviewed materials do not include a completed independent audit report.

On Aug. 8, 2026 Justin Sun wrote on X that his goal was for TRON to become ‘the first quantum-resistant blockchain network,’ citing testing on the Nile testnet. The implementation work described in the proposal extends beyond signing routines to wallet derivation, keystore changes, SDK updates and hardware wallet adaptations. Testnet implementations and key-generation tools do not yet demonstrate that all consumer wallets or custodians can perform every migration and recovery operation.

Under the current rules, if both proposed quantum schemes were disabled and no surviving signing set met the owner or relevant active thresholds, there would be no ordinary immediate way to spend or rotate keys. Governance reactivation or a future protocol change would remain possible recovery routes. The proposal notes that migration configurations need both a way to move funds and a surviving owner-authorized path to replace keys in order to preserve the migration’s quantum-resistance objective.