Public verification labs for inspecting Quantova consensus. Point the labs at a Quantova node, either the public testnet or your own, and they check over the gateway that signatures are post-quantum, that there is no elliptic curve recovery path, that leadership runs through the QORUS committee sortition, and that hashing is SHA-3.
Quantova is a sovereign post-quantum Layer 1 built from scratch. The virtual machine is the QVM, a register machine that runs compiled containers. Consensus is QORUS, a committee byzantine fault tolerant protocol with ML-DSA-65 finality and a budget bounded sortition committee. Cryptography is Q-Crypto, a from scratch NIST post-quantum suite with ML-DSA-65 from FIPS 204 for signatures, ML-KEM-768 from FIPS 203 for key exchange, SLH-DSA from FIPS 205, SHA-3 and SHAKE from FIPS 202, and ChaCha20-Poly1305 for the transport channel. There is no elliptic curve and no classical public key cryptography anywhere in the chain.
This is a hands on companion to the consensus specification. The specification says how consensus works. These labs let anyone confirm that a running node behaves that way.
These labs are an inspection harness, not a security proof. Read docs/what-the-labs-prove.md before drawing conclusions.
They confirm that a node exhibits the expected post-quantum structure. That means post-quantum signature schemes and sizes, no ecrecover and no secp256k1 path, Q1 bech32m addresses, QORUS committee sortition rather than a fixed or unbounded author set, SHA-3 hashing, and stable finality over the window observed.
They do not prove that the cryptography is unbreakable, that the implementation is free of side channels, or that no classical path exists elsewhere. Those questions rest on the NIST standardization of the underlying schemes and on external audit, which is still ahead. The labs are evidence, not a substitute for audit.
The Quantova gateway is a plain HTTP surface. Every call is an HTTP POST to /v1/<method> with a flat JSON body. The methods are node_info, head, validators, chain_params, get_account, get_transaction, submit_transaction, get_block, supply, get_container, get_storage, and get_events. The full reference is in docs/endpoints.md.
The testnet gateway is at https://testnet.quantova.io. Free TQTOV for the testnet is available from the faucet at https://quantova.org. TQTOV is the testnet asset. The mainnet asset is QTOV, and its base unit is the Quon, where one QTOV is one million Quon.
git clone https://github.com/Quantova/consensus-spec-test.git
cd consensus-spec-test
npm install
# point the labs at a node
export QUANTOVA_GATEWAY_URL=https://testnet.quantova.io
# run every lab
npm test
# or run one lab
npm run lab:signatureLabs that need a node skip cleanly when QUANTOVA_GATEWAY_URL is unset, so npm test passes offline and runs the self-verifying checks, for example the SHA3-256 known-answer tests. Set the endpoint to run the live checks. The variable and its default are documented in .env.example.
Lab 00 connectivity confirms the gateway is reachable, that it reports a node identity and chain params, and that the head advances.
Lab 01 signature scheme classifies a signature by byte length and confirms it is in the post-quantum band. ML-DSA-65 is 3309 bytes, far above the roughly 64-byte classical band.
Lab 02 no elliptic curve confirms addresses are Q1 bech32m rather than 20-byte hex, and that the gateway exposes no ecrecover or secp256k1 recovery method.
Lab 03 committee sortition confirms the validators endpoint returns an active committee within the budget the chain reports, and that recent block authors are drawn from the validator registry.
Lab 04 SHA3 hashing runs self-verifying known-answer tests offline and confirms block hashes are 32-byte values on a live node.
Lab 05 finality stability confirms a finalized block is stable on re-read and that finality lag stays bounded over a short window.
Shared helpers live in lib. The gateway client is in lib/gateway-client.js and the post-quantum size reference is in lib/pq-schemes.js.
docs/how-the-labs-work.md describes the verification approach and how to adapt a lab to the node's exact responses. docs/what-the-labs-prove.md states the honest scope, inspection against proof, and you should read it. docs/endpoints.md lists the gateway endpoints and the methods the labs use. docs/address-key-binding.md describes how an account is bound to its first public key.
The labs are written against the documented Quantova gateway, but the exact field names and byte layout in a node's responses are confirmed against the running node. Where a lab depends on a specific response shape, for example where a block records its author, signature, or hash, that point is marked in the code with an ADAPT note. Confirm those against the node you test, then the live checks run.
Copyright 2026 Quantova Inc. See LICENSE.md. These labs are provided for inspection and educational use. They are not a security audit, a guarantee, or financial advice.