Midnight NIGHT

Claim: Midnight documents its cryptographic primitives (sr25519, Ed25519, ECDSA, blake2_256) in official node documentation and acknowledges quantum risk through the Nightstream research program and IOG blog posts on post-quantum horizons.

Coverage basis: Official documentation and research communications

Implementation score: 0.5 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Official docs provide high-confidence inventory of classical primitives. Quantum threat awareness is expressed through research communications and the Nightstream program rather than a structured threat model document with attack assumptions, affected assets, and affected layers.

Crypto inventory is verifiable from official docs. Quantum threat awareness is credible but informal.

• https://docs.midnight.network/nodes
• https://docs.midnight.network/concepts/network-architecture/cryptography
• https://www.iog.io/news/from-research-to-reality-building-midnight-on-peer-reviewed-foundations

Claim: Evidence includes official documentation, open-source node code, Nightstream research prototype (LFDT-Nightstream), and secondary coverage of quantum roadmap.

Coverage basis: Code repositories, official docs, research communications

Implementation score: 0.5 · Evidence confidence: Medium

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

Assurance: No independent audit exists for any quantum-critical component. Node code is open-source but depends on unreleased dependencies preventing independent compilation. Nightstream is open-source research code with explicit no-audit warning.

Evidence is sufficient to verify current cryptographic posture but insufficient for assurance of correctness.

• https://github.com/midnightntwrk/midnight-node
• https://github.com/LFDT-Nightstream/Nightstream
• https://docs.midnight.network/

Claim: Midnight uses Halo 2 (PLONK-derived) ZK proofs over BLS12-381 for most transactions, with sr25519 for AURA block authorship, Ed25519 for GRANDPA finality, and ECDSA for partner-chain consensus. All are classical and quantum-vulnerable.

Coverage basis: Official node documentation and architecture specification

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Active production spend authorization remains entirely classical: Halo 2 ZK proofs and sr25519/Ed25519/ECDSA signatures are all vulnerable to Shor's algorithm.

Most transactions are proof-based rather than signature-based, but the proof system (Halo 2) relies on classical elliptic curve assumptions (BLS12-381) for soundness.

• https://docs.midnight.network/concepts/network-architecture/cryptography
• https://docs.midnight.network/nodes

Claim: NIGHT token accounts use sr25519 public keys. All unshielded NIGHT UTXOs expose public keys on-chain, creating long-exposure vulnerable ownership paths.

Coverage basis: Official documentation and token design

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All 24B NIGHT tokens exist as unshielded UTXOs with sr25519 public keys, representing full long-exposure value-at-risk.

No PQ account types, hybrid addresses, or key-derivation schemes exist. No migration path for existing classical accounts is available.

• https://docs.midnight.network/nodes
• https://midnight.network/night
• https://docs.midnight.network/concepts/how-midnight-works/midnight-combined-model

Claim: Midnight uses sr25519 for AURA block production, Ed25519 for GRANDPA finality, and ECDSA for BEEFY bridge proofs and partner-chain consensus. All are classical.

Coverage basis: Official node documentation

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Consensus finality and block production are secured by quantum-vulnerable signatures, enabling potential chain reorganization or finality compromise.

Assurance: The federated validator set (Kūkolu phase) means a smaller number of known validators, which could simplify a targeted quantum attack on consensus.

• https://docs.midnight.network/concepts/network-architecture/cryptography
• https://docs.midnight.network/nodes

Claim: State integrity relies on Halo 2 ZK proofs over BLS12-381 for private contract execution and blake2_256 for hashing. ZK proof soundness depends on classical elliptic curve assumptions.

Coverage basis: Official documentation and architecture

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Halo 2 proof system soundness relies on classical elliptic curve (BLS12-381) assumptions, enabling potential state-binding failure under quantum attack.

Assurance: blake2_256 is a hash function with no known quantum speedup beyond Grover's algorithm, making it quantum-safer than ECC components, but state binding depends on the ZK proof system which is quantum-vulnerable.

The hybrid UTXO/account state model adds complexity; ZK proof verification is the critical path for state integrity.

• https://docs.midnight.network/concepts/network-architecture/cryptography
• https://docs.midnight.network/concepts/how-midnight-works/midnight-combined-model

Claim: Midnight uses Halo 2 (PLONK-derived) ZK proofs for privacy-preserving smart contracts. Statistical blinding (salt added to circuits) provides partial HNDL mitigation for shielded state confidentiality.

Coverage basis: Official documentation and secondary sources

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: Halo 2 proof system is quantum-vulnerable; statistical blinding only mitigates HNDL for data confidentiality, not quantum forgery.

