Quantova Developer Documentation

Quantova is a post quantum Layer 1 blockchain built to protect digital assets for governments, institutions and finance. This is the complete developer reference for the Quantova clients, the gateway RPC, smart contracts, the post quantum wallet, the name service, and the Airlock bridge, every one secured end to end with NIST post quantum cryptography.

1. Read Me First

Quantova is a post quantum Layer 1 blockchain. This document is the canonical developer reference. It explains the protocol, the account and consensus model, the economic system, and the toolchain, the QCore clients, the qtv terminal client, the gateway RPC, and the nodes, with runnable code throughout.

If you read nothing else, read this page. It tells you what Quantova is, who the documentation is for, and the fastest path from here to a working integration.

1.1 What Quantova Is

Quantova is a sovereign Layer 1 blockchain whose cryptography is post quantum from the signature layer up. Every account is secured by ML-DSA-65 under FIPS 204, every hash is SHA-3, consensus is QORUS with a post quantum verifiable random function that draws each committee, and the smart contract environment, the Quantova Virtual Machine or QVM, runs the Quanta language compiled to QVM containers. The native asset is QTOV and its base unit is the Quon, where one QTOV is one million Quon.

The stack ships with first party tooling. The QCore clients cover Rust, JavaScript, and Python over one signing core, the qtv terminal client drives accounts and transactions from the command line, and the gateway answers a plain HTTP wire so the chain is reachable from any language. The Quantova wallet and the Quantova IDE round out the ecosystem for users and contract authors.

1.2 Who This Is For

1.3 How to Read This Document

The chapters are ordered so each builds on the last, and they are self contained enough to jump between. A path by goal.

To build an app fast, start at the Quick Start, then the SDK and Code Examples, then the Gateway RPC.

To ship a contract, start at Accounts and Keys, then Smart Contracts on the QVM.

To run a validator, start at Consensus, then Staking, then Running Nodes, then the Chain Specifications.

To understand the economy, start at the Economic Model and Fees, then Tokenomics, then Governance.

Conventions. Inline identifiers like get_account are code. The local gateway is shown as http://127.0.0.1:40404, point it at your own node where noted. Addresses are shown as Q1 bech32m. Figures are the network's configured values, and the consensus critical numbers are gathered in the Chain Specifications.

1.4 Glossary

2. Introduction

Every blockchain running today authenticates with elliptic curve signatures, ECDSA on secp256k1 or Ed25519. Shor's algorithm recovers a private key from its public key in polynomial time on a fault tolerant quantum computer, so on the day such a machine exists every one of those signatures can be forged and every exposed key can be spent. A ledger is permanent, which makes this not a future event. An adversary records the chain now and breaks it later, so the keys guarding value today are already living on borrowed time.

Quantova is the answer to that problem, built the only way the problem allows, from the ground and from genesis. It is a sovereign post quantum Layer 1 blockchain with no elliptic curve anywhere an attacker can reach and no classical path to fall back to. Accounts, consensus, the random beacon, contracts, and the bridge are authenticated by the signature and hash standards NIST finalized for the quantum era, and by nothing else. There is no migration to schedule and no kill switch to time, because there is no classical key to migrate away from.

What follows is the complete reference. It is written for the developer who integrates against the chain and for the institution or government that has to know exactly what secures it, and it leaves no part of the stack undocumented.

2.1 The Problem Quantova Solves

The quantum threat to a blockchain is not that transactions slow down. It is that authority itself becomes forgeable. Once a public key is on chain, a quantum adversary derives the secret and signs as the owner, mints as the issuer, or votes as the validator. Because the ledger keeps that public key forever, the only defense that works is to never place a breakable key on it in the first place. Quantova is designed around that single fact. It removes the elliptic curve from the trust base entirely and signs with the module lattice scheme NIST standardized as ML-DSA-65, so an account, a validator, and a contract all rest on a problem a quantum computer cannot solve.

2.2 Built From Genesis, Not Forked

Quantova inherits no code and no design from another network. There is no borrowed runtime, no imported consensus, and no classical key scheme carried over from a base stack. A chain that bolts post quantum signatures onto a classical core still exposes classical keys in consensus, in a fallback, or in its history, and a quantum adversary needs only one of those to win. Quantova was chosen for the requirement rather than adapted to it, so the post quantum property holds on every path and not only at the account layer.

2.3 Design Principles

Four principles shape the stack. Post quantum from genesis, so there is no migration event to survive and no window an adversary can wait for. One implementation of anything that touches a key, so a client never restates a signature the node would reject. Deterministic execution, so a contract computes the same result for every node and finality is provable rather than probabilistic. And an open stack pinned by exact version, so a reviewer, an auditor, or a government sees the precise code the network runs.

2.4 Architecture at a Glance

Consensus is QORUS, a committee drawn each round by the first post quantum verifiable random function in the world, with finality carried by an aggregated ML-DSA-65 certificate. Execution is the QVM, a deterministic register machine that runs containers compiled from the Quanta language, with post quantum signing and hashing as native instructions rather than library calls. Accounts sign with ML-DSA-65 and render as Q1 addresses. The clients are the QCore family over one signing core, and value crosses to other chains through the Airlock, a bridge that admits only a post quantum artifact onto the chain. Each chapter that follows takes one of these apart in full, and the proposals in QIP record the design decisions behind them.

3. Quick Start

From nothing to a working integration in three steps, a node connection, a quantum safe account, and a first contract. The concrete examples use the local gateway at http://127.0.0.1:40404, point them at your own node or the testnet gateway where noted.

3.1 Connect to a Node

Read the node info to confirm the gateway and learn the chain id, height, and fee. An empty object is a valid body.

curl -s http://127.0.0.1:40404/v1/node_info -d '{}'
# => {"chain_id":"Q-test-net-1","head_height":26841,"fee":{"transfer_quon":"500"},"version":"..."}

The same read in QCore.js is new Client(url).nodeInfo(), covered in the SDK chapter.

3.2 Create a Quantum Safe Account

Make an account offline with the terminal client. Keep the seed and the phrase secret, the phrase is the only backup.

qtv key new
# seed    17a7...8565
# phrase  bless device stadium ... proud
# address Q1U94GM6GYCCLREFF4HYDP04DKFD726WG3GTPRZW5A3UUC2YJ0373QLT9YNL

Fund the address from the faucet, then register the key so the account can sign, with qtv register. Accounts and keys are covered in full in the Accounts chapter.

3.3 Deploy Your First Contract

Write a contract in the Quanta language, compile it to a QVM container, and deploy the container. The client prints the contract address.

qtv contract deploy hello.qbc --key @account.key
# contract Q1...
# deployed QTX1...

Call it with an encoded selector and arguments using qtv contract call, and read its storage with qtv contract storage. The language and its compiler are in Quanta-Smart-Contract-language, and the terminal client in quantova-cli.

4. Testnet and TQTOV Faucet

Before deploying against mainnet, build and test on the Quantova testnet using TQTOV, the free testnet asset. TQTOV behaves like mainnet QTOV for development. It pays test fees, funds test stake, and exercises contracts and the bridge, but it is distributed at no cost from a faucet and carries no monetary value.

4.1 The Quantova Testnet

The testnet is a full Quantova network running the same post quantum stack as mainnet, the QORUS consensus, the QVM, and the gateway RPC, with its own genesis and validator set. It lets a developer exercise the whole stack, accounts, transactions, staking, governance, QNS, the bridge, and contracts, without spending anything of value. Point your client at the testnet gateway exactly as you would a local node, only the base URL changes.

The wire is the same everywhere. A read against a local node, and the testnet gateway differs only by its base URL.

# local node
curl -s http://127.0.0.1:40404/v1/node_info -d '{}'

# the testnet gateway, same wire, published on the roadmap
curl -s <testnet gateway>/v1/node_info -d '{}'

Testnet accounts use the identical Q1 address scheme and the same QCore clients. To move an integration from testnet to mainnet you change only the gateway base URL, with no code change.

4.2 TQTOV, The Testnet Asset

TQTOV is the native asset of the Quantova testnet, mirroring the role QTOV plays on mainnet. It has no price and no monetary value. It is not for sale, cannot be purchased, is not redeemable for QTOV or any other asset, and is intended solely for development and testing. Treat any offer to buy or sell TQTOV as fraudulent.

4.3 Claiming TQTOV

Test tokens come from the Quantova faucet. The flow follows the pattern common across Layer 1 testnets, you supply an address and receive a capped amount of test tokens. The faucet works with any wallet that supports the Quantova Q1 address scheme.

Generate a Quantova address, with the qtv terminal client or a QCore client, or in the Quantova wallet. Copy the address, it begins with Q1. Open the faucet and select the Quantova testnet. Paste your Q1 address, the faucet checks it is a well formed Q1 address before accepting it. Set the amount up to the per request cap, then submit. The faucet signs and submits a testnet transfer, and the TQTOV arrives once the block is final.

Confirm receipt by reading your balance over the testnet gateway, exactly as on mainnet, with a get_account call.

4.4 Claim Limits and Anti Spam Rules

To keep the faucet available to everyone and prevent draining or spam, the faucet rate limits claims per address and per source, the same approach mainstream testnet faucets use. A small per request cap with a cooldown spreads a finite pool of valueless tokens across many developers, keeps the faucet responsive, and removes any incentive to hoard an asset that has no value. If you need a larger allocation for load testing or a hackathon, request it through the official Quantova developer channels rather than scripting repeated calls, since automated abuse is rate limited and may be temporarily blocked.

4.5 What TQTOV Is Used For

TQTOV opens the whole Quantova development surface so you can validate an integration end to end before touching mainnet. Across the ecosystem it is used to pay testnet fees, where transfers, contract calls, and QVM deployments are all metered and charged in TQTOV under the fee model in the economic chapter. It funds contract work, so you can deploy a Quanta container to the testnet QVM and exercise it with real signed transactions. It funds staking, so you can stake TQTOV to a testnet validator and observe rewards and slashing safely. It funds governance, so you can raise and vote on testnet referenda with TQTOV bonds. And it funds the bridge and QNS, so you can register testnet names and move test assets across the testnet bridge.

TQTOV exists only to make testing realistic. It has no price, is not an investment, is not tradable, and is not convertible to QTOV or fiat. Anyone offering to buy, sell, or exchange TQTOV is acting fraudulently. Testnet state may be reset and TQTOV balances may be cleared at any time.

5. Accounts and Keys

A Quantova account is a post quantum signing key and the address derived from it. The same core makes and reads accounts across every client, so an account made in one place is the same account made from the same seed anywhere.

5.1 Signature Schemes

