Is Sui Quantum Safe? Ed25519 and BLS12-381 Exposure in the Move Ecosystem

Sui is a high-performance Layer 1 blockchain developed by Mysten Labs and launched in 2023. It emerged from the Diem/Libra project at Meta, sharing its Move smart contract language and several cryptographic design choices with Aptos. Sui has attracted significant developer interest for its object-centric data model and parallel transaction execution, which enables throughput that traditional account-based chains cannot match. But high performance does not imply quantum security, and Sui's cryptographic foundation carries the same vulnerabilities as most modern blockchains.

Is Sui Quantum Safe?

No. Sui uses Ed25519, secp256k1, and BLS12-381 across its signing infrastructure. All three schemes are based on elliptic curve mathematics vulnerable to Shor's algorithm. Mysten Labs has not published a post-quantum cryptography roadmap. Every Sui address with an exposed public key is at risk once a cryptographically relevant quantum computer exists.

The multi-signature flexibility that makes Sui developer-friendly also means that quantum risk exists at multiple layers of the stack. User accounts use one set of schemes, validators use another, and the zkLogin identity system introduces yet another layer of cryptographic dependency. Understanding each layer separately is necessary for a complete picture of Sui's quantum exposure.

Sui's Signature Schemes

Sui supports three signature schemes for user transactions: Ed25519, secp256k1, and secp256r1 (NIST P-256). For validator consensus, Sui uses BLS12-381 for signature aggregation. The design rationale is pragmatic: Ed25519 and secp256k1 cover the dominant wallet ecosystems, secp256r1 enables compatibility with hardware security keys and mobile secure enclaves (the P-256 curve is used in Apple's Secure Enclave and Android's StrongBox), and BLS12-381 enables efficient validator signature aggregation.

From a quantum security perspective, all of these schemes fail at the same fundamental level. Ed25519, secp256k1, and secp256r1 are all elliptic curve discrete logarithm problems. BLS12-381 is a pairing-friendly elliptic curve, and while its structure differs from the others, it is equally vulnerable to Shor's algorithm. A quantum computer that can break Ed25519 can break BLS12-381 through analogous (though somewhat more complex) quantum algorithms. The pairing-based structure does not provide quantum resistance. For context on why all elliptic curve schemes fall to quantum attacks, see our post-quantum cryptography overview.

Sui's Object Model and Address Derivation

Sui's core design innovation is its object-centric model. Unlike account-based chains where state is organized around accounts that hold balances and storage, Sui organizes state around objects that are owned by addresses. Each object has a unique 32-byte identifier and an owner, which can be an address, another object, or "shared" (accessible to all). Transactions in Sui manipulate specific objects by reference rather than reading and writing account state.

Sui addresses are 32 bytes, derived by computing a hash of the public key prefixed by a scheme flag byte. The hashing step means that a Sui address does not directly reveal the underlying public key, similar to Bitcoin P2PKH or Ethereum addresses. However, the protection only holds as long as the address has never signed a transaction. Once a Sui address sends a transaction, the full public key is embedded in the transaction's signature and becomes permanently visible on-chain.

The practical implication is that Sui addresses which have only received SUI or objects, and have never sent a transaction, retain some quantum protection from the hash step. Any address that has sent at least one transaction has its public key fully exposed. On an active blockchain, the vast majority of addresses with meaningful balances have sent transactions, which means they have exposed public keys. The "quantum-safe subset" of Sui holdings is likely small.

The object model does not change this calculus in any meaningful way. Objects are owned by addresses, and the security of those ownership relationships depends on the security of the underlying key pair. If the key pair can be broken by a quantum computer, the attacker can sign transactions transferring any owned objects to their own address.

Does the Move Language Affect Quantum Risk?

Move is a resource-oriented programming language developed originally for Diem, designed to make it difficult to accidentally duplicate or lose digital assets. Sui uses a version of Move adapted for its object-centric model. The question of whether Move affects quantum risk has a clear answer: no, it does not.

