PQCBlockchain is a post-quantum-oriented, object-state Proof-of-Stake blockchain designed as a secure settlement layer for financial applications, AI-agent transactions, and heterogeneous Layer 2 networks.
The project is not an Ethereum clone with a different signature algorithm. Its protocol is designed around large post-quantum signatures, explicit object access, deterministic parallel execution, cryptographic agility, validator key separation, and L2-first scaling.
Development status: the core architecture and protocol decisions are complete enough to begin implementation, local development networks, and public testnet work. The protocol is not mainnet-ready. Mainnet requires the testing, audit, performance, committee-scaling, and randomness-security gates described below.
PQCBlockchain aims to provide long-lived settlement infrastructure for:
- post-quantum-secure payments and custody;
- stablecoins, tokenized deposits, real-world assets, bonds, and funds;
- regulated markets with optional application-level compliance;
- cross-border and institutional settlement;
- AI-agent payments, procurement, subscriptions, and market activity;
- ZK, Optimistic, Validium, Sovereign, and permissioned L2 networks;
- cross-L2 messaging and high-throughput financial applications.
The L1 remains a neutral settlement and data-commitment layer. Compliance, credential, privacy, and market policies belong to assets, applications, bridges, or L2 systems rather than being imposed globally by base consensus.
- No Proof of Work. PQCBlockchain uses PoS in every environment. It never falls back to PoW during genesis, testing, network degradation, or recovery.
- BFT safety is never weakened for liveness. A block requires a strict greater-than-two-thirds committee Precommit quorum.
- Fixed self-bond and equal seats. One ValidatorId requires 100,000 PQC and receives one selection ticket, one committee vote, and one governance vote. Extra stake on the same ValidatorId adds no weight.
- Objective punishment. Availability penalties require quorum-certified protocol evidence. Malicious-signing slashes require canonical cryptographic evidence.
- Unrelated assets are never confiscated. Slashing is limited to validator self-bond and validator rewards.
- Supply is auditable. Genesis allocation, minting, fees, burns, staking, penalties, and withdrawals are consensus-visible state transitions.
- Finalized history is immutable. Governance and emergency recovery cannot rewrite finalized blocks, balances, or supply history.
flowchart TB
Wallets[Wallets / AI agents / institutions] --> RPC[RPC and indexers]
RPC --> TX[Transaction validation and Mempool]
TX --> EX[Deterministic native executor]
EX --> OBJ[Object state and Sparse Merkle Tree]
OBJ --> BFT[Slot BFT consensus]
VAL[Eligible validators] --> COM[Epoch committee]
COM --> BFT
BFT --> FIN[Finalized L1 blocks]
FIN --> GOV[Staking / governance / upgrades]
FIN --> L2[L2 settlement / DA / proofs / exits]
L2 --> ZK[ZK Rollups]
L2 --> OP[Optimistic Rollups]
L2 --> EXT[Validium / Sovereign / Permissioned L2]
The core implementation is divided into these consensus-sensitive subsystems:
- protocol identifiers, canonical codec, and cryptographic suite;
- accounts, keys, native coins, transactions, gas, and receipts;
- object storage, state commitment, snapshots, and proofs;
- validator lifecycle, self-bond, rewards, penalties, exit, and withdrawal;
- Slot BFT, timeout certificates, randomness, and committee transitions;
- issuance, fee burning, supply accounting, governance, and upgrades;
- P2P networking, synchronization, RPC, and observability;
- L2 registration, escrow, proof verification, DA, forced inclusion, and exits.
PQCBlockchain uses Tendermint-style Propose, Prevote, Precommit, and locking rules. Non-committee Full Nodes independently execute and verify blocks but do not vote.
| Parameter | Protocol decision |
|---|---|
| Slot duration | 6 seconds |
| Epoch duration | 600 Slots, approximately 1 hour |
| Maximum optional skipped Slots | 99 |
| Mandatory heartbeat | At least one block every 100 Slots / 10 minutes |
| Genesis committee | 32 validators |
| Genesis finality quorum | 22 of 32 |
| Permissionless committee target | 128 validators |
| Permissionless finality quorum | 86 of 128 |
| Proposer rotation | Every Slot and retry Round |
| Committee rotation | At finalized ConsensusEpoch transition |
Slot, BlockHeight, ScheduledEpoch, ConsensusEpoch, and
RewardedBlockIndex are distinct:
- Slot advances on the six-second schedule;
- BlockHeight advances only when a block finalizes;
- ScheduledEpoch is derived from Slot;
- ConsensusEpoch changes only after the old committee finalizes a transition checkpoint;
- RewardedBlockIndex advances only for reward-eligible finalized blocks.
Crossing an Epoch time boundary does not automatically change authority. If the transition checkpoint is delayed, the old committee remains authoritative and continues safe BFT retries.
Formal genesis contains at least 32 predeclared validators and an explicit 32-member committee. Genesis PQC assigned to validators is deposited directly into bonded stake and cannot simultaneously exist as liquid balance.
New operators may register and bond already-issued PQC. Before the permissionless scaling upgrade, qualified public registrations remain Pending and cannot influence the trusted 32-member bootstrap lottery or governance. Once at least 128 qualified validators and all release gates are satisfied, a finalized upgrade atomically:
- activates the qualified pending validators;
- fixes the eligible-set snapshot;
- enables the 128-member committee format;
- selects the first permissionless committee;
- changes finality to 86-of-128 and the certificate limit to 512 KiB.
Each ValidatorId locks at least 100,000 PQC. Additional bond does not increase committee probability, reward weight, or governance power.
Register and bond
-> Pending
-> activation delay and finalized Epoch transition
-> Eligible
-> optional committee selection
-> exit request
-> 7-day eligibility delay
-> Unbonding
-> 30-day unbonding delay
-> Withdrawable
-> explicit withdrawal
Activation waits at least 32 finalized blocks and an Epoch boundary. Voluntary exit is processed in canonical request order and may become effective only when the remaining eligible set is at least both:
- 64 validators; and
- the size required to form the next committee.
Validator lifecycle is represented separately from flags such as current committee membership, pending exit, under-bonding, Jail, evidence suspension, and emergency pause. A flag never silently changes the current Epoch quorum.
| Event | Consequence |
|---|---|
| Missed required proposal | No reward and 3 PQC burned |
| Missed required Precommit duty | No reward and 1 PQC burned |
| Three consecutive certified missed duties | Temporary Jail |
| Randomness commitment not revealed | 100 PQC burned, minimum two-Epoch Jail, repeat-offence exclusion |
| Proven equivocation or conflicting finality signing | Tombstone and 100% validator self-bond/reward slash |
A missed duty is punishable only through a quorum-signed TimeoutCertificate or certified participation transcript. Nil votes permitted by the BFT state machine count as participation. A validator can receive at most one proposer and one vote availability penalty per Slot, regardless of retry Round count.
Ordinary penalties and slashes are burned. They do not change scheduled issuance, the RewardedBlockIndex, or reduction intervals. Correlated network failure cannot automatically mass-trigger three-strike Jail, but it never lowers quorum.
| Parameter | Value |
|---|---|
| Symbol | PQC |
| Decimal places | 16 |
| Genesis supply | 64,000,000 PQC |
| Immutable cumulative mint cap | 1,000,000,000 PQC |
| Initial maximum block issuance | 6 PQC |
| Reduction interval | 50,000,000 rewarded blocks |
| Reduction amount | 1 PQC |
The scheduled issuance stages are 6, 5, 4, 3, 2, 1, and finally 0 PQC per rewarded block. Skipped Slots produce no reward and do not advance RewardedBlockIndex. Transaction blocks and mandatory heartbeat blocks are reward-eligible.
For committee size C, the reward denominator is C + 2:
proposer weight = 3
each other successful Precommit signer weight = 1
total full-participation weight = C + 2
Missing shares and atomic rounding remainder are not minted or redistributed. Base fees, availability penalties, and slashes are burned. Burns reduce current supply but never reduce CumulativeMinted or reopen mint capacity.
Every supply change produces a canonical SupplyDeltaReceipt and satisfies:
CurrentSupplyAfter = CurrentSupplyBefore + ActualMinted - AuthorizedBurns
CumulativeMintedAfter = CumulativeMintedBefore + ActualMinted
The state model combines stable accounts with explicitly versioned objects:
- AccountId remains stable across key rotation and recovery;
- ObjectId is derived from immutable genesis or transaction origin and is never reused;
- transactions declare read, write, destroy, and output objects before signing;
- explicit ObjectRef versions reject stale inputs deterministically;
- sequential and legal parallel execution must produce identical receipts and StateRoot;
- floating-point values are forbidden from consensus data and arithmetic.
Transaction v1 uses sequential account nonces, explicit validity heights, a native PQC fee CoinObject, EIP-1559-style base and priority fees, and ML-DSA-65 authentication. The base fee is burned; priority fees are split between the successful Proposer and finalizing Precommit signers.
Protocol hashes use SHA3-256 with immutable ASCII domain separation. Consensus data uses a custom fixed canonical codec, never JSON, Protobuf, language struct layout, or implementation-specific serialization.
| Purpose | Protocol v1 algorithm |
|---|---|
| Transaction signatures | ML-DSA-65 |
| Validator Owner/Governance | ML-DSA-87 |
| Consensus signatures | Ed25519 + ML-DSA-65 hybrid |
| Emergency recovery | SLH-DSA-SHAKE-256s |
| P2P hybrid key establishment | X25519 + ML-KEM-768 |
| Hash and expansion | SHA3-256 / SHAKE256 |
Final NIST/FIPS encodings are required. Draft, padded, alternate, or non-canonical key and signature representations are rejected. Cryptographic algorithms are versioned and may change only through a timelocked protocol upgrade.
Protocol v1 intentionally executes only audited, versioned native modules:
- Account and Key Registry;
- PQC Coin;
- Validator, Stake, Reward, and Evidence;
- Governance and Upgrade;
- Forced Queue;
- L2 Registry, Escrow, DA, and Settlement.
Arbitrary smart-contract bytecode, EVM/WASM compatibility, dynamic host calls, Paymasters, generalized session-key policies, and third-party fee sponsorship are roadmap capabilities, not enabled v1 consensus features.
The implementation must begin with a slow sequential reference executor. An optimized parallel executor may commit non-conflicting work concurrently, but must match the reference executor byte-for-byte.
Once an admitted transaction starts, nonce consumption and actual fee settlement do not revert. Native payload object writes and payload events revert on NativeError, explicit Revert, or OutOfGas. OutOfGas charges the full gas limit; unused maximum-fee reservation is otherwise refunded atomically.
Live objects are committed in a depth-256 SHA3 Sparse Merkle Tree keyed by ObjectId. Blocks also commit transaction, receipt, event, participation, evidence, L2, and DA roots. Database writes use an atomic prepared-batch and replay mechanism so a crash cannot partially advance canonical state.
Full Nodes retain current state, recent snapshots, all headers and finality certificates, and at least 432,000 Slots of receipt/evidence data. Light Clients verify committee-transition certificates and object or transaction proofs from a trusted checkpoint. The initial weak-subjectivity period is approximately 30 days.
The bootstrap randomness beacon uses delayed commit-reveal contributions from the current committee to select a later committee. Selection is uniform without replacement and uses SHAKE256 rejection sampling to avoid modulo bias.
CommitRevealV1 is explicitly classified as bounded-bias, not perfectly unbiasable. The complete commitment/reveal transcript is finalized on chain, and fewer than the active CommitQuorum reveals cannot produce a new seed. The existing committee is extended in RandomnessDegraded mode rather than deriving unsafe randomness.
Before unrestricted permissionless activation, repeated-Epoch grinding, last-revealer strategies, seat concentration, and committee-capture probability must pass the security gate in ADR-0013 and ADR-0018. If they do not, an audited post-quantum-safe beacon upgrade is mandatory.
All Eligible ValidatorIds in a proposal snapshot may vote; each has one vote. Consensus hot keys cannot govern.
| Proposal class | Threshold | Typical scope |
|---|---|---|
| Class A | More than 2/3 of full snapshot electorate | Bounded operational parameters |
| Class B | More than 4/5 of full snapshot electorate | Consensus, security, economics, crypto, upgrades |
| Class C | Not changeable by ordinary governance | Constitutional invariants |
Class C includes the permanent PoW prohibition, strict BFT quorum, finalized history, evidence requirements, unrelated-asset protection, domain separation, and the 1,000,000,000 PQC cumulative mint cap.
Proposals contain exact canonical changes, immutable electorate snapshots, future activation points, and timelocks. Conflicting parameter proposals are resolved deterministically. Protocol upgrades require reproducible manifests and more than four-fifths UpgradeReady signaling.
If finality halts, recovery uses a published, delayed, supermajority-authorized offline package. Recovery cannot lower quorum, introduce PoW, rewrite balances, increase supply, or confiscate user assets.
L1 supports registered ZK Rollup, Optimistic Rollup, Validium, Sovereign, and Permissioned modes. RPC and wallet responses must expose each mode's proof, DA, sequencer, upgrade, and exit assumptions.
Only ZK or Optimistic Rollups using L1 Blob DA may claim that validity, availability, and exits fully inherit L1 security. A ZK L2 may claim end-to-end post-quantum validity only when it uses a transparent hash-based STARK construction.
Optimistic roots remain pending through the initial seven-day challenge window. Protocol v1 enables only fully specified deterministic one-step fraud verification; interactive games require a separate ADR.
A request first receives a minority receipt proving delivery and then a full CommitQuorum admission certificate. The 100-Slot service bound begins only after finalized admission.
Reservations are tracked per future Slot for gas, body bytes, and DA bytes. Optional skipped Slots provide no fictitious capacity. A due forced queue makes the assigned service Slots mandatory. Under live L1 finality, an admitted request receives inclusion or deterministic rejection within 100 Slots.
The ten-minute bound is an L1 admission-to-inclusion guarantee, not universal L2 economic finality. It excludes proof generation, the Optimistic challenge period, external DA recovery, and Sovereign L2 finality. During an L1 safe halt, the deadline remains recorded but the wall-clock service promise is suspended; quorum is never weakened.
The network distinguishes Validator, Full, Archive, DA, RPC/Indexer, and Light Client roles. Consensus traffic is prioritized over blocks, transactions, and bulk snapshot/DA traffic. Validators use authenticated direct committee connections, peer diversity, rate limits, and eclipse resistance.
Production validators must use a Remote Signer or HSM boundary. The signer accepts typed canonical requests, durably persists anti-double-sign and lock state before returning signatures, and never exposes withdrawal authority to online consensus keys.
RPC methods are untrusted interfaces: clients verify finality and state proofs where appropriate. Administrative, signing, and public RPC services must be separated.
.
├── cmd/pqc-node/ Experimental Go orchestration scaffold
├── node/ Experimental Go process packages
├── crates/pqc-node-runtime/ Runnable Rust reference node, BFT, RPC, and wallet
├── crates/ Portable Rust protocol and execution core
├── bindings/c/ Stable C ABI header
├── platform/android/ Android SDK/AAR project
├── protocol/canonical/ Independent Go codec/vector verifier
├── scripts/ Unified build entry points
├── test-vectors/ SHA-256-locked cross-language golden vectors
├── tools/xtask/ Repository task runner
└── docs/ Architecture, development guide, PDF, and ADRs
The Architecture Decision Record index is normative. The technical solution PDF is the product and architecture overview. When this README, the PDF, and an Accepted ADR differ, the Accepted ADR takes precedence.
Implementation boundaries and local setup are documented in Repository architecture and Development environment. Genesis materialization and durable commit semantics are documented in Genesis and durable state. Localnet operation, ports, configuration, RPC, BFT, wallet, and recovery are in Reference node runtime.
Key ADR groups:
- Identifiers, cryptography, codec, and Transaction v1
- Validators, committees, and penalties
- Timing, economics, lifecycle, and governance parameters
- BFT, randomness, and Epoch transitions
- Blocks, state, and Light Clients
- Gas, fees, Mempool, and forced inclusion
- Validator evidence and key recovery
- L2 settlement, DA, proofs, and exits
- Governance, emergency recovery, and upgrades
- Testing and release gates
- Genesis and account bootstrap
- Networking, RPC, and observability
- Committee scaling
- Epoch boundaries and duty proof
- Native execution and receipts
- Validator state and stake accounting
- Forced-service capacity
- Randomness security
- Native Account, Key, Coin, and instruction schemas
Implementation should proceed in dependency order:
- protocol types, canonical codec, domains, and immutable test vectors;
- cryptography, Key Registry, Account, and Coin native modules;
- object store, Sparse Merkle Tree, atomic commits, and snapshots;
- sequential native executor, gas, fees, receipts, and supply accounting;
- validator, stake, reward, evidence, Jail, exit, and withdrawal state machines;
- Slot BFT, Remote Signer, timeout certificates, and crash recovery;
- randomness, committee sampling, and ConsensusEpoch transitions;
- P2P, synchronization, RPC, indexer interfaces, and observability;
- governance, upgrades, and emergency recovery drills;
- L2 Registry, escrow, DA, proof verification, forced inclusion, and exits;
- parallel executor and performance optimization.
Implemented foundation: item 1 is complete. Item 3 now has atomic in-memory and durable snapshot/redo-WAL stores, restart recovery, depth-256 Sparse Merkle state commitments, canonical inclusion and non-inclusion proofs, and locked Rust/Go roots. Item 4 now has canonical receipt and supply-delta schemas, fixed gas accounting, checked fee/base-fee arithmetic, strict access/output enforcement, rollback separation, and centrally computed object-change commitments. Account/Key/Coin handlers now perform real ML-DSA-65 transaction and possession-proof verification, nonce/fee/deposit settlement, and checked Coin conservation. Object growth locks incremental deposit without partial shrink refunds. Audited mainnet crypto providers, complete block/receipt persistence, optimized RocksDB storage, online snapshots, and pruning remain part of items 2–4. Item 5 now has a deterministic Validator/Stake lifecycle and monetary reference state machine: fixed equal-seat bond eligibility, 32-block activation, canonically ordered exits, 64/next-committee safety floors, seven-day/30-day deadlines, objective penalty burns, three-strike Jail, Tombstone, reward posting, issuance reduction/cap logic, and priority-fee distribution. Canonical Validator/Stake/Monetary objects, registration/bond/exit/withdraw payloads, system activation/exit/penalty transitions, and deterministic genesis materialization are integrated. Block finalization now atomically writes issuance, priority-fee credits, base-fee/rounding burns, and the RewardedBlockIndex to Stake/Monetary objects. Evidence object handlers and an explicit reward-claim transaction type remain to be integrated.
Items 6 and 8 now have a runnable reference-testnet path: real-key Genesis, hybrid-signed Proposal/Prevote/Precommit BFT, persistent locks, finalized block storage and recovery, transaction gossip, full re-execution sync, JSON-RPC, wallet transfer commands, and Android ML-DSA/RPC APIs. This is a feature-test chain, not a mainnet node. Remote signing, formal timeout/equivocation evidence objects, permissionless Epoch rotation, production transport/storage/telemetry, governance, and L2 proof execution remain explicit release work.
Mainnet launch is blocked until all Accepted ADR requirements pass, including:
- cross-language canonical and cryptographic vectors;
- property, fuzz, differential, Byzantine, chaos, and model-checking suites;
- deterministic sequential/parallel execution equivalence;
- five-region six-second finality performance or a prospectively revised Slot;
- 128-validator permissionless committee and certificate benchmarks;
- randomness-bias and committee-capture analysis;
- at least 90 days of public testnet operation;
- validator lifecycle, recovery, L2 DA failure, fraud, and forced-exit drills;
- reproducible builds, SBOMs, signed artifacts, and independent builders;
- at least two independent consensus/cryptography audits and an L2 escrow audit;
- no unresolved critical or high-severity security finding.
Safety checks, signature requirements, quorum, or supply invariants are never removed to satisfy a performance target.
The repository does not yet publish a production security-contact or bounty policy. Until one is added, do not treat this codebase as suitable for holding real assets. Never submit private keys, seed phrases, validator signer state, or exploitable production details through public issues.
The implementation contribution process, code of conduct, security policy, and software license will be added before accepting production code from external contributors. Until a license file is committed, no open-source license should be assumed from repository visibility alone.