Sui SUI

Claim: Sui published a comprehensive cryptographic inventory and quantum threat model covering ECDSA, EdDSA, BLS12-381, RSA (via zkLogin), TLS, hash functions, and ZK proof systems in the 'Securing Sui in the Quantum Computing Era' blog post.

Coverage basis: Official Sui Foundation blog post enumerating all quantum-vulnerable primitives, attack assumptions, affected assets, and NIST transition timeline.

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: The inventory is in a blog post format, not a formal audited security assessment. However, it is detailed and technically specific, referencing NIST standards, attack algorithms (Shor, Grover, BHT), and concrete transition strategies. Evidence confidence is Medium because it is a blog rather than a formal assessment; the content quality is high.

Comprehensive enumeration includes: ECDSA secp256k1, EdDSA Ed25519 for user tx; BLS12-381 for validator consensus/randomness; RSA for JWT in zkLogin; Groth16/BN254 for zkLogin proofs; hash functions (256-bit digests); TLS for P2P. Acknowledges harvest-now-decrypt-later risk for encryption.

• https://blog.sui.io/post-quantum-computing-cryptography-security/
• https://docs.sui.io/develop/cryptography/
• https://docs.sui.io/concepts/cryptography/transaction-auth/signatures
• https://docs.sui.io/concepts/cryptography/system/validator-signatures
• https://docs.sui.io/concepts/cryptography/zklogin

Claim: Sui's cryptographic inventory and threat model are supported by public code, official documentation, protocol message definitions, and reproducible on-chain data.

Coverage basis: Open-source GitHub repository (MystenLabs/sui), official docs, gRPC protocol message definitions confirming BLS12381 validator signatures, and Sui Explorer for on-chain verification.

Implementation score: 0.75 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Code is fully open-source (Rust/Move). Protocol message definitions confirm 48-byte BLS12381 aggregated validator signatures and 96-byte BLS public keys. Move framework exposes BLS12381 and Groth16 verification APIs. Evidence is primary-source and independently verifiable.

The gRPC ValidatorAggregatedSignature message confirms '48-byte Bls12381 aggregated signature' in production. ValidatorCommitteeMember confirms '96-byte Bls12381 public key'. These provide reproducible evidence of quantum-vulnerable consensus authentication.

• https://github.com/MystenLabs/sui
• https://docs.sui.io/doc/protocol-messages-full.html
• https://docs.rs/sui-sdk-types/latest/sui_sdk_types/struct.ValidatorSignature.html
• https://docs.sui.io/references/framework/sui_sui/bls12381
• https://github.com/MystenLabs/sui/blob/main/docs/content/develop/cryptography/groth16.mdx
• https://suiexplorer.com/

Claim: Sui supports Ed25519, Secp256k1, and Secp256r1 for user transaction signatures on mainnet.

Coverage basis: Official documentation confirms these are the only supported transaction signature schemes in production; no PQ or hybrid alternatives exist.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All production spend authorization uses ECC-only signatures (Ed25519, Secp256k1, Secp256r1) with no PQ or hybrid path on mainnet.

All three supported schemes are broken by Shor's algorithm. EdDSA's seed-based derivation (RFC 8032) provides a structural advantage for future migration (seed can serve as PQ-NIZK witness) but does not constitute current protection. No hybrid-PQ or dual-mode signing exists in production.

• https://docs.sui.io/develop/cryptography/
• https://docs.sui.io/concepts/cryptography/transaction-auth/signatures
• https://docs.sui.io/develop/transactions/transaction-auth/auth-overview

Claim: Sui addresses are derived as Blake2b_256 hashes of public key data; public keys are exposed on-chain when users sign transactions, creating long-exposure quantum-vulnerable surfaces.

Coverage basis: Address derivation uses a 256-bit hash (adequate preimage resistance) but public keys become permanently exposed after first transaction, enabling offline quantum key-recovery attacks.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Public keys are permanently exposed on-chain after first transaction; all transacted accounts have long-exposure quantum-vulnerable public keys with no PQ migration path deployed.

Per eprint 2025/1368, EdDSA's seed-based derivation means the seed remains hidden behind SHA-512 (256-bit quantum preimage resistance) even when the public key and signature scalar are exposed. This is a structural migration advantage but does not prevent current quantum key-recovery from exposed public keys. No PQ address formats or key-derivation controls exist in production.