Assurance: Statistical blinding is documented via secondary sources only. No formal specification, security proof, or independent review identified. Even if effective for HNDL, it does not prevent a quantum adversary from forging proofs against current live state.

The proof system is the critical quantum vulnerability for privacy. Statistical blinding is a positive operational measure but provides zero protection against active quantum attack on proof soundness.

• https://docs.midnight.network/concepts/how-midnight-works/midnight-combined-model
• https://docs.midnight.network/glossary

Claim: P2P networking uses libp2p with Ed25519 for node identity (default port 30333). Node identity keys are classical.

Coverage basis: Official node documentation

Implementation score: 0 · Evidence confidence: High

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

Assurance: P2P node identity is not consensus-critical, spend-critical, or custody-critical per QRI applicability rules. Node impersonation at P2P layer could enable eclipse attacks but does not directly enable asset theft or consensus compromise.

Treated as note-only because asset ownership and consensus security do not depend on P2P identity.

• https://docs.midnight.network/concepts/network-architecture/cryptography
• https://docs.midnight.network/nodes

Claim: Wallets (Lace, Midnight wallet CLI) support unshielded and shielded NIGHT operations. No PQ wallet support exists.

Coverage basis: GitHub repositories and wallet documentation

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: No PQ wallet, custody, or HSM workflow exists. This is a consequence of no PQ production cryptography rather than an independent gap.

Wallet support for PQ is contingent on protocol-level PQ migration.

• https://github.com/midnightntwrk/midnight-wallet-dapp

Claim: 0% of NIGHT token value-at-risk is protected. All 24B NIGHT tokens exist as unshielded UTXOs controlled by sr25519 public keys, representing full long-exposure.

Coverage basis: Token design and mainnet transaction evidence

Implementation score: 0.05 · Evidence confidence: High

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

Quantum blocker: 0% value-at-risk coverage; all NIGHT tokens are quantum-vulnerable with no migration path.

Assurance: Coverage is verifiable from protocol design: NIGHT is unshielded by specification, all accounts use sr25519, and no PQ account type exists.

Per QRI coverage threshold table 9.3.1, <25% coverage scores 1 out of 20 subfactor weight. Implementation Score = 1/20 = 0.05.

• https://midnight.network/night
• https://docs.midnight.network/nodes
• https://docs.midnight.network/concepts/how-midnight-works/midnight-combined-model

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations) have been migrated to PQ protection. All operate with classical keys.

Coverage basis: Protocol design and mainnet architecture

Implementation score: 0 · Evidence confidence: High

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

Assurance: Governance contracts on Cardano inherit Cardano's quantum-vulnerable cryptography. Federated node operators use classical AURA/GRANDPA keys.

No PQ migration possible for any wallet until protocol supports PQ accounts/signatures.

• https://github.com/midnightntwrk/midnight-reserve-contracts
• https://midnight.network/blog/state-of-the-network-february-2026

Claim: The project has documented its classical cryptographic primitives, implicitly identifying the vulnerable surface. No specific inventory of vulnerable pools, no deprecation mechanism, and no freeze/migration path exists.

Coverage basis: Official documentation

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: Crypto inventory identifies vulnerable algorithms but does not map them to specific accounts, pools, or value concentrations. No deprecation or freeze mechanism exists.

All accounts are equally vulnerable by design (sr25519-only), so specific pool identification is somewhat moot, but the lack of any migration mechanism is the critical gap.

• https://docs.midnight.network/concepts/network-architecture/cryptography

Claim: Nightstream lattice-based folding scheme is a public research prototype (LFDT-Nightstream on GitHub) intended to eventually replace Halo 2. Pluggable signature architecture (Substrate) supports future algorithm swap.

Coverage basis: GitHub repository and public announcements

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Nightstream is explicitly a research prototype with no production timeline. README states: 'Not production-ready,' 'No audit / formal verification.' The roadmap lacks specific activation criteria, sequencing, or target dates for Midnight mainnet integration.

Nightstream code exists and demonstrates serious research investment. However, it is a separate repository from Midnight node with no integration path defined.

• https://github.com/LFDT-Nightstream/Nightstream
• https://www.iog.io/news/from-research-to-reality-building-midnight-on-peer-reviewed-foundations

Claim: No PQ account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, or migration prompts exist for Midnight users.

Coverage basis: Production mainnet status

Implementation score: 0 · Evidence confidence: High

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

Assurance: Absence of migration tooling is verified by the complete absence of PQ production cryptography; no PQ accounts can exist.

