Main Takeaways
- Sui is adding two NIST-approved post-quantum signature schemes: ML-DSA-65 as a native protocol signature scheme for everyday accounts, and hash-based SLH-DSA-SHA2-128s inside Move smart contracts for high-value vaults.
- Because Sui keys derive deterministically from a seed, users will be able to move to a quantum-safe key using the recovery phrase they already hold. Address aliases, already live on Sui, let an existing account update its authorization key without transferring assets out.
- Quantum-safe vaults are targeted for Mainnet this year and native ML-DSA-65 accounts for Testnet by end of year, with native account authentication on Mainnet targeted for Q1 2027. Timelines remain open while independent audits and Testnet feedback continue.
A public key onchain is different from a public key anywhere else. In most systems, an attacker needs a breach before they can start working on a key. Onchain, the key is already published, exposed permanently the moment an account transacts.
That changes what the quantum timeline means for a blockchain. Shor's algorithm breaks the elliptic-curve cryptography behind most onchain accounts today, the same math securing banking systems and most of the internet. Harvest-now-forge-later collection doesn't require quantum hardware; it requires a visible key and patience. The exposure is already accruing. In March 2026, Google Quantum AI estimated that exactly this attack, recovering a private key from an exposed public key, would run in minutes on a fault-tolerant machine of under half a million physical qubits.
The deadlines are also moving. NIST had planned to deprecate classical algorithms by 2030 and disallow them by 2035. Executive Order 14412, signed June 2026, pulls that forward for federal agencies’ sensitive systems: post-quantum key establishment by the end of 2030, digital signatures by the end of 2031.
Sui was built for cryptographic agility, which means signature schemes can be added without disturbing the fundamentals of the network. That property is the difference between a migration and a rebuild, and it is why the work described here is a routine protocol-feature update rather than a change to consensus or existing state.
Two schemes, two threat models
Rather than betting on one algorithm, Sui is adopting two, matched to different kinds of risk.
ML-DSA-65 (FIPS 204) for native accounts. For everyday transactions, ML-DSA-65 becomes a native protocol signature scheme. Sui is integrating Level 3 rather than the cheaper Level 1, following a July 2026 incident where an AI model halved the effective key strength of HAWK, a post-quantum signature candidate, in about 60 hours, after two years of expert human review had cleared it. While the finding does not affect ML-DSA, the speed of it is reason to carry margin rather than take the cheapest parameters on offer. Level 3 is also where Chrome and Cloudflare landed for the post-quantum encryption now protecting over half of human-initiated web traffic. The rest of the internet stack is converging on the same choice too: AWS KMS now offers ML-DSA signing in its hardware-backed key service, and Android 17's Keystore generates quantum-safe signatures inside the device's secure hardware starting at ML-DSA-65, skipping the 44 parameter set entirely.
SLH-DSA-SHA2-128s (FIPS 205) for smart contract vaults. For high-value assets, hash-based signatures are handled inside Move contracts rather than the protocol core. Hash-based security is the better-understood of the two families, and keeping it in-contract means Sui can stay compatible with whichever post-quantum standards the wider industry settles on, without a core protocol upgrade. Given Sui's bridges to other networks, that adaptability matters.
The two rest on different mathematics, one lattice-based and one hash-based, so a weakness found in one does not undermine the other. Both follow NIST's standardized post-quantum algorithms and the joint CISA/NSA/NIST quantum-readiness roadmap.
Users keep their recovery phrase, and their address
The hardest part of any cryptographic migration is not the new algorithm. The problem is that everyone is already using the old one.
On Sui, an ML-DSA-65 private key is a 32-byte seed, the same size wallets store today, derived from the same recovery phrase through a new standard derivation path. Wallets back up and restore exactly as they do now.
Existing accounts have a path that does not involve moving funds. Address aliases, already deployed on Sui, let an account update its authorization key to a post-quantum key while keeping its address and its assets in place. No forced migration, no expensive transfer of everything an account holds.
The honest cost is size. A post-quantum signature and public key are substantially larger than an Ed25519 pair, which increases transaction size. That is the price the whole industry is paying for quantum resistance. Verification is the part that could have hurt and does not: ML-DSA-65 verification on Sui is close enough to Ed25519 that per-signature network cost does not rise. Sui's transaction size limit and support for programmable transaction blocks absorb the rest, and further optimization work is underway.
What ships, and when
The core implementation is built and benchmarked. Quantum-safe vaults are targeted for Mainnet this year, with native ML-DSA-65 accounts reaching Testnet by end of year and native account authentication on Mainnet targeted for Q1 2027. Wallet, SDK, and CLI support will arrive alongside. Independent audits are underway, and timelines stay open while that review and Testnet feedback continue. This reflects current direction, not a finished, fully audited release.
Post-quantum accounts arrive as an additive, opt-in capability, through the same rollout path zkLogin and passkeys used. Nothing existing changes, and no application needs to do anything today.
For background on how each Sui primitive transitions to post-quantum cryptography, see Securing Sui in the Quantum Computing Era. More on Sui's approach to security lives at sui.io/security.
FAQs
Is Sui quantum-resistant today? Sui is built for cryptographic agility, so it can adopt quantum-resistant cryptography as standards mature. Quantum-safe vaults and native ML-DSA-65 accounts are in development and progressing toward Testnet. This is an ongoing work, not a finished, fully audited release.
What is the actual quantum threat to my account? A public key is exposed the moment an account transacts. A sufficiently capable quantum computer could recover the private key from that exposed public key and forge signatures. Moving authorization onto quantum-safe signatures ahead of that point is what removes the risk.
Do I need to change anything in my app or account today? No. Existing accounts, contracts, and integrations continue to work unchanged. When quantum-safe accounts and vaults are available, they are additive and opt-in, and a quantum-safe key derives from the recovery phrase you already use.
Why two different algorithms? The two schemes are built on different mathematical families, one lattice-based and one hash-based. If an unexpected weakness is ever found in one, the other does not share its assumptions, so account and vault protection does not rest on a single scheme holding.
When will this ship? Quantum-safe vaults are targeted for Mainnet this year, native accounts for Testnet by end of year, and native account authentication on Mainnet in Q1 2027. Timelines are kept open while independent review continues.
Does this require a hard fork or risk downtime? No. Adding a signature scheme is a routine protocol-feature update, not a change to consensus or existing state, the same path zkLogin and passkeys followed. Vault support requires no core protocol change at all.
Can I secure an account with both a classical and a post-quantum key? Yes. ML-DSA-65 will also be supported in Sui's multisig authenticator, so an account can require both an Ed25519 key and an ML-DSA-65 key to authorize a transaction.
