IOTA IOTA

Claim: IOTA documents its cryptographic mechanisms (Ed25519, ECDSA secp256k1/secp256r1, BLS12381, multisig) in official developer documentation. Quantum threat is acknowledged in IOTA Identity PQ documentation but no formal quantum threat model covering attack assumptions, affected assets, and affected layers exists for the core protocol.

Coverage basis: Partial cryptographic inventory exists; quantum threat model is implied through Identity-layer documentation only

Implementation score: 0.5 · Evidence confidence: Medium

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

Assurance: Cryptographic inventory is detailed for signature schemes but lacks a comprehensive CBOM-style enumeration of all cryptographic dependencies. Quantum threat model is not formalized for core protocol.

The cryptography documentation page states 'Cryptographic agility is core to IOTA' and claims support for multiple algorithms, but no specific PQ algorithms are documented for core protocol use. The Identity 1.7 PQ docs acknowledge quantum threat to ECC generally but scope mitigation to VCs only.

• https://docs.iota.org/developer/cryptography
• https://docs.iota.org/developer/cryptography/transaction-auth/signatures
• https://docs.iota.org/developer/iota-identity/how-tos/post-quantum

Claim: Evidence consists of official documentation, open-source code repositories, and blog posts. No independent audits of core protocol cryptography, no mainnet transaction analysis for quantum exposure, and no reproducible quantum-risk analytics identified.

Coverage basis: Documentation and code references exist; audits and analytics are absent

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Open-source code is available but no independent cryptographic audit covers the current production signature implementations. Evidence is limited to self-published documentation and code.

Zokyo audit (March 2024) covered IOTA EVM smart contracts only. Hacken audit (August 2025) covered Echo Protocol bridge only. Neither addresses core protocol Ed25519/ECDSA/BLS12381 implementations.

• https://github.com/iotaledger/iota
• https://github.com/iotaledger/hornet
• https://docs.iota.org/developer/cryptography
• https://blog.iota.org/iota-identity-1-7-beta/

Claim: Mainnet spend authorization uses classical Ed25519 Pure (flag 0x00), ECDSA Secp256k1 (0x01), ECDSA Secp256r1 (0x02), and multisig (0x03) exclusively. No PQ or hybrid-PQC path exists for transaction signing.

Coverage basis: ECC-only; no PQ/hybrid option available

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Active production spend authorization remains entirely ECC-only (Ed25519, ECDSA secp256k1, ECDSA secp256r1)

Assurance: Official documentation is explicit and unambiguous about signature scheme support. No PQ options are listed for transaction authentication.

Signature flag bytes (0x00-0x03) are documented with no reserved or planned PQ flag values. The signature serialization format (flag || sig || pk) has no extension point visible for PQ schemes.

• https://docs.iota.org/developer/cryptography/transaction-auth/signatures
• https://docs.iota.org/developer/cryptography/transaction-auth/keys-addresses

Claim: Addresses are derived from Ed25519/ECDSA public keys via Blake2b-256 hashing. Public keys are exposed in transaction signatures. No PQ/hybrid address formats, key-derivation paths, or exposure mitigations exist.

Coverage basis: All classical ECC address derivation; public keys exposed on-spend

Implementation score: 0 · Evidence confidence: High

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

Assurance: Address derivation and key exposure patterns are clearly documented. Public keys are revealed at transaction broadcast (short-exposure on-spend), but address reuse creates long-exposure risk.

Ed25519 public keys are 32 bytes compressed; ECDSA public keys are 33 bytes compressed. Both are included in the serialized signature (flag || sig || pk), making public keys visible to any network observer at spend time.

• https://docs.iota.org/developer/cryptography/transaction-auth/keys-addresses
• https://docs.iota.org/developer/cryptography/transaction-auth/signatures

Claim: Validator/authority aggregated signatures use BLS12381 (minSig mode, 48-byte signatures, 96-byte public keys). Account keys for staking rewards use Ed25519. Network keys for TLS/QUIC use Ed25519. All classical.

Coverage basis: BLS12381 and Ed25519 exclusively for all consensus-critical authentication

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Validator/authority consensus signatures use BLS12381 exclusively — quantum-vulnerable pairing-based scheme

Assurance: BLS12381 is a pairing-based scheme vulnerable to quantum attacks via Shor's algorithm on the underlying elliptic curves. Proof of possession (KOSK) is used to prevent rogue key attacks but does not address quantum threats.

