Sui plans to introduce quantum-safe account security without requiring users to move assets into new blockchain addresses. The network will add post-quantum signatures for accounts and higher-value vaults. The design centers on ML-DSA-65 for regular accounts and SLH-DSA-SHA2-128s for Move-based vaults. Both cryptographic systems aim to withstand attacks from future large-scale quantum computers.
Normally, changing an account’s cryptography can require a new address and asset transfers. That process can affect tokens, NFTs, identities, smart contracts, and connected applications. Instead, Sui plans to use its existing Address Aliases system. An account can authorize another signer while the original blockchain address continues to appear as the transaction sender.
Once native ML-DSA support arrives, existing accounts could authorize post-quantum signers without abandoning their addresses. Users could later make the new signer their only authorized transaction signer.
The approach could simplify migrations for accounts already linked to applications or smart contracts. It also avoids transferring every asset solely because the account needs stronger cryptography.
Sui also plans to let users derive an ML-DSA-65 key from an existing recovery phrase through a new derivation path. Therefore, users would not need another recovery system. Still, an authorized alias receives full control over the account. Sui warns that wallet software must present this process carefully because adding an alias grants authority over account assets.
Also Read: Top 10 Sui Ecosystem Coins Ranked by Market Cap (2026 Guide)
NIST standardized ML-DSA-65 under FIPS 204. The lattice-based signature scheme carries NIST Category 3 security and targets frequent account transactions. Sui selected ML-DSA-65 instead of the smaller ML-DSA-44 configuration because it provides a larger security margin while remaining practical for regular signature verification.
For high-value vaults, Sui plans to support SLH-DSA-SHA2-128s through Move smart contracts. NIST standardized the hash-based signature system under FIPS 205. SLH-DSA-SHA2-128s carries Category 1 security, below ML-DSA-65’s Category 3 level. However, its hash-based construction gives Sui another cryptographic foundation alongside lattice-based ML-DSA.
Using separate systems reduces reliance on one mathematical approach. A weakness affecting lattice-based cryptography would not automatically compromise a hash-based system. What happens if future cryptanalysis exposes weaknesses in one post-quantum signature family? Sui’s vault design lets developers replace the smart-contract authentication scheme when necessary.
Post-quantum signatures require considerably more data than Ed25519 signatures. An ML-DSA-65 signature reaches 3,309 bytes, while its public key requires 1,952 bytes. By comparison, a typical Ed25519 signature uses only 64 bytes. Meanwhile, SLH-DSA-SHA2-128s produces a 7,856-byte signature.
Those figures remain below the 16-to-30-kilobyte sizes linked with stronger SLH-DSA parameter sets. Sui selected the smaller 128s configuration for its planned vault system. Larger signatures increase transaction size and network data. Even so, Sui says ML-DSA verification performs closely enough to Ed25519 that per-signature network costs need not rise.
Sui targets quantum-safe vaults for Mainnet before the end of 2026. Native ML-DSA-65 accounts should reach Testnet by year-end and Mainnet during the first quarter of 2027. Wallet, SDK, and command-line support will accompany the rollout. Independent audits and Testnet feedback continue, so Sui may adjust the schedule before production deployment.
Existing users do not need to act now. Sui plans an additive and optional migration rather than a compulsory network-wide account change. The design also provides a warning against migration scams. Sui’s stated process does not require users to send all assets into a newly supplied wallet address.
Sui plans to introduce post-quantum security through ML-DSA-65 accounts and SLH-DSA vaults while preserving existing addresses. Address Aliases will support migration without asset transfers. Users need no action now as audits, testing, wallet support, and phased deployment continue.