Post quantum cryptography in Quantova
Quantova enforces post quantum cryptographic controls directly within the Quantova Virtual Machine. Signature verification, key validity and hashing are protocol execution rules, evaluated identically on every node and independent of client software, wallets or external tooling.
The protocol uses NIST approved post quantum signatures, SHA3 256 hashing and an optional encrypted mempool. These mechanisms are exposed to applications through a structured access layer while remaining fully enforced by the QVM, placing the cryptographic trust boundary inside the protocol rather than at the network edge.
The full post quantum cryptographic stack
Every layer that establishes identity, authorises a state change or commits to state is protected by NIST approved post quantum cryptography, enforced at the execution layer.
| Layer | Mechanism |
|---|---|
| Account signatures | Falcon, Dilithium, SPHINCS+ |
| Validator keys | Post quantum signing |
| Finality | Post quantum verification |
| Hashing | SHA3 256 |
| Address binding | Public key pinning |
| Order flow privacy | Optional ML KEM encrypted mempool |
| Smart contract cryptography | Post quantum precompiles in the QVM |
| Standard | NIST approved |
Signatures, hashing and confidentiality
Lattice signatures
Falcon and Dilithium provide compact, fast lattice based signatures for account and validator authorisation, with verification performed inside the QVM before any state transition.
Hash based signatures
SPHINCS+ provides a stateless, hash based signature scheme that relies on no number theoretic assumptions, available across accounts, validator keys and finality.
Quantum resilient hashing
SHA3 256 establishes transaction identity, block linkage and state commitments, with output size chosen to retain resistance under quantum search models.
Public key pinning
An account is bound to the exact key it first signs with. The execution layer rejects any attempt to authorise that account with substituted cryptographic material.
Encrypted mempool
An optional encrypted mempool uses ML KEM threshold encryption to protect order flow, so pending transactions are not exposed before inclusion.
QVM precompiles
Post quantum precompiles expose verified cryptographic operations to smart contracts, so applications inherit protocol grade primitives without reimplementing them.
Post quantum key systems in the QVM
Quantova replaces classical public key assumptions based on elliptic curves and integer factorisation. Those constructions are exposed to quantum accelerated algorithms that reduce the cost of the underlying mathematical problems. The post quantum key systems used in Quantova rest on constructions that do not depend on discrete logarithms or factorisation, selected to remain resistant under both classical and quantum models.
Key validity is determined exclusively by the QVM. The execution layer enforces key structure, parameter constraints and usage rules. Keys are bound to execution domains, so a key authorised for one operation cannot be reused in another context, preventing cross protocol or cross contract misuse. Validator keys, account keys and protocol keys are all subject to the same enforcement, creating one uniform cryptographic identity model across the network.
| Property | Detail |
|---|---|
| Account keys | Falcon, Dilithium, SPHINCS+ |
| Validator keys | Post quantum, same enforcement |
| Key validity | Determined by the QVM only |
| Scope | Bound to execution domains |
| Address binding | Public key pinning |
How keys are created and signed
Created offline
A post quantum keypair is generated on a secure machine using Falcon, Dilithium or SPHINCS+. The secret seed never touches a networked system.
Address from the public key
The account address is the SHA3 256 hash of the public key, shown in Bech32m as a Q1 identity and held as a 20 byte value for execution compatibility.
Only public keys leave the device
Public keys are published for verification. Secret keys remain on the holder device, or in a validator node keystore for session keys.
Signed on the device
Every transaction is signed with the account post quantum key on the holder own device. The signature binds the payload, the execution context and the sender.
Checked before execution
The protocol verifies the post quantum signature before any state change is applied, under rules for message construction, domain separation and replay prevention.
Bound by public key pinning
The first key an account signs with is recorded as a 32 byte hash and the account is bound to it. A different key is rejected, even one that resolves to the same address.
Validators hold one account alongside separate post quantum session keys for block authoring, finality, peer discovery and liveness. These are generated offline and registered with the network, and misuse such as double signing is penalised at the protocol level.
Authorisation verified before state changes
- ✓Every state changing action carries a post quantum signature that binds the transaction payload, execution context and sender identity.
- ✓Signature verification occurs before any state transition is applied, against protocol rules for message construction, domain separation and replay prevention.
- ✓A valid signature authorises exactly one execution context and cannot be reused across calls, blocks or contracts.
- ✓Execution metering explicitly accounts for the larger size and verification cost of post quantum signatures, keeping behaviour predictable under load.
- ✓No smart contract or application logic can bypass signature verification or redefine authorisation.
Deterministic SHA3 256 commitments
SHA3 256 establishes transaction identity, block linkage, state commitments and execution integrity. Hashing is applied consistently and cannot be altered by contracts or applications.
Transaction identity
Transaction payloads are hashed with SHA3 256 for identification and inclusion proofs.
Block linkage
Block headers reference prior blocks through hash commitments, forming the ordered chain.
State roots
State roots commit to the full execution state after each block, anchoring verification.
Execution traces
Execution traces are hashed to allow independent verification and faithful replay.
Quantum search resistance
Output size is selected to retain resistance where brute force search can be accelerated.
Fixed at the protocol
Hashing behaviour is fixed at the protocol level, ensuring consistent state interpretation for all participants.
Cryptography enforced inside the QVM
Quantova enforces cryptographic validation at the execution layer rather than relying on off chain libraries or client behaviour. The QVM defines which primitives are valid, how they are applied and when verification must occur. Smart contracts operate within these constraints. They may call cryptographic functions exposed by the QVM but cannot weaken authorisation rules or override protocol level enforcement. Centralising enforcement in the QVM establishes a clear, auditable boundary of responsibility for cryptographic correctness.
| Enforcement | Boundary |
|---|---|
| Primitive selection | Defined by the QVM |
| Verification timing | Before state execution |
| Contract capability | Call only, cannot weaken rules |
| Trust placement | Protocol execution, not clients |
Structured access and independent verification
Cryptographic access layer
Applications, wallets and validators construct transactions, request signatures and observe results through a structured access layer. It performs no final cryptographic validation. All verification occurs within the QVM during execution, so trust rests on protocol execution rather than client implementations. The layer surfaces execution proofs, hash commitments and finality indicators that external systems verify without privileged access.
Determinism
QVM execution is deterministic, including every post quantum cryptographic operation. Given the same initial state, inputs and block ordering, all compliant nodes compute identical results. This enables independent replay of historical state and verification of authorisation by auditors and oversight bodies, without access to internal node state.
Transparent accounting for institutions
- ✓The higher computational and data overhead of post quantum cryptography is managed through explicit execution accounting and protocol defined limits enforced by the QVM.
- ✓The model separates identity, authorisation, execution and finality, with cryptographic rules publicly specified and uniformly enforced.
- ✓Because enforcement occurs within protocol execution, institutions can observe and verify network behaviour without reliance on discretionary actors or opaque processes.
- ✓This supports auditability, regulatory review and durable protocol operation.
The cryptographic threat model
The model assumes adversaries that observe network traffic, submit adversarial transactions, compromise client software and apply both classical and quantum accelerated techniques. The protocol assumes no trusted clients, wallets or external libraries.
| Threat | Mitigation |
|---|---|
| Private key recovery | NIST approved post quantum signatures, classical schemes excluded |
| Key compromise or misuse | Keys bound to execution domains, unauthorised use rejected |
| Transaction replay | Execution context binding and state dependent validation |
| Signature forgery | Post quantum verification before state execution |
| Denial of service | Verification cost explicitly metered |
| State integrity attacks | Deterministic SHA3 256 and protocol level state commitments |
| Long horizon recording | Verification at execution time with publicly verifiable state |
Post quantum security enforced by the protocol
Key systems, signature authorisation and SHA3 256 hashing are uniformly applied across all network activity and validated deterministically by the QVM. Authorisation and state transitions depend on execution layer cryptography, becoming authoritative only after verification and consensus finality. This establishes clear accountability boundaries, supports formal analysis and addresses emerging cryptographic threat models while preserving protocol neutrality.
Owned by Quantova Inc. Released under the Business Source License 1.1.
