Mentioned in This Article
1. Sui quantum-safe transaction clears devnet
Mysten Labs, the developer behind the Sui blockchain, said on October 13 that Sui's development network has processed its first native quantum-safe transaction. The transaction used ML-DSA-65, a post-quantum signature scheme now supported as a native account signature type on devnet under protocol version 139, released on October 12.
The milestone is limited in scope. It took place on devnet, a testing environment, and the feature is opt-in. Mainnet support for ML-DSA-65 accounts is targeted for the first quarter of 2027, and that date depends on independent audits and feedback from testnet.
For everyday holders of SUI, nothing changes today. The announcement matters mainly as a marker of progress on a roadmap that Sui laid out in August 2026 to prepare the network for the possibility that quantum computers could one day break the digital signatures that secure blockchain accounts.
The Sui quantum-safe transaction is therefore best read as an engineering checkpoint. It shows that the network can validate a post-quantum signature in a live test environment, which is a precondition for everything that comes after: audits, a wider testnet rollout and, eventually, mainnet availability.
2. What changed in the code?
The update adds a new entry to Sui's list of supported signature schemes, registering ML-DSA-65 alongside the options the network already accepts. With it in place, an account can authorize transactions using the post-quantum scheme instead of a conventional one.
ML-DSA-65 was standardized by the U.S. National Institute of Standards and Technology under FIPS 204 and is rated at security level 3. Sui intends to use it for ordinary native accounts, meaning the wallets people use to send tokens and interact with applications.
A signature scheme is the mathematical method by which a wallet proves that the owner approved a transaction. Most blockchains rely on schemes whose security would be undermined by a sufficiently powerful quantum computer. Post-quantum schemes are built on different mathematical problems that are not expected to be vulnerable in the same way.
Post-quantum signatures typically come with trade-offs. Their keys and signatures are larger than those of the elliptic-curve schemes used by most blockchains today, which can increase the amount of data each transaction carries. Blockchain developers therefore have to confirm that verification remains fast enough and that the added size does not translate into higher costs for users. Mysten Labs says users will not pay extra fees for quantum-safe signatures.
ML-DSA belongs to the family of lattice-based schemes, which rely on the difficulty of certain problems involving high-dimensional geometric structures. Researchers have studied these problems for years, and NIST selected the approach after a multi-year public evaluation of candidate algorithms. Standardization does not guarantee permanent security, but it means the scheme has been examined widely and has a defined specification that software and hardware vendors can implement consistently.
3. Why does Sui use two different schemes?
Sui plans to pair ML-DSA-65 for everyday accounts with a second scheme, SLH-DSA-SHA2-128s, for high-value vaults written as Move smart contracts. Move is the programming language used for contracts on Sui. Both schemes are approved by NIST, and they belong to different mathematical families.
That difference is deliberate. If a weakness were found in one family, the other would not automatically be compromised. Using the hash-based scheme to protect the largest pools of funds, while the lattice-based scheme secures routine accounts, spreads the risk across two independent bets.
The vault upgrade is scheduled to reach mainnet before the account-level change, with a target of 2026. Native ML-DSA-65 account support follows, with the first-quarter 2027 target. Both timelines are conditional on audit results and testnet feedback, so they could move.
The reasoning behind the pairing is a form of diversification. Hash-based schemes derive their security from the properties of hash functions, which are among the best-understood building blocks in cryptography, but their signatures tend to be larger. For a vault that holds substantial value and signs infrequently, that cost is acceptable. For a wallet that signs many small transactions, a more compact scheme is more practical.
4. What does it mean for users and wallets?
Adoption is opt-in, and users who choose to switch can keep their existing 32-byte seeds and recovery phrases. Addresses do not change. The upgrade relies on Sui's existing address alias mechanism and lets users rotate their keys starting from their recovery phrases.
Gas costs are also unchanged. Quantum-safe signatures carry no extra fees on the network, which removes one practical objection, since post-quantum signatures are generally larger than conventional ones and could otherwise raise the cost of transactions.
The effort is led by Kostas Chalkias, a Mysten co-founder and its chief cryptographer, and Adeniyi Abiodun, co-founder and chief product officer. Their stated aim is to make the change as unobtrusive as possible for people who simply want to hold and use tokens.
Keeping the same seed and address is a significant design choice. Moving to a new signature type often forces users to create new addresses and transfer funds, a process that introduces risk, particularly for less technical holders. By letting people rotate keys under the same address, Sui aims to make the transition closer to a settings change than a migration.
A recovery phrase is the list of words from which a wallet derives its keys. Because users can start from the phrase they already hold, they would not need to back up a new secret to benefit from the upgrade. That reduces the chance of lost access during the switch, though users will still need to follow the wallet's instructions carefully when the feature becomes available.
5. How does this fit Sui's quantum roadmap?
The devnet transaction is one step in the quantum readiness strategy that Sui published in August 2026. The plan sequences the work: first the vault protection, then native account signatures on testnet and mainnet, with audits running alongside.
A staged approach is common for changes to a blockchain's cryptography. New signature types touch wallets, software development kits, exchanges and custodians, and an error in verification code could have serious consequences for funds. Running the feature on devnet first lets developers exercise it where mistakes are inexpensive.
The roadmap is also explicit that it reflects current direction, not a finished and fully audited release. Until audits are complete and testnet feedback has been incorporated, the schedule remains a target rather than a promise.
Why take these steps years before quantum computers are expected to threaten blockchains? Part of the answer is that cryptographic transitions are slow. Standards must be finalized, code written and audited, and software across wallets and exchanges updated. A network that waits until a threat is imminent may find that there is not enough time to move every account safely.
There is also a concern sometimes described as harvest now, decrypt later, in which an adversary stores data today in the hope of breaking its protection once better machines exist. For blockchains, public keys and signatures are already recorded permanently, so planning the transition early reduces the window in which old accounts remain exposed.
6. Who is affected right now?
For typical holders, the feature is a devnet capability that they need not act on. Applications do not have to change anything today, and existing accounts continue to work as before.
The vault upgrade is the nearer-term item of consequence. Teams managing large treasuries in Move contracts should watch whether SLH-DSA vaults reach mainnet on the 2026 schedule and how auditors assess the implementation. Institutions that custody significant amounts on Sui have an obvious interest in those results.
The account-level change affects a wider group, but only those who opt in. An opt-in feature protects only the people who use it, so its security value depends on how many wallets and applications adopt it once it reaches mainnet.
For application developers and wallet makers, the work ahead is practical. They will need to integrate the new signature type into their software, test it against the network and decide how to present the option to users. Because the feature is opt-in, the pace at which wallets offer it will shape how quickly accounts actually become quantum-safe.
Larger holders and institutions are likely to be the first to take interest. Their balances make them more attractive targets and more sensitive to long-term risk, and they usually operate under internal policies that require security upgrades to be assessed well in advance. The vault feature is aimed squarely at that audience.
7. What to watch next
Several markers will show whether the schedule holds. The first is the outcome of independent audits of the signature implementations. The second is feedback from testnet, where the account feature is expected to be tested more widely before it reaches mainnet. The third is whether the vault upgrade lands on mainnet within 2026.
Wallet providers and exchanges will also need to add support for the new signature type before users can benefit from it. Without that, the capability would exist on the network but remain difficult to use.
Mysten Labs has targeted the first quarter of 2027 for mainnet support of ML-DSA-65 accounts, subject to audits and testnet results. Until then, the devnet transaction is best understood as evidence that the core implementation works in a test environment, not as a change to the security of funds held on the live network.
The broader context is an industry-wide discussion about quantum risk. Other networks and standards bodies are examining their own paths to post-quantum signatures, and the approaches differ. Sui's decision to introduce the capability as an optional signature type, rather than forcing a network-wide change, gives it room to learn from early adopters before deciding what comes next.