Sui’s Quantum Security Plan Puts Wallet Usability to the Test

Sui is preparing optional quantum safe accounts and high value asset vaults, but the technology will succeed only if users can adopt it without facing larger transactions, broken wallet flows or costly asset transfers.

Sui ecosystem developers are turning a long term cryptographic risk into a near term product test. The network plans to introduce optional quantum safe vaults on mainnet later in 2026, followed by native quantum safe accounts on testnet by the end of the year and on mainnet in the first quarter of 2027.

The proposed system would combine ML-DSA-65, a post-quantum signature standard, with hash based signatures for vaults holding high value assets. The objective is to protect accounts against a future class of quantum computers capable of undermining the public key cryptography used by most blockchains today.

That future may still be distant. The implementation problems are not. Larger signatures can increase transaction costs and place pressure on wallets, custodians and applications. New account types may complicate recovery. Smart contracts and exchanges may need to recognize additional address and authorization formats. Users may also resist security upgrades if the process requires them to move funds, change addresses or understand unfamiliar cryptographic choices.

Sui’s plan is therefore less a response to an immediate quantum attack than a live test of blockchain migration. It will show whether a working network can add heavier cryptography while preserving the basic expectations of digital finance: simple account management, predictable fees, broad application support and reliable recovery.

A threat measured in decades, with consequences today

Most blockchain accounts rely on elliptic curve signatures. These systems are considered secure against conventional computers because deriving a private key from a public key is computationally impractical. A sufficiently capable quantum computer could use Shor’s algorithm to solve the underlying mathematical problem much faster.

The threat is not that every crypto wallet becomes vulnerable as soon as quantum computing improves. The timing depends on several factors, including the size and reliability of quantum machines, whether a public key has been exposed and how quickly users can move assets after a breakthrough.

Some blockchain accounts reveal a public key only when a transaction is signed. Other systems expose public keys through repeated use or account formats. Assets held at addresses whose public keys are already visible could become more attractive targets in a future attack. An attacker would need to derive the private key quickly enough to authorize a competing transaction before the legitimate owner moved funds.

That uncertainty has encouraged a gradual approach. Developers can prepare quantum resistant tools now, even if they do not yet know when the risk becomes operational. Preparing early also gives wallets, exchanges, custodians and regulators time to test the consequences without waiting for a crisis.

The practical challenge is that post-quantum cryptography generally requires larger keys, signatures or other data structures than the cryptography used in current blockchains. This can affect transaction size, storage, bandwidth, execution costs and user interfaces. In a financial network, those changes are not merely technical details. They influence the cost of custody, the design of compliance controls and the accessibility of the system to ordinary users.

What Sui is proposing

According to reporting by The Block, Sui developers are preparing two related forms of protection.

The first is an optional account model using ML-DSA-65. ML-DSA is a lattice based digital signature scheme standardized through the US National Institute of Standards and Technology’s post-quantum cryptography program. The 65 parameter set is designed to provide a security level broadly associated with conventional 192 bit security, although direct comparisons between classical and post-quantum systems should be treated carefully.

ML-DSA-65 offers a familiar account concept: a user controls a private key and signs transactions, while the network verifies the signature using a public key. Its difference is the cryptographic construction and the size of the resulting data. A standard ML-DSA-65 signature is roughly 3.3 kilobytes, with a public key of roughly 2 kilobytes. Those figures are materially larger than many signatures used in current blockchain transactions.

The second part is a hash based signature approach for quantum safe vaults. Hash based systems rely on the security of hash functions rather than the mathematical problems threatened by Shor’s algorithm. They are regarded as conservative post-quantum options, but can involve substantial signatures, state management requirements or limits on how many signatures a key can produce, depending on the specific construction.

Sui’s planned division of responsibilities is significant. A vault can protect a concentrated pool of assets, treasury holdings or other high value positions without forcing every user and application to adopt the largest signature format immediately. Native quantum safe accounts would provide a broader option for users who want direct protection at the account level.

The rollout could allow Sui to learn from the lower volume, higher value use case first. Vault operators may be more willing than retail users to accept additional operational complexity if the assets justify the cost. Their feedback could shape account tooling before the broader launch.