• https://docs.sui.io/develop/transactions/transaction-auth/auth-overview
• https://docs.sui.io/develop/sui-architecture/sui-security.mdx
• https://eprint.iacr.org/2025/1368

Claim: Sui validators use BLS12381 (minSig mode) for consensus signatures, checkpoint certification, and aggregated quorum signatures. The randomness beacon also relies on BLS threshold signatures.

Coverage basis: Protocol message definitions confirm 48-byte BLS12381 aggregated signatures for checkpoint certification; validator committee members use 96-byte BLS12381 public keys.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Validator consensus authentication depends entirely on BLS12381 pairing-based signatures; quantum attack would compromise consensus finality, checkpoint integrity, and validator authentication.

Assurance: BLS12381 implementation was audited by Common Prefix (April 2023). The audit is stale (3+ years) but the implementation remains verifiable from open-source code and protocol message definitions.

BLS signature aggregation is central to Sui's high-throughput Mysticeti consensus. Replacing BLS12381 with a PQ alternative would require fundamental architectural changes: no PQ scheme supports comparable signature aggregation with the same efficiency profile. The Sui blog acknowledges this challenge and mentions research directions (HashRand, lattice-based PVSS, HERB) but no implementation exists.

• https://docs.sui.io/concepts/cryptography/system/validator-signatures
• https://docs.sui.io/doc/protocol-messages-full.html
• https://docs.rs/sui-sdk-types/latest/sui_sdk_types/struct.ValidatorSignature.html
• https://docs.sui.io/develop/transactions/transaction-auth/auth-overview
• https://docs.sui.io/develop/sui-architecture/consensus

Claim: Sui's state integrity relies on BLS12381-aggregated checkpoint signatures for certification, Groth16/BN254 proofs for zkLogin state transitions, and 256-bit hash commitments for object state.

Coverage basis: Checkpoints are certified by BLS12381 aggregated validator signatures; zkLogin uses Groth16 over BN254 for proof verification; object hashes use Blake2b_256.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Checkpoint certification depends on BLS12381 signatures; zkLogin state transitions depend on Groth16/BN254. Both are quantum-vulnerable.

Assurance: Hash-based object commitments (Blake2b_256) provide ~128-bit quantum preimage resistance, which is adequate for second-preimage security. However, the 256-bit collision resistance (~85-bit quantum) may need upgrading for fork prevention — acknowledged in the Sui blog.

The object model's hash-based integrity is the most quantum-resilient part of Sui's architecture. However, checkpoint certification (BLS12381) and zkLogin proof verification (Groth16/BN254) create quantum-vulnerable state-binding paths. The Move Groth16 API supports both BN254 and BLS12-381 curves — both are pairing-based and quantum-vulnerable.

• https://docs.sui.io/doc/protocol-messages-full.html
• https://docs.sui.io/concepts/cryptography/zklogin
• https://github.com/MystenLabs/sui/blob/main/docs/content/develop/cryptography/groth16.mdx
• https://docs.sui.io/references/framework/sui_sui/bls12381

Claim: Sui's zkLogin uses Groth16 zero-knowledge proofs over the BN254 elliptic curve. The Move VM natively supports Groth16 verification over BN254 and BLS12-381. No PQ proof systems exist in production.

Coverage basis: Official zkLogin documentation confirms Groth16/BN254 for proof generation and verification; the Sui blog acknowledges both Groth16 and RSA (JWT) are quantum-vulnerable.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: zkLogin relies on Groth16/BN254 proofs and RSA-signed JWTs — both quantum-vulnerable. A quantum adversary could forge zkLogin credentials.

Assurance: zkLogin circuits and ceremony were audited by zkSecurity (September 2023). This audit covers the classical security of the Groth16 implementation, not PQ security. The Sui blog discusses PQ migration for zkLogin (PQ-JWT, PQ-zkSNARK) but no implementation exists.

