Sui is preparing a post-quantum security upgrade that could let users protect existing assets with new cryptographic keys, without transferring funds to new addresses. The approach promises a smoother migration, but larger signatures will test transaction economics, wallet support and the network’s operational discipline.
A security problem with a practical deadline
Quantum computing is not yet capable of breaking the public-key cryptography used by major blockchains. That does not make the risk theoretical for long-term asset holders.
Most blockchain accounts depend on signature schemes that are considered secure against conventional computers but vulnerable to sufficiently powerful quantum machines. A future quantum computer could use Shor’s algorithm to derive a private key from a public key, allowing an attacker to authorize transactions from an exposed account. The threat is especially relevant to organizations holding assets for years, including exchanges, treasuries, custodians and financial institutions.
The challenge for a live Layer 1 network is not simply choosing a stronger signature algorithm. It is upgrading accounts without forcing every user to understand cryptography, move assets manually or accept a period in which old and new wallets behave differently.
Sui’s proposed response is to support NIST-approved post-quantum signature schemes and allow users to derive quantum-safe keys from existing recovery phrases. The plan, described by Sui to The Block, is designed to reduce the most disruptive part of a cryptographic migration: moving ownership of assets from an old account to a new one.
That distinction matters. A conventional wallet migration usually requires a user to create a new key pair, send assets to a new address and confirm that the destination is correct. Each step introduces fees, phishing risks and the possibility of lost access. For institutional users, the process can also require changes to custody policies, internal approvals and accounting records.
Sui’s proposal instead separates the recovery phrase from the signing method. A phrase that currently derives a conventional key could also derive a post-quantum key under a compatible wallet implementation. Users could then use address aliases to change which key authorizes transactions, while retaining control of the same assets.
The idea is similar to replacing the lock on a vault without moving the contents. It is technically more demanding than a standard wallet update, but substantially easier for users to understand.
The cost of bigger signatures
Post-quantum security comes with a measurable burden. The cryptographic material is much larger than the keys and signatures used by many current blockchain accounts.
For comparison, an Ed25519 public key is typically 32 bytes and its signature is 64 bytes. NIST’s ML-DSA family, one of the principal standards for post-quantum signatures, uses considerably larger objects. Depending on the security level, a public key can range from roughly 1,300 bytes to 2,600 bytes, while a signature can range from about 2,400 bytes to more than 4,600 bytes.
The alternative SLH-DSA family can produce signatures that are much larger still, in some configurations reaching tens of kilobytes. These sizes are not an abstract engineering detail. They affect how much data a transaction carries, how much information validators must transmit and how much work wallets and nodes must perform when creating and checking transactions.
A Sui transaction with a quantum-safe signature would not necessarily cost users a simple multiple of the current fee. Sui’s gas model accounts for computation and storage, and signature data may be processed differently from data permanently written to the network. The exact effect will depend on how Sui encodes signatures, which parameter sets it supports and whether the network introduces special accounting for authentication overhead.
Still, three costs will need to be measured.
The first is transaction size. Larger signatures consume more bandwidth between users, full nodes and validators. A single transfer is unlikely to threaten capacity, but applications that batch payments, submit many orders or generate frequent automated transactions could feel the difference.
The second is verification cost. Post-quantum signatures require more computation than conventional elliptic-curve signatures. Validators will need to verify those signatures quickly enough to maintain transaction throughput. The network may be able to parallelize some of this work, but the performance profile must be tested under realistic load rather than isolated benchmarks.
The third is wallet and storage overhead. Mobile devices and browser wallets will need to generate, store and use larger keys. Hardware wallets may require new firmware and memory management. Custodians will need to update signing infrastructure, approval systems and recovery procedures.
For users, the most important number will be the marginal cost of a post-quantum transaction compared with a conventional transaction. Sui has not yet provided a broadly available public schedule showing that cost across transfer types and signature schemes. That information should become a central adoption metric as the feature moves through testing.
A useful benchmark would compare a conventional transfer, a transfer signed with the first supported post-quantum scheme and a transaction involving several signers. The results should include bytes transmitted, signature verification time, gas consumed and validator resource use. Without those figures, “quantum-safe” describes a security property but not the product experience.
Migration without moving the assets
Sui’s use of address aliases is intended to solve a difficult part of the transition. Instead of creating a new on-chain account and transferring every asset, a user could update the authorization associated with an existing address.
That could be valuable for more than individual wallets. A company could preserve a known treasury address while rotating from conventional keys to post-quantum keys. A decentralized application could maintain established ownership records while changing its account authorization. An exchange could reduce the operational risk of moving large balances between hot and cold wallets.
The design also recognizes that cryptographic migration is rarely a single event. Users may want to maintain more than one valid signing method during a transition. A conventional key could remain available for compatibility while a post-quantum key is added for higher-value operations. Over time, the older key could be removed or restricted.
This flexibility creates its own security questions. Users must know which key is active, which key can change authorization and whether an alias update is reversible. If an attacker gains control of an old key before it is retired, the migration process could become an additional attack surface. Wallets will need clear warnings, transaction previews and recovery flows that do not hide the change behind a generic account update.
The recovery phrase model also deserves scrutiny. Deriving multiple cryptographic keys from one phrase is convenient, but it means that the phrase remains the ultimate root of control. A user who loses it may lose both conventional and post-quantum access. A user who exposes it may compromise every key derived from it.
Wallet developers will need to explain whether the same phrase can be restored across products, whether derivation paths are standardized and whether a user can export a post-quantum account without exporting a conventional one. Interoperability will determine whether the feature feels like a network upgrade or an ecosystem-specific lock-in.
Move contracts and high-value vaults
Sui is also positioning Move contracts as a way to protect high-value assets during the transition. A vault can require more than one authorization method, impose a delay before withdrawals or limit the actions available to a compromised key.
This is where post-quantum support can become a broader account design improvement rather than a replacement for one signature algorithm. A treasury might require a conventional key for routine transactions but demand a post-quantum signature, a second signer or a time delay for large withdrawals. A custodian could separate daily operational balances from a long-term reserve held behind stricter rules.
Move contracts are well suited to this kind of programmable control because account behavior can be defined in code. The benefit is not that a contract eliminates cryptographic risk. It is that the contract can reduce the consequences of a single compromised key.
An opt-in vault model also gives Sui a way to introduce quantum-safe security gradually. Users who hold small balances may not want larger transactions or a more complicated wallet. Institutions with long holding periods may accept the additional overhead immediately. Allowing both models could prevent the post-quantum upgrade from imposing its highest costs on the entire network at once.
Adoption will be the test. Sui should disclose how many wallets create quantum-safe keys, how many assets enter protected vaults and how often those vaults are used. The number of supported wallets alone will not demonstrate demand. A feature that exists in documentation but protects little value is not yet a migration strategy.
The network could publish separate figures for individual users, applications and institutional accounts. It could also report the share of high-value assets held under quantum-safe or hybrid policies. Those measurements would show whether the system is solving a real custody problem or merely adding a specialized option for developers.
Wallet support is the bottleneck
A protocol can support a new signature scheme long before the average user can use it safely. Wallets, hardware devices, custodians and applications must all recognize the new account format.
For Sui, the first challenge will be recovery. A user must be able to enter an existing phrase into a supported wallet and see the correct quantum-safe account. The wallet should make the relationship between the old address and the alias visible, while preventing users from confusing an authorization update with a transfer.
The second challenge is signing. Post-quantum keys may require more memory and processing power, particularly on hardware devices with strict resource limits. A wallet that works smoothly on a desktop may be slow or unavailable on a mobile device. Custody providers may prefer remote signing systems, but those systems will need new controls to protect larger key material and verify the selected algorithm.
The third challenge is application compatibility. Decentralized applications often assume a particular address format, transaction structure or signature type. They may need updates to recognize aliases and request the correct authorization. If an application cannot interpret a quantum-safe account, users may be forced to maintain a conventional key even after migrating their assets.
This is why a staged rollout is important. Sui’s approach appears to begin with support that can be layered onto existing accounts, including wallet-level key derivation and Move-based vaults, before native mainnet account support becomes broadly available. That sequence gives developers time to test the user experience and lets validators prepare for new transaction types.
The timetable toward native mainnet accounts will be a meaningful signal. A testnet launch can demonstrate that key generation, signing and verification work. It cannot establish that exchanges, wallets and high-volume applications are ready. Sui will need to publish clear milestones for testnet availability, validator software, wallet integrations, audits and mainnet activation.
A vague roadmap would create the same uncertainty that the upgrade is intended to remove. Users holding assets for years need to know whether they should wait, create a vault now or begin a hybrid migration. Developers need to know when a new account type can be used in production. Validators need enough lead time to benchmark hardware and update operations.
Validator readiness after recent outages
The timing places an additional burden on Sui’s execution team. CoinDesk reported in June that the Sui mainnet halted three times in 48 hours, with developers attributing the incidents to a bug in an upgrade. The interruptions were resolved, but they made upgrade reliability part of the conversation around any future protocol change.
A cryptographic upgrade is not identical to a routine software release. It changes transaction parsing, signature verification and potentially account authorization. A failure in any of those areas could prevent valid transactions from executing, create inconsistent behavior across software versions or leave users uncertain about which key controls an account.
Sui will need more than a successful demonstration on a small testnet. Validators should test mixed workloads containing conventional and post-quantum signatures, large transactions, multisignature operations and alias updates. They should measure bandwidth, CPU utilization, memory consumption and recovery behavior when nodes restart or fall behind.
The network should also make its rollout reversible where possible. A staged activation, clear version requirements and emergency procedures can reduce the chance that a cryptographic feature becomes an operational fault line. Independent audits of signature libraries and transaction handling would add another layer of confidence, especially because cryptographic implementations can fail even when the underlying mathematics is sound.
The recent outages do not prove that Sui cannot deliver this upgrade. They do mean that reliability claims should be backed by public evidence. Validator participation, test results and incident response plans will matter as much as the security standard selected.
The business case for cryptographic agility
Quantum resistance is often presented as a distant technical requirement. Sui’s plan makes it a product and infrastructure test that can be evaluated today.
The strongest part of the proposal is its focus on migration. Reusing recovery phrases, changing authorization through aliases and protecting valuable assets with Move contracts could lower the cost of moving from one cryptographic era to another. That has implications for institutions that cannot casually rotate billions of dollars in assets, as well as for consumers who will not follow a complex manual migration guide.
The trade-off is equally clear. Larger signatures can increase transaction overhead, wallet complexity and validator costs. If the network hides those costs from users, application developers and node operators may absorb them instead. If Sui exposes the costs clearly and gives users a choice between conventional, hybrid and quantum-safe controls, the upgrade can become an example of practical cryptographic agility.
The next milestones should therefore be measured, not promotional. Sui needs to show the size of each supported signature, the gas impact of representative transactions, the effect on validator performance and the number of wallets that can restore and use the new accounts. It should report how many opt-in vaults are created and how much value they protect. It should publish a firm path from experimental support to native mainnet accounts.
Post-quantum security will not be adopted because a blockchain announces a standards-compliant algorithm. It will be adopted when users can activate it without fear of losing access, applications can support it without rewriting their systems and validators can process it without sacrificing reliability.
Sui has chosen a migration problem that is both technically ambitious and commercially important. The result could give long-term asset holders a credible path to stronger security. It could also expose the hidden costs of asking a live network to carry much larger cryptographic objects.
That tension is the real test. Quantum-safe accounts must be secure, affordable and dependable at the same time. If Sui can deliver all three, cryptographic agility may become a feature that helps define the next generation of Layer 1 infrastructure.
