Formal specifications for the Quantova consensus layer: a post-quantum, Nominated Proof-of-Stake (NPoS) Layer 1 that separates block production from finality and removes the quantum-vulnerable randomness that classical Substrate consensus depends on.
This repository is the canonical, public reference for how Quantova reaches agreement and why that agreement is secure against an adversary with a fault-tolerant quantum computer. It is written for protocol engineers, validator operators, and cryptographers.
| Resource | URL |
|---|---|
| Website | https://quantova.org |
| Developer Documentation (full) | https://quantova.org/static/pdfjs/web/viewer.html?file=/static/pdf/Gitbook-Quantova-Developer-Documentation.pdf#nameddest=cover&page=1&pagemode=bookmarks |
| Consensus chapter (in the docs) | See Chapter 6 — Consensus & Finality in the developer documentation linked above |
The developer documentation is the broader reference (accounts, transactions, the QVM, the SDK, JSON-RPC, bridges, staking, and governance). This repository narrows in on the consensus layer and its quantum-security argument.
Quantova secures the network with Nominated Proof-of-Stake (NPoS): a bounded active validator set is elected from validators and their nominators' combined stake. On top of NPoS, Quantova separates block production from finality and removes the quantum-vulnerable randomness that classical Substrate consensus depends on.
Three properties define the consensus layer:
- Stake-weighted validator selection (NPoS). The active set is elected from combined validator and nominator stake.
- Deterministic slot leadership with no VRF. Slot leadership is round-robin and predictable; there is no per-slot random draw, and therefore no classical Verifiable Random Function in the trust base.
- Deterministic, provable finality with post-quantum (Falcon) authority keys. Production can briefly fork at the head; finality then commits a single canonical chain.
The headline change for anyone coming from a classical Substrate stack: Quantova removes the VRF and signs the randomness path with a quantum-resistant primitive instead. Validator authority keys are Falcon (FN-DSA), and randomness needed elsewhere in the protocol is sourced from Quantova's post-quantum primitives rather than from an elliptic-curve VRF.
| File | Description |
|---|---|
specs/00-overview.md |
The consensus layer at a glance: NPoS, production/finality split, the three defining properties, and chain timing parameters. |
specs/01-no-vrf-slot-leadership.md |
Why the VRF is removed, how deterministic round-robin slot leadership works, and the Substrate migration note. |
specs/02-block-production.md |
Slot-based block production and deterministic author verification. |
specs/03-finality.md |
Deterministic, provable finality and Falcon authority keys at the finality layer. |
specs/04-validator-set.md |
The single elected validator set, epoch timing, and block-derived scheduling. |
specs/05-quantum-security.md |
How Quantova consensus resists Shor's algorithm: the threat model, where classical schemes break, and what replaces each one. |
node/running-a-node.md |
Build from source, run a full / archive / validator node, operator RPC configuration, and the JSON-RPC surface with runnable snippets. |
These specifications describe the current Quantova implementation. Post-quantum VRF research
is tracked as future work and is explicitly not part of the current consensus design —
see specs/01-no-vrf-slot-leadership.md.
Documentation in this repository is published for public reference. See the developer documentation for licensing of the protocol implementation.
Quantova — post-quantum infrastructure for institutional settlement.