The Sui blog acknowledges the dual quantum vulnerability: 'Both Groth16 proofs and RSA signatures are subject to quantum attacks. The security properties of zkLogin break when either of them is compromised.' zkLogin addresses use hash-based derivation (Blake2b_256 with Poseidon_BN254 and user salt), which provides some quantum resilience for address binding but does not protect against proof forgery.

• https://docs.sui.io/concepts/cryptography/zklogin
• https://docs.sui.io/sui-stack/zklogin-integration/zklogin
• https://github.com/MystenLabs/sui/blob/main/docs/content/develop/cryptography/groth16.mdx
• https://blog.sui.io/post-quantum-computing-cryptography-security/

Claim: Sui validators use Ed25519 keys for network/TLS identity. Validator network_public_key and worker_public_key use classical cryptography.

Coverage basis: Validator metadata includes Ed25519-based network public key for TLS handshake and worker public key for Narwhal consensus networking.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: P2P node identity is not directly spend, consensus, bridge, or custody-critical for asset security. However, since all other layers remain quantum-vulnerable, P2P cannot be treated as satisfied-by-design. A quantum attacker compromising P2P could disrupt validator communication.

Per QRI spec 7.1, P2P can be satisfied-by-design when 'all asset-spending authorization is PQ-signed on device and network identity is not consensus, spend, bridge, or custody-critical.' This condition is not met because spend authorization is NOT PQ-signed. Therefore P2P is scored as applicable and vulnerable.

• https://docs.sui.io/develop/transactions/transaction-auth/auth-overview
• https://docs.sui.io/doc/protocol-messages-full.html
• https://docs.sui.io/operators/validator/node-tools

Claim: Sui wallets and custody solutions use classical Ed25519/Secp256k1 key pairs. No evidence of PQ-compatible wallet, HSM, or custody workflow support in production.

Coverage basis: Wallet SDKs (@mysten/dapp-kit, ts-sdks) use Ed25519/Secp256k1 key pairs; no PQ key generation or signing support exists.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

No hardware wallet, HSM, or custody solution supports PQ signing for Sui. The SPECTER protocol (third-party) provides ML-KEM-768 stealth addresses but requires separate wallet integration and does not protect standard Sui accounts.

• https://github.com/MystenLabs/ts-sdks/blob/main/packages/docs/content/sui/cryptography/keypairs.mdx
• https://docs.sui.io/develop/cryptography/signing

Claim: No Sui mainnet value is protected by PQ or hybrid cryptography. 100% of circulating supply, staked SUI, DeFi TVL (~$570M), stablecoin market cap (~$582M), and bridged assets remain quantum-vulnerable.

Coverage basis: All on-chain assets are controlled by ECC/BLS-based keys with no PQ migration path deployed. Coverage is <25% (effectively 0%).

Implementation score: 0.05 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Zero percent of value-at-risk is protected by PQ cryptography; all value is quantum-vulnerable.

Assurance: TVL and stablecoin market cap figures are approximate and from DefiLlama/CoinMarketCap as of early June 2026. Sui has processed over $1 trillion in cumulative stablecoin volume since August 2025, indicating significant economic activity at risk.

Per 9.3.1 coverage threshold table: <25% coverage = Score 1 (out of 20 subfactor weight). Implementation Score = 1/20 = 0.05. No PQ migration has occurred; no PQ-native accounts exist.

• https://suiexplorer.com/
• https://defillama.com/chain/Sui
• https://www.mexc.co/news/1109580

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) have migrated to PQ protection on Sui mainnet.

Coverage basis: All critical wallets use classical Ed25519/Secp256k1 keys; no migration has occurred.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Sui Bridge treasury, Sui Foundation wallets, exchange deposit addresses, and major DeFi protocol treasuries all remain under classical key control. Grayscale GSUI ETF and institutional products hold SUI through classical custody paths.

• https://docs.sui.io/develop/cryptography/
• https://docs.sui.io/concepts/cryptography/transaction-auth/signatures

Claim: Sui has identified quantum-vulnerable primitives (Ed25519, Secp256k1, BLS12381, BN254, RSA) in the risk assessment blog post but has not systematically identified, measured, deprecated, or migrated specific vulnerable accounts, UTXOs, or contracts.