Starfish BFT consensus (deployed on mainnet) depends on BLS12381 aggregated signatures for validator attestations. A CRQC could forge validator signatures and compromise consensus finality. The protocol requires 2f+1 validator signatures for transaction certification.

• https://docs.iota.org/developer/cryptography/transaction-auth/signatures
• https://docs.iota.org/about-iota/iota-architecture/consensus
• https://blog.iota.org/starfish-mainnet-release/

Claim: Checkpoint verification relies on BLS12381 validator committee signatures. State integrity is bound to the same classical signature schemes. No quantum-safe commitments, accumulators, or verifiable data-availability proofs identified.

Coverage basis: State integrity depends on classical BLS12381 validator signatures

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Checkpoint verification documentation references BLS12381 validator committee signatures. No quantum-safe alternative or hybrid mechanism is documented.

The Starfish protocol uses an uncertified DAG structure with three-round finality. Block header metadata is separated from transaction payloads. State integrity ultimately depends on validator signature verification which is BLS12381-based.

• https://docs.iota.org/developer/cryptography
• https://docs.iota.org/about-iota/iota-architecture/consensus
• https://blog.iota.org/starfish-mainnet-release/

Claim: IOTA core protocol does not implement on-chain privacy layers, shielded transactions, or zero-knowledge proofs. IOTA Identity provides PQ-secured Verifiable Credentials but this is a separate application layer.

Coverage basis: No privacy/proof layer exists in core protocol

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

IOTA Identity v1.7 PQ features (ML-DSA, SLH-DSA, Falcon, hybrid signatures) are noted for completeness but are out of scope for core protocol privacy evaluation.

• https://docs.iota.org/developer/cryptography
• https://docs.iota.org/developer/iota-identity/how-tos/post-quantum

Claim: Network key pair uses Ed25519 for TLS handshake (QUIC) and peer ID. This is classical ECC. P2P is not satisfied by design because asset-spending authorization is not PQ-signed.

Coverage basis: Classical Ed25519 for all P2P/node identity

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: P2P node identity using classical Ed25519 is a lower-severity concern than spend/consensus vulnerabilities, but remains applicable because asset-spending is not PQ-protected (failing the satisfied-by-design condition in QRI spec Section 7).

Per QRI spec: 'P2P node identity uses classical cryptography, but all asset-spending authorization is PQ-signed on device and network identity is not consensus, spend, bridge, or custody-critical' → satisfied by design. Since IOTA asset-spending is NOT PQ-signed, this condition is not met.

• https://docs.iota.org/developer/cryptography/transaction-auth/signatures

Claim: IOTA Wallet (browser extension), Ledger hardware wallet support, and Nightly Wallet all use classical Ed25519/ECDSA key pairs. No PQ/hybrid signing workflows exist for native asset transactions.

Coverage basis: All wallet/custody paths are classical ECC-only

Implementation score: 0 · Evidence confidence: High

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

Assurance: Wallet documentation and SDK references confirm Ed25519/ECDSA keypair generation only. No PQ key types are available in the TypeScript SDK cryptography modules.

Ledger hardware wallet support exists for the Rebased mainnet but uses classical Ed25519. BitGo custody integration (December 2025) and Turnkey support (October 2025) are presumed to use classical key material.

• https://blog.iota.org/builders-welcome-rebase-complete/
• https://docs.iota.org/developer/ts-sdk/typescript/cryptography/keypairs

Claim: Approximately 100% of native IOTA circulating supply is quantum-vulnerable. No PQ-protected accounts, addresses, or transaction paths exist for the native asset. Coverage is effectively 0%.

Coverage basis: <25% coverage — experimental/negligible protection

Implementation score: 0.05 · Evidence confidence: High

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

Quantum blocker: All native IOTA value (~100% of circulating supply) is quantum-vulnerable with no migration path

Assurance: Coverage assessment is based on the absence of any PQ transaction path in core protocol documentation and code. No on-chain PQ signatures have been observed or documented for native asset transfers.

IOTA is not PQ-native. The protocol launched with Winternitz OTS (quantum-resistant) but migrated to Ed25519 during Chrysalis (2021). All current production value uses classical ECC. Attack windows include both short-exposure (on-spend public key revelation) and long-exposure (address reuse, dormant holdings with exposed keys).

• https://docs.iota.org/developer/cryptography/transaction-auth/signatures
• https://docs.iota.org/developer/cryptography/transaction-auth/keys-addresses