The default account scheme is ML-DSA-65 under FIPS 204, the module lattice signature standardized by NIST, carried as scheme identifier 1. There is no classical fallback, so an account is quantum safe end to end. SLH-DSA under FIPS 205 and FN-DSA are reserved scheme identifiers, held for a hash based or lattice alternative and gated until that use is settled.

5.2 The Q1 Address Format

An address is the SHA-3 hash of the account scheme byte and the public key, rendered in a Quantova bech32m form whose human readable part is the letter Q, so every address reads as Q1 followed by its data and a checksum. It is uppercase, and its case does not change a signature, so a lowercased address signs the same transaction. A client checks an address is a valid Q1 address before it uses it, so a mistyped recipient is refused before anything is signed.

5.3 Address Derivation

An account starts from a thirty two byte seed. From the seed a keypair and an account are derived by index, so one seed derives many accounts, and index 0 is the default. The seed is backed up as a twenty four word recovery phrase that carries a checksum, so a single typo is caught on restore rather than resolving to a silent wrong account. The derivation is deterministic, so the same seed and index always give the same address, offline, with no gateway.

5.4 Key Registration

Because the address is only the hash of the public key, the chain needs the full key to verify a signature. An account publishes its public key once, by a registration call, before it can send. After that it can sign transfers and contract calls. An account record carries the nonce, the balance, the scheme, and whether the key is registered.

5.5 Working With Keys in Code

Make an account with the terminal client. It prints a seed, a phrase, and an address, all offline. Keep the seed and the phrase secret.

qtv key new
# seed    17a7...8565
# phrase  bless device stadium ... proud
# address Q1U94GM6GYCCLREFF4HYDP04DKFD726WG3GTPRZW5A3UUC2YJ0373QLT9YNL

The same derivation and signing are available in the QCore clients over the one core. See QCore.rs and the terminal client in quantova-cli.

6. Consensus & Finality

Compare the current head height against the finalized head. The gap is the set of blocks still waiting on a committee threshold.

# the current head height
curl -s http://127.0.0.1:40404/v1/head -d '{}'
# => {"head":26841}

# the finalized head, the last block a committee threshold made irreversible
curl -s http://127.0.0.1:40404/v1/finalized_head -d '{}'
# => {"finalized_head":26838}

QCore.js reads the same wire. Read the head, then treat any block at or below the finalized head as final with no reorg.

import { Client } from '@quantovainc/qcore';

const q = new Client('http://127.0.0.1:40404');

// the chain id, head height, fee, and version
const info = await q.nodeInfo();
console.log(`chain ${info.chainId} at height ${info.headHeight}`);

// a block at or below the finalized head from /v1/finalized_head
// is final and cannot reorg

Quantova reaches agreement with QORUS, a committee consensus whose whole path is post quantum. Each round a committee is drawn from the active validator set by stake, the committee attests to the proposed block, and finality is recorded as a single aggregated certificate of ML-DSA-65 signatures. Consensus is the part of a chain most exposed to a quantum adversary, since one classical public key in the voting or finality path would let such an adversary forge authority, so QORUS carries no elliptic curve anywhere in selection, voting, or finality.

Three properties define the layer. A committee is drawn by a post quantum verifiable random function rather than a fixed order. The committee is bounded by a budget, so the work to finalize a block does not grow as the validator set grows. Finality is provable, a vote threshold that a dishonest minority cannot meet, carried by post quantum ML-DSA-65 authority keys.

6.1 The Post Quantum VRF

Committee selection is by sortition, and the draw is seeded by a verifiable random function. Quantova ships the first post quantum VRF in the world, built entirely on NIST approved primitives, ML-DSA-65 under FIPS 204 and SHA-3 under FIPS 202. A classical VRF rests on elliptic curve cryptography that a quantum adversary could break, which would let an attacker grind or predict committee membership. The Quantova VRF removes that exposure, so committee selection stays unpredictable and verifiable against both a classical and a quantum adversary.

The output is verifiable. Any node checks that the draw was produced correctly from the chain carried seed, so a proposer cannot fake its way into a committee, and the randomness path carries no classical public key cryptography. The VRF lives in its own repository, QVRF.

6.2 Block Production

Each round the proposer for that round builds a block, which is gossiped and imported. Peers verify the proposer was drawn for that round from the sortition output, so eligibility is checked against the verifiable draw rather than a fixed slot order.

6.3 Finality

Finality is deterministic and provable. Production can briefly fork at the head, then the committee votes and the block is final once the votes reach the required threshold, gathered as one aggregated certificate. Once final a block is irreversible, since the threshold cannot be met without honest votes, so the network reaches agreement while a dishonest minority of the committee cannot force a different chain.

Finality votes are ML-DSA-65 signatures under FIPS 204, so authority at the finality layer is post quantum. Finality gives a user irreversibility once their block is final, and it gives the bridge a finalized anchor that an outbound proof is bound to before a withdrawal can be claimed on a remote chain.

6.4 Committee and Cost

The same drawn committee handles proposing and finality for its round, and validators enter the draw through their stake, covered in the staking chapter. Because the committee is bounded by a budget rather than by the validator count, the cost to finalize a block stays stable as the validator set grows. The consensus implementation lives in QRC-CONSENSUS and the post quantum VRF in QVRF.

7. Transactions

Every transaction is built and signed inside the QCore core and submitted to the gateway. The client never assembles the wire by hand.

7.1 The Transaction Body

A transaction body carries the sender, a nonce, a meter limit, a fee, a call with a target and arguments, an optional value, and the chain id. A native transfer is a call whose arguments encode the amount, so a transfer and a contract call share one shape. The meter limit is the execution budget that bounds the work, and the fee is paid separately in QTOV base units. The meter is a metering count, not a coin.

7.2 The Signature Envelope

The signed transaction is the body wrapped with an ML-DSA-65 signature that binds the whole body. The transaction id is a hash of the wrapper, rendered as a QTX1 string. The chain id is one of the signed fields, so a transaction signed for one network cannot replay on another, and the client reads the chain id from the node rather than the caller setting it by hand.

7.3 Lifecycle

A transaction moves through a short path. The client reads the node info for the chain id and the current fee, and refuses to sign if the fee is above the ceiling the caller set. It reads the sender nonce, signs the body, and submits the signed bytes. The gateway returns a verdict, accepted with a state and a transaction id, or rejected with a reason and, on a nonce mismatch, the expected and the given nonce. Follow the id to finality, where it lands in a finalized block and cannot reorg. The transaction and signature formats are documented in QIP.

8. Economic Model and Fees

A Quantova transaction carries two economic quantities, a meter limit that bounds the work it may perform and a fee that pays for its inclusion. The meter is a metering count, an upper bound on execution work, and it is never a coin. The fee is paid in QTOV base units, the Quon. Both are recorded in the transaction format in QIP 4.

8.1 The Meter and the Fee

Every account action on Quantova travels in one transaction shape. The signed body names the sender, the nonce, the meter limit, the fee, the call to make, the value carried with that call, and the chain id. A plain value transfer and a contract call use the same body, so one encoding and one signing rule cover the whole surface.

The meter limit is the execution budget the sender grants to the transaction. It is a meter, an upper bound on the execution work the transaction may consume, and it is neither a fee nor a coin. A native transfer sets this budget to the fixed native transfer meter constant, so a plain transfer always reserves the same bounded amount of work.

The fee is a separate field, the amount the sender pays for inclusion. It is denominated in the network base unit, the Quon, the smallest unit of QTOV. The fee the sender signs is bounded by the sender. The client reads the fee the node quotes and refuses to sign when that quote sits above the maximum the caller stated, so a gateway cannot inflate the fee on a plaintext request.

A collected fee is split three ways. Seventy percent is burned and leaves the supply, ten percent goes to the block proposer that included the transaction, and twenty percent funds grants. The split is the same for every category of fee.

8.2 Transfer Fee

A native QTOV transfer pays a transfer fee. The transfer is not a separate object, it is a call whose arguments encode the amount, and its meter is fixed at the native transfer budget. Because the work is bounded and constant, the transfer fee is predictable. The fee is quoted and paid in Quon and splits across burn, proposer, and grants like any other fee.

8.3 Contract Deploy Fee

Deploying a contract is a transaction whose call carries the compiled contract code and its constructor arguments. It pays a contract deploy fee. The meter limit must cover constructor execution and the cost of writing the deployed code into storage, so a larger contract and heavier constructor work reserve a larger meter budget. The sender sets the meter limit at or above the work the deployment needs, then signs the fee the node quotes within the bound the sender stated.

8.4 Bridge Fee

A transfer that crosses to another network through the bridge pays a bridge fee. The fee is quoted and paid in Quon and covers the protocol work of moving value to the destination network. Exact rates are set on chain and are not fixed in this document. The bridge fee splits across burn, proposer, and grants on the same terms as every other fee.

8.5 Governance Bonds

Governance carries no fee beyond the standard transaction fee, but a proposal must post a QTOV bond so that spam is discouraged. The bond returns to the proposer when the proposal reaches its engagement threshold and is forfeited when it does not. The bond amounts are a governance parameter and are not fixed here.

Quantova runs on testnet. The transaction and meter model described here is the intended design of the network, and the format together with its post quantum cryptography has not yet been externally audited. The fee categories above are the real categories on the testnet build, and exact rates are set on chain rather than written into this document.

9. QTOV Tokenomics

QTOV is the native asset of Quantova. Its base unit is the Quon, where one QTOV is one million Quon, so QTOV carries six decimals. On the current network the live asset is TQTOV, the testnet token, which holds no market value. QTOV pays the protocol fee on every transaction, bonds validators, carries governance weight, and settles cross chain corridors. Staking rewards are not new issuance. They are drawn from a fixed genesis staking pool and shared across stake as an emergent yield, so the network runs no hardcoded disinflation curve. Fees are split three ways with a real burn, so use of the network reduces supply over time. Quantova is on testnet and has not completed an external security audit. The figures below are read from the staking and node code, or are marked as subject to the founder pin.

The Emergent Yield Model

Staking rewards come from a pool funded at genesis, not from minting new QTOV. Each session the protocol releases a fixed emission and shares it across all bonded stake in proportion to each validator share, the emission over total staked. The yield is emergent. It runs high when little is staked, which draws validators in, and it settles as the staked set grows. It carries no cap and no fixed schedule. The pool is finite, so the emission can never overdraw it, and once the pool is spent the reward ends. The earlier fixed rate curve and the USD yield cap are retired.

Genesis supply stays fixed at the allocation while the pool pays out, and because a fifth of every fee is burned, the circulating total falls with network use rather than rising on a schedule. There is no inflation figure to publish, because there is no issuance curve.