Coverage basis: The blog post enumerates vulnerable cryptographic primitives but does not provide account-level or value-pool-level vulnerability measurement.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: The blog identifies vulnerable primitives but does not quantify exposed value. No on-chain analytics, address tagging, or measurement of quantum-vulnerable value pools has been published.

Sui's object-based model (rather than UTXO) means all accounts that have ever signed a transaction have exposed public keys. The EdDSA seed-based advantage means dormant accounts with unexposed seeds retain some migration potential, but this has not been systematically measured.

• https://blog.sui.io/post-quantum-computing-cryptography-security/

Claim: Sui's 'Securing Sui in the Quantum Computing Era' blog post discusses transition strategies (PQ-signs-PreQ, PreQ-PQ multisig, seed-based ZK migration, standard ownership transition) and references the NIST timeline (deprecation by 2030, phase-out by 2035).

Coverage basis: The blog post provides design-level transition strategy discussion but lacks concrete sequencing, activation criteria, protocol version milestones, or governance proposal references.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: The roadmap is a blog post, not a formal SIP (Sui Improvement Proposal) with governance approval. No protocol version targets, activation heights, or epoch-based milestones are specified.

The eprint 2025/1368 paper (accepted at FC 2026) provides an academic foundation for EdDSA seed-based PQ migration via PQ-NIZKs. This represents a credible research contribution but is not a production roadmap. Testnet PQ signature work (May 2026) is reported by secondary sources only.

• https://blog.sui.io/post-quantum-computing-cryptography-security/
• https://eprint.iacr.org/2025/1368

Claim: No PQ account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist on Sui mainnet.

Coverage basis: No evidence of any PQ-accessible features in production wallets, SDKs, CLI, or documentation.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Users cannot create PQ-protected accounts or migrate existing accounts to PQ protection on mainnet.

Classical account creation remains the only path. Move VM agility theoretically allows adding new signature schemes, but no PQ scheme has been integrated into wallet SDKs or transaction construction tooling.

• https://docs.sui.io/develop/cryptography/
• https://github.com/MystenLabs/ts-sdks

Claim: No enforcement mechanisms (deprecation, freeze, disabled legacy signing, restricted withdrawals, mandatory migration deadlines) exist. No exchange, custody, bridge, wallet, or infrastructure coordination for PQ migration has occurred.

Coverage basis: No evidence of any migration enforcement or ecosystem coordination.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

No SIP, governance vote, or protocol parameter exists to freeze, deprecate, or restrict classical signing. Sui's validator-governed architecture could theoretically enact such measures via protocol upgrades, but none have been proposed.

Claim: Sui has general security processes (bug bounty, security@ email, audit program) but no published quantum-specific incident-response playbook, emergency governance process, or disclosure procedure.

Coverage basis: Sui's security page lists audits and a reporting process but nothing quantum-specific.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: The absence of a quantum-specific incident-response process is an assurance gap but does not itself create a quantum-attack path. The general security infrastructure (bug bounty, audit program, validator governance) provides a foundation.

General security page shows mature audit program with multiple firms (OtterSec, Zellic, Halborn, Common Prefix, zkSecurity, FYEO, Blaize Security, Critical Section) but no quantum-specific planning. Validator governance via DPoS could theoretically enable emergency protocol changes.

• https://www.sui.io/security
• https://github.com/sui-foundation/security-audits

Claim: No NIST-standardized or standards-track PQC algorithms (ML-DSA/Dilithium, SLH-DSA/SPHINCS+, FN-DSA/FALCON, ML-KEM) are deployed in Sui mainnet production.

Coverage basis: All production cryptography is classical ECC/BLS; no PQ algorithm deployment exists.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: The blog post discusses Dilithium, FALCON, and SPHINCS+ as NIST candidates and evaluates their suitability for Sui's throughput requirements. This is analysis only, not deployment.

Testnet PQ work (reported May 2026) may use NIST-standardized algorithms but this is unconfirmed from primary sources. The blog identifies lattice-based schemes (Dilithium, FALCON) as more practical than SPHINCS+ for Sui's high-throughput requirements.

• https://docs.sui.io/develop/cryptography/
• https://blog.sui.io/post-quantum-computing-cryptography-security/

Claim: No independent audit of any PQ cryptographic implementation exists for Sui, because no PQ implementation exists in production.

