Quantova is a post quantum blockchain stack. Every security property in it reduces to a NIST standardized post quantum algorithm, and classical cryptography is not merely rejected but has no valid encoding anywhere the chain parses. The stack is at the testnet and pre audit stage. This reference states what is built and true today. It does not claim the stack is audited, production secure, unhackable, quantum proof, or fully trustless. The true strong form is that Quantova is post quantum end to end and nothing that secures it is vulnerable to Shor.
This repository is the developer map. It gives the layout of the stack, every gateway RPC method in one place in rpc.md, and every Q primitive, identifier family, and cryptographic scheme in one place in primitives.md. Everything here is drawn from the source and the normative specifications, not invented.
| repository | what it is |
|---|---|
| Quantova-Chain | the node, the mempool, the state trie, execution, and the gateway that clients talk to |
| QVM | the register machine that runs compiled containers, with the post quantum operations wired in as instructions |
| QRC-CONSENSUS | QORUS, the committee based byzantine fault tolerant consensus |
| Quanta-Smart-Contract-language | the Quanta contract language and its compiler |
| Q-Crypto | the from scratch post quantum primitives, ML-DSA, ML-KEM, SLH-DSA, SHA-3, and SHAKE |
| QCore.rs, QCore.js, QCore.py | the one client core and its per language bindings |
| QNS | the Quantova Name Service |
| QVRF | the verifiable random function used for sampling |
| Quantova-Specs | the normative specifications every component is built from |
| Quantova-Conformance | the frozen test vectors |
The QVM is the execution layer. It is a deterministic register machine that runs a compiled bytecode container, and it is not the Ethereum virtual machine and not a wasm virtual machine. It has sixteen general registers of 64 bit words, a linear scratch memory that is zeroed at entry and sized to hold a full post quantum key or signature or proof, and a bounded operand and call stack. Arithmetic is checked so an overflow faults rather than wraps, and on any fault the machine rolls back and records nothing. The post quantum operations are first class instructions, so a contract verifies a signature, hashes over SHA-3, checks a Merkle proof, or verifies a random output without rolling its own cryptography, and there is no instruction that verifies a classical signature. Read the instruction set in Quantova-Specs under SPEC-isa.md and the container format under SPEC-container.md.
QORUS is the consensus of Quantova. It is a post quantum byzantine fault tolerant protocol that reaches sub second deterministic finality and produces one aggregated certificate rather than a list of votes, so consensus never consumes block space. A committee of about five hundred is sampled each round from the stake ranked active set by the verifiable random function, a leader proposes a block, the committee attests with the module lattice signature, and a supermajority of two thirds plus one aggregates into a single STARK backed certificate that finalizes the block. Validation is permissionless and Sybil resistance comes from stake alone. Every validator re executes every block, so one honest re executor protects validity. Read SPEC-consensus-qorus.md in Quantova-Specs and the implementation in QRC-CONSENSUS.
Quanta is the Quantova contract language. Security is declared in an entry signature and proven by the compiler before a contract can exist, so whole classes of exploit become compile errors rather than runtime hazards. Source files carry the extension qs and compile to a bytecode container with an embedded interface descriptor. There is no ecrecover and no elliptic curve escape hatch, because the machine holds only post quantum operations. Authority comes from a signed by parameter that desugars to a native signature verify, asset conservation is proven by a linear flow analysis over the conserves clause, a competitive order that is not sealed does not compile, and a bare unbounded addition into stored state has no lowering. Read SPEC-quanta-language.md and SPEC-lowering.md in Quantova-Specs.
Q-Crypto is Quantova's own from scratch implementation of the post quantum primitives, carrying no third party cryptography dependency. It provides the module lattice signature ML-DSA-65 from FIPS 204, the hash based signature SLH-DSA from FIPS 205, key encapsulation with ML-KEM-768 from FIPS 203, and hashing with SHA-3 and SHAKE from FIPS 202. Every operation maps to an exact FIPS reduction recorded in the specifications, and classical cryptography is banned across the tree and enforced before every change. The node and the client build on this same code so a client and the chain agree byte for byte.
QCore is the client core, one implementation of the four things a client has to get exactly right, key derivation, transaction building, signing, and speaking the gateway wire. It is written once in Rust as QCore.rs, and QCore.js and QCore.py are generated over that same core so a signature is never rewritten in another language. QCore.js is published on npm as @qunatovainc/qcore and carries a WebAssembly build for the browser and a native build for Node. QCore.py is the Python binding. All three derive the same Q1 address from the same seed and sign the same transaction body to the same bytes. The client passes the highest fee it will accept and the core refuses to sign a fee the gateway reports above it, so a gateway cannot inflate the fee and drain the account. Read the QCore.rs README for the full surface.
The Quantova Name Service is the human layer of identity. A name ends in the suffix q, reads as a label then a dot then q, and resolves forward to a Q1 address while an address resolves back to its primary name. A name is a pointer in an on chain registry rather than a key, so a short name is safe even though a short key never is. Every record is signed with the module lattice signature and the whole resolution path is post quantum, which makes this the first name service whose entire path is post quantum. The name service is the strongest defence against a look alike address, because a name cannot be confused the way a hash can. Read SPEC-qns.md in Quantova-Specs.
QAsset is the fungible token standard and QCollectible is the collectible standard, both written directly in the Quanta primitives so their guarantees are proven by the compiler rather than hand rolled. QAsset gives a regulated issuer the controls the law requires under an issuer quorum of guardian keys with a threshold, freeze and unfreeze of a named account, an evidence bound clawback, quorum gated mint and burn, and an emergency pause, each gated by the quorum and each emitting a permanent event. Optional compliance hooks such as an allow or deny registry and a sanctions freeze are opt ins the chain never imposes. QCollectible tracks ownership of a collectible by its identifier with a per token owner and a signed mint. These standards use the module lattice or the hash based signature for every authority check, never a classical one. The reference contracts live in the Quanta standard library and are brought up as the compiler reaches its milestones. Read SPEC-token-standard.md in Quantova-Specs and the QCollectible and issuer token examples in the language repository.
The two companion files in this repository are rpc.md, which documents every gateway method with its path, request fields, response fields, and a small example, and primitives.md, which documents every Q primitive, the address scheme, the identifier families, the asset and its units, and the cryptographic schemes with their FIPS numbers. The full normative detail lives in Quantova-Specs.