Claim: Pluggable signature architecture (Substrate) provides a technical foundation for future signature algorithm swap. Federated authority governance could coordinate migration. No enforcement mechanisms are currently deployed.

Coverage basis: Protocol architecture and governance design

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Pluggable signatures are a Substrate framework feature. No deprecation policy, freeze mechanism, legacy signing disablement, or exchange coordination exists.

Architectural preparation exists but no enforcement or coordination mechanisms are deployed.

• https://github.com/midnightntwrk/midnight-node
• https://docs.midnight.network/nodes

Claim: No evidence of a quantum-specific incident-response process, emergency disclosure mechanism, or governance procedure for quantum vulnerability disclosure.

Coverage basis: Absence of public documentation

Implementation score: 0 · Evidence confidence: None

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

Assurance: Per QRI Section 8.2, absence of a formal quantum-specific IR playbook does not create a Readiness & Risk Cap by itself.

Note-only caveat.

Claim: Nightstream prototype uses lattice-based cryptography (Ajtai commitments, module-SIS binding) derived from the Neo paper (Nguyen & Setty, ePrint 2025/294). These are broadly reviewed lattice assumptions but Nightstream itself is a novel research protocol, not a NIST-standardized construction.

Coverage basis: Nightstream GitHub repository and academic paper

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Lattice-based assumptions are broadly reviewed in academic cryptography. However, Nightstream is a novel protocol and has not undergone independent review. The production Midnight system uses no PQC algorithms.

Score 0.25 reflects that the research prototype uses broadly reviewed lattice assumptions but is not NIST-standardized, not audited, and not deployed in production.

• https://github.com/LFDT-Nightstream/Nightstream

Claim: No independent audit exists for Midnight node, Halo 2 proving system, or Nightstream prototype. Nightstream README explicitly states 'No audit / formal verification.'

Coverage basis: Absence of public audit reports

Implementation score: 0 · Evidence confidence: High

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

Assurance: Per QRI Section 8.2, absence of audit does not create a Readiness & Risk Cap by itself. However, the quantum-critical security property (PQ resistance) cannot be verified since no PQ protection exists in production.

Audit absence is noted but does not independently reduce the QRI Score since there is no PQ implementation to audit in production.

• https://github.com/LFDT-Nightstream/Nightstream

Claim: Midnight node (Apache 2.0) and Nightstream (Apache 2.0) are publicly available on GitHub. Midnight node depends on unreleased dependencies and cannot be independently compiled.

Coverage basis: GitHub repositories

Implementation score: 0.5 · Evidence confidence: Medium

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

Assurance: Midnight node source is publicly viewable but not independently compilable. Nightstream is fully open-source and compilable.

Partial open-source posture: code is visible and licensed openly, but independent reproducibility of production node is limited.

• https://github.com/midnightntwrk/midnight-node
• https://github.com/LFDT-Nightstream/Nightstream

Claim: Midnight's Substrate-based architecture supports pluggable signatures. Nightstream is designed as a drop-in replacement for Halo 2. Official docs describe the runtime upgrade mechanism.

Coverage basis: Protocol architecture and research prototype design

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Parameter agility is an architectural property of the Substrate framework. Midnight-specific testing of signature algorithm swap has not been demonstrated publicly. Nightstream integration path is not defined.

Architecture supports agility but no PQ-specific upgrade has been tested, specified, or scheduled.

• https://docs.midnight.network/nodes
• https://github.com/LFDT-Nightstream/Nightstream

Claim: Nightstream README acknowledges potential side-channel issues and states 'Parameter selection not hardened for production.' No analysis exists for production Midnight node.

Coverage basis: Nightstream README

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Side-channel and implementation risk acknowledgment exists for Nightstream research code but no formal analysis. No stateful signatures (XMSS/LMS) are in use.

Note-only caveat: implementation risks are acknowledged in research code but have no bearing on current production quantum-attack readiness.

• https://github.com/LFDT-Nightstream/Nightstream

Claim: Nightstream claims GPU optimization per secondary sources. No formal benchmarks, block-validation impact analysis, or node hardware requirement analysis exists.

Coverage basis: Secondary sources and Nightstream README

Implementation score: 0 · Evidence confidence: Low

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

Assurance: Performance claims are from marketing/secondary sources. Nightstream's own README lists benchmarks as a TODO. Per QRI Section 8.2, lack of formal performance benchmark does not create a Readiness & Risk Cap by itself.

Note-only caveat: performance analysis gap is relevant for future deployment planning but does not affect current quantum-attack readiness.

• https://github.com/LFDT-Nightstream/Nightstream