TRON’s Draft Quantum‑Signature Design May Allow Payments but Block Key Replacement

TRON is testing a quantum‑resistant upgrade under TIP‑899. The draft design adds two post‑quantum signature algorithms – Falcon‑based FN‑DSA‑512 and ML‑DSA‑44 – that can be enabled or disabled by on‑chain governance.

Governance‑controlled activation

TRON’s 27 elected Super Representatives vote on proposals that toggle each scheme independently. The Nile test‑net release on June 30 included both implementations, each with its own activation flag (codes 1000 for Falcon and 1001 for ML‑DSA). As of September 12, the Nile endpoint showed Falcon enabled (value 1) while the ML‑DSA flag had no value, and the mainnet reported neither flag.

Permission model and potential lockout

Accounts on TRON assign weights to keys and require a threshold to be met for a permission to be valid. Owner permissions can change keys and permissions; active permissions are limited to specific actions such as transfers.

If a quantum scheme is disabled, any signature from that scheme is rejected. A transaction must therefore be signed only with keys from enabled schemes that together meet the required threshold. Disabling a scheme does not automatically grant remaining keys the authority to meet the owner threshold, so an account could retain the ability to pay (via an active permission) but lose the ability to replace its keys.

Illustrative configurations

• Owner permission with only a Falcon key (weight 1, threshold 1) becomes unusable when Falcon is disabled.
• Owner permission with ECDSA + Falcon keys (each weight 1, threshold 2) cannot meet the threshold after Falcon is disabled, even though ECDSA remains.
• Owner permission with Falcon + ML‑DSA keys (threshold 1) can still authorize transactions if ML‑DSA remains enabled.

Recovery considerations

For a successful migration, a surviving owner key must be able to meet the owner threshold on its own, allowing key rotation. A backup key limited to payments does not provide this recovery path.

The proposal notes that adding a quantum‑resistant key does not protect assets if an ECDSA‑only signing set can still meet the threshold, and vice‑versa. Both availability after a scheme is disabled and resistance to a compromised scheme while enabled are separate concerns.

Implementation status

ML‑DSA was standardized in NIST FIPS 204 (August 13, 2024); Falcon is still under standardization. TIP‑899 calls for external cryptographic audits, public audit material, and bug‑bounty coverage before mainnet activation. Wallets, SDKs, and hardware‑wallet support for the new schemes are still under development, and no independent audit report has been released.

What remains to be demonstrated

A complete test‑net demonstration would need to: disable a scheme, construct a transaction using only surviving signatures, verify which transfers remain authorized, and confirm whether the owner can replace the affected keys. Without such a demonstration, the risk of accounts being able to spend but unable to rotate keys cannot be fully assessed.