Mysten Labs Processes First Quantum-Resistant Sui Transaction Under Protocol Version 139
Mysten Labs processed the first Sui devnet transaction signed with ML-DSA-65, the NIST-standardized post-quantum scheme, under protocol version 139.
AI SummaryAI
- Mysten Labs processed Sui's first devnet transaction using ML-DSA-65 signatures under protocol version 139.
- ML-DSA-65 is the signature scheme NIST standardized as FIPS 204.
- Sui Foundation's August 6 plan assigns SLH-DSA-SHA2-128s signatures to smart contract vaults.
- ML-DSA-65 accounts target testnet by year-end and mainnet support in Q1 2027.
Update 05:59 UTC: The transaction executed on v1.82.0 confirms the point in practice, since the ML-DSA-65 signature rides on the standard per-signature fee model.
First ML-DSA-65 Signature on Sui Devnet
Until this change, an account on Sui could commit a transaction only under classical signatures, the Ed25519 scheme that secures most addresses today and the kind of public-key cryptography that protects much of web3 and that a sufficiently advanced quantum computer could eventually break. That limit is now gone at the trial stage. Mysten Labs has processed the first native transaction on the Sui devnet signed with ML-DSA-65, a quantum-resistant scheme, and the change is documented in the network's own release record rather than an announcement post. The devnet changelog ties the capability to protocol version 139, which adds ML-DSA-65 signatures and multisig support to the development network. This is a feature test, not an upgrade applied to mainnet accounts. A digital signature does two jobs at once: it confirms who approved a transaction and verifies that the underlying data was not altered. The security question for blockchains is whether the signature layer can be swapped once quantum machines mature, because an attacker who could forge signatures could spend from addresses whose public keys sit exposed on-chain. ML-DSA-65 is the signature scheme the US National Institute of Standards and Technology standardized as FIPS 204, giving implementers a fixed, reviewed specification instead of an experimental design. NEAR Protocol has already deployed ML-DSA-65 on its mainnet, although each chain applies the scheme within its own scope and verification rules, so the Sui result does not transfer automatically. What the devnet shows is concrete: the transaction path now accepts and validates a post-quantum signature end to end, with multisig policies available on top of it. The milestone hands node operators and wallet builders a concrete target to build against before any mainnet date is set.
Mysten Labs co-founder and chief cryptographer Kostas Karylis announced the milestone on October 13, publishing the on-chain transaction record, and the capability arrived with the devnet v1.82.0 release the company shipped on October 12. The devnet build lets a transaction signed with ML-DSA-65 be submitted through the ExecuteTransaction API and checked through the VerifySignature API, and the same release extends the scheme to multisig transactions while integrating it into the GraphQL interface and the Rust SDK. On cost, the foundation says the larger post-quantum signatures and public keys inflate transaction size relative to Ed25519, but per-signature network load stays unchanged. Work on the independent audit continues, and the foundation restates that the testnet and Q1 2027 targets can move with test results.
One cost detail adds clarity to the milestone: choosing a post-quantum signature carries no extra gas charge. Kostas Karylis said on October 8, ahead of the merge, that Sui-native post-quantum accounts would go live with the Monday devnet release and that holders would not pay more simply for protecting assets against quantum computers. The transaction executed on v1.82.0 confirms the point in practice, since the ML-DSA-65 signature rides on the standard per-signature fee model. The implementation, documented on Mysten Labs' GitHub, also allows combined authentication that mixes the classical Ed25519 scheme with ML-DSA-65 in a single account authorization, a capability that lets existing setups adopt the new scheme incrementally rather than all at once.
Sui Foundation's Two-Track Quantum Plan
The August 6 quantum readiness plan from the Sui Foundation assigns the two schemes to separate tracks. Regular accounts are slated to adopt ML-DSA-65, while smart contract vaults, the code that secures everything from escrow logic to a bridge protocol, are set to use SLH-DSA-SHA2-128s, a hash-based signature design. The two schemes rest on different mathematical foundations, which is why the foundation runs them on separate schedules. The layering is explicit: SLH-DSA-based vaults carry a 2026 mainnet target, ML-DSA-65 accounts are slated for the testnet at the end of the year, and mainnet support for those accounts is targeted at the first quarter of 2027. None of it is fixed. The foundation has said timelines can shift with independent audits and testnet feedback, so Q1 2027 reads as a planning target rather than a commitment. Migration is designed as the holder's choice. Users would derive new keys from their existing recovery phrase and then switch the account's authentication key through address aliasing, without moving assets to a new address. That covers every custody setup, including funds held in a cold wallet, because the re-keying happens at the account layer rather than through a transfer. The physical cost of the change is larger data: ML-DSA-65 signatures and public keys are bigger than the Ed25519 ones they would replace. The foundation says verification cost stays at a similar level, but real mainnet performance and security are exactly what the audits and tests ahead must establish, on a network whose throughput has been pushed to 40,614,180 TPS in a live stress test.
Adoption Stays the Open Constraint
Our reading: the devnet switch settles whether post-quantum signing can run on Sui's transaction path, not whether holders will actually move. Migration is opt-in, so legacy Ed25519 accounts remain fully valid alongside post-quantum ones, and the network's aggregate security will depend on how quickly users re-key. Both gating conditions, independent audit and testnet feedback, sit outside the code that shipped this week, which is why every date in the foundation's plan stays provisional. The constraint that remains after this one is gone is adoption, not capability. The token itself slipped about 5% over the past 24 hours, a move our live Sui technical analysis tracks separately from the code change. Holders planning a re-key can start with our Sui beginner guide, and broader coverage of the Sui ecosystem is collected on our tag hub.
AI-generated, AI-reviewed, under COINOTAG editorial oversight.

