QNet: Post-quantum Layer-1 in Rust using native ML-DSA-65 signatures QNet Blockchain has published details of a post-quantum layer-1 blockchain in which every consensus vote, block signature, node identity and transaction is authenticated with ML-DSA-65 (CRYSTALS-Dilithium3, FIPS 204), using 1952-byte public keys and 3309-byte signatures. The protocol pairs a single elected producer streaming microblocks on a fixed one-second slot, rotating every 30 blocks, with a Checkpoint-BFT committee that certifies a finality checkpoint every 30 microblocks and seals a macroblock every 90, with a committee size of 1000 and quorum of n - floor((n-1)/3). The project labels itself pre-launch and experimental, warning that parameters such as CHECKPOINT_INTERVAL, COMMITTEE_SIZE and VIEW_TIMEOUT_MS are compile-time constants requiring a full network rebuild and relaunch to change, and that chain resets should be expected. QNet Blockchain is a post-quantum layer-1 blockchain. Every consensus vote, block signature, node identity and transaction on the chain is authenticated with ML-DSA-65 CRYSTALS-Dilithium3, FIPS 204 . The external Solana burn credential presented at node activation is verified with its own native Ed25519 signature. Blocks are produced in two tiers — a single elected producer streams microblocks on a fixed one-second slot and rotates every 30 blocks, while a Checkpoint-BFT committee certifies a finality checkpoint every 30 blocks and seals a macroblock every 90 — so irreversibility comes from an explicit quorum certificate rather than block depth. The protocol defines two node types: Super nodes, which participate in consensus and serve the network's HTTP/RPC surface, and Light nodes, which are mobile clients that store no chain data. Node participation is paid for by proof of burn, and consensus reputation is binary 70 or 0, dropping to 0 only on a cryptographically proven equivocation . Pre-launch and experimental. The software is under active development. Consensus and economic parameters such as CHECKPOINT INTERVAL , COMMITTEE SIZE and VIEW TIMEOUT MS are compile-time constants rather than operator settings, so changing any of them means rebuilding and relaunching the whole network. Expect chain resets during this period, and run nodes, hold value and deploy contracts at your own risk. See SECURITY.md https://github.com/AIQnetLab/QNet-Blockchain/blob/master/SECURITY.md for how to report a vulnerability. | Property | Value | |---|---| | Signature scheme | ML-DSA-65 / CRYSTALS-Dilithium3 FIPS 204 — 1952-byte public key, 3309-byte signature | | Hash function | SHA3-256 domain-separated per structure | | Address format | 45 ASCII chars: 19 lowercase hex, the literal eon , 15 hex, 8-hex checksum | | Microblock slot | MICROBLOCK INTERVAL SECS = 1 ; a block's timestamp is its parent's plus 1 s, or after a halt a declared gap of at least SLOT GAP MIN SECS = 90 s that verifiers refuse if it runs more than SLOT GAP FUTURE TOLERANCE SECS = 30 s ahead of their own clock; below height SLOT GAP REANCHOR GATE HEIGHT = 1 339 200 it is exactly genesis ts + height x 1s | | Producer rotation | ROTATION INTERVAL BLOCKS = 30 ; leader is a public, deterministic SHA3-256 selection over the roster of macroblock N-2 | | Macroblock / epoch | MACROBLOCK INTERVAL = 90 microblocks 3 producer rotations per window | | Finality | Checkpoint-BFT quorum certificates at CHECKPOINT INTERVAL = 30 microblocks, 2-chain commit rule | | Quorum | quorum size n = n - floor n-1 /3 , equal to 2f+1 when n = 3f+1 | | Committee | COMMITTEE SIZE = COMMITTEE THRESHOLD = 1000 , sampled from the eligible-producer set of macroblock N-2 | | Producer failover | Signed timeout votes forming an n-f timeout certificate; MAX FAILOVER ROUND = 50 | | Node types | Light , Super | | Reputation | Binary {70.0, 0.0} ; INITIAL REPUTATION = MIN CONSENSUS REPUTATION = 70.0 | | State model | Account-based, committed in a state merkle root; RocksDB persistence | | Native token | QNC, 9 decimals; MAX QNC SUPPLY = 4 294 967 296 QNC 2^32 ; genesis supply 0, no premine. The public testnet's genesis also funds 50,000 load-test accounts with 1,000 QNC each, whose keys derive from a public seed; that balance is outside total supply , and the explorer lists it apart | | Emission | One emission every EMISSION BLOCK INTERVAL = 14 400 microblocks, split 25% operators / 75% light nodes when both cohorts are non-empty; when either cohort is empty the other receives the whole emission. Rewards are pull-only via signed claims | | Transaction fees | Credited in full to the block producer's registered wallet | | Smart contracts | WASM contracts execute on the apply path in the deterministic qnet-vm interpreter fuel-metered, float-free , so contract state is part of the state root. QRC-20 and QRC-721 are native transaction arms in the state crate | | P2P transport | QUIC over TLS 1.3 on the aws-lc-rs provider. Peer identity is proved by an ML-DSA-65 signature bound to the session through exported keying material; the negotiated key-exchange group is the provider default. Block fetch, peer authentication and health probes run over HTTP/TCP | | | Super | Light | |---|---|---| | Consensus | Produces microblocks, votes in Checkpoint-BFT, votes in producer failover | Wallet and reward client only | | Consensus key | Publishes a 1952-byte ML-DSA-65 vrf pk in its on-chain registration row | None | | Chain data | Stores and serves chain state, and may take on archival duty | Stores no blocks, headers or state | | Producer eligibility | From ACTIVATION WARMUP BLOCKS = 180 blocks past its registration height; genesis identities are eligible immediately | Not applicable | | Reward eligibility | On-chain heartbeat subwindow popcount = 9 for the epoch and never banned; from the super reward admission gate also in the epoch's consensus-admitted set | Per-epoch eligibility bitmaps published on chain by genesis nodes | | Where it runs | Servers and desktops, via Docker | A phone or tablet, inside QNet Wallet; one device per Light node, which passes the system's device check | | Registration | Created server-side by the node itself | Submitted by the aiqnet.io node cabinet or the browser extension; the wallet signs its consent in QNet Wallet or the extension | Five pinned genesis identities genesis node 001 through genesis node 005 form the consensus committee at network start, and the committee is sampled from the on-chain roster thereafter. A node is registered on QNet Blockchain after its owner pays the network's entry cost. Two phases exist. In Phase 1 the payment is a burn of the external 1DEV token on Solana; the price is identical for both node types and falls as more of the 1DEV supply is burned, following max 1500 - 150 x floor burn% / 10 , 300 whole 1DEV. In Phase 2 the payment is QNC transferred on-chain rather than burned, with base costs of 10,000 QNC for a Light node and 7,500 QNC for a Super node before a network-size multiplier. The transition happens when 90% of the 1DEV supply has been burned or five years have passed since the genesis block, whichever comes first; Phase 1 is the active path today. The Phase 1 burn is made in one of two places, with one activation per wallet: the QNet Wallet browser extension burns with the wallet's own key, from its Activate tab or when the node cabinet at aiqnet.io/node asks it qnet activateNode ; and the node cabinet itself, in a phone's or a computer's browser, burns with a one-time payment key it creates in the page, whose activation code names the wallet the burn is for. That payment key burns for a Light node only, once QNet Wallet has signed the wallet's reservation; a Super node is activated only in the extension. QNet Wallet on a phone or tablet signs the wallet's consent to the registration and links the node to its device, on a sheet a verified link.aiqnet.io link opens QNet Link https://github.com/AIQnetLab/QNet-Blockchain/blob/master/docs/protocols/qnet-link-v1.md section 14 . A burn yields an activation code. A Super node's server takes the code with the burn transaction and amount; a Light node needs no code of its own: its registration carries the burn, the wallet's consent and the owner bind, and its code is only a receipt. Every burn is cryptographically bound to one node identity and re-verified by every node that validates a block carrying it. See docs/economics/node-activation.md https://github.com/AIQnetLab/QNet-Blockchain/blob/master/docs/economics/node-activation.md . | Path | Contents | |---|---| | core/ | Rust workspace crates: qnet-consensus Checkpoint-BFT, reputation , qnet-state accounts, blocks, transactions, storage model , qnet-mempool , qnet-core crypto primitives, merkle , qnet-vm deterministic WASM interpreter used for contract execution, plus its deploy-time determinism validator | | development/ | The production node and developer tooling: qnet-integration the Rust node binary, P2P, RPC, block pipeline, storage , qnet-contracts , qnet-sdk , qnet-proto , qnet-loadtest , qnet-security , Dockerfiles | | applications/ | Client applications, licensed Apache-2.0: qnet-mobile mobile wallet and Light node , qnet-wallet browser extension , qnet-explorer , qnet-cli | | infrastructure/ | nginx and configuration templates | | deployment/ | Deployment scripts and environment templates | | monitoring/ | Prometheus scrape configuration | | audit/ | Rust audit test-suite crate storage, reputation, consensus, activation security | | governance/ | DAO design material | | testing/ | Standalone test material outside the Cargo workspace | | scripts/ | Node install and helper scripts | | docs/ | The documentation set indexed below | Full prerequisites, activation, firewall rules, key handling and migration are in docs/operators/running-a-node.md https://github.com/AIQnetLab/QNet-Blockchain/blob/master/docs/operators/running-a-node.md . The minimal Super-node invocation, from the repository root: docker build -f development/qnet-integration/Dockerfile.production -t qnet-production . printf %s "