Claim: No critical wallets (treasuries, exchanges, custodians, foundations, bridges) have been migrated to PQ protection. All use classical Ed25519/ECDSA key material.

Coverage basis: No critical wallet migration

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: BitGo custody (December 2025) and Turnkey support (October 2025) are presumed to use classical key material. No PQ custody attestations identified.

IOTA Foundation, Tangle Ecosystem Association, and DLT Foundation treasuries were mapped to new addresses during the Rebased genesis ceremony (May 2025) but remain on classical Ed25519/ECDSA address formats.

• https://blog.iota.org/builders-welcome-rebase-complete/
• https://blog.iota.org/bitgo-adds-iota-to-global-custody-offering/

Claim: No identification, measurement, deprecation, or freeze mechanism exists for quantum-vulnerable IOTA holdings. The Wotsicide migration (TIP-0034) moved funds from quantum-resistant W-OTS to quantum-vulnerable Ed25519.

Coverage basis: No legacy pool management for quantum vulnerability

Implementation score: 0 · Evidence confidence: High

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

Assurance: TIP-0034 (Wotsicide) documents the migration from W-OTS to Ed25519 during Chrysalis. This was a migration away from quantum resistance. No equivalent mechanism exists for migrating from Ed25519/ECDSA to PQ.

The Rebased mainnet upgrade (May 2025) included a Stardust Objects Snapshot and migration.blob for moving state to the new network, but this preserved classical address formats rather than migrating to PQ.

• https://github.com/iotaledger/tips/blob/main/tips/TIP-0034/tip-0034.md
• https://docs.iota.org/developer/cryptography/transaction-auth/signatures

Claim: No public PQ migration roadmap, sequencing plan, activation criteria, or dependency analysis exists for the core IOTA protocol. Cryptographic agility is claimed as a design feature but without specific PQ milestones.

Coverage basis: No roadmap exists

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: No public PQ migration roadmap, governance proposal, or testnet for core protocol

Assurance: The 2025-2026 roadmap (ChangeNOW interview, January 2026) mentions PQ only in the context of Identity 1.7. No core protocol PQ migration is referenced.

The cryptography documentation states 'you can choose the right cryptography solution for your system and implement the latest algorithms as they become available' but this is a general agility claim, not a migration plan.

• https://docs.iota.org/developer/cryptography
• https://changenow.io/blog/iota-roadmap-team-interview

Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist for the native IOTA asset.

Coverage basis: No migration accessibility exists

Implementation score: 0 · Evidence confidence: High

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

Assurance: TypeScript SDK cryptography modules support only Ed25519 and ECDSA keypair generation. No PQ key types, hybrid signing, or migration tooling is available.

The IOTA Wallet browser extension and Nightly Wallet both use classical key derivation. No quantum-safety warnings or migration prompts are presented to users.

• https://docs.iota.org/developer/ts-sdk/typescript/cryptography/keypairs
• https://blog.iota.org/builders-welcome-rebase-complete/

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

Coverage basis: No enforcement or coordination mechanisms exist

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: No evidence of any coordination with exchanges, custodians, or infrastructure providers regarding PQ migration. The Rebased upgrade demonstrated coordination capability for protocol upgrades but did not address quantum readiness.

The Rebased genesis ceremony (May 2025) showed that IOTA can coordinate complex network upgrades with validators and infrastructure providers, but this capability has not been applied to quantum migration.

Claim: No quantum-specific emergency disclosure process, incident-response playbook, or governance mechanism identified. General security contacts and disclosure processes may exist but are not quantum-specific.

Coverage basis: No quantum-specific incident response

Implementation score: 0 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Per QRI spec Section 7.4, lack of a formal quantum-specific incident-response playbook is normally a note-only caveat. However, in the absence of any PQ migration path, the lack of even a basic quantum emergency process contributes to the overall quantum-critical uncertainty.

The IOTA Foundation has demonstrated operational security capability through the Rebased upgrade coordination, but no quantum-specific processes are publicly documented.

Claim: No PQC algorithms are used in the core IOTA protocol. IOTA Identity v1.7 uses ML-DSA (NIST FIPS 204), SLH-DSA (NIST FIPS 205), and Falcon (NIST standards-track) — but only for Verifiable Credentials, not native asset protection.

Coverage basis: No PQC algorithms in core protocol scope

Implementation score: 0 · Evidence confidence: High

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

Assurance: IOTA Identity's use of NIST-standards-track algorithms (ML-DSA-44/65/87, SLH-DSA-128/192/256, Falcon-512/1024) demonstrates awareness of appropriate PQC algorithm selection. This capability has not been extended to core protocol.