Move operates at the smart contract layer. It governs how contracts manipulate objects and enforces ownership rules at the language level. But the cryptographic signing of transactions, the derivation of addresses from public keys, and the validation of signatures by the consensus layer are all below the Move abstraction. Move contracts can be perfectly written and still fall victim to a quantum attack that steals the private key of the account that owns the relevant objects. The language's safety properties are classical safety properties, not quantum safety properties.

This is worth stating clearly because Move's strong safety guarantees sometimes create an impression of broad security. Move prevents a class of bugs (reentrancy, integer overflow-style asset duplication) that have caused significant losses in Solidity-based ecosystems. But those are application-layer vulnerabilities. Quantum attacks operate at the cryptographic layer, entirely beneath Move's reach.

BLS12-381 Validator Signatures and Consensus Risk

Sui's validator set uses BLS12-381 signatures, which enable efficient aggregation. When validators attest to a block, their individual signatures can be combined into a single aggregated signature that is compact and fast to verify. This is an important performance optimization for any high-throughput proof-of-stake chain. BLS aggregation is also used by Ethereum's beacon chain and several other major blockchains.

The quantum vulnerability of BLS12-381 is real but slightly different in its threat model from user key vulnerability. A quantum attacker targeting Sui's validator consensus would need to break a validator's BLS key in the time window between when that validator broadcasts its attestation and when the protocol finalizes. The finality time for Sui is sub-second in most conditions, which is a very short window. However, a precomputed attack (where the quantum computer precomputes the discrete log for a known validator public key before the attack window) could operate faster than the finality window.

Breaking a validator key does not directly steal funds, but it enables double-signing attacks that can fork the chain and potentially reverse finalized transactions. At sufficient scale (breaking a threshold fraction of the validator set), it could allow an attacker to take full control of consensus. This is a systemic risk distinct from individual user account theft, and it would require a more capable quantum attacker.

Mysten Labs' Position on Quantum Security

Mysten Labs has not published a post-quantum cryptography roadmap as of mid-2026. The Sui documentation does not address quantum security planning. This is consistent with the broader blockchain industry posture: post-quantum migration is acknowledged as a future requirement, but concrete planning has been deferred pending clearer signals from quantum hardware development.

The academic cryptography community's view is that post-quantum planning should begin well before Q-Day, precisely because migration lead times are long and the harvest now, decrypt later attack is already active. Blockchain projects that wait for Q-Day before starting migration work will not be able to complete that migration before significant user funds are at risk.

Signature Scheme Comparison

What a Post-Quantum Migration Would Require for Sui

A complete post-quantum migration for Sui would need to address three separate layers. First, user key pair migration: all existing Sui addresses that have sent transactions must be migrated to post-quantum key pairs. This requires a coordinated campaign where every wallet holder generates a new PQC key pair, signs a migration transaction with their old key (proving ownership), and registers the new key as the address's authorized signer. Any address whose owner cannot be reached (lost keys, deceased holders, abandoned wallets) cannot migrate and becomes permanently vulnerable.

Second, validator key migration: all Sui validators must replace their BLS12-381 keys with post-quantum equivalents. The BLS aggregation optimization would need to be replaced with a post-quantum aggregation scheme. Lattice-based aggregation research exists but is less mature than BLS. The validator migration requires a hard fork with tight coordination across the entire validator set.

Third, zkLogin and other cryptographic dependencies: Sui's zkLogin feature uses zero-knowledge proofs that have their own quantum security considerations. zk-SNARKs based on elliptic curve pairings (the dominant approach) are quantum-vulnerable. A complete post-quantum Sui would need quantum-resistant zero-knowledge proof systems for zkLogin, adding significant complexity beyond the signature scheme changes.

The full scope of this migration is why chains like QuanChain that were designed with post-quantum cryptography from genesis have a structural advantage. The migration problem does not exist if there is nothing to migrate from.