{"id":13228,"date":"2026-09-14T20:22:24","date_gmt":"2026-09-14T20:22:24","guid":{"rendered":"https:\/\/cryptonews.uk.com\/?p=13228"},"modified":"2026-09-14T20:22:24","modified_gmt":"2026-09-14T20:22:24","slug":"why-payment-keys-may-not-restore-control","status":"publish","type":"post","link":"https:\/\/cryptonews.uk.com\/?p=13228","title":{"rendered":"Why payment keys may not restore control"},"content":{"rendered":"

<\/p>\n

\n

TRON\u2019s 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.<\/p>\n

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\u2019s 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.<\/p>\n

That is the practical question behind Justin Sun\u2019s 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.<\/p>\n

As of Sept. 12, TIP-899 remains labeled Draft. Nile\u2019s 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.<\/p>\n

A Sept. 12 check of the Nile parameter endpoint returned getAllowFnDsa512<\/code> 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.<\/p>\n

A network switch meets an account threshold<\/h2>\n

TIP-899 lets governance enable or disable each proposed scheme separately. TRON\u2019s 27 elected Super Representatives govern through on-chain proposals. The proposed switches belong to that process.<\/p>\n

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.<\/p>\n

\n

Related Reading<\/span><\/p>\n

Staking Ethereum could soon look entirely different under a new deposit proposal<\/h3>\n<\/p>\n

<\/span> <\/div>\n

At account level, the question is which signatures remain acceptable. TRON assigns keys weights and requires a selected permission\u2019s valid signers to meet or exceed its threshold. The proposed quantum-signature path uses that same permission calculation.<\/p>\n

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\u2019s signature, even if the remaining keys carry enough weight.<\/p>\n

Turning off a scheme can consequently remove a signing route without changing the account\u2019s configured threshold. Nothing in that switch automatically grants another key the missing authority.<\/p>\n

TRON\u2019s permission documentation separates owner authority from active permissions. Owner permission can authorize any contract type and change the account\u2019s permissions. An active permission is limited to the operations assigned to it, such as transfers.<\/p>\n

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\u2019s keys.<\/p>\n

\"Conditional\"Conditional<\/p>\n

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.<\/p>\n