At the founder preference rate the pool funds roughly twelve years of rewards, around 57,143 QTOV a year across about two sessions. The exact per session emission is still a founder item, and governance can tune it once set.

9.1 Core Parameters

9.2 Token Functions

9.3 Genesis Allocation

The split below is the intended shape and every figure is subject to the founder pin. Only the staking reward pool, 685,714 QTOV, is set in code today.

The genesis supply is allocated across categories that fund network security, ecosystem growth, and treasury durability. Allocations are released through on chain vesting with publicly verifiable addresses.

The Reserve funds ecosystem development, partnerships, audits, and treasury operations under governance. Grants and Development seeds ecosystem work under governance release. Staking and Network Rewards is the reward pool that funds the emergent yield. Core Contributors and Advisors vest over multiple years. Liquidity and the Public Sale open at launch. The exact category shares, token counts, and their vesting all wait on the founder pin.

9.4 Vesting Schedule

The one release rule set in code today is the staking reward vest. A reward tranche is locked for 365 days from the session it was earned, then becomes fully transferable, a rolling twelve month schedule that is the sell pressure control. At mainnet start there is a 365 day blackout during which no reward accrues at all.

The vesting of the genesis allocations, the cliffs and linear streams per category, is a genesis configuration item and is subject to the founder pin. It is not fixed in the staking code and is not stated here as a settled schedule.

9.5 Fee Distribution and Treasury

Every transaction fee is split three ways by the node ledger. The split is set in code and tunable by governance.

Because a fifth of every fee is burned, activity on the network reduces the circulating total, so the fee model is deflationary with use rather than accruing in full to a treasury. Slashed stake and forfeited bonds are routed to the treasury, covered in Chapter 10.

9.6 Voting Weight and Locking

Governance weight is denominated in QTOV. A holder votes with a conviction that sets both a lock and a weight multiplier. The multipliers are set in code.

Weight is the stake times the multiplier, so committing QTOV for longer buys more say and the holders who can move the network are those committing the most stake. Referendum thresholds, quorums, and proposal bonds are covered in Chapter 11.

10. Staking & Validator Economics

Validators secure Quantova by staking QTOV directly. A validator bonds QTOV into the stake ledger, and once its bond is above the minimum it joins the active set. Each round QORUS draws a budget bounded committee from that active set by a post quantum verifiable random function, and the drawn committee proposes and finalizes the block. Stake is what admits a validator to the active set and weights its chance in the per round draw, so committed capital is what earns the right to produce blocks along with the rewards and the slashing risk that come with it. Quantova runs on testnet and the protocol and its cryptography are not yet audited.

10.1 Roles

Quantova has one staking role. A validator bonds QTOV, runs a node, and stands to be drawn into the committee each round. When drawn, it proposes or attests to the block and signs finality votes with its ML-DSA-65 authority key under FIPS 204. A validator stakes only its own QTOV and bears its own slashing risk, with no third party staking on its behalf. Governance, covered in the next chapter, sets the staking parameters and can change them only through a high threshold referendum.

10.2 Validator Requirements

A validator must bond at least the minimum stake, keep its node available so it can answer when its committee is drawn, and hold the ML-DSA-65 authority key it signs finality with. Bonding is time bound. The bond is locked for a fixed period before an exit can be requested, an exit then runs an unbonding window before the stake returns to a spendable balance, and the bond stays slashable throughout that window so a validator cannot exit ahead of a fault it has already committed. The values below are read from the qtv-staking crate as configured for testnet.

10.3 Revenue Streams

Validator reward comes mainly from new issuance, paid pro rata by stake from a fixed staking pool. The yield is emergent rather than a set curve. A fixed emission is shared out each session in proportion to each validator's stake against the total staked, so when little is staked the yield per validator is high and draws validators in, and it settles as the set grows. There is no yield cap. On top of issuance a validator earns a share of network fees, a share of priority fees and a share of the fees paid for bridge attestations, with the remainder of each routed to the governance controlled network treasury. The exact fee shares are set outside the staking crate and are covered in the tokenomics chapter.

The reward and bonding parameters as configured in the qtv-staking crate for testnet. Values are tunable by governance and are not audited.

minimum stake         2,000 QTOV
staking pool          685,714 QTOV
session emission      28,571 QTOV per session
session length        182 days
reward vesting        365 days after the session it was earned
first year blackout   365 days with no reward paid
bond lock             90 days before an exit request
unbonding window      21 days after an exit request

Reward accrues on a rolling schedule. A reward earned in a session is recorded against the validator and becomes fully transferable one year after the session it was earned, so sell pressure is spread rather than released at once. No reward is paid in the first year after mainnet start, and on testnet no reward carries economic value. A validator claims its unlocked reward from the accrued tranches, and the pool is finite, so once the staking pool is drawn down issuance stops and only the fee shares remain.

10.4 Running a Validator

A validator is a node that bonds stake and answers when its committee is drawn. The steps are the same on testnet and mainnet, only the gateway and the asset change.

Build the node from the pinned repositories and run it. The daemon produces and finalizes blocks under QORUS and serves the gateway on a local port.

# build the node from source
cargo build --release

# run it, it serves the gateway front door on a local port
quantovad

Make the validator account, register its key, then bond stake. A bond is a transfer to the reserved stake address, so the same signing path builds it.

# a validator account and its registered key
qtv key new
qtv register --key @validator.key

# bond stake, a transfer to the reserved stake address bonds the amount
# the amount is in Quon, 2,000 QTOV is 2000000000 Quon, the minimum stake
qtv send <stake address> 2000000000 --key @validator.key

Once the bond is above the minimum stake the validator joins the active set and stands to be drawn each round. Read the validator set and each bonded weight from the gateway with the validators method, and read the live staking figures with staking_state. Keep the node available, since a validator that cannot answer when its committee is drawn is slashed for a liveness fault.

10.5 Slashing

Slashing is enforced in consensus and is Quantova's response to validator faults. Faults fall into two kinds. A liveness fault is a validator that is unavailable when its committee is drawn, and it forfeits a small portion of the bond, a larger portion when the unavailability is prolonged. An attributable fault is a provable safety violation, above all equivocation, a validator signing two blocks at the same height, which is exactly what QORUS finality must never admit. An attributable fault forfeits the entire bond, removes the validator from the active set, and permanently bans its identity from bonding again. Slashed stake is routed in full to the governance controlled network treasury, so value taken from a faulty validator returns to the network rather than being destroyed or paid to anyone.

The whole penalty goes to the governance controlled network treasury in every case. A validator slashed for an attributable fault is removed from the active set and barred from bonding again under the same identity, while a validator slashed for a liveness fault keeps the remainder of its bond and can requalify.

10.6 Committee Selection

Consensus is QORUS and the full description is in the consensus chapter. In staking terms the active set is the pool of bonded validators above the minimum stake, and each round QORUS draws a budget bounded committee from that set by a post quantum verifiable random function. The committee size is fixed by a budget rather than by the validator count, so the work to finalize a block stays flat as the set grows, and authority rotates across the set instead of resting on a fixed order. A validator's bonded stake is what places it in the active set and weights its chance of being drawn. The draw is seeded from post quantum randomness carried by the chain, and finality votes are ML-DSA-65 signatures under FIPS 204, so committee selection, voting, and finality carry no classical public key cryptography. The consensus implementation lives in QRC-CONSENSUS.

11. Governance

Quantova has no sudo path, no super user key, no LAA, and no root key anywhere in the ledger or the governance crate. From genesis, governance is the top authority of the network, and the only way to change privileged chain state is an approved referendum. Every privileged mutation of chain state, minting, parameter changes, freezes, blacklisting, bridge administration, and feature activation, is reachable only through a referendum and its enactment path. Proposals ride one of five tracks, each with its own deposit and timelock. Votes are cast under conviction. A constitution gate binds every enacted action to the track it was raised on and shields protected accounts. An emergency guardian caucus, rotated only by governance, can lift a bridge freeze under a threshold of signatures. The full design is recorded in QIP 8.

11.1 No Superuser: Governance Only

There is no sudo path and no super user key anywhere in the ledger or the governance crate. The privileged actions all flow through gov_enact, which admits an action only after its referendum has reached Status::Approved, then runs the constitution gate, then calls execute_action. The one path that does not require a referendum is the guardian caucus, and the guardian caucus is a threshold multisig whose membership is set and rotated only by governance. No single key can mint, change a parameter, freeze an account, blacklist an account, or turn on a feature.

11.2 The Five Tracks

Every proposal is raised on exactly one track. Each track carries a deposit denominated in QTOV, where one QTOV is NATIVE_UNIT base units, and a period that is both the voting window and the timelock before enactment. A proposal opens a referendum at the time it is submitted, and the referendum can be concluded and enacted only once the current time reaches the submission time plus the track period.

The proposer posts the deposit up front. It is returned when the referendum passes and is forfeit to the stake treasury when it fails or is killed. A referendum passes when the aye stake reaches forty percent of the total staked, drawn from a THRESHOLD_BPS of 4,000 basis points against a denominator of 10,000. The electorate is the total staked at conclusion time, and below that bar the referendum is rejected.

11.2.1 Deposit Economics and Governance Slashing

The deposit is the stake a proposer puts at risk to open a referendum. gov_propose debits the full track deposit from the proposer balance before the referendum opens, so a proposal that a proposer cannot fund never reaches the queue. The deposit is denominated in QTOV, where one QTOV is NATIVE_UNIT of 1,000,000 base units, and the amount is fixed per track in code. The smallest deposit is the 292,500 QTOV of the FreezeRecovery track and the largest is the 4,000,000 QTOV of the Mint track, so even the lightest proposal puts a large sum at risk.

gov_conclude settles the deposit at the close of the voting window. It refunds the deposit only when deposit_refunded holds, which is true when the referendum was not killed and the aye stake cleared the forty percent bar. On a refund the full deposit returns to the proposer balance. On a miss, where the referendum reaches the end of its window without the support to pass, or on a kill, where the referendum is struck as spam, the whole deposit moves to the stake treasury. The forfeit is the entire deposit and never a fraction, so this is the governance slashing that prices spam out of the network. A killed Mint proposal forfeits its whole 4,000,000 QTOV, and even a killed FreezeRecovery proposal forfeits 292,500 QTOV.

The refund test is the same predicate that decides the vote, so a deposit comes back to the proposer on exactly the passes that enact and is slashed to the treasury on every miss and every kill.

