Sui is preparing a two-track approach to transaction authorization that is designed to withstand attacks from future cryptographically relevant quantum computers. The plan combines a native signature option for ordinary accounts with a contract-based mechanism for high-value vaults. These Sui post-quantum signatures are additive and opt-in, allowing the network to introduce new protection without immediately replacing its existing account system.
The native route uses ML-DSA-65, a lattice-based signature standard intended for frequent account activity. The vault route uses SLH-DSA-SHA2-128s inside Move smart contracts. That second scheme has larger signatures and is better suited to assets that move infrequently but require a conservative security profile.
How Sui post-quantum signatures would work
ML-DSA-65 is planned as a protocol-level signature type. Once implemented, an account could authorize ordinary transactions with a quantum-resistant key while retaining the network’s familiar transaction flow. Native verification matters because it avoids rebuilding signature checks separately inside every application.
The second path places SLH-DSA-SHA2-128s verification in a Move contract that acts as a vault. Funds are controlled by the contract and can move only when the required post-quantum authorization is presented. This design is aimed at treasuries, long-term holdings and other use cases where transaction frequency is low and added data cost may be acceptable.
Using two schemes recognizes that cryptography involves engineering trade-offs. ML-DSA offers practical performance for routine use, while SLH-DSA is based on a different family of assumptions and can provide diversification for especially sensitive holdings. The options are complementary rather than competing replacements for the same job.
Existing recovery phrases can derive new keys
Sui’s plan includes a migration path from existing account material. A user’s current recovery phrase can derive a post-quantum key, avoiding the need to create an entirely unrelated backup from scratch. That convenience still requires careful wallet implementation so that users understand which key controls which authorization method.
Address aliases are another important element. They are intended to let an account update its authentication key without transferring all assets to a new address. If deployed as described, a user could keep a stable account identifier while rotating from a conventional signature to a quantum-resistant one.
Key rotation can reduce migration friction, but it must be designed against takeover and recovery errors. Wallets will need clear prompts, safe backup procedures and protections against attackers who try to change the authentication method before the legitimate owner does.
Why blockchain networks are preparing now
Current quantum computers cannot simply break widely used blockchain signatures on demand. The concern is future capability. Public blockchains expose public keys in some transaction patterns, and assets may remain dormant for years. Designing migration tools before a capable machine exists gives users and institutions time to move deliberately.
The problem has two timelines. Researchers must judge when quantum hardware could threaten deployed schemes, while networks must account for how long software upgrades, wallet support and user migration take. Waiting for a breakthrough could leave a narrow and disorderly transition window.
Post-quantum preparation also affects dormant or lost-key assets. A network can offer safer signatures for active users, but it cannot automatically rotate keys for owners who no longer have access or never move their funds. That limitation is one reason communities debate proactive rules cautiously: protecting vulnerable assets without changing ownership assumptions is difficult.
Larger signatures have a network cost
Quantum-resistant signatures and public keys are generally larger than the signatures blockchain users encounter today. More bytes per transaction can increase bandwidth, storage and execution costs. For a high-throughput network, those effects matter even if verification itself is efficient.
Sui’s two-track design manages that pressure by matching the scheme to the use case. Routine users can choose the native option intended for everyday performance. High-value vaults can accept the heavier contract-based method because they transact less often. Opt-in adoption also lets the network measure real-world demand and performance before considering broader defaults.
Developers will need benchmarking across validators, wallets and indexers. Average transaction size is only one metric; peak verification load, hardware variability and denial-of-service resistance are equally important. Fee rules may need to reflect the extra computation and data accurately.
The rollout is staged, not complete
The current schedule describes targets rather than finished mainnet features. Contract-based quantum-safe vaults are targeted for mainnet during 2026. ML-DSA-65 support is planned for testnet by the end of 2026 and for native mainnet availability in the first quarter of 2027.
Those dates can change as implementations are audited and tested. Post-quantum code deserves especially careful review because a flawed integration can undermine a sound cryptographic standard. The network must verify signature parsing, key derivation, replay protection, gas accounting and interoperability with existing account features.
Wallet support will determine whether the upgrade is usable. A protocol can accept a signature while most users remain unable to create, back up or recover the corresponding keys. Hardware-wallet vendors, custodians and exchanges will need their own implementation and audit cycles.
What to watch next
The first meaningful milestone will be a public specification for the Move vault and evidence of independent security review. Users should look for details on withdrawals, recovery, key rotation and what happens if a contract implementation needs an upgrade. For ML-DSA, testnet performance and wallet integration will show whether the native path is ready for frequent transactions.
Institutions will also ask whether the two options meet their custody and policy requirements. Some may prefer the standardized native scheme; others may value a vault using a separate mathematical foundation. Neither choice removes operational risk around backups, access controls and software supply chains.
The proposal is notable because it treats quantum readiness as a product-design problem, not only a cryptographic one. Migration, account continuity, transaction cost and user choice all matter. If the staged rollout performs as planned, Sui post-quantum signatures could give everyday users and high-value custodians distinct ways to prepare without forcing an immediate network-wide switch.
