TRON’s draft quantum-signature design could leave some migrated accounts unable to replace their keys after network governance disables the signing scheme they depend on. Some of those accounts could still make payments through a separate permission.
The design includes a possible recovery route through a second quantum-resistant signature scheme. To use it, holders would need the surviving keys to meet the account’s existing owner threshold, the level of authority required to change permissions. A backup key authorized only for payments would leave that repair power out of reach.
That is the practical question behind Justin Sun’s quantum push. On Aug. 8, 2026, @justinsuntron said his goal was for TRON to become the first quantum-resistant blockchain network and referred to testing on the Nile test network. That dated statement of ambition provides the backdrop to a migration design whose governance switches can later withdraw approval for a signing scheme.
As of Sept. 12, TIP-899 remains labeled Draft. Nile’s June 30 software release included implementations of Falcon-based FN-DSA-512 and ML-DSA-44, each subject to its own activation setting. Each implementation still needs its own governance approval before the network accepts its signatures.
A Sept. 12 check of the Nile parameter endpoint returned getAllowFnDsa512 with a value of 1. The ML-DSA setting appeared without a value, providing no affirmative activation reading. The mainnet response contained neither setting. Developers had said in their July 15 call that mainnet timing was undecided; the current checks do not establish mainnet activation.
A network switch meets an account threshold
TIP-899 lets governance enable or disable each proposed scheme separately. TRON’s 27 elected Super Representatives govern through on-chain proposals. The proposed switches belong to that process.
The activation settings have also been renumbered. TIP-899 and the Nile implementation use codes 1000 and 1001, while the earlier migration discussion still contains 99 and 100. The July 1 developer call explains that the larger numbers were chosen to avoid conflicts with future mainnet numbering. Those numbers identify the proposed settings; activation requires a separate governance decision.
At account level, the question is which signatures remain acceptable. TRON assigns keys weights and requires a selected permission’s valid signers to meet or exceed its threshold. The proposed quantum-signature path uses that same permission calculation.
There is a consequential detail in the reference transaction verifier: a signature from a disabled scheme triggers rejection. A working fallback transaction must therefore use accepted signatures and omit the disabled scheme’s signature, even if the remaining keys carry enough weight.
Turning off a scheme can consequently remove a signing route without changing the account’s configured threshold. Nothing in that switch automatically grants another key the missing authority.
TRON’s permission documentation separates owner authority from active permissions. Owner permission can authorize any contract type and change the account’s permissions. An active permission is limited to the operations assigned to it, such as transfers.
A permission update must be signed under the existing owner permission. That makes owner configuration central to recovery: a key capable of sending a payment does not necessarily have the power to replace the account’s keys.
Consider an owner permission containing only a Falcon key with weight 1 and threshold 1. While Falcon is disabled, that owner permission cannot authorize a transfer or a permission update. A separately configured active permission might still permit transactions, so this does not necessarily make the entire account unable to spend.
Keeping a key for TRON’s existing ECDSA signing method alongside Falcon does not always restore access. With ECDSA weight 1, Falcon weight 1 and threshold 2, both signatures are required. After Falcon is disabled, the remaining ECDSA weight cannot meet the threshold.
The following examples apply the proposed rules to hypothetical configurations. They show deductions from the documented permission and verification rules; no observed lockout or executed rollback test underlies these examples. Assume Falcon has been disabled, any ML-DSA keys were configured beforehand, ML-DSA remains enabled and secure, and the holder can still use those keys.
| Existing permission configuration | Spending after Falcon is disabled | Changing permissions |
|---|---|---|
| Falcon-only owner: weight 1, threshold 1 | Owner cannot authorize; a separate active permission may still work | Unavailable through that owner |
| Owner: ECDSA weight 1 plus Falcon weight 1, threshold 2 | Owner cannot meet threshold; separate active permissions must be assessed | Unavailable through that owner |
| Owner: Falcon weight 1 plus ML-DSA weight 1, threshold 1; no ECDSA keys | ML-DSA owner signature can authorize | ML-DSA owner signature can authorize |
| Owner: Falcon weight 1 plus ML-DSA weight 1, threshold 2 | Owner cannot meet threshold; separate active permissions must be assessed | Unavailable through that owner |
| Falcon-only owner plus a viable ML-DSA active permission | Only operations allowed by that active permission | Active permission cannot repair the owner |
These outcomes concern signature authority; other transaction requirements still apply. The distinction works in the other direction too. A surviving ML-DSA owner permission could authorize transactions directly and replace a disabled Falcon active permission.
A second quantum key helps only if it can act
The two-scheme owner example preserves a quantum-resistant route to permission repair if either key can independently meet the owner threshold. Requiring both keys creates a dependency on both schemes remaining available. The threshold determines which of those properties an account has.
Nor does a classical recovery route preserve the same security objective. The migration proposal explicitly says that adding a quantum-resistant key provides no quantum protection if an ECDSA-only signing set can still meet the threshold. An ECDSA-only owner route can also replace a quantum-protected active permission.
The relevant configuration is therefore broader than the key used for routine payments. Owner authority and every active route capable of moving the protected assets have to be considered together.
An either-scheme configuration also has a limit: it preserves an alternative after a scheme is disabled, but it does not protect against a compromised scheme while that scheme remains enabled and independently authorized. Availability after disablement and resistance to a still-accepted compromised key are separate properties.
ML-DSA’s standards status helps explain its place in the design. NIST finalized FIPS 204, which specifies ML-DSA, on Aug. 13, 2024. NIST still describes Falcon standardization as underway. TIP-899 presents ML-DSA as an implemented alternative to Falcon’s standardization and audit risk. That provides an alternative algorithm, rather than automatic recovery permission.
The remaining work extends beyond adding a signing button. TIP-899 calls for external cryptographic and implementation auditing, public audit material and bug-bounty coverage before mainnet activation. The reviewed proposal materials do not provide a completed independent audit report.
The proposal and July 15 developer discussion also identify wallet derivation, keystore, SDK and hardware-wallet adaptation work. Testnet implementation and key-generation tools do not establish that consumer wallets or custodians can already perform every migration and recovery operation.
A useful testnet demonstration would follow the permissions through the failure: disable the scheme, construct a transaction using only surviving signatures, show which transfers remain authorized, and show whether the existing owner can replace the affected keys. The outcome would need to match the configuration users actually hold.
If both proposed quantum schemes were disabled and no valid signing set could meet the owner or relevant active threshold, the described rules would provide no immediate ordinary path to spend or rotate keys. That does not establish permanent loss. Governance reactivation or a later protocol change would be a different recovery route; the faster emergency channel and zero-knowledge recovery ideas remain outside this proposal’s current scope.
For wallets and custodians, payment continuity alone would leave the central recovery question unanswered. A migration configuration needs a surviving owner-authorized path to replace keys as well as a way to move funds, with both paths preserving its quantum-resistance objective.