// gov_conclude, once the window has closed and the referendum has resolved
if referendum.deposit_refunded(electorate) {
    // not killed, and the aye stake cleared the forty percent bar
    account.balance = account.balance.saturating_add(referendum.deposit);
} else {
    // a miss or a kill sends the whole deposit to the stake treasury
    self.set_stake_treasury(self.stake_treasury() + referendum.deposit);
}

11.3 Conviction Voting

A ballot commits stake under a conviction. Voting debits the committed stake from the voter balance and locks it. The conviction sets how long the stake stays locked and carries a weight factor. Each fresh ballot extends the lock so it ends no earlier than the new conviction demands, and the committed stake is returned through gov_release once the lock has run. A voter casts at most one ballot per referendum.

11.3.1 The Conviction Lock in Detail

A conviction carries two numbers, a weight factor and a lock period. The weight factor is held in tenths as factor_x10, so Liquid is 10, Year is 15, and TwoYear is 25. The weight a ballot carries is its committed stake scaled by that factor, computed as the stake times the factor divided by ten, so a one year lock values the same stake at one and a half times and a two year lock at two and a half times. The longer lock is the price a voter pays for the heavier weight, and the stake stays out of reach for the whole period.

The lock is held per voter and not per ballot. gov_vote debits the committed stake from the voter balance, adds it to the voter lock amount, and sets the lock end to the later of the current end and the present time plus the conviction lock period. A fresh ballot under a heavier conviction can only push the release further out and never pull it in, so a voter cannot shorten a standing lock by voting again under a lighter conviction. The network wide sum of locked stake is tracked in gov_total_locked. Once the present time reaches the lock end, gov_release returns the whole locked amount to the voter balance, clears the lock, and lowers the locked total.

The weight is the committed stake scaled by the conviction factor held in tenths, so the arithmetic stays in whole base units and never rounds a voter up.

// the weight a ballot carries, from the conviction factor held in tenths
pub fn weight(self, stake: u64) -> u128 {
    (stake as u128) * self.factor_x10() / 10
}

// gov_vote extends the lock, it never shortens it
let release = now.saturating_add(conviction.lock_seconds());
if release > lock.until {
    lock.until = release;
}

11.4 The Constitution Gate

Before any approved action runs, check_enactment binds it to the track it was raised on and shields protected accounts. If the action does not belong to the referendum track the gate returns WrongTrack and nothing is enacted. For a FreezeRecovery action the gate requires that the seizure set hash to the scope that was approved, computed as the SHA3-256 of the recovery preimage over the victim and the seizures, and it returns RecoveryOutOfScope when the hash does not match and RecoveryTouchesProtected when any seizure source is a protected account. For a Freeze action it returns FreezeTouchesProtected when any target is protected, and for a Blacklist action it returns BlacklistTouchesProtected when the target is protected.

A protected account is any account that holds a stake bond, so an active validator, any account that holds a governance vote lock, so an active voter, or any of the reserved network pots, which are the grants pot, the stake treasury, the stake pool, the stake system pot, the governance system pot, the bridge bond pot, and the ecosystem marketing, market maker, and foundation pots. These accounts cannot be frozen, blacklisted, or seized by a governance action.

11.5 The Action Set

Each action that governance can enact is pinned to a single track in code, and the constitution gate refuses any attempt to enact an action off its track.

11.5.1 What Each Action Does at Enactment

Once gov_enact has confirmed the referendum reached Status::Approved and the constitution gate has passed, execute_action carries out the action. Each arm runs its own guard, so an approved action can still be refused at the moment of enactment when it is malformed or out of bounds, and the deposit refund and the receipt settle only on a clean run.

The guard on each arm is why an approved referendum is a permission to enact and not a promise the state will move, an out of bounds mint of nothing or a spend beyond a pot still returns an error and writes no receipt.

11.6 Forkless Upgrades

The upgrade path is the Activate action on the ChainUpgrade track. An Activate action names a feature and a version. When it is enacted, execute_action writes the version to a feature gate key derived as the SHA3-256 of the tag qtv/gov/feature/ joined with the feature name. Node logic reads that state through feature_version, which returns the stored version or zero when the feature has never been raised, and through feature_active, which is true once the version is above zero. A feature name cannot be empty, and only an approved ChainUpgrade vote through execute_action can raise a version.

Logic that ships dormant in the binary reads the gate and branches on it, so a passed vote turns it on across the network at once, on the same chain, with no fork and no flag day.

// a feature that shipped dormant in the binary, off until a vote raises its version
if feature_active("example_feature") {
    // the new path runs across the network once the ChainUpgrade vote enacts
} else {
    // the prior behaviour, unchanged
}

// feature_version returns the stored version, or zero when never raised
let version = feature_version("example_feature");

This path turns on logic that already exists in the running binary. It does not write new logic. Brand new logic that is not yet compiled into the binary, a fix to the pinned QVM, or a change to QORUS consensus still needs a new binary shipped to operators. The feature gate flips behaviour that the current binary already carries, and nothing more.

11.7 The Emergency Guardian Caucus

The guardian caucus is a threshold multisig recorded in state as a set of members and a threshold. The set is well formed only when the threshold is at least two and does not exceed the membership, so a caucus never acts on a single key. Authorization counts distinct members from the set until the threshold is met, and an outsider or a repeated key carries no extra weight.

The bridge freeze is a bonded safety valve. Any account that is not blacklisted can post the bridge freeze bond of 390,000 QTOV, which equals the BlacklistKill deposit, to freeze the bridge for seven days, subject to a one day cooldown after any lift. The account that posted the bond can lift the freeze early and take a refund. The guardian caucus can lift the freeze early under its threshold of signatures, in which case the bond is slashed to the treasury. Governance can also lift the freeze through the BridgeUnfreeze action on the BlacklistKill track, which slashes the bond as well. The guardian caucus is created and rotated only by governance through the GuardianRotate action, so the emergency power itself sits under the top authority.

11.7.1 The Caucus Powers and the Freeze Bond

The caucus authorization counts distinct members from the set until the threshold is met, so an outsider carries no weight and one member named twice is still one key. A caucus is well formed only when its threshold is at least two and does not exceed its membership, so no single key can ever act. The membership and the threshold are set in state by the GuardianRotate action on the ChainUpgrade track and by nothing else, so the emergency power is created, widened, or retired only by a passed referendum.

The caucus holds an emergency account freeze. Under its threshold it can set a freeze on a batch of accounts through guardian_freeze, which refuses an empty batch, refuses to touch any protected account, and is bound to a freeze epoch that rises by one on every use, so a captured set of signatures cannot be replayed against a later batch. This is the rapid brake that does not wait for a two day BlacklistKill window, and it still cannot reach a validator, an active voter, or a network pot.

The bridge freeze bond ends one of three ways, and the bond follows the exit. When the depositor lifts the freeze early the bond is refunded. When the seven day duration runs out and the freeze expires the bond is refunded. When the caucus lifts the freeze early under its threshold, or governance lifts it through the BridgeUnfreeze action, the bond is slashed to the stake treasury. So an honest freeze that the depositor or the clock lifts costs only the fee, while a freeze that the caucus or a referendum has to unwind forfeits the whole 390,000 QTOV bond.

// guardian_freeze, the emergency account brake under a threshold of signatures
if targets.is_empty() || !self.guardian_set().authorizes(approvers) {
    return false;
}
if bound != self.guardian_freeze_epoch() {
    return false; // the epoch guard stops a captured signature set being replayed
}
if targets.iter().any(|target| self.is_protected_account(target)) {
    return false; // a validator, an active voter, or a network pot is out of reach
}

Quantova is on testnet, and external audits of the governance system and its cryptography are still ahead.

12. Cross Chain Bridges

Quantova moves value across chains through the Airlock, a trustless bridge. The design keeps the chain post quantum by letting only two kinds of artifact cross to Quantova, an ML-DSA attestation and a hash STARK proof, while the classical cryptography of a foreign chain stays off chain behind the Airlock. Nothing a quantum adversary could forge is verified on Quantova.

12.1 The Airlock

A foreign observation is verified off chain by the oracle and a light client, then it crosses the Airlock as an ML-DSA attestation, and where a stronger guarantee is needed as a hash STARK the chain checks. The Airlock is the one boundary where a foreign fact becomes a Quantova fact, and it admits only post quantum artifacts. The oracle lives in Q-Oracle and the light client in Q-Lightclient.

12.2 Inbound Mint

A deposit on a foreign chain mints wrapped tokens on Quantova, but only under a quorum of distinct operator signers, never a single relayer. The destination chain and the chain id are bound into the signed preimage, so an attestation cannot replay on another network, and each source reference is consumed once so a deposit cannot mint twice. Per epoch and global caps bound how much can mint in a window.

12.3 Exit and Custody

An exit burns the wrapped tokens on Quantova and releases the real asset abroad. Custody is a single governance held pool. It is drawn only when a payout is proven at settle, and a failed exit that ends in a slash refunds the holder on chain without drawing that custody a second time, so the backing is always conserved. Per epoch and global payout caps bound the exit path, and governance can freeze the bridge and move the pool in an emergency.

The whole exit path is gated off by default, and the bridge is a design under review, not audited and not live. The full design and its status are in QIP.

14. Smart Contracts on the QVM

The reference fungible token, a QAsset written in Quanta and compiled to a QVM container. Balances live in contract storage, each write is reached by a four byte selector, and state is read with get_storage.

import { Map } from "quantova/stdlib";
contract QAsset {
  asset QRC;
  state {
    owner: Q_Address;
    total_supply: u128;
    balances: Map<Q_Address, u128>;
  }
  genesis {
    owner = deploy_params.owner;
    total_supply = deploy_params.initial_supply;
  }
  entry mint(order: MintOrder signed by owner)
    mints QRC
    writes(total_supply, balances)
  {
    total_supply += order.amount;
    balances.credit(order.to, order.amount);
    emit Minted(order.to, order.amount);
  }
  entry transfer(to: Q_Address, amount: u128)
    writes(balances)
  {
    guard amount > 0;
    balances.debit(caller, amount);
    balances.credit(to, amount);
    emit Transferred(caller, to, amount);
  }
  event Minted(to: Q_Address, amount: u128);
  event Transferred(sender: Q_Address, to: Q_Address, amount: u128);
}

Contracts on Quantova are written in the Quanta language and compiled to QVM containers that run on the register machine. There is no other virtual machine under the QVM and no borrowed contract language in the toolchain. A .qs source is checked and lowered by the Quanta compiler in Quanta-Smart-Contract-language into a container, and the QVM loads that container and runs it. The QAsset listing above is the reference fungible token, and it reads the way it runs, because the entries, the state, and the events are exactly what the deployed container executes.

