Quantum-resistant upgrades are moving from theoretical debates to operational stress tests for two major Layer-1 networks. New findings highlight that Bitcoin and TRON face different but related challenges: Bitcoin must migrate a large actively managed exchange cohort, while TRON's draft design could complicate key recovery if governance disables a signing scheme.
Bitcoin's visible exchange exposure. Coinbase published a September 9 account of a closed-door post-quantum Bitcoin workshop with Stanford and Localhost Research. Participants reached no consensus on an exact post-quantum approach and flagged tradeoffs involving transaction size, hardware performance, key management and adoption. Glassnode's May study gave the rollout problem scale: roughly 1.6 million BTC, about 8% of supply, sat in exchange-related outputs with public keys already visible on-chain. The firm estimated 6.04 million BTC, or 30.2% of issued supply, had public-key exposure at rest. Sources described no cryptographically relevant quantum computer capable of breaking Bitcoin signatures, and Coinbase called the risk non-immediate.
Proposed paths and early tests. BIP-360 would add Pay-to-Merkle-Root outputs through a soft fork, removing Taproot's key-path spend and reducing long-exposure attack surface without adding a post-quantum signature. It would still leave short-exposure windows open. Separately, Blockstream Research published August benchmarks showing some hardware wallets could generate hash-based post-quantum signatures, while BitGo and Silence Laboratories reported a May simulation using ML-DSA in a multi-party computation wallet workflow. Both remain early-stage, with production deployment still unproven.
TRON's key-recovery risk. Justin Sun said on Aug. 8 that his goal was for TRON to become the first quantum-resistant blockchain network. TRON's TIP-899 remains a draft, implementing Falcon-based FN-DSA-512 and ML-DSA-44 on the Nile testnet. Governance can enable or disable each scheme independently. The critical permission issue: if an owner permission contains only a Falcon key and Falcon is disabled, that owner cannot authorize transactions or change permissions. A separate active permission may allow payments, but it cannot repair the owner configuration. A second quantum key helps only if it can independently meet the account's owner threshold. TIP-899 still requires external audits, wallet derivation work, SDK and hardware-wallet adaptation before mainnet activation.
Together, the two cases show that quantum-safe migration depends on operational execution and permission recovery, not just cryptographic selection.
