By Kostas Chalkias and Mahdi Sedaghat, Mysten Labs
Main Takeaways
- Sui is going with ML-DSA-65 at NIST Level 3, not the cheaper level. AI-assisted cryptanalysis is now breaking lattice schemes that survived years of human review, and the extra margin is nearly free: verification is at parity with Ed25519.
- Two schemes from two different math families: SLH-DSA vaults live in Move, not the protocol, so a lattice break never touches the hash-based path and Sui can adapt to external standards without a protocol upgrade.
- Nothing breaks for existing users. Private keys stay 32 bytes, so wallet backups are unchanged. Post-quantum accounts are opt-in, and address aliases let existing accounts swap in a quantum-safe key while keeping their address and assets.
In our recent Making Sui Quantum Ready post, we laid out where Sui is headed on post-quantum security: ML-DSA-65 for native account authentication, SLH-DSA-SHA2-128s for high-value vaults, and a migration path that keeps existing addresses and recovery phrases intact.
This post is “the why,” at a cryptographer’s depth. Why ML-DSA-65 and not a cheaper security category. Why we declined Falcon despite its smaller signatures. Why SLH-DSA lives in a smart contract instead of the protocol. Why we wrote our own Rust wrapper implementation instead of pulling in an existing library, and what we found when we did. If you read the first post and wondered what was underneath the decisions, this is that layer.
None of those decisions were really about which algorithm to use. NIST closed that question years ago. For signatures, the shortlist is only two: ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). What took work was everything downstream of it: which security category, which implementation, how the code gets verified, what happens to keys that already exist, and which technically attractive shortcut we decided not to take.
Some context on where we are coming from. Our work on post-quantum systems predates Sui by years: a production stateless PQ scheme at R3's Corda in 2017 (the first stateless and multi-times quantum-safe signature in the distributed ledger space), blockchain-friendly PQ constructions with Mike Hearn in the years after, Winterfell (the first open-source STARK prover, built at Meta), and research on PQ-EdDSA, HashWires, and Truncator. The transition strategy for Sui specifically was mapped out in April 2025 in Securing Sui in the Quantum Computing Era across signatures, hashing, encryption, and zero-knowledge proofs. What follows is the signature half of that plan, now that the decisions are final.
The threat, precisely
Shor's algorithm breaks RSA and elliptic-curve cryptography outright. Grover's gives only a quadratic speedup against hash functions, which larger output sizes absorb. So for a blockchain, the exposure is concentrated almost entirely in signatures rather than hashing.
What makes the blockchain case unusual isn't the algorithm; it's the disclosure pattern. In most systems, a public key sits behind some access boundary, and an attacker needs a breach before the clock even starts. Onchain, the public key is published permanently, at the very first transaction. The signature analogue of harvest-now-decrypt-later needs no quantum hardware at all, just storage and patience: record public keys today, forge signatures whenever the hardware arrives. The collection window opened years ago, and the estimate for when it closes keeps moving in one direction. Google's own figure for factoring a 2,048-bit RSA key fell from twenty million qubits in 2019 to under one million in 2025. Every revision has made the machine cheaper. None has made it more expensive.
That reframes the deadline. In the U.S., Executive Order 14412 (June 2026) set a December 2030 timeline for federal agencies to complete post-quantum key establishment and December 2031 for signatures, earlier than NIST's own 2035 horizon in its still-in-draft transition guidance. For onchain keys, the practical deadline is earlier, because the exposure runs backward: a key published on day one has been exposed since day one, not from when the deadline arrives.
Why ML-DSA-65 and not ML-DSA-44
NIST grades post-quantum schemes into five security categories, each pegged to a brute-force benchmark rather than an abstract bit count: breaking a category 1 scheme must be at least as hard as recovering an AES-128 key, category 3 matches AES-192, category 5 matches AES-256; any PQ attack model allowed (The even categories are defined based on hash collisions instead: category 2 to SHA-256, category 4 to SHA-384.) ML-DSA ships three parameter sets across three of these: ML-DSA-44 at category 2, ML-DSA-65 at category 3, ML-DSA-87 at category 5. A category is a floor under the best-known attack, and choosing one means answering a single question: how much room does that floor need before the best-known attack improves?
We're integrating ML-DSA-65, category 3, as Sui's native protocol signature scheme, instead of the cheaper ML-DSA-44.
One of the reasons is the recent attack on the HAWK signature scheme discovered by Anthropic. HAWK was a well-studied lattice construction with real cryptanalytic attention behind it. Note that HAWK rests on a different lattice problem than ML-DSA, and the attack transfers nothing. What transfers is the lesson: AI-assisted cryptanalysis is now finding things in schemes that have been reviewed by people for years, and that changes how much margin a lattice assumption deserves. Level 1 gives you less room if the security estimate moves. Level 3 gives you a buffer, and the cost of that buffer turns out to be small (see the benchmarks below).
Two secondary reasons. Level 3 is where Chrome and Cloudflare landed for the post-quantum key exchange now protecting a large fraction of web traffic, so it is the level with the most operational deployment behind it. And in conversations about how key establishment is handled in regulated financial contexts, Level 3 is the level that matches expectations.
Hardware was the other input. We verified FIPS 204 compatibility directly against HSM and hardware wallet vendor SDKs. We also prototyped ML-DSA on ultra-low-power DePIN-class devices, the constrained CPU and RAM envelope for NFC post-quantum wallets, which is the case that fails first if the scheme is too heavy. The ecosystem is converging on the same answer: Ledger recently shipped initial support for the official ML-DSA (FIPS 204) in its SDK, bit-for-bit compatible with the NIST standard, and we verified signature interoperability with our implementation in both directions.
We're also monitoring ML-DSA cryptanalysis continuously, and that ongoing uncertainty is part of why SLH-DSA ships first as a smart contract and is what we recommend for vaults: its security rests on hash functions rather than lattices, so a lattice result that moves ML-DSA's estimates does not touch it.
Why didn't we pick Falcon?
The other lattice option was Falcon (FN-DSA, the upcoming FIPS 206), and its signatures are smaller: FN-DSA-512 has signatures of size 666 bytes at Level 1 while ML-DSA-65 signature is 3,309 bytes at Level 3. We still declined for the following reasons:
- No Level 3. Falcon ships at Levels 1 and 5 only (FN-DSA-512 and FN-DSA-1024): either the thin margin we just argued against, or paying Level 5 prices for the buffer which doubles all measurements.
- Not yet standardized. FIPS 206 is still not final; FIPS 204 has been since 2024.
- No canonical seed-to-key derivation. That breaks the 32-byte-seed property that keeps wallet backup unchanged.
- Floating-point Gaussian sampling. Falcon signing samples a discrete Gaussian with floating-point FFT arithmetic, machinery that is widely considered harder to implement correctly than anything ML-DSA requires. ML-DSA is integer arithmetic end to end.
- Harder to implement safely. Constant-time behavior, fault and cache attack resistance, and randomness quality are all more demanding under Gaussian sampling.
- Side-channel resistance. Securing Falcon against timing, cache, and fault attacks is generally considered more difficult than ML-DSA, because of the Gaussian sampling and FFT arithmetic.
- Verification speed. Falcon for higher security Level verifies slower than our ML-DSA results. To be more concrete, on the same machine, FN-DSA-1024 verifies at 49.8 µs vs ML-DSA-65's 23.2 µs, the Falcon parameter set with a real security buffer verifies about 2x slower than our pick.
- Hardware ecosystem. Many HSM vendors, smartcards, TPMs, and secure elements prioritized ML-DSA: it has been finalized earlier, is easier to implement, and was requested by enterprise customers. Our feedback is that hardware support for Falcon is improving but remains less widespread.
- And last but not the least is the ecosystem and tooling. Libraries, SDKs, test vectors, compliance suites, and certified implementations are all more mature for ML-DSA today. That reduces engineering risk, especially for a native function.
Smaller signatures did not outweigh any one of these, let alone all of them together.
Why SLH-DSA lives in Move, not the protocol
For high-value assets we are providing hash-based SLH-DSA-SHA2-128s (FIPS 205) through Move smart contract vaults rather than as a native scheme. This was not a statement about trust in SLH-DSA. If anything, it’s the opposite. Hash-based security is the better-understood family, SHA-256 is already everywhere, and several hardware wallet teams we consulted prefer hash-based schemes precisely because their engineers understand them more deeply. Preference, not capability.
There are three reasons it belongs in-contract:
- Cost profile. SLH-DSA verification is considerably more expensive than Ed25519, and the signatures are large in a way that caching cannot help with. In ML-DSA, the public key is the reusable part, so caching pays off; SLH-DSA offers no comparable win.
- Standards risk. There is a real chance that Bitcoin, Ethereum, and the next round of NIST standards converge on a narrower set of signature schemes than exists today. Whatever the Bitcoin and Ethereum communities settle on, including the various hash-based proposals now under discussion, we want to be compatible quickly. Sui's bridges to Ethereum and Hashi for Bitcoin make that concrete: an in-contract implementation means supporting a PQ-compatible Bitcoin wallet on Sui requires no new core Sui version. A native scheme would mean a protocol upgrade every time the target moved.
- Implementation surface. SLH-DSA in Move is mostly Merkle tree work, which is a smaller and more legible surface than a new native authenticator, and it ships without a fork or protocol upgrade: the byte handling and hash primitives it needs already exist in the Move language.
The two schemes rest on different mathematical families, which is the point. A break in lattice assumptions does not touch the hash-based path, and vice versa. For the highest-value accounts, Sui's existing two-of-two multisig also lets users require both a classical and a post-quantum signature, so neither scheme alone is a single point of failure. That is the hybrid position argued in the recent debate initiated by Bernstein.
Both choices follow NIST's standardized post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA) and the joint CISA/NSA/NIST quantum-readiness roadmap.
Benchmarks
Every argument above rests on cost. Here's the cost, measured through fastcrypto on Apple M2 Max:
Two things matter here.
Verification is at parity, slightly better in fact, so the per-signature CPU cost to validators does not rise, which is an excellent property as Sui is one of the fastest L1s globally and it is paramount to maintain that leadership even after a post-quantum transition. This (verification cost) is the number that matters, because the costs live in different places: key generation and signing happens per transaction, offchain, on the signer's own device, while verification runs on every validator for every transaction. Signing is slower in absolute terms but irrelevant at 66 µs on a client device, and also in order of milliseconds in the browser, that never notices.
The private key stays 32 bytes because it is a seed. Wallets back up and restore exactly what they do today, and the new keys derive from the same recovery phrase through a new standard derivation path.
The honest cost is size, roughly 50x per transaction. That is what the whole industry is paying for quantum resistance and it is where our optimization work is focused. Two things soften it on Sui specifically: the transaction size limit is up to 128 KB, so we have room that chains with tighter limits do not, and we have shipped and operated large-signature constructions before, including multisig zkLogin. Programmable transaction blocks also mean one signature can authorize many intents, so the per-operation overhead is lower than the per-signature figure suggests. Public-key caching, along the lines of what we already do for zkLogin, would let a user submit their public key once and send only signatures afterward. That is not enabled in version zero; we are keeping the first implementation conservative and will turn it on deliberately.
We should also note that these numbers are one configuration. Reporting properly means covering the validator-side Rust path, a normal developer configuration, and browser signing through the TypeScript stack. We intend to publish that fuller set. A broader comparison of the NIST signature candidates is at nist-sigs-zoo.
Separately, Sui's Remora research on execution scaling makes the throughput side of a post-quantum transition considerably easier than it would otherwise be. The two lines of work were aligned deliberately.
The implementation, and why we wrote our own
Every language has a large cryptographic library that already includes ML-DSA, and pulling one in is the obvious move. We did something else: mysten-mldsa-native-rs, our thin Rust wrapper over mldsa-native, the compact formally verified implementation of exactly this scheme maintained under the Linux Foundation's pq-code-package project. It is the same core that ships inside several major industry libraries like aws-lc, only without the rest of the library around it.
The reason is what sits on the consensus path. Every validator runs the verification code on every transaction, so we wanted a surface that is easy to read and no configuration knobs that could be set incorrectly. The wrapper exposes exactly one mode: the FIPS 204 default, hedged signing with fresh randomness per signature, the variant that resists fault attacks and randomness reuse. It carries no random number generator of its own, so every operation is reproducible in a test. The private key has one serialized form, the 32-byte seed, which is what lets wallets back up and restore exactly what they do today.
As discussed above, our implementation is fast and the speed comes from upstream's verified assembly for Apple/ARM and x86 server hardware, selected per machine at run time so one binary stays correct across a mixed validator settings. The signatures are identical either way. The Assembly backends just arrive about 2.5x faster than the portable C.
The failure nobody talks about
The danger in new cryptography is rarely the math. It is the code and rush in implementation.
This year a soundness bug was disclosed in one of the leading STARK provers. A value the verifier trusted was never bound into the proof transcript, which meant a malicious prover could forge proofs of false statements and verifiers would accept them. It had been in open-source code since 2024. It survived an external audit and formal verification. It was found by an AI auditor in June 2026 too, while nothing was exploited.
ML-DSA already has its own version of this record. In 2026 alone, 4 implementation vulnerabilities were disclosed across 3 independent codebases of this one scheme: an out-of-bounds write in libgcrypt's signing path (CVE-2026-41990), a timing side channel in the RustCrypto ml-dsa crate's hint computation that could leak signing-key material (CVE-2026-22705), a verification bug in the same crate that accepted signatures with duplicate hint indices (CVE-2026-24850), and a fault-injection weakness in wolfSSL's post-quantum code on embedded targets (CVE-2026-3503). The verification bug is the one worth sitting with: FIPS 204 gives a valid signature with exactly one encoding, and an implementation that accepts a second one makes signature validity depend on which node you ask; which, on a blockchain, is a chain split. In the same period, the count of breaks in ML-DSA's actual mathematics was zero. The math is holding and the code is where the risk lives.
We keep returning to this example because it is the correct prior for anything we ship; the HAWK result points in the same direction. The review processes we have historically trusted (meaning human audit, formal methods) and years of open exposure, did not catch either of these, and AI-assisted analysis did. That is an argument for margin in parameter selection, small auditable surfaces, cross-implementation verification as a build gate, and for being slow about the components that are newest.
It is also the reason for the next section.
The button we are not pressing yet
There is a shortcut available to us that is better than the path we are taking, and we are not taking it.
Every Ed25519 key on Sui derives from a seed that sits behind a hash. A quantum computer that breaks the curve recovers the signing scalar, but not the seed it came from. Our research, Post-Quantum Readiness in EdDSA Chains (Baldimtsi, Chalkias, Roy and Sedaghat, eprint 2025/1368), turns that asymmetry into a quantum-safe ownership proof: prove in zero knowledge that you hold the seed, authorize a new post-quantum key, keep your address, and never expose a secret.
The properties are better than a derivation-path migration. It works for accounts with already-exposed public keys. It works retroactively for keys derived years ago. And it works for dormant accounts that will never sign another transaction, which is the population no other migration proposal reaches, and on chains without deterministic seed derivation is not reachable at all. This is the structural advantage EdDSA chains have over ECDSA chains, and it is the reason the paper is about EdDSA specifically.
So why not press it now? Because the button is a zero-knowledge proof system, and shipping it means the proof system becomes the thing account security rests on, machinery younger than the signatures it would protect. Read the previous section again.
Waiting costs very little, because the button does not expire. A seed does not become less secret over time. The proof can be built when proof systems have earned that trust. And in the meantime the direct path carries the migration: native post-quantum accounts through a new derivation path, plus address aliases for existing accounts. We are treating zkPQ-EdDSA as a killswitch rather than a launch feature. One property falls out of the design worth noting: because an ML-DSA private key on Sui is also a 32-byte seed, the same proof-of-seed construction can later run on top of post-quantum accounts themselves, if that is ever wanted.
Migration mechanics
Under both hardening updates, Sui offers a new standard derivation path, and adoption is opt-in per account. Existing accounts do not need to move funds. Address aliases, already deployed, let an account update its authorization key to a post-quantum key while keeping its address and its assets in place. That is the mechanism doing the real work for existing users today, not the ZK construction above, which is deferred.
For quantum vaults, withdrawals use a two-transaction model, with simple transfers potentially requiring only one. For builders and institutions, there’s a practical upshot: quantum-safe accounts arrive as an additive option through the same rollout path zkLogin and passkeys used. No migration is forced, nothing existing changes, and enabling it is a routine protocol-feature update rather than a change to consensus or existing state.
Where the industry is
We are not alone, and we do not want to be. Near shipped ML-DSA-65 as an opt-in key type this summer, the same scheme and the same level we chose, which is a useful independent signal. Ethereum's consensus roadmap leans hash-based. Bitcoin has active proposals and no decision.
Where we think Sui is ahead of the curve is architectural rather than algorithm choice: two schemes matched to two threat models, vaults that adapt to external standards without a protocol upgrade, and users who keep their addresses.
Status and timeline
The core implementation is built and benchmarked. Quantum-safe vaults are targeted for Mainnet this year, native ML-DSA-65 accounts for Testnet by end of year, and native account authentication on Mainnet in Q1 2027 as a worst case with wallet, SDK, and CLI support arrive alongside.
Independent external audits are underway. We cannot commit that every audit completes on schedule, and we would rather move a date than ship an unaudited authenticator. Everything here reflects current direction and is subject to audit findings and Testnet feedback.
Everything you'd need for that review is public: FIPS 204 and FIPS 205, the standards themselves; mldsa-native, the formally verified C implementation that we build on; mysten-mldsa-native-rs, our native Rust wrapper, with its KAT vectors; and Post-Quantum Readiness in EdDSA Chains open source implementation, the construction we're deliberately not shipping yet.
We would rather have this reviewed than admired. The implementation surface is small on purpose, the cross-verification is a build gate on purpose, and the migration shortcut is deferred on purpose. If you work on post-quantum signatures, hardware wallets, or proof systems and you think one of these calls is wrong, we want to hear it.
One Easter egg
A derivation path is the recipe a wallet follows to turn one recovery phrase into many keys: a short sequence of numbers applied step by step, so the same phrase yields the same keys on any device. Every mnemonic-based Sui key derives from such a path, and the first number in it, the purpose number, identifies the signature scheme. An Ed25519 key on Sui today derives from:
m/44'/784'/0'/0'/0'
where 784' identifies Sui and 44' is the purpose number; the ECDSA schemes use 54' and 74'. Post-quantum keys will use:
m/94'/784'/0'/0'/0'
That is not just the next number in the sequence. It is a date. Surprisingly, in 1994, Peter Shor published the algorithm that made all of this necessary. To celebrate this coincidence, every quantum-safe Sui key will carry the year the countdown started in its derivation path.