A contract is post quantum resistant because its signing and verification use ML-DSA-65 and its hashing uses SHA-3, and both are native QVM instructions rather than calls into a swappable library. The machine pins their semantics and meters their cost, so a contract cannot reach a weaker primitive and no classical public key primitive is present anywhere in the contract path.

14.1 The QVM Execution Model

The QVM is a deterministic register machine with sixteen general registers, each a 64 bit word, a program counter held as a 32 bit offset into the code, a call stack bounded at 1024 words, and a flat memory of 65536 bytes read and written in big endian order. Arithmetic is explicit about width. The checked forms Add, Sub, and Mul fault on wraparound, Div and Rem fault on a zero divisor, and the wrapping forms wrap by definition. Every instruction is metered, and a run that would exceed its meter halts before that instruction takes effect.

Execution is all or nothing. A call runs from its entry offset until a clean Halt, and only a clean halt yields an outcome of registers, storage, and effects. Any fault ends the run with no committed storage and no effects, so a caller sees either the full result of a clean run or none of it. A native cryptographic instruction that would panic on adversarial input is caught and mapped to a fault, so no input crashes the machine.

A contract is published as a container of three parts, the code section, the constant pool, and the entry table. The canonical byte format begins with the four byte tag QVM1, and the container identifier is the SHA-3 digest of these canonical bytes, so any change to code, to a constant, to an entry offset, or to an access manifest changes the identifier. A container is bounded and checked before it is trusted, with the code at most 65536 bytes, the constant pool at most 4096 entries, and the entry table at most 256 entries. Verification decodes the code linearly and requires that every jump target, call target, and entry offset lands on an instruction start, that every constant load names an index inside the pool, and that no two entries share a selector.

14.2 Native Post Quantum Instructions

The most exposed part of a contract is its cryptography. A contract that verified a signature or hashed a message through a swappable library would inherit that library's assumptions, including any classical public key assumption. The QVM removes that exposure by carrying post quantum verification, key encapsulation, address derivation, and hashing as native instructions with fixed semantics, so a contract cannot reach a weaker primitive and the same code runs identically on every node.

Two of these instructions carry the post quantum property that the section opened with. The VerifyMl instruction verifies an ML-DSA-65 signature, the module lattice signature of FIPS 204, over a region laid out as a public key, then a signature, then the message. The Hash instruction writes the SHA-3 digest of a memory region, thirty two bytes, to an output pointer, and the same SHA-3 digest names container identifiers, selectors, and storage keys throughout the machine. Because these are instructions rather than library calls, their semantics are pinned by the machine and their variable work is priced by the meter as it scales with the length absorbed.

There is no elliptic curve instruction and no classical verify anywhere in the set, so the cryptographic surface of a contract stays inside the machine. A contract verifies with ML-DSA-65, hashes with SHA-3, and where it needs them reaches SLH-DSA and ML-KEM-768, all under semantics the machine pins.

The call ABI and contract storage

A call is a four byte selector followed by an encoded argument image. The selector names the entry and is the leading four bytes of the SHA-3 digest of the entry signature, so the mint entry and the transfer entry each carry their own selector, and a selector that names no entry is refused. The client builds the argument image by placing each typed argument at the offset the compiled entry expects. A word occupies eight big endian bytes, an address occupies thirty two bytes, and a Q_Name occupies a thirty two byte label window followed by an eight byte length, spanning forty bytes in all.

call = selector (4 bytes) || argument image

argument image
  [0   .. 80)   reserved host context   node fills this window
  [80  .. )     encoded arguments        client writes these

host context window (80 bytes)
  @caller     32 bytes   Q address of the authenticated caller
  @contract   32 bytes   Q address of this contract
  @time        8 bytes   block time as a word
  @chain       8 bytes   chain id as a word

Storage is a map from a thirty two byte key to a 64 bit word value. The SLoad instruction reads the key from memory and returns the stored word or zero, and SStore writes the word to the key. A scalar field such as total_supply lives at a key whose trailing eight bytes hold its slot number. A keyed field such as the balances map lives at a key the contract derives at run time as the SHA-3 digest of an eight byte map base followed by the field key, so a holder balance sits at a slot no one can list ahead of time. Each entry authorises the storage it may touch through a declared manifest, and a load or store to an undeclared slot faults.

The first eighty bytes of the argument image are a reserved host context window that the caller does not fill. It holds @caller and @contract as thirty two byte addresses and @time and @chain as eight byte words, which together fill exactly eighty bytes. The client writes all of its own arguments at or above offset eighty and leaves the window as zero, and the compiled entry reads the context only from these fixed offsets. The node owns the window and writes the true caller, the contract, the time, and the chain into it before the entry runs, so a value a contract reads there is a value the node placed and never one the caller supplied.

14.3 QAsset, the Token Contract Example

The QAsset contract shown at the head of this section keeps every holder balance in its own storage and moves value across the balances map through two write entries. A balance and the total supply are not entries. They are reads against contract storage, reconstructed from the same keys the machine derives and returned as words, and a key that has never been written reads as zero. The stored width for a u128 value is among the details still being pinned for this Draft standard.

entry mint(order: MintOrder signed by owner)
  mints QRC
  writes(total_supply, balances)
{
  total_supply += order.amount;
  balances.credit(order.to, order.amount);
  emit Minted(order.to, order.amount);
}

The mint entry takes an order that is signed by owner, so it is reached through a signed order rather than a bare call. The order preimage folds a domain tag with the chain id, then the contract address, the selector as a word, the signer address, the signer nonce, and the field values, and it is signed with the owner ML-DSA-65 key. The public key, the signature, and the message are laid out in a verify region for the VerifyMl instruction to check. The nonce is tracked in a per signer slot so the same order cannot be replayed, and because the chain id and the contract address are folded into the preimage, an order signed for one chain or one contract does not verify against another.

entry transfer(to: Q_Address, amount: u128)
  writes(balances)
{
  guard amount > 0;
  balances.debit(caller, amount);
  balances.credit(to, amount);
  emit Transferred(caller, to, amount);
}

The transfer entry guards that the amount is above zero, debits the caller, credits the recipient, and emits Transferred. The account it debits is caller, which the entry reads from the host context window that the node filled, not from any argument the client supplied. This is the property that stops a transfer from being spoofed, because a client cannot debit an account it does not control. An event surfaces to a reader as the contract address, a four byte selector, and a data payload, and a single word payload decodes as a big endian word.

14.4 Q Primitives

A Q primitive is a post quantum operation the machine carries as its own instruction, so a contract reaches it in a single opcode with no library linked in and no classical public key primitive anywhere on the path. The QVM exposes six of them, and each takes three register operands, a pointer, a length, and an output, over a memory region the contract has already laid out. The QVM pins their meaning, so the same input yields the same result on every node, and the meter prices the variable work as it scales with the bytes each one absorbs.

Because these are native instructions, a contract verifies a post quantum signature or checks a Merkle proof without a library and without a classical primitive. A signature check is one VerifyMl over a region holding the public key, the signature, and the message, and the machine returns one or zero into a register the contract branches on. A proof of membership is one MerkleVerify over a root, an index, a leaf, and the sibling path, and the machine rebuilds the root with a leaf tag and a node tag so an internal node cannot be passed off as a leaf. Neither reaches outside the machine and neither depends on an elliptic curve, so the cryptographic surface a contract stands on is exactly the set the QVM pins.

The signing primitives are the two that carry the post quantum property. VerifyMl checks ML-DSA-65, the module lattice signature of FIPS 204, and VerifySlh checks SLH-DSA, the stateless hash based signature of FIPS 205, while Kem encapsulates under ML-KEM-768 of FIPS 203. Where a contract needs an account address it reads a scheme byte, a one for ML-DSA-65 or a two for SLH-DSA, and Addr derives the address as a SHA-3 digest over that byte and the public key, the same derivation the account model uses everywhere else.

14.5 Reference Contract Entries

The reference contracts show how an entry authorises a caller in practice. In the Quanta source the name caller is the authenticated account the node writes into the host context window before the entry runs, never a value the client encodes, so an entry that acts on caller acts on the account the node vouched for. The QAsset token and the QNS name registry both lean on this, and the entries below are the real code from the QAsset.qs and QNS.qs reference files.

state {
  owner: Q_Address;
  total_supply: u128;
  balances: Map<Q_Address, u128>;
}

The QAsset state. A balance is a read of the balances map and the supply is a read of total_supply, so neither is an entry.

A balance is not a function a caller invokes. It is a word read out of the balances map at the key the machine derives for a holder, and total_supply is a word read at its own slot, so a reader reconstructs either one from contract storage without an entry and a key that was never written reads as zero.

entry transfer(to: Q_Address, amount: u128)
  writes(balances)
{
  guard amount > 0;
  balances.debit(caller, amount);
  balances.credit(to, amount);
  emit Transferred(caller, to, amount);
}

The transfer entry moves value from the account that sent the call to a recipient. It guards that the amount is above zero, debits caller, credits the recipient, and emits Transferred. Because it debits caller rather than an address in the argument image, a client cannot move value out of an account it does not control, and the authority for the debit is the node filled caller and nothing the client wrote.

entry mint(order: MintOrder signed by owner)
  mints QRC
  writes(total_supply, balances)
{
  total_supply += order.amount;
  balances.credit(order.to, order.amount);
  emit Minted(order.to, order.amount);
}

The mint entry raises the supply and credits a recipient, and it is reached through an order signed by owner rather than a bare call. Here the trusted party is the owner key that signed the order, checked with VerifyMl against the owner ML-DSA-65 public key, so only the owner can mint even though the account that submits the transaction may be someone else.

entry register(label: sealed Q_Name, years: u64, payment: sealed Q_Asset<QTOV>)
  reads(base_3, base_4, base_5_plus, grace_period, auction_duration, reserved)
  writes(owner_of, expiry_of, vault)
  conserves QTOV
{
  guard label.len >= 3;
  guard reserved.get(label) == 0;
  guard expiry_of.get(label) == 0 || now >= expiry_of.get(label) + grace_period + auction_duration;
  guard payment.amount >= (base_3 * (3 / label.len) + base_4 * ((4 / label.len) - (3 / label.len)) + base_5_plus * (1 - (4 / label.len))) * years;
  owner_of.set(label, caller);
  expiry_of.set(label, now + years * 31536000);
  vault.merge(payment);
  emit Registered(label, caller, now + years * 31536000, years);
}

The register entry claims a name for a term of years against a payment. It guards that the label is at least three characters, that the name is not reserved, that any prior registration has lapsed through its grace period and auction, and that the payment covers the length based price for the term, then it records the name under caller, sets the expiry, and merges the payment into the vault. The owner it writes is caller, the account the node vouched for, so a name is claimed by the account that actually paid and no client can register a name in another account's stead.