The address question

The most important usability issue may be whether users can upgrade security without moving their assets.

Sui’s address alias design is intended to help with that problem. The concept allows an account to adopt a different signing scheme while retaining an address identity that applications and counterparties can recognize. If it works as intended, users would not need to send coins or tokens from an old address to a new one merely because they changed the cryptography controlling the account.

That distinction matters. A conventional migration can create a long list of problems. Users must pay transaction fees, exchanges may need to approve a new deposit address, decentralized applications may need to update permissions and automated systems may continue sending funds to the old location. A transfer also creates a permanent on-chain record and may complicate accounting, tax reporting or compliance monitoring.

An alias can reduce those frictions, but it does not automatically solve every compatibility problem. Wallets still need to display the account correctly. Applications need to understand which key is authorized. Custodians must update signing policies, approval workflows and recovery procedures. Exchanges need to decide whether an aliased account is equivalent to an existing address for deposits and withdrawals.

The design will also need clear rules for key rotation and conflict resolution. If a user adds a quantum safe authorization method, can the older key still sign transactions? Can both keys be used, or does one replace the other? How can a user recover an account if the quantum safe key is lost? What happens if a wallet supports the address but not the new signature algorithm?

These questions are central to the test. An address alias that works at the protocol level but produces confusion in custody software would offer only partial protection.

The cost of larger signatures

The direct cost of ML-DSA-65 is measurable. A signature several kilobytes in size consumes more transaction bandwidth than a conventional signature. Depending on Sui’s fee schedule and transaction accounting, the additional data could increase gas costs or place pressure on users during periods of network demand.

The effect may be limited for occasional high value transactions. A treasury that signs a few transfers each month can probably absorb a modest increase in fees. The calculation changes for applications that submit large numbers of transactions, maintain many accounts or use signatures as part of frequent automated activity.

Large signatures also affect storage. Validators and full nodes must process and retain more data, while wallets and indexers need to parse and present it. Developers may have to adjust transaction limits, serialization libraries and application programming interfaces. Infrastructure providers could face higher bandwidth and storage expenses even if the average user does not see the full cost directly.

Hash based vault signatures may create a different set of costs. If the scheme uses stateful keys, operators must track signature usage carefully. Reusing a stateful signing position can undermine security, so a vault system must make it difficult to sign incorrectly. Operational safeguards may include hardware backed key storage, counters, monitoring and recovery procedures.

This is where institutional adoption will be informative. Banks, asset managers and custodians routinely pay for stronger controls, but they also demand predictable costs and auditable processes. A quantum safe vault that requires unusual manual procedures may be unsuitable for a regulated custodian, even if its cryptographic security is strong.

Sui will need to publish more than a list of supported algorithms. Users and institutions will want fee estimates, transaction size comparisons, performance benchmarks and guidance on how signature costs change with different account configurations.

Wallets and custodians are the adoption gatekeepers

Protocol support does not equal user access. Most people do not interact directly with a blockchain’s signing algorithm. They use a wallet, exchange or custody platform that selects the account type and hides much of the cryptographic detail.

The first adoption signal will be wallet support. A quantum safe account should be easy to create, identify and recover. The wallet should explain whether an account is protected by conventional signatures, ML-DSA-65 or a combination of methods. It should warn users before signing transactions that an application does not yet support the account format.

Recovery is especially important. Many users understand the basic idea of a seed phrase, even if they do not always protect it properly. Post-quantum accounts may require larger key material, new backup formats or hardware that is not yet widely available. If recovery becomes more difficult, some users may choose not to upgrade.

Hardware wallet support could determine the pace of adoption among serious users. Secure hardware must generate, store and use larger keys without creating unacceptable delays or memory constraints. Custodians will also need multi-party authorization systems that can handle the new signature types. Their systems often depend on tightly controlled signing policies, transaction simulation and address allowlists. Each of those controls must recognize the new account format.

The rollout will also test whether developers treat quantum safety as a user choice or as a system wide migration. Optional accounts reduce disruption, but they can produce a fragmented ecosystem. Some applications may accept only conventional accounts. Others may support both but display them differently. Users could face uncertainty over which account to use for a particular asset or service.