Coverage basis: All existing audits cover classical implementations; no PQ scope exists to audit.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Extensive audit history exists for classical implementations: BLS12381 (Common Prefix, Apr 2023), Groth16 verifier (Halborn, Dec 2022), zkLogin circuits (zkSecurity, Sep 2023), Secp256k1 (Common Prefix, Apr 2023), Secp256r1 (Common Prefix, Jun 2023), Sui Core (Halborn, Apr 2023), Sui Bridge (OtterSec Apr 2024, Zellic Apr 2024). All cover quantum-vulnerable classical cryptography only.

No PQ audit is applicable since no PQ implementation exists. Once PQ code is deployed, independent audit will be essential given the novelty of lattice-based signature verification in consensus-critical contexts.

• https://www.sui.io/security
• https://github.com/sui-foundation/security-audits

Claim: Sui's classical cryptographic implementations are fully open-source (Rust/Move) and reproducible. No PQ implementation exists to reproduce.

Coverage basis: GitHub repository (MystenLabs/sui) contains all production cryptography; no PQ code exists.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: The existing codebase is high-quality, well-structured, and fully open-source. The fastcrypto library provides the cryptographic backend. Once PQ code is implemented, reproducibility will be assessable.

Low score reflects the absence of PQ implementation, not the quality of existing classical code. The open-source nature of Sui is a strength for future auditability.

• https://github.com/MystenLabs/sui
• https://crates.io/crates/sui-crypto/dependencies

Claim: Sui's Move VM and cryptographic architecture support multiple signature schemes through unified key/signature types, enabling algorithmic agility. The blog post documents detailed PQ upgrade paths.

Coverage basis: Move VM natively supports multiple signature schemes (Ed25519, Secp256k1, Secp256r1, BLS) through abstracted types. The blog discusses transition strategies including PQ-signs-PreQ, hybrid multisig, and seed-based ZK migration.

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: Cryptographic agility has been demonstrated for classical algorithm switching (e.g., the validator switch to BLS12381 minSig mode). The agility architecture is a genuine strength, but PQ agility remains untested in production. The blog documents upgrade paths at design level only.

Score of 0.50 reflects prototype/testnet-level evidence: the agility architecture exists in production for classical schemes, PQ upgrade paths are documented in detail, and testnet PQ work is reported. However, no mainnet PQ scheme integration has been demonstrated.

• https://www.mystenlabs.com/blog/cryptography-in-sui-agility
• https://blog.sui.io/post-quantum-computing-cryptography-security/
• https://docs.sui.io/develop/cryptography/

Claim: No PQ signature implementation exists in Sui production, so stateful-signature safety (XMSS/LMS anti-reuse), side-channel, fault-injection, and custody implementation risks are not yet applicable.

Coverage basis: No PQ implementation exists to evaluate these concerns against.

Implementation score: 0 · Evidence confidence: None

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Not applicable until PQ implementation exists. The blog discusses stateless schemes (Dilithium, FALCON, SPHINCS+) rather than stateful hash-based schemes (XMSS/LMS), which avoids state-management risks.

Sui's preference for lattice-based stateless schemes (per the blog) avoids XMSS/LMS state-management complexity. However, lattice schemes have their own side-channel considerations (floating-point timing for FALCON, power analysis for Dilithium) that will need evaluation.

Claim: The Sui PQ blog post provides analysis of PQ signature performance characteristics, including batch verification limitations, signature sizes, and verification costs, contextualized for Sui's high-throughput requirements.

Coverage basis: Blog post discusses: Dilithium batch verification speedup (20-50%), FALCON batch verification challenges, SPHINCS+ signature sizes, and the tension between PQ security and Sui's throughput requirements.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: The analysis is qualitative and design-level, not a formal benchmark. No gas cost modeling, block validation impact analysis, mempool policy assessment, archival growth projections, or validator hardware requirement analysis has been published.

The blog acknowledges that 'currently we have a lack of batching optimizations to the same extent for the PQ signatures under consideration' — a significant concern for Sui's architecture which depends heavily on BLS signature aggregation for throughput. No concrete performance data from the testnet PQ implementation has been published.

• https://blog.sui.io/post-quantum-computing-cryptography-security/