entry set_resolved(label: Q_Name, target: Q_Address)
  reads(owner_of, expiry_of)
  writes(resolved_of)
{
  guard owner_of.get(label) == caller;
  guard now < expiry_of.get(label);
  resolved_of.set(label, target);
  emit Resolved(label, caller, target);
}

The set_resolved entry points a name at the address it resolves to. It guards that caller is the recorded owner of the label and that the registration has not expired, then it writes the resolution target and emits Resolved. The check reads owner_of for the label and compares it to caller, so only the recorded owner, presented as caller by the node, can repoint a name and a stranger's call fails the guard before any state changes.

QAsset is a Draft standard and its surface is set by this reference contract rather than by a frozen specification, so the entry set and the value widths recorded here will keep maturing toward mainnet. Quantova is on testnet, and the QVM, its container format, the Quanta language, and the native cryptography have not had an external audit. This section describes the design and its intended properties and should not be read as a statement that the design has been independently reviewed.

15. Developer SDK and Code Examples

The Quantova clients are the QCore family, one signing core with a client generated over it for each language, so a signature and a request are built the same way everywhere and no client ever hand rolls the post quantum signing or the gateway wire.

15.1 Packages

15.2 A Signed Transfer

Sign and submit a transfer with QCore.js. The client reads the fee from the gateway and refuses to sign above the ceiling you pass, so an untrusted gateway cannot inflate the fee and drain the signer.

import { Client } from '@quantovainc/qcore';

const q = new Client('http://127.0.0.1:40404');

// one seed derives an account by index, keep the seed and phrase secret
const seed = loadSeed(); // thirty two bytes, or restored from a twenty four word phrase

// sign and submit a transfer of one QTOV, refusing any gateway fee above 500
const result = await q.transfer(seed, 0, 'Q1...', 1000000, 500);
console.log(result); // the transaction id and the accepted or rejected verdict

15.3 Reading Chain State

Read the node info and an account. Every client speaks the same gateway wire covered in the RPC chapter, and reading needs no key.

const info = await q.nodeInfo();          // chain id, head height, fee, version
const account = await q.account('Q1...'); // balance, nonce, scheme, and whether the key is registered

The same calls exist in QCore.rs and QCore.py over the one core, and the qtv terminal client wraps them for the command line. The terminal client and its full command reference live in quantova-cli.

16. Gateway RPC

16.1 The Wire

The gateway is a plain HTTP front door. Every request is a POST to a path of the form /v1/<method> with a flat JSON body, and every response is JSON with no envelope. An empty body is read as an empty object. Wide integers such as a balance are decimal strings, and small numbers such as a height are JSON numbers. The native transport refuses to send a request in plain text to a host that is not loopback, since a fee or a nonce read over an open link would be unauthenticated.

Read the node info. An empty object is a valid body.

curl -s http://127.0.0.1:40404/v1/node_info -d '{}'
# => {"chain_id":"Q-test-net-1","head_height":26841,"fee":{"transfer_quon":"500"},"version":"..."}

16.2 Methods

The methods the gateway answers.

16.3 Examples

Read an account. The address is the only field.

curl -s http://127.0.0.1:40404/v1/get_account -d '{"address":"Q1..."}'
# => {"address":"Q1...","nonce":4,"balance":"12500000","scheme":1,"has_key":true}

Follow a transaction to finality.

curl -s http://127.0.0.1:40404/v1/get_transaction -d '{"tx_id":"QTX1..."}'
# => {"status":"finalised","height":26838,"block":"..."}

The clients in the QCore family build these bodies and parse the responses for you, and the full surface is defined in QSP.

16.4 Method Detail

This section documents each method in full, the exact request body fields it reads and the exact response fields it returns, as the QSP gateway service renders them. A field named here is a field the node emits, nothing is invented. A method that takes no argument reads an empty body or the object {}. The red token marks a method name, as in get_block.

Wide integers travel as decimal strings so no digit is lost in a JSON number. The decimal string fields on this surface are balance, fee, value, the four fields of the fee block, supply_quon, price_micro_usd_per_qtov, governance_locked, and every storage slot value. Word sized quantities travel as JSON numbers. These are height, nonce, meter_limit, scheme, time, every count, and the enumeration codes, and also the validator stake, the reward pool, the treasury, and the staking constants, which the node reports as numbers today. A client parses the string form back into a wide integer.

node_info

The body is empty. The reply carries the chain identity and the current fee schedule.

head

The body is empty. The reply carries the head height, the head block id, and the state root at the head. The block field is null until the chain passes the minimum height.

finalized_head

The body is empty. The reply carries the height finality has reached under the field head.

chain_params

The body is empty. The reply carries the staking and governance constants the node runs under, grouped into a staking object and a governance object. The tracks array holds one entry per governance track.

supply

The body is empty. The reply carries the total supply in Quon as a decimal string.

validators

The body is empty. The reply carries the active validator set. Each entry carries the validator address and its staked weight.

Read the validator set. An empty object is a valid body.

curl -s http://127.0.0.1:40404/v1/validators -d '{}'
# => {"count":7,"validators":[{"address":"Q1...","stake":100000}]}

staking_state

The body is empty. The reply carries the live staking figures, the reward pool, the treasury, the price in micro USD per QTOV, whether mainnet has started, and the total locked under governance.

get_account

The body carries one field, address, a q1 Bech32m string. An address that does not parse is answered 400 with bad_address. The reply carries the account nonce, its balance, its signature scheme code, and whether a public key is registered.

submit_transaction

The body carries one field, tx, the hex of the encoded transaction wrapper. A tx that is not hex is answered 400 with bad_request. Bytes that do not decode into a wrapper are answered as a rejection with the reason malformed. A wrapper that decodes is offered to the mempool and the reply is a verdict. An accepted transaction carries its state, fresh for a newly seen transaction and known for one the pool already held.

The reject reason codes are unknown_sender, unsupported_scheme, bad_signature, bad_nonce, bad_call, self_transfer, meter_limit_too_low, fee_too_low, insufficient_funds, wrong_chain, pool_full, sender_queue_full, rate_limited, and malformed. A bad_nonce rejection also carries the expected and the got nonce.

Submit a signed wrapper as hex. The verdict comes straight back.

curl -s http://127.0.0.1:40404/v1/submit_transaction -d '{"tx":"..."}'
# => {"verdict":"accepted","state":"fresh","tx_id":"QTX1..."}

get_transaction

The body carries one field, tx_id. The reply carries the status of that transaction, one of finalised, pending, or unknown. A finalised transaction also carries its height and its block and the decoded transaction fields. A pending transaction carries the decoded fields with no height. An unknown transaction carries only its identifier and the status.

When the node returns the decoded transaction, whether from get_transaction or pending, it uses the same field shape. from and to are addresses, value and fee are decimal strings, nonce and meter_limit and scheme are numbers, and signature and raw are hex, with raw the full re encoded wrapper.

pending

The body is empty. The reply carries the transactions the mempool is holding, each with its identifier and the decoded transaction fields described under get_transaction.

get_block

The body carries either a height, a number, or a block, a block id string. A body with neither is answered 400 with bad_request, and a height or id with no finalised block is answered 404 with not_found. The reply carries the block header and the identifiers of the transactions it carries.

Read a block by height. A block id in the field block reads the same block.

curl -s http://127.0.0.1:40404/v1/get_block -d '{"height":26838}'
# => {"height":26838,"block":"...","parent":"...","q_root":"...","proposer":"Q1...","time":1753600000,"tx_count":1,"extra_data":"...","tx_ids":["QTX1..."]}

get_container

The body carries one field, address, a q1 string. An address that holds no contract is answered 404 with not_found. The reply carries the container code as hex and its byte length.

get_storage

The body carries one field, address, a q1 string. The reply carries the occupied storage slots of the contract at that address. Each slot carries its 32 byte key as hex and its value as a decimal string.

Read the storage slots of a contract. Each value is a decimal string.

curl -s http://127.0.0.1:40404/v1/get_storage -d '{"address":"Q1..."}'
# => {"address":"Q1...","slots":[{"slot":"...","value":"5"}]}

get_events

The body carries one field, height, a number. A body with no height is answered 400 with bad_request. The reply carries the events recorded at that height, each with the emitting contract, the four byte selector as hex, and the event data as hex.

burn_block

The body carries one field, height, a number. A height with no archived record is answered 404 with not_found. The reply carries the archived block at that height, the raw header bytes as hex, the finality certificate as hex, and the event leaves recorded there as an array of hex leaves. A relayer reads these to prove a bridge burn.

burn_heights_after

The body carries one field, cursor, a number. A body with no cursor is answered 400 with bad_request. The reply carries the archived heights greater than the cursor, which lets a follower walk the archive forward.

17. Running Nodes & Operator RPC

quantovad is the Quantova node daemon. This chapter describes the shape of a node, how to build one from source and run it so that it produces and finalizes blocks under QORUS, and how an operator reaches it through the gateway. Everything here targets the current test network and has not been through the mainnet audit.

A node keeps its own copy of the chain and follows the head as new blocks arrive. Under QORUS a selected committee produces and finalizes blocks, so a node that is chosen takes part in production and finality while a node that is not chosen still checks every block and serves reads. Each node also runs the gateway, the single front door for reads and writes. The daemon serves that gateway over HTTP on a local port, and operators and applications talk to the node only through it.

17.1 Build From Source

A node is assembled from a small set of pinned repositories. Each one is fixed to an exact release so that every operator who builds from the same tags produces the same binary, with no floating dependency deciding what runs. The build uses the Rust toolchain and produces the quantovad daemon.

The node repository opens to the public at the audited mainnet release. The layers underneath it, the QVM that runs containers and the consensus runtime that carries QORUS, are already open, so their behaviour can be built and read today while the node source completes its road to that release.

Build the pinned workspace with the Rust toolchain, which yields the daemon.

# build the pinned node workspace from source
cargo build --release

# the build produces the node daemon, quantovad

17.2 Run a Node

Running quantovad starts a node that joins the network, syncs the chain, and follows the head. When it is selected to the committee under QORUS it produces and finalizes blocks, and at every other time it checks the blocks its peers publish. As the node runs it serves the gateway over HTTP on a local port, and that port is where every query and every submitted transaction arrives.

Start the daemon and it syncs, follows the head, and serves the gateway on a local port.

# run the node daemon
# it syncs, follows the head, and serves the gateway over HTTP on a local port
quantovad

Keep the peer to peer port reachable so the node can sync and take part in consensus. That port is separate from the gateway and carries no operator methods, so it can stay open to peers while the gateway stays private to the operator.