Hybrid signatures (id-MLDSA44-Ed25519, id-MLDSA65-Ed25519) are implemented in Identity v1.7 via LINKS Foundation collaboration, showing technical feasibility for hybrid approaches that could theoretically be applied to core protocol.

• https://docs.iota.org/developer/cryptography/transaction-auth/signatures
• https://docs.iota.org/developer/iota-identity/how-tos/post-quantum

Claim: No independent cryptographic audit of core protocol signature implementations (Ed25519, ECDSA, BLS12381) identified. Available audits cover different scopes.

Coverage basis: No audit of quantum-critical core cryptography

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Zokyo audit (March 2024): IOTA EVM smart contracts only — scope-mismatched for core protocol cryptography. Hacken audit (August 2025): Echo Protocol bridge (Move-based, IOTA side only) — scope-mismatched. No audit covers Ed25519/ECDSA/BLS12381 production signature implementations.

Per QRI spec, absent audit does not by itself reduce QRI Score when the quantum-security property can be verified from other evidence. Here, the absence of any PQ implementation means there is no quantum-security property to verify — the score is 0 on implementation grounds, not audit grounds.

• https://blog.iota.org/perfect-audit-iota-smart-contracts/
• https://hacken.io/audits/echo-protocol/sca-echo-protocol-bridge-iota-jul2025/

Claim: IOTA core protocol is open source (Apache 2.0 license). However, no PQ implementation exists in core protocol to be open-source or reproducible. Classical implementations are open source but do not contribute to quantum readiness.

Coverage basis: No PQ implementation exists to evaluate for openness

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Assurance: Source code is publicly available and actively maintained (latest mainnet release v1.24.0, June 2026). The iota-crypto crate provides unified cryptography primitives. This infrastructure could support future PQ integration but currently contains only classical algorithms.

The iota-crypto crate (crates.io/crates/iota-crypto) provides the unified type alias/enum wrapper for cryptography primitives. This architectural choice could facilitate future PQ algorithm addition but does not constitute current PQ implementation.

• https://github.com/iotaledger/iota
• https://github.com/iotaledger/hornet

Claim: IOTA documentation claims cryptographic agility as a core design feature: 'The system supports multiple cryptography algorithms and primitives and can switch between them rapidly.' The unified cryptography type system supports this claim architecturally.

Coverage basis: Documented design claim with architectural support

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: The cryptographic agility claim is a design-level assertion. The unified type system (enum wrapper for public key, signature, aggregated signature, hash functions) provides architectural support for algorithm substitution. However, no specific PQ upgrade path, activation mechanism, or migration procedure is documented.

Scored at 0.25 (public design/roadmap level) because the agility claim is documented and architecturally supported, but no PQ-specific upgrade path, testnet, or activation criteria exist. This is a general design property, not a quantum-specific migration plan.

• https://docs.iota.org/developer/cryptography
• https://crates.io/crates/iota-crypto

Claim: IOTA core protocol does not use stateful hash-based signatures (XMSS/LMS). Classical Ed25519/ECDSA implementations have standard side-channel considerations but no PQ-specific risks apply.

Coverage basis: No stateful PQC signatures in core protocol

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

If IOTA were to adopt XMSS/LMS for PQ migration, stateful-signature safety would become applicable. The historical use of Winternitz OTS (a stateful one-time signature scheme) suggests the team has prior experience with stateful signature management.

• https://docs.iota.org/developer/cryptography/transaction-auth/signatures

Claim: No public performance or resource-impact analysis for PQ signature deployment on IOTA core protocol. PQ signature sizes (kilobytes vs. current 64-96 bytes) would significantly impact block sizes, validation times, and storage requirements.

Coverage basis: No PQ performance analysis exists

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Per QRI spec Section 7.4, lack of formal performance benchmark is normally a note-only caveat. Scored at 0 because no PQ implementation exists to benchmark — the absence of analysis reflects the absence of any PQ deployment rather than a gap in an existing deployment.

IOTA Rebased claims 50,000+ TPS with sub-second finality. PQ signature sizes (ML-DSA-44: ~2.4KB, SLH-DSA-128: ~7.8KB, Falcon-512: ~0.7KB) would represent a significant increase over current Ed25519 (64 bytes) and BLS12381 (48 bytes) signatures. No analysis of impact on throughput, storage, or validation costs is publicly available.