Clear standards will be essential. Wallets and applications need common methods to identify quantum safe accounts, verify authorization and communicate limitations. Without those standards, users may receive inconsistent warnings or mistakenly assume that an account is protected when only part of its activity is.

Applications will expose the real compatibility test

Decentralized applications often assume that an account has a familiar address format and a conventional signature. They may use account addresses as permission lists, embed them in smart contract logic or rely on signature verification libraries. A new account model can expose those assumptions quickly.

Sui developers will need to show that quantum safe accounts work with transfers, decentralized exchanges, lending markets, staking systems and governance tools. The question is not simply whether a transaction can be verified. The broader issue is whether applications can treat the account as a normal participant without custom integration for every action.

Smart contract developers may also need to update verification logic. If an application accepts signed messages, delegated transactions or session keys, it must understand the rules governing the new account type. A partial implementation could create confusing failures, especially when a wallet shows that a transaction is valid but an application rejects it.

The testnet milestone at the end of 2026 should provide an opportunity to measure these issues before mainnet deployment. A serious test program would include wallet providers, exchanges, custodians, infrastructure firms and application developers. It should examine not only successful transactions but also failed signing attempts, recovery, account rotation and interactions with older accounts.

The mainnet target in the first quarter of 2027 will carry more weight if developers can publish results from that testing. Users and institutional operators need evidence that the system works under realistic conditions, not merely a demonstration of cryptographic verification.

A policy issue as much as a technical one

Quantum safe migration also intersects with financial regulation. Institutions are increasingly expected to maintain operational resilience, manage technology risk and protect customer assets over long time horizons. Regulators may not require a particular post-quantum algorithm today, but they are likely to ask how firms identify and manage emerging cryptographic risks.

For custodians, the issue is one of asset continuity. A firm that waits until quantum attacks are practical may discover that it cannot migrate thousands of customer accounts quickly. A firm that migrates too early could impose unnecessary costs or adopt technology that later changes.

This resembles other infrastructure decisions in traditional finance. Payment networks, banks and securities depositories often upgrade security standards years before a threat becomes urgent because coordination takes time. Every participant must test its systems, update procedures and maintain service continuity. Public blockchains face the same coordination problem, but with a more diverse group of independent developers and users.

Sui’s optional model may be attractive from a policy perspective because it supports gradual adoption. It lets risk sensitive institutions begin with high value vaults while allowing ordinary users to remain on established account types. That flexibility can reduce disruption, but it also makes communication important. Users need to know what protection they have and what risks remain.

The approach may also become a competitive feature. If one network can offer a credible migration path without forcing asset transfers, custodians and institutions may view it as easier to integrate than a network requiring a sudden, chain wide address change. The advantage will depend on execution rather than on the algorithm’s label.

What to watch through 2027

The first milestone is the delivery of quantum safe vaults on Sui mainnet later in 2026. Observers should look for details on the hash based construction, key state management, supported custody models and the transaction costs associated with signing.

The second is the native quantum safe account release on testnet by year end. The quality of documentation, software development kits and wallet integrations will indicate whether the feature is being treated as infrastructure or as an isolated protocol upgrade.

The third is mainnet deployment in the first quarter of 2027. At that stage, adoption will matter more than availability. The relevant questions will include how many wallets support ML-DSA-65, whether major custodians offer the option, whether exchanges recognize aliased accounts and whether applications can accept quantum safe users without special workarounds.

Signature size will remain a key metric. Sui should make clear how much larger transactions become, how fees respond and whether network limits create practical barriers. Recovery incidents and failed integrations will also be revealing. A system can be cryptographically sound and still unusable if users cannot restore access or applications mishandle the account.

The broader measure of success is whether users can upgrade security without treating the process as a migration project. If the address alias design works, if wallets make recovery understandable and if institutions can manage the additional operational burden, Sui will have addressed the most important obstacle to early adoption.

Quantum computing may not threaten blockchain assets tomorrow. But the time required to coordinate a secure response is already running. Sui’s plan matters because it moves the debate from abstract warnings to a set of observable engineering and market tests. The network will not be judged only on whether its signatures resist a future attack. It will be judged on whether people can use them before that attack arrives.