17.3 Operator RPC Configuration

An operator does not reach the node through a private admin channel. Reading a block, reading the state of a container, and submitting a transaction are all gateway methods, and the full method surface with its request and response shapes is described in the RPC chapter. This chapter covers only how to expose that surface safely.

Treat the gateway as an edge surface. Bind it to a local port and place a reverse proxy in front of it before any of it faces the open network. Rate limit the expensive methods, turn off any method a deployment does not need, and never let a public client reach a signing path. A node that only serves reads to the public and a node that also carries operator writes want different exposure, so keep the two behind different front doors.

18. Oracle Integration Guide

The Quantova oracle is the off chain side of the Airlock bridge. It observes a foreign chain and carries only two kinds of artifact across the Airlock to Quantova, an ML-DSA attestation from a distinct signer operator quorum and a hash STARK proof. Classical cryptography stays off chain behind the Airlock, so nothing a quantum adversary could forge crosses onto Quantova. The oracle and its logic live in Q-Oracle, and the light client it reads through is Q-Lightclient.

18.1 Reading Finalized Data

An integration should act only on final blocks. Read the finalized head, then read blocks and events at or below it, so a value that could still reorg never triggers an action.

# the finalized head
curl -s http://127.0.0.1:40404/v1/finalized_head -d '{}'
# => {"finalized_head":26838}

# events in a finalized block
curl -s http://127.0.0.1:40404/v1/get_events -d '{"height":26838}'

18.2 The Airlock Boundary

A foreign observation is verified off chain by the oracle and the light client, then it crosses to Quantova as an ML-DSA attestation, and where a stronger guarantee is needed as a hash STARK that the chain checks. An inbound deposit mints wrapped tokens only under a quorum of distinct operator signers, with the destination chain and the chain id bound into the signed preimage so an attestation cannot replay on another network.

The exit path is gated off by default and the whole bridge is a design under review, not audited and not live. The full design is in the Airlock chapter and its proposal, and the code that carries it is in Q-Oracle.

19. Chain Specifications

A quick reference for the network parameters of Quantova, covering identity, consensus, signatures, execution, and fees. Values that are fixed at genesis are noted here and given their full treatment in the chapter they belong to. Quantova runs on a testnet and external audits of the protocol and its cryptography are still ahead.

19.1 Network Identity

19.2 Consensus and Cryptography

19.3 Execution and Fees

The consensus parameters are documented in the QORUS proposal, and the account and transaction formats in their proposals, in QIP.

20. FAQ

Do Quantova addresses really start with Q

Yes, by design. Every Quantova address is a Q1 bech32m string. The human readable part is the letter Q, and the encoder writes the separator 1 after it, so every valid address reads as Q1 followed by its data and a checksum. The address is the hash of the account scheme byte and the public key, and its case does not change a signature.

Why post quantum signatures

A chain is a permanent record. A classical public key exposed on it today can be recovered by a quantum adversary later, who harvests the data now and breaks it once the hardware exists. Quantova signs every account and every validator with ML-DSA-65 under FIPS 204 from genesis, so there is no classical key to harvest and no migration to time.

Does Quantova use a VRF

Yes. Quantova ships the first post quantum VRF in the world, built entirely on NIST approved primitives, ML-DSA-65 and SHA-3. It seeds committee sortition in QORUS, and its output is verifiable so a proposer cannot fake its way into a committee. The function lives in QVRF.

Is there a superuser or admin key

No. There is no sudo, no admin, and no root key anywhere. Governance is the top authority from genesis, and every privileged change flows through an on chain vote on its track.

Is Quantova a fork

No. Quantova is a sovereign chain built from scratch, with its own consensus QORUS, its own virtual machine the QVM, its own language Quanta, and its own post quantum cryptography. It inherits no code or design from another network.

How are contracts written

Contracts are written in the Quanta language and compiled to QVM containers. They are post quantum resistant because the signing and verification they rely on use ML-DSA-65 and the hashing uses SHA-3 as native QVM instructions, with no classical primitive in the contract path.

Is the supply fixed

The reward model is an emergent staking yield rather than a fixed disinflation schedule. A per session emission is shared across stake, a portion of every fee is burned, and the rest routes to the proposer and to grants. The exact emission rate is a pinned governance value.

21. Cryptography

Quantova is post quantum end to end. Every primitive on the trust path is a NIST standard or is built directly on one, so a signature, a consensus vote, a random draw, and a hash all stand against a classical and a quantum adversary. There is no classical public key primitive anywhere an attacker could reach, and there is no fallback to elliptic curve cryptography.

This chapter is written for developers who integrate against the chain and for institutions and governments that need to know exactly what secures it. The implementation lives in Q-Crypto, and the post quantum random function in QVRF.

21.1 The NIST Family Quantova Uses

Quantova builds only on the finalized NIST post quantum standards for the parts that carry authority, and pairs them with a standard authenticated channel for transport.

ML-DSA-65 is the default account scheme from genesis. SLH-DSA and FN-DSA are reserved scheme identifiers, held for the day a deployment wants a hash based or lattice alternative, and gated until that use is settled. FN-DSA is not standardized yet, so Quantova does not run it as a live scheme.

21.2 Post Quantum End to End

Many networks that describe themselves as quantum resistant secure only one layer, a signature or a state proof, and leave a classical primitive in consensus or in a fallback path. Quantova removes every one of those.

Transaction authority is ML-DSA-65. Consensus authority is ML-DSA-65, since QORUS finalizes each block with an aggregated certificate of committee signatures. The random function that draws each committee is post quantum, built on ML-DSA-65 and SHA-3. Addresses, the state trie, and every proof are SHA-3. The node to node channel is keyed with ML-KEM-768. No elliptic curve key, and no classical public key primitive, sits anywhere in signing, voting, finality, randomness, or state.

21.3 The First Post Quantum VRF

A verifiable random function lets the chain draw an unpredictable value that anyone can then check was produced correctly. Classical chains build this on elliptic curve cryptography, which a quantum adversary could break, letting an attacker grind or predict the draw and so influence who holds authority. Quantova ships the first post quantum VRF in the world, built entirely on NIST approved primitives, ML-DSA-65 under FIPS 204 and SHA-3 under FIPS 202.

The draw seeds committee sortition in QORUS, and its output is verifiable, so any node confirms the draw was correct from the chain carried seed and a proposer cannot fake its way into a committee. Selection stays unpredictable and checkable against both a classical and a quantum adversary. The function lives in QVRF.

21.4 Why This Matters

A quantum computer able to run Shor's algorithm at scale breaks the elliptic curve and RSA cryptography that secures almost every chain today. The threat is not only future. An adversary can harvest signed and encrypted data now and break it later once the hardware exists, so any value or identity that must survive the coming decade needs post quantum protection from the start rather than a migration under pressure.

Quantova is designed for that requirement. Because the authority path is post quantum from genesis with no classical fallback, an institution or a government can rely on the network without planning a cryptographic migration and without trusting that a fallback will never be reached. The standards it uses are the ones NIST has finalized, so the assurance rests on public, reviewed cryptography rather than a private design.

Quantova is on testnet and has not completed an external security audit. This chapter describes the design and the standards it is built on, and the cryptographic implementation is open for review in Q-Crypto.

22. The Open Source Stack

Quantova is built as a set of focused repositories rather than one monolith, and the chain side is open for review. Each layer is its own repository with a single job, and the node pins the exact tagged version of the components it runs, so a build is reproducible and every reviewer sees the same code the network runs. This chapter maps the stack so a developer, an auditor, or a government reviewer can go straight to the source for any part of the system.

22.1 How the Stack Is Pinned

The virtual machine and the consensus engine are the two components whose exact behavior must never drift, so the node pins each to a specific tagged release and builds against that tag, not a moving branch. The Quanta compiler builds against the same pinned virtual machine, so a container the compiler produces runs in the node interpreter with no version mismatch. The client core is pinned the same way, so a signature a wallet builds is the signature the node verifies. Pinning is what lets the whole stack be split across repositories while staying one coherent system.

22.2 The Repositories

The chain side of the stack, grouped by layer.

22.3 The Node and the Bridge

The node that ties the pinned components together and the trustless bridge are the last pieces to open. They carry the running network and its custody logic, so they open at the audited mainnet release rather than before it. Until then the components they are built on, the consensus, the virtual machine, the cryptography, and the light client, are already open for review in the repositories above.

Quantova is on testnet and has not completed an external security audit, so treat every repository as pre audit. The proposals in QIP track what is Final, what is still Draft, and the path to mainnet.

22.4 What Each Repository Contains

The table above says what each repository is for. This subsection goes one level deeper and names the crates, modules, and functions inside each one, so a developer knows the shape of the code before opening it. Everything here is at testnet and pre audit, so read a module as a reference build rather than a settled one.

QRC-CONSENSUS is a workspace of four crates. qtv-bft is the byzantine fault tolerant core, a deterministic state machine that decides one block per height and exposes an equivocating signer as a slashable set. qtv-sampler draws the committee and the leader by the one time key sortition, a SHAKE256 draw over a committed preimage, the beacon seed, and the slot, stake weighted against a committee budget so the work to finalize stays flat in the validator count. qtv-attest is the attestation and finality certificate layer, where each attestation binds the height, the slot, the block, the sortition credential, and an ML-DSA signature, and a certificate forms once distinct verified signers clear the two thirds quorum. qtv-sim is a deterministic round simulator with the cryptography abstracted away, and a folding certificate lives in qtv-attest as an experiment that is not on the finality path.

QVM is the qtv-vm crate. isa defines the opcodes and their fixed byte encoding, interp is the metered interpreter with its fault and rollback model, state holds the sixteen registers, the 64 KiB scratch memory, and the bounded stack, and the meter is the fixed cost schedule. container is the bytecode container and its SHA3-256 identifier, carrying the code, the constant pool, and the state access manifest each entry declares. crypto is the native post quantum opcode group, HASH over SHA3-256, VERIFY_ML for ML-DSA-65, VERIFY_SLH for SLH-DSA, KEM for ML-KEM-768, and MERKLE_VERIFY for a SHA3-256 authentication path, and asm is a small assembler for test programs. A separate fuzz target feeds random bytes and random programs to the decoder and interpreter under a fixed meter bound.

Q-Crypto is a single crate whose src holds one file per primitive. sha3 is the Keccak sponge with SHA3-256, SHA3-512, SHAKE128, and SHAKE256, written first because everything else builds on it. ml_dsa is ML-DSA-65 from FIPS 204, the primary signature, ml_kem is ML-KEM-768 from FIPS 203 for the transport key exchange, and slh_dsa is SLH-DSA-SHAKE-192s from FIPS 205, the hash based alternative. chacha20poly1305 is the one symmetric AEAD the crypto policy permits, and zeroize wipes secret material. fn_dsa is present behind a feature flag and stays off until FIPS 206 is final. Every scheme is checked against the official NIST vectors committed under vectors.

QVRF is the qtv-vrf crate, one interface with three operations, one to produce the output, one to produce the proof, and one to verify an output and proof against an input. The hash based construction is implemented, squeezing SHAKE256 over the deterministic SLH-DSA signature of the input and returning that signature as the proof, with uniqueness following from deterministic signing. The lattice based construction stands behind the same interface over an ML-DSA signature and returns a pending error until its logic lands. The primitives arrive from Q-Crypto and are never reimplemented here.

q-prover is the qtv-stark crate, the hash based STARK backend. It carries arithmetic over the Goldilocks prime with a number theoretic transform, Merkle commitments over SHA-3, the FRI low degree test folded against a SHA-3 transcript, and an AIR constraint framework. On top of the backend it arithmetizes the ML-DSA-65 verify relation into gadgets, the Qudros SHA-3 permutation, the modular multiplication over the signature modulus, the response norm range check, the bit decomposition and hint recovery, and the sampling steps. The entry module wraps a fused certificate as prove_batch and verify_batch over a public message, and a second arithmetization proves a signature is the canonical one with the randomizer fixed at zero, which is what gives the sortition draw its grinding resistance.

Q-Lightclient is the embedded verification core a wallet or the QCore family carries so it can read the chain without a full node. It follows Quantova headers, refusing any header whose attestation is not the module lattice scheme, checks membership under a trusted header with SHA-3 Merkle inclusion and state proofs, the header sync and SPV style verification a light client rests on, and carries the verifier side of the hash based STARK certificate from q-prover. The workspace crates are qlc-core, the corridor verification framework with the hash only header follow state machine and the verification tier ratchet, qlc-stark, the canonical hash only statement a verification proves, qlc-registry, the corridor and asset registry that resolves each network to a verification tier and a finality config with a confirmation depth and a reorg depth, and qlc-airlock, the ingress grammar that parses only an ML-DSA attestation and a hash STARK and makes every foreign artifact unparseable.

Quanta-Smart-Contract-language is a Rust workspace that compiles a .qs source file to a QVM container. quanta-lexer turns source into tokens and holds the forbidden foreign identifier list, quanta-ast defines the syntax tree, and quanta-parser builds it with position accurate errors. quanta-typeck is the static checker and its passes, resolve, types, linear, signature, conserve, access, and sealed, which is where reentrancy, unchecked overflow, forged authority, infinite mint, dropped value, and front running become compile errors. quanta-codegen lowers a checked contract to QVM bytecode and packs the container, and quanta-emit produces the one JSON document that carries the container bytes and the interface. quanta-cli is the command line front end with parse, fmt, tokens, check, build, and emit, and quanta-web runs the whole compiler in the browser page so the container the editor shows matches the command line byte for byte.

QCore.rs is the one Rust client core, a src of a handful of files. lib.rs holds the key derivation, a per account seed grown with SHAKE256 over the master seed, the scheme byte, and the account index, the ML-DSA-65 signing, the transaction body assembly, and the address rendering as the Q1 Bech32m string over the SHA3-256 of the scheme byte and the full public key. json is the custom codec for the gateway body, http is the loopback transport under the client feature, and contract carries the payable call signing. The bin directory builds a small qcore terminal client over the same core, and the fee cap that refuses a gateway fee above a caller chosen ceiling lives in the Client rather than the raw signing functions.

QCore.js and QCore.py are the same core in two other languages, QCore.js compiled to WebAssembly for the browser and Node and published on npm as @quantovainc/qcore, and QCore.py built as a native extension with pyo3 that imports as qcore. Neither rewrites the signing. Both expose the Client with the fee cap and the amount guard that keeps a value off a JavaScript number, the core address and signing functions, and signPayableCall for a call that also moves value under an explicit chain id, and both ship the frozen conformance vectors they check their binding against byte for byte.

quantova-cli is the qtv binary, a thin layer over QCore.rs in a single main. The commands cover the whole path on a fresh chain, qtv key new, address, pubkey, and restore for offline account work, qtv account, register, send, info, and tx for balances and transfers, and qtv contract deploy, contract call, contract storage, and events for a Quanta container. A max fee flag refuses to sign when the gateway reported fee is above the ceiling, and a docs folder carries the detail behind accounts, transactions, contracts, and the gateway wire.

QSP holds the Quantova standards process rather than running code, the proposal templates, the accepted standards, and the transition rules. Its one guarded track is the crypto transition track, the only path that can add or retire an approved cryptographic scheme or set a key rotation window, and it carries two hard rules, that a proposal on it is invalid without an external cryptanalysis report and that it can never introduce a classical primitive. It mirrors the same one way door enforced on chain by the QONCORD governance, and the frozen algorithm set it defends lives in POLICY-crypto in Quantova-Specs.

Q-Primitives is the catalog of the Q types the Quanta language and the QVM share, with the normative definitions in SPEC-primitives. Q_Address names an account or a contract in the Q1 format, Q_Sig binds a signed message to its signer and exists only through a real ML-DSA verification, and Q_Asset carries an amount of a declared kind and is linear so it must be used exactly once. Q_Commit binds a hidden value to a public SHA3 digest, Q_Rand is a verified output of the verifiable random function, Q_Sealed is confidential in the mempool under ML-KEM until execution, and Q_Key holds a public key with its scheme byte. Each type can be produced only in its one sanctioned way, which is what makes a forged authority or a conjured balance impossible to write.

Quantova-Conformance is the frozen cross repo vectors and the runner that reproduces them. vectors holds the positive cases that fix the wire, the canonical codec for u32, u64, u128, byte strings, and Option, the address derivation, the transfer body and its transaction identifier, the scheme hash, and the identifier families, and a hostile directory holds the cases the reference must refuse. The runner replays every vector against the reference crates pinned by tag, confirming a positive vector recomputes byte for byte and a hostile one, a hex hash shaped like a foreign chain address or a classical digest, is refused. It is what keeps the machine, the language, the SDK, and the node on one format.

Quantova-Specs holds the normative specifications and the crypto policy the rest of the stack is built against. POLICY-crypto is the supreme law that names the one algorithm family and outranks every other document, POLICY-disclosure governs the order repositories go public, and the SPEC files cover the stack end to end, SPEC-accounts, SPEC-codec, SPEC-transactions, SPEC-blocks, and SPEC-state for the ledger, SPEC-isa, SPEC-container, SPEC-cid, and SPEC-lowering for execution, SPEC-consensus-qorus, SPEC-sortition-onetime, and SPEC-vrf for consensus and randomness, and SPEC-rpc, SPEC-gateway, SPEC-qns, SPEC-economics, and SPEC-governance for the services, the asset, and QONCORD. PARAMETERS collects every chain constant in one place and PRIVILEGED-AUTHORITY names every special address and power.

QIP is the Quantova Improvement Proposals and the public roadmap. ROADMAP records where the chain is and the path to mainnet, qip-1 defines what a QIP is and how the process works, and qip-template is the template a new proposal uses. The Final core proposals are qip-2 QORUS consensus, qip-3 accounts and addresses, qip-4 the transaction format and signature envelope, qip-6 the QVM container format and contract ABI, and qip-8 on chain governance and forkless upgrades. qip-10 the Airlock trustless bridge is in Review, qip-5 gateway RPC is a Living interface standard, and qip-7 the QAsset token standard and qip-9 the QNS name service are Draft.

Licensing, Intellectual Property and Copyright

This section is the authoritative licensing overview for the Quantova technology stack. It covers the software, specifications, and documentation developed and maintained by Quantova Inc., and applies to all associated materials unless explicitly stated otherwise.

Copyright and Ownership

Copyright 2026 Quantova Inc. Quantova Inc. is the legal owner and steward of the Quantova protocol, the QAsset and QCollectible standards, the Quantova Virtual Machine, the QORUS consensus, the post quantum cryptography, and the associated research, specifications, and reference implementations.

The License, Apache-2.0 or MIT

Unless otherwise stated, all Quantova protocol code, including the consensus and finality logic, the runtime and state transition code, the Quantova Virtual Machine, the networking and node implementation, and the post quantum cryptographic integrations, is dual licensed under the Apache License 2.0 or the MIT license, at your option. The full texts are included in each repository as LICENSE-APACHE and LICENSE-MIT, alongside the NOTICE and AUTHORS files.

The permissive license places no field of use restriction on the code. You may run it, fork it, modify it, audit it, and build on it, subject only to keeping the license notice and the Quantova Inc copyright intact.

Validator and Node Operator Clarification

Running a validator node or a full node on the Quantova network is permitted. Participation in staking, consensus, block production, and transaction processing creates no additional licensing obligation, since the license is permissive. Validators, node operators, exchanges, custodians, and infrastructure providers may operate freely under the Apache-2.0 or MIT terms.

Canonical Network Definition

For identity purposes, the canonical Quantova network is defined by the official signed source releases published by Quantova Inc., a unique post quantum genesis hash, signed runtime and protocol artifacts, and post quantum signatures under ML-DSA-65. A deployment that does not match these identifiers is a separate network and is not the Quantova network. Protocol identity is anchored at genesis by an immutable on chain commitment.

Documentation, Third Party Software, and Disclaimers

Documentation, research materials, and protocol specifications are licensed under Apache-2.0 or MIT, at your option, unless explicitly stated otherwise within the relevant file or directory, and are provided for informational and technical reference, reflecting protocol behavior enforced by code.

This repository may include or depend on third party open source software. Such components remain subject to their original licenses, with notices provided in the dependency manifests.

Trademarks. Quantova, the Quantova logo, QTOV, QVM, QNS, and the Q address brand are trademarks of Quantova Inc. The trademarks are not licensed under Apache-2.0, MIT, or any third party software license and remain the property of Quantova Inc.

No legal, financial, or regulatory advice. Nothing in this repository, including the documentation and specifications, constitutes legal, financial, or regulatory advice. Operators, validators, and users are responsible for compliance with the laws and regulations of their jurisdictions. Licensing, institutional, and regulatory inquiries should be directed through the official Quantova channels published by Quantova Inc.

Quantova Developer Documentation, Version 1.0, Copyright 2026 Quantova Inc. Protocol code and documentation licensed under Apache-2.0 or MIT. Quantova and QTOV are trademarks of Quantova Inc.