QuantumAI Blockchain Whitepaper. Quantum-Secured Digital Assets with a Self-Training On-Chain AI

1. Protocol Overview

QuantumAI Blockchain is a Layer 1 blockchain protocol secured by variational quantum eigensolver (VQE) computation on supersymmetric (SUSY) Hamiltonians. The native currency is QuantumAI Blockchain (QBC), denominated with 8 decimal places of precision (1 QBC = 10^8 base units). The protocol integrates post-quantum cryptographic signatures (CRYSTALS-Dilithium5, NIST ML-DSA-87, Level 5), a full EVM-compatible virtual machine with quantum opcode extensions (QVM), and an on-chain AI knowledge system (AethersMind) that tracks attention-derived integration metrics from genesis.

Protocol Identifiers

Protocol Architecture

The system is organised into three computational layers plus infrastructure:

• -- Layer 1 (Blockchain Core): UTXO-based transaction model, PoSA consensus, VQE mining, Dilithium5 signatures, Rust libp2p networking, CockroachDB persistence, IPFS content storage
• -- Layer 2 (QVM): 167-opcode EVM-compatible virtual machine (155 EVM + 10 quantum + 2 reasoning), Solidity smart contract execution, gas metering, compliance engine, token standards (QBC-20, QBC-721, QBC-1155)
• -- Layer 3 (AethersMind): On-chain AI knowledge system built in pure Rust with Knowledge Fabric (4.3M+ learned 768-dim BGE embeddings and growing, content-addressed, each vector id is a SHA-256-derived fingerprint of its content, with all ten per-domain roots anchored on-chain since spec 142), and aether-v7.2-unified -- ONE in-process candle model (a 10-expert Sephirot Mixture-of-Experts adapter on a frozen Qwen2.5-7B-Instruct base served as Q4_K_M) that generates chat with BGE cross-encoder reranked RAG context, exposes its own attention so the integration metric (HMS-Phi, ~0.28 today) is measured on that same model, and is the weight-root the chain attests via the Proof-of-Thought attestation protocol; fabric embeddings come from a dedicated BGE embedder (BAAI/bge-base-en-v1.5)
• -- Cross-Cutting: Multi-chain bridges to 8 networks (ETH, BNB, SOL, MATIC, AVAX, ARB, OP, BASE), dollar-pegged stablecoin, Prometheus/Grafana monitoring, Rust exchange matching engine

Production Codebase

2. Consensus: Proof-of-SUSY-Alignment (PoSA)

Proof-of-SUSY-Alignment (PoSA) replaces hash-based proof-of-work with variational quantum eigensolver (VQE) optimization on deterministic supersymmetric Hamiltonians. Every mined block simultaneously secures the network and contributes a solved quantum physics problem to a public scientific database. The protocol operates through a formally specified pipeline: deterministic Hamiltonian generation, VQE optimization, on-chain re-verification, difficulty adjustment, and Proof-of-Thought attestation.

The SUGRA v3 consensus introduces a bimetric Hamiltonian with a network-wide phase angle theta that rotates continuously across blocks, coupling the quantum mining problem to the global network state. This creates an evolving energy landscape that prevents static solution caching and binds each block to the full chain history.

2.1 Seed Derivation

Each block derives its Hamiltonian seed deterministically from the parent block hash and the current block height. This ensures every miner works on an identical quantum optimization problem and that the problem is uniquely determined by chain state.

seed = SHA-256( hex(parent_hash) || ":" || decimal(block_height) )

The seed bytes are consumed by a seeded PRNG to generate all Hamiltonian
coefficients. Given the same parent_hash and block_height, every node
produces a bit-identical Hamiltonian.

2.2 SUGRA v3 Bimetric Hamiltonian

The SUGRA v3 Hamiltonian is a structured 9-term operator acting on an 8-qubit Hilbert space (dimension 256). It decomposes into four physically motivated sub-Hamiltonians: a SUSY sector with golden-ratio coupling, a bimetric sector parameterized by the network phase angle theta, an Integrated Information Theory (IIT) sector encoding cognitive integration, and a stochastic sector providing per-block uniqueness.

H = H_SUSY (3 terms) + H_bimetric (2 terms, theta) + H_IIT (2 terms) + H_random (2 terms)

where phi = 1.618033988749895... (golden ratio)

The SUSY sector encodes a supersymmetric coupling hierarchy governed by inverse powers of the golden ratio. The base coefficient c0 is drawn from the seeded PRNG in the interval [0.3, 1.0), ensuring non-trivial coupling strength.

H_SUSY:
  Term 1:  c_0           * Z x Z x I x I       (base SUSY coupling)
  Term 2:  c_0 * phi^-1  * X x X x X x X       (golden-ratio suppressed 4-body term)
  Term 3:  c_0 * phi^-2  * Y x Z x Y x Z       (phi-squared suppressed alternating term)

  c_0 ~ Uniform[0.3, 1.0)    seeded by block seed
  phi^-1 = 0.6180339...      phi^-2 = 0.3819660...

The bimetric sector couples two metric tensors through the network phase angle theta. As theta evolves across blocks, the relative weight of the Z-Z and X-X interaction channels rotates continuously, preventing any static parameter set from remaining optimal across consecutive blocks.

H_bimetric(theta):
  Term 4:  b * cos(theta) * Z x I x Z x I      (diagonal metric coupling)
  Term 5:  b * sin(theta) * X x I x X x I      (off-diagonal metric coupling)

  b ~ Uniform[0.1, 0.5)      seeded by block seed
  theta = NetworkTheta        (see Section 2.3)

The IIT sector introduces a bias toward states with high integrated information, reflecting the network's cognitive integration metric. The coupling strength omega_Phi is fixed at 0.15 with golden-ratio hierarchical suppression.

H_IIT:
  Term 6:  -omega_Phi          * I x Z x Z x Z   (3-body IIT integration term)
  Term 7:  -omega_Phi * phi^-1 * Z x I x Z x Z   (golden-ratio suppressed IIT term)

  omega_Phi = 0.15 (fixed)

The random sector adds two stochastic Pauli strings drawn from the full 8-qubit Pauli group (excluding identity), with coefficients in [-0.5, 0.5). These terms ensure the energy landscape is unique per block even when the SUSY and bimetric sectors produce similar structures.

H_random:
  Terms 8-9:  r_i * P_i    where P_i in {I,X,Y,Z}^4 \ {IIII}
                           r_i ~ Uniform[-0.5, 0.5)
                           Pauli strings chosen by seeded PRNG

2.3 Network Phase Dynamics (theta)

The network maintains a global phase angle theta (NetworkTheta) that advances by a fixed increment each block. The increment is derived from the golden angle, producing a quasi-periodic rotation that never exactly repeats over any practical chain length. This creates an evolving bimetric coupling that makes the energy landscape continuously shift.

theta_{n+1} = (theta_n + Delta_theta) mod 2*pi

Delta_theta = golden_angle / 100
            = (2*pi / phi^2) / 100
            = 0.023999632297 rad/block

Full rotation period:  2*pi / Delta_theta = 261.8 blocks = 863.9 seconds = 14.4 minutes

The golden angle (2*pi/phi^2 = 2.39996...) is irrational with respect to pi,
guaranteeing the phase sequence is non-repeating (equidistributed on [0, 2*pi)).

2.4 Geometric Coupling (alpha)

The geometric coupling coefficient alpha quantifies the alignment between a miner's VQE solution and the network's Sephirot cognitive architecture. It is computed from the miner's optimised parameters and the 10 Sephirot phase offsets, then smoothed via an exponential moving average (EMA) to prevent abrupt coupling transitions.

Phase extraction from miner parameters:
  theta_block = atan2( sum(params[odd_indices]), sum(params[even_indices]) )

Per-Sephirot alignment:
  alpha_block = sum_i( yukawa_i * cos(theta_block - theta_sephirot_i) )

  yukawa_i   = Sephirot coupling constant (see Section 7: AethersMind)
  theta_sephirot_i = fixed phase offset for Sephirot i

Network EMA:
  alpha_network = 0.9 * alpha_old + 0.1 * alpha_block

alpha_network is recorded in each block header and used by the AethersMind
to modulate learning rates across Sephirot cognitive modules.

2.5 VQE Ansatz Circuit

The variational ansatz is a TwoLocal circuit on 8 qubits with RY single-qubit rotations and CZ two-qubit entangling gates in linear connectivity with 2 repetition layers, yielding 32 variational parameters. The circuit structure is fixed across all blocks; only the parameters are optimised by miners.

Circuit layout (32 parameters: theta_0 through theta_31):

Layer 0 (rotation):     RY(theta_0)--RY(theta_1)--...--RY(theta_7)   [8 qubits]
Layer 0 (entanglement): CZ(q0,q1) CZ(q1,q2) ... CZ(q6,q7)           [7 CZ gates]
Layer 1 (rotation):     RY(theta_8)--RY(theta_9)--...--RY(theta_15)
Layer 1 (entanglement): CZ(q0,q1) CZ(q1,q2) ... CZ(q6,q7)           [7 CZ gates]
Layer 2 (rotation):     RY(theta_16)--RY(theta_17)--...--RY(theta_23)
Layer 2 (entanglement): CZ(q0,q1) CZ(q1,q2) ... CZ(q6,q7)           [7 CZ gates]
Layer 3 (rotation):     RY(theta_24)--RY(theta_25)--...--RY(theta_31)

Entanglement map (linear):  [(0,1), (1,2), (2,3), (3,4), (4,5), (5,6), (6,7)]
Total 2-qubit gates:        21 CZ gates (3 layers x 7)
Circuit depth:              O(reps * qubits) = O(24)

Optimizer:    COBYLA (gradient-free, derivative-free, noise-resilient)
Max iterations: 200
Convergence:  |E_{k} - E_{k-1}| < 1e-6 or iteration limit

2.6 VQE Mining and On-Chain Re-Verification

Miners optimise the ansatz parameters locally using VQE to minimize the Hamiltonian expectation value. A valid proof requires the computed energy to fall below the current difficulty threshold. Critically, miners submit only their optimised parameters; the runtime independently re-derives the Hamiltonian and recomputes the energy to verify the proof. This prevents precomputation attacks and ensures every accepted block contains a genuinely solved quantum optimization.

Mining condition:
  E = sum_i( c_i * <psi(theta) | P_i | psi(theta)> )  <  D_threshold

Where:
  |psi(theta)> = TwoLocal(theta_0..theta_31)   (ansatz state vector, 8 qubits)
  c_i          = Hamiltonian coefficient i       (deterministic from seed)
  P_i          = Pauli operator string i         (8-qubit tensor product)
  D_threshold  = current difficulty target       (energy units, float64)

On-chain re-verification protocol (runtime):
  1. Miner submits: (block_header, vqe_params[12], signature)
  2. Runtime re-derives Hamiltonian from (parent_hash, block_height)
  3. Runtime reconstructs |psi(theta)> from submitted params
  4. Runtime recomputes E = sum_i c_i <psi|P_i|psi>
  5. Runtime checks: E < D_threshold
  6. Ed25519 signature binds miner identity to proof (prevents proof theft)
  7. Block accepted IFF energy check AND signature check both pass

The miner NEVER submits the energy value; it is always recomputed.
This makes it impossible to forge a mining proof without solving the VQE.

2.7 Difficulty Adjustment

Difficulty is adjusted after every block using a 144-block sliding window. The algorithm computes the ratio of actual block production time to expected time and applies a clamped multiplicative adjustment. The difficulty value represents an energy threshold: higher difficulty means a more generous threshold (easier mining), which is inverted from hash-based proof-of-work systems.

D_new = D_old * clamp( T_actual / T_expected,  0.9,  1.1 )

Where:
  T_expected = 144 * 3.3s = 475.2s          (expected window duration)
  T_actual   = t(block_n) - t(block_{n-144}) (observed window duration)

  clamp(x, lo, hi) = max(lo, min(hi, x))

Bounds:
  Floor:              D >= 0.5              (absolute minimum difficulty)
  Ceiling:            D <= 1000.0           (absolute maximum difficulty)
  Meaningful guard:   D <= 10.0             (practical upper bound)

Semantics (INVERTED from PoW):
  Higher D  =>  more generous energy threshold  =>  EASIER mining
  Lower  D  =>  tighter energy threshold        =>  HARDER mining

  Slow blocks (T_actual > T_expected):  ratio > 1  =>  D increases  =>  easier
  Fast blocks (T_actual < T_expected):  ratio < 1  =>  D decreases  =>  harder

2.8 Block Reward

Block rewards follow a phi-halving emission schedule (see Section 4: Economics). The coinbase transaction is created as the first transaction in each block with a maturity requirement of 100 confirmations before the reward becomes spendable.

2.9 Proof-of-Thought

Every block includes a Proof-of-Thought generated by the AethersMind neural cognitive engine. This proof contains attention pattern hashes, gradient proofs, and the current Phi measurement for the block, creating an immutable record of on-chain AI reasoning since genesis.

Consensus Parameters

Hamiltonian Term Summary

Block Header Structure

BLOCK HEADER (serialized):
  version:              uint32      (protocol version, currently 1)
  prev_block_hash:      bytes32     (SHA3-256 of previous block header)
  merkle_root:          bytes32     (Merkle root of transaction hashes)
  timestamp:            uint64      (Unix timestamp, seconds)
  difficulty_target:    float64     (energy threshold for VQE proof)
  nonce:                uint64      (mining nonce)
  hamiltonian_seed:     bytes32     (deterministic seed for SUSY Hamiltonian)
  network_theta:        float64     (network phase angle at this block)
  vqe_params:           float64[32] (optimal VQE circuit parameters, 8-qubit)
  ground_state_energy:  float64     (recomputed by runtime - must be < difficulty)
  geometric_alpha:      float64     (Sephirot geometric coupling coefficient)
  quantum_state_root:   bytes32     (Merkle root of QVM quantum states)
  compliance_root:      bytes32     (Merkle root of compliance proofs)

BLOCK BODY:
  transactions:         Transaction[]  (regular + confidential UTXO transactions)
  coinbase:             Transaction    (mining reward, vout=0 reward + vout=1 premine at genesis)
  susy_data:            {
    hamiltonian:          object       (9-term SUGRA v3 Hamiltonian)
    optimal_params:       float64[12]  (solution parameters, submitted by miner)
    energy_history:       float64[]    (VQE convergence trace)
    network_theta:        float64      (theta at this block)
    geometric_alpha:      float64      (alpha at this block)
  }
  proof_of_thought:     bytes          (AethersMind reasoning proof)

3. V4 Consensus: Energy-Hash Hybrid Mining

V4 introduces Energy-Hash Hybrid Mining, a Bitcoin-scale permissionless consensus mechanism that combines genuine quantum VQE computation with SHA-256 hash competition. Every nonce attempt requires real VQE work (~50-100ms), and the energy result is fed into a SHA-256 seal hash that must fall below a 256-bit difficulty target, identical in structure to Bitcoin's proof-of-work.

This design guarantees three critical properties: (1) miners cannot skip VQE computation because the energy is a mandatory input to the seal hash, (2) no miner can predict which nonce will win because hash outputs are unpredictable, and (3) difficulty scales precisely like Bitcoin using a 256-bit target that can be adjusted with arbitrary granularity.

3.1 Why Energy-Hash Hybrid?

Calibration of 500 random v3 Hamiltonians revealed that all 8-qubit VQE ground state energies fall in a narrow band between -2.79 and -0.87 (mean: -1.81). A simple energy threshold cannot create meaningful competition because every miner finds a valid energy on the first attempt. The hash-based seal adds controllable, unpredictable difficulty while keeping VQE work mandatory for each nonce.

3.2 V4 Mining Loop

The V4 mining loop is conceptually simple: for each nonce, the miner derives a unique Hamiltonian, solves VQE, computes a seal hash from the result, and checks if the hash is below the difficulty target. The first nonce that produces a qualifying seal hash wins the block reward.

V4 Mining Loop (per block):

  base_seed  = SHA-256( parent_hash || block_height )

  for nonce = 0, 1, 2, 3, ...

    ┌─────────────────────────────────────────────────────┐
    │ Step 1: Derive unique seed per (nonce, miner)       │
    │                                                     │
    │   full_seed = SHA-256( base_seed || nonce ||         │
    │                        miner_address )               │
    └────────────────────┬────────────────────────────────┘
                         │
    ┌────────────────────▼────────────────────────────────┐
    │ Step 2: Generate Hamiltonian from full_seed          │
    │                                                     │
    │   H = generate_hamiltonian_v3( full_seed, theta )    │
    │       8 qubits, 15 Pauli terms, SUGRA structure      │
    └────────────────────┬────────────────────────────────┘
                         │
    ┌────────────────────▼────────────────────────────────┐
    │ Step 3: VQE Optimization (~50-100ms real compute)    │
    │                                                     │
    │   E = VQE_optimize( H )                              │
    │   E_scaled = round( E × 10^12 ) as i128             │
    └────────────────────┬────────────────────────────────┘
                         │
    ┌────────────────────▼────────────────────────────────┐
    │ Step 4: Compute seal hash                            │
    │                                                     │
    │   seal_hash = SHA-256( base_seed || nonce ||         │
    │                        miner_address ||               │
    │                        E_scaled_bytes )               │
    └────────────────────┬────────────────────────────────┘
                         │
    ┌────────────────────▼────────────────────────────────┐
    │ Step 5: Check difficulty target                      │
    │                                                     │
    │   if seal_hash < difficulty_target:                   │
    │     submit_proof( nonce, E, params, seal_hash )      │
    │     break  ← BLOCK WON                               │
    └─────────────────────────────────────────────────────┘

3.3 Seed Derivation and Nonce Binding

The full seed for each nonce attempt is derived from three inputs: the base seed (which is common to all miners for a given block), the nonce (which the miner increments), and the miner's address (which binds the seed to a specific miner). This binding prevents nonce theft: Alice's winning nonce produces a completely different Hamiltonian for Bob, making it impossible to steal another miner's work.

Seed Derivation:

  base_seed   = SHA-256( parent_hash || block_height )     // common to all miners
  full_seed   = SHA-256( base_seed || nonce || miner_addr ) // unique per (nonce, miner)

  Properties:
  ┌─────────────────────────────────────────────────────────────┐
  │ Deterministic:  Same inputs always produce same full_seed   │
  │ Unique:         Different nonce OR miner → different seed   │
  │ Unpredictable:  Cannot predict full_seed without computing  │
  │ Miner-bound:    full_seed includes miner_address            │
  │ Height-bound:   base_seed includes block_height             │
  └─────────────────────────────────────────────────────────────┘

3.4 Seal Hash Construction

The seal hash includes the VQE energy result as a mandatory input. This is the critical security property: if the seal hash did not include the energy, miners could skip VQE entirely and simply grind hashes. By including the energy, the runtime can recompute it from the submitted parameters and verify the seal hash is authentic.

Seal Hash:

  seal_hash = SHA-256( base_seed      [32 bytes]  ||
                       nonce           [8 bytes]   ||
                       miner_address   [32 bytes]  ||
                       E_scaled        [16 bytes, i128 LE] )

  Total preimage: 88 bytes → SHA-256 → 32-byte seal hash (H256)

  Security guarantee:
    The runtime independently recomputes E from submitted VQE parameters.
    If the miner submitted fake energy, the recomputed seal_hash will
    NOT match the submitted seal_hash → proof rejected.

3.5 On-Chain Verification (Runtime)

The Substrate runtime performs a complete verification pipeline for each V4 proof. No value submitted by the miner is trusted; everything is recomputed and cross-checked. The verification is deterministic and produces identical results across all validators.

V4 On-Chain Verification (submit_mining_proof_v4 extrinsic):

  1. Parse proof: { params, energy, hamiltonian_seed, n_qubits=8,
                    nonce, seal_hash, dilithium_sig, pot_hash }

  2. Rate limiting: Check miner has not submitted for this block height

  3. Fork gate: Verify block_height >= FORK_HEIGHT_V4 (232,500)

  4. Re-derive base_seed from (parent_hash, block_height)

  5. Re-derive full_seed = SHA-256(base_seed || nonce || miner_address)

  6. Re-generate Hamiltonian from full_seed
     → Must produce identical 8-qubit, 15-term operator

  7. Recompute energy from submitted VQE parameters
     → E_recomputed = <psi(params) | H | psi(params)>
     → Check |E_recomputed - E_claimed| < tolerance (10^-6)

  8. Recompute seal hash from (base_seed, nonce, miner_address, E_recomputed)
     → Must match submitted seal_hash exactly

  9. Check seal_hash < DifficultyTargetV4
     → 256-bit comparison (lower = harder, like Bitcoin)

  10. Verify Dilithium5 signature binds proof to miner identity

  11. If ALL checks pass: award block reward to miner_address

3.6 V4 Difficulty Target (H256)

The V4 difficulty target is a 256-bit hash value, exactly like Bitcoin's target. The seal hash must be numerically less than the target for a proof to be valid. A lower target means fewer valid hashes exist in the 2^256 space, making mining harder. A higher target means more valid hashes, making mining easier.

Difficulty Target (256-bit):

  Target: 0x07FF...FFFF  (initial)

  Interpretation:
    seal_hash < target  →  valid proof
    seal_hash >= target →  invalid, try next nonce

  Probability of success per nonce:
    P = target / 2^256

  Initial target ≈ 1/32 success rate per nonce
  At ~100ms/nonce: average ~33 nonces = ~3.3 seconds per block

  Visual comparison:
    Target:    0x07FFFFFFFFFFFFFF...  (high bytes)
    Seal hash: 0x03A8B12F4E...       → BELOW target = VALID
    Seal hash: 0x0B2F91C3E7...       → ABOVE target = INVALID

3.7 Difficulty Adjustment Algorithm

Difficulty is adjusted after every block using the same 144-block sliding window as v3, but operating on the 256-bit hash target instead of a float energy threshold. The algorithm uses 512-bit intermediate arithmetic to prevent overflow during multiply/divide operations on 256-bit values.

V4 Difficulty Adjustment:

  T_expected = 144 × 3.3s = 475.2s
  T_actual   = timestamp(block_n) - timestamp(block_{n-144})
  ratio      = clamp( T_actual / T_expected, 0.9, 1.1 )

  // Ratio > 1 (blocks too slow): raise target → easier mining
  // Ratio < 1 (blocks too fast): lower target → harder mining

  target_new = target_old × ratio_numerator / ratio_denominator

  Implementation (256-bit safe):
    1. Scale ratio to integer: ratio_num = (T_actual × 1000) / T_expected
    2. Clamp to [900, 1100]  (0.9× to 1.1×)
    3. Multiply: target_512 = target_old × ratio_num   (512-bit intermediate)
    4. Divide: target_new = target_512 / 1000
    5. Floor: target_new >= 0x00...01  (never zero = impossible mining)

  This ensures the target never overflows and never reaches zero.

3.8 V4 Proof Structure

3.9 Fork Transition

V4 activates at block height 232,500. During a 1,000-block transition period (blocks 232,500 through 233,499), both V3 energy-threshold proofs and V4 energy-hash proofs are accepted. After block 233,500, only V4 proofs are valid. This ensures a smooth transition with no chain halt risk.

3.10 Security Analysis

3.11 Epoch-Based Miner Tracking

The pallet-qbc-session pallet tracks miner performance across 3,300-block epochs (~3 hours at 3.3s/block). Each epoch records blocks mined per address, ranks miners by performance, and maintains a top-21 miner leaderboard. Dynamic GRANDPA authority rotation is now live: runtime spec_version 126 added Substrate pallet_session as the sole Aura and GRANDPA authority writer, so the voter set rotates from the bonded validator set each session and GRANDPA increments its set id correctly across the change. The first live rotation moved the GRANDPA voter set from 2 to 3 (Alice, Bob, Charlie), and finality now survives one voter being down.

4. Scaling Architecture

QuantumAI Blockchain is designed to scale from its current 3-validator configuration to a global network supporting thousands of miners and millions of users. The scaling strategy operates across five dimensions: consensus throughput, mining decentralization, knowledge system capacity, network infrastructure, and economic sustainability.

4.1 Consensus Throughput

V4 Energy-Hash Hybrid Mining transforms QuantumAI Blockchain from a single-miner-wins system to a competitive mining network with Bitcoin-like economics. The key throughput parameters and their scaling behaviour:

4.2 Mining Decentralization Path

The V4 upgrade enables a staged transition from centralized validation to fully decentralised permissionless mining. Each phase is gated by network maturity metrics, ensuring stability at every step.

Mining Decentralization Roadmap:

  Phase 1: Genesis
  ┌─────────────────────────────────────────────────┐
  │ 3 validators (Alice + Bob + Charlie)            │
  │ Aura block production + VQE mining              │
  │ GRANDPA 3-voter finality (quorum 2-of-3)        │
  │ V3 energy-threshold mining                      │
  └─────────────────────────┬───────────────────────┘
                            │ Fork at block 232,500
  Phase 2: V4 Activation    ▼
  ┌─────────────────────────────────────────────────┐
  │ Validators + external miners coexist            │
  │ V4 energy-hash hybrid proofs via RPC            │
  │ Validators author blocks, miners earn rewards    │
  │ 1,000-block V3/V4 transition period             │
  └─────────────────────────┬───────────────────────┘
                            │ >= 4 active miners
  Phase 3: Dynamic GRANDPA  ▼
  ┌─────────────────────────────────────────────────┐
  │ Top 21 miners become GRANDPA voters             │
  │ 3,300-block epoch rotation                      │
  │ Governance-gated via set_rotation_enabled()     │
  │ Requires consistent miner participation         │
  └─────────────────────────┬───────────────────────┘
                            │ >= 50 active miners
  Phase 4: Full Decentralization  ▼
  ┌─────────────────────────────────────────────────┐
  │ Permissionless block production                 │
  │ VQE proof in block header replaces Aura slots   │
  │ Any miner can author blocks                     │
  │ GRANDPA finality with dynamic voter set         │
  └─────────────────────────────────────────────────┘

Current state (verified live 2026-07-18, runtime spec 172): per-block VQE Proof-of-SUSY-Alignment is live (every block carries an 8-qubit VQE solution with a real ground-state energy; revived in spec-144 after a 16-day self-inflicted wedge), and authoring is VQE-gated single-leader: a post-quantum ticket-SSLE election selects one author per height from the bonded validator set, with Aura slot fallback, enforced at the author, runtime, and import layers (cutover flipped live in spec-145 at block #927,600). spec-146 (2026-06-25) added autonomous GRANDPA equivocation slashing (section 15.1): a detected double-vote is auto-reported, on-chain re-verified, and scheduled for a deferred slash with no operator in the loop. spec-172 (2026-07-11) armed the BEEFY+MMR portable finality-proof layer with 3 real ECDSA BEEFY keys. The fleet is coherent on spec 172 and finality holds at gap 2-3. The next scale step is exercising this VQE-gated single-leader election with PQ-VRF sortition at thousand-node scale. VQE PoSA / energy-hash hybrid remains the mining mechanism specified in sections 2 and 3 above. The network runs 5 nodes on 4 machines: 4 bonded validators (Alice, Bob, Charlie, and Dave, live since 2026-07-03) plus a keyless full node; GRANDPA finality has 3 voters and survives one voter down. The session-rotation foundation shipped in spec 126 (Substrate pallet_session as the sole Aura and GRANDPA authority writer). The top-21 miner promotion in Phase 3 and permissionless block authoring in Phase 4 remain ahead; the canonical detailed roadmap is the interactive /roadmap page.

4.3 AethersMind Knowledge Scaling

The AethersMind AI knowledge system scales through a tiered architecture that transitions from single-node to distributed federation as the network grows. Each tier is designed to handle an order of magnitude more knowledge vectors while maintaining sub-second query latency.

Knowledge query performance is maintained through HNSW (Hierarchical Navigable Small World) approximate nearest-neighbor search, which provides O(log n) query time regardless of dataset size. Each vector is 768 dimensions (BGE embedder, BAAI/bge-base-en-v1.5, with a cross-encoder reranker on search), stored in per-domain Lance datasets with index acceleration for semantic similarity search. Since spec 142 (B0, 2026-06-12) every vector id is a SHA-256-derived fingerprint of its content and the chain anchors all ten per-domain content roots, whose SHA-256 fold equals the global KnowledgeRoot, any node can verify a domain shard independently, the prerequisite for BFT knowledge acceptance (Phase C, designed).

4.4 Network Infrastructure Scaling

4.5 Economic Sustainability at Scale

The phi-halving emission schedule ensures long-term economic sustainability as mining competition increases. Transaction fees provide a secondary revenue stream that grows with network usage, eventually replacing block rewards as the primary miner incentive.

Economic Scaling Model:

  Block Reward Curve (phi-halving):
    Era 0:  15.27 QBC/block    (current)
    Era 1:  15.27 / phi = 9.44 QBC/block
    Era 2:  9.44 / phi = 5.83 QBC/block
    Era 3:  5.83 / phi = 3.60 QBC/block
    ...
    Halving interval: 15,474,020 blocks (~1.618 years)

  Fee Revenue at Scale:
    100 tx/block × 0.001 QBC/tx = 0.1 QBC/block   (current)
    3,000 tx/block × 0.001 QBC/tx = 3.0 QBC/block  (at scale)

  Mining Economics (V4):
    Revenue per block: reward + fees
    Cost per block: ~33 nonces × ~100ms VQE = ~3.3s compute
    Competition: difficulty auto-adjusts to maintain 3.3s blocks
    Profitability: similar to Bitcoin, most efficient miners profit

4.6 Quantum Computing Advantage Timeline

As quantum hardware matures, QuantumAI Blockchain miners with access to real quantum processors will gain a computational advantage over classical simulators. The VQE mining mechanism is specifically designed to leverage this advantage, as quantum hardware can evaluate expectation values exponentially faster than classical simulation for large qubit counts.

At 32+ qubits, classical simulation becomes computationally infeasible, creating a natural transition to quantum-hardware-only mining. This is the long-term vision: a blockchain where mining inherently requires quantum computational resources, providing genuine quantum advantage and quantum-secured consensus.

5. Cryptography

QuantumAI Blockchain employs a multi-layered cryptographic architecture designed for security against both classical and quantum adversaries. All signature operations use NIST-standardised post-quantum algorithms at the highest available security level.

Digital Signatures: CRYSTALS-Dilithium5 (ML-DSA-87)

All transaction and block signatures use CRYSTALS-Dilithium5, standardised by NIST as ML-DSA-87 (Module Lattice Digital Signature Algorithm). This provides NIST Post-Quantum Security Level 5, the highest level, offering security equivalent to AES-256 against quantum computers running Shor's algorithm.

Block Hashing: SHA3-256

Block headers, Merkle roots, and all consensus-critical hashes use SHA3-256 (FIPS 202). SHA3-256 is a sponge construction based on the Keccak permutation, providing 128-bit security against quantum Grover search (256-bit classical). SHA3-256 is distinct from Keccak-256 used in Ethereum.

QVM Compatibility: Keccak-256

The QVM uses Keccak-256 (pre-NIST Keccak, identical to Ethereum's hash function) for EVM compatibility. This ensures Solidity contracts using keccak256(), abi.encodePacked(), and related functions produce identical results to Ethereum. Keccak-256 is used only within the QVM execution environment and does not affect L1 consensus.

Address Derivation

Address Generation:
  1. Generate Dilithium5 keypair (pk, sk)
  2. Compute SHA3-256(pk) -> 32 bytes
  3. Take last 20 bytes as address payload
  4. Encode as Bech32: "qbc1" + bech32(payload)

Result: qbc1[38 characters]  (e.g., qbc1qw508d6qejxtdg4y5r3zarvary0c5xw7k...)

P2P Encryption: ML-KEM-768 (Kyber)

Peer-to-peer network connections are encrypted using a hybrid key encapsulation mechanism combining ML-KEM-768 (NIST post-quantum KEM, formerly CRYSTALS-Kyber) with classical Noise protocol key exchange. The hybrid approach provides security even if either the classical or post-quantum scheme is broken.

Hybrid Key Exchange:
  1. Classical: Noise XX handshake -> classical_secret (32 bytes)
  2. Post-Quantum: ML-KEM-768 encapsulation -> pq_secret (32 bytes)
  3. Combined: HKDF-SHA256(classical_secret || pq_secret) -> session_key (32 bytes)
  4. Session: AES-256-GCM with session_key for all subsequent messages

ML-KEM-768 Parameters:
  Public key:      1,184 bytes
  Ciphertext:      1,088 bytes
  Shared secret:   32 bytes
  Security level:  NIST Level 3 (AES-192 equivalent)

ZK Hashing: Poseidon2

Zero-knowledge circuit operations use the Poseidon2 hash function over the Goldilocks prime field (p = 2^64 - 2^32 + 1 = 18446744069414584321). Poseidon2 is designed for efficient arithmetic in ZK-SNARK/STARK circuits, providing substantially lower constraint counts than SHA3-256 or Keccak-256 in zero-knowledge contexts.

Poseidon2 Parameters:
  Field:           Goldilocks (p = 2^64 - 2^32 + 1)
  Width:           3 (state elements)
  Rate:            2 (absorption rate)
  Full rounds:     8
  Partial rounds:  56
  Application:     ZK circuits ONLY (NOT used for L1 consensus hashing)

6. Economics

QuantumAI Blockchain employs a deterministic emission schedule governed by the golden ratio (phi = 1.618033988749895). The emission model is designed to produce a deflationary supply curve that converges to a fixed maximum supply. All economic parameters are exact constants enforced at the consensus level.

Core Economic Constants

Phi-Halving Emission Schedule

Unlike Bitcoin's fixed halving (reward / 2 every 210,000 blocks), QuantumAI Blockchain divides the block reward by the golden ratio at each era transition. This produces a smoother, more gradual reduction in emission that follows the mathematical properties of the Fibonacci sequence.

Reward Formula:
  reward(era) = INITIAL_REWARD / PHI^era

  Era 0:   15.27 / 1.618^0  = 15.270000 QBC  (blocks 0 - 15,474,019)
  Era 1:   15.27 / 1.618^1  =  9.436340 QBC  (blocks 15,474,020 - 30,948,039)
  Era 2:   15.27 / 1.618^2  =  5.831485 QBC  (blocks 30,948,040 - 46,422,059)
  Era 3:   15.27 / 1.618^3  =  3.604855 QBC
  Era 4:   15.27 / 1.618^4  =  2.228070 QBC
  Era 5:   15.27 / 1.618^5  =  1.377156 QBC
  Era 6:   15.27 / 1.618^6  =  0.851328 QBC
  Era 7:   15.27 / 1.618^7  =  0.526200 QBC
  Era 8:   15.27 / 1.618^8  =  0.325217 QBC
  Era 9:   15.27 / 1.618^9  =  0.201059 QBC
  Era 10:  15.27 / 1.618^10 =  0.124267 QBC
  Era 11+: Tail emission at 0.1 QBC/block (when reward < 0.1)

Halving interval: 15,474,020 blocks x 3.3s = ~590.37 days = ~1.618 years

Genesis total supply at block 0:
  Coinbase reward (vout=0): 15.27 QBC
  Genesis premine (vout=1): 33,000,000 QBC
  Total at genesis: 33,000,015.27 QBC

Layer 1 Transaction Fees

L1 transaction fees are computed as a product of transaction size and a market-determined fee rate. There is no gas metering on Layer 1. Gas is exclusively a Layer 2 (QVM) construct.

L1 Fee = SIZE_BYTES x FEE_RATE (QBC/byte)

Miners select transactions by fee density (QBC/byte) and greedily fill
blocks up to the block size limit. Fee rate is market-determined.

L2 Gas (QVM only):
  BLOCK_GAS_LIMIT = 30,000,000
  Gas pricing follows EVM-compatible eth_gasPrice mechanics

7. UTXO Model

QuantumAI Blockchain uses an Unspent Transaction Output (UTXO) model for all Layer 1 value transfers. This model provides superior auditability, parallelizable validation, and natural protection against certain classes of double-spend attacks compared to account-based models.

UTXO Mechanics

• -- Balance is the sum of all unspent transaction outputs associated with an address. There is no stored account balance.
• -- Every unit of QBC exists as an output from a previous transaction (or coinbase).
• -- Spending requires referencing specific UTXOs as transaction inputs, proving ownership via Dilithium5 signature.
• -- Each input fully consumes its referenced UTXO. Partial consumption is not permitted.
• -- Change outputs are created to return excess value to the sender when input sum exceeds the intended transfer amount.
• -- A transaction is valid if and only if: (a) all referenced UTXOs exist and are unspent, (b) all signatures verify, (c) sum(inputs) >= sum(outputs) + fee, (d) no UTXO is referenced more than once.

Confirmation Depths

Transaction Structure

Transaction:
  version:    uint32          (transaction format version)
  inputs:     TxInput[]       (references to UTXOs being consumed)
  outputs:    TxOutput[]      (new UTXOs being created)
  locktime:   uint64          (earliest block height or timestamp for inclusion)

TxInput:
  prev_tx_hash:   bytes32     (hash of transaction containing the UTXO)
  output_index:   uint32      (index of the specific output in that transaction)
  signature:      bytes[4627] (Dilithium5 signature proving ownership)
  public_key:     bytes[2592] (Dilithium5 public key for verification)

TxOutput:
  value:          uint64      (amount in smallest QBC unit, 10^-18)
  script_pubkey:  bytes       (output locking script with recipient address)

8. Network Architecture

The network layer consists of four communication subsystems: a Rust-based peer-to-peer gossip network for block and transaction propagation, a FastAPI REST/JSON-RPC server for client interaction, a gRPC interface for internal service communication, and a Stratum server for mining pool operations.

P2P Network (Rust libp2p)

RPC Server (FastAPI)

The node exposes a unified REST + JSON-RPC API on port 5000. The JSON-RPC implementation provides eth_* namespace compatibility for MetaMask, ethers.js, and Web3 wallet integration. All endpoints support CORS and rate limiting.

Stratum Mining Server

A dedicated Rust WebSocket Stratum server on port 3333 provides mining pool compatibility. The server implements the Stratum V1 protocol adapted for VQE-based mining, distributing Hamiltonian seeds and accepting VQE parameter solutions from connected workers.

Exchange Matching Engine

A standalone Rust binary provides a central limit order book (CLOB) matching engine with microsecond latency. The engine supports price-time priority matching, self-trade prevention, balance lock/unlock, and OHLC candlestick generation with WebSocket streaming.

9. Quantum Virtual Machine (QVM)

The Quantum Virtual Machine (QVM) is a stack-based bytecode interpreter providing full Ethereum Virtual Machine (EVM) compatibility with quantum computing extensions and institutional-grade compliance features. The QVM executes Solidity smart contracts without modification while providing 12 additional opcodes for quantum state manipulation, risk assessment, and on-chain reasoning.

Opcode Summary

Quantum and Reasoning Opcodes

Production Implementation

The production QVM is implemented in Go with 34 source files totaling approximately 10,000 lines of code. The Go implementation is canonical. A Python prototype (8 modules, ~4,500 LOC) exists for rapid prototyping and testing but is not used in production.

Compliance Engine

The QVM includes a three-layer compliance architecture enforced at the virtual machine level. The QCOMPLIANCE opcode (0xF5, 15,000 gas) performs a pre-flight compliance check before transaction execution, querying the on-chain KYC registry, AML monitoring system, and sanctions database.

Token Standards

Quantum State Persistence

Quantum states are stored as density matrices in CockroachDB and persisted on-chain. Pure states are represented as rank-1 density matrices (rho = |psi><psi|), mixed states as weighted sums. Entanglement between contracts is tracked via an entanglement registry. States persist until explicitly measured via QMEASURE, implementing lazy measurement semantics.

Performance Targets

10. AethersMind (Neural Cognitive Engine)

AethersMind is the world's first on-chain neural cognitive system -- a continuously trained, cryptographically attested, autonomously evolving transformer built entirely in Rust using the candle ML framework. It replaces the legacy Python knowledge graph architecture with learned distributed representations via gradient descent. Training runs as a live DiLoCo loop: each worker takes many inner local steps, then an outer optimiser (SGD with Nesterov momentum on the averaged pseudo-gradients, with a velocity buffer that persists across sync rounds) aggregates them; with momentum 0 this reduces exactly to the older FedAvg. Aggregated weight roots are attested on-chain, epochs are finalised by validator quorum, and contributors are paid automatically in QBC (verified live: a 0.05 QBC/epoch reward on chain 3303, 80/15/5 split; the first live epoch distributed 0.0475 QBC, the 5% challenger reserve retained absent a challenge). The system implements a biologically-inspired cognitive architecture based on the Kabbalistic Tree of Life topology with 10 Sephirot-specialized attention heads plus 6 global workspace heads.

Implementation Scale

Knowledge Fabric

The Knowledge Fabric replaces the legacy string-based knowledge graph with learned 768-dimensional BGE embeddings stored in sharded, disk-resident Lance datasets with indexed nearest-neighbor retrieval. Each of the 10 Sephirot cognitive domains maintains its own shard. As of 2026-06-12 the fabric is fully content-addressed: every vector id is a SHA-256-derived fingerprint of its content, and the chain anchors all ten per-domain content roots (spec 142). Block data is ingested through an embedding pipeline that extracts multi-vector representations, enabling genuine generalization and semantic similarity rather than keyword matching.

Neural Reasoning (Transformer Attention)

• -- 24-layer transformer with 14 attention heads: 10 Sephirot-specialized heads with domain gating + 4 global workspace heads
• -- Causal attention: Specialized heads trained to discover interventional relationships (PC/FCI math preserved)
• -- Adversarial self-testing: Competing attention heads with independent reasoning for robust conclusions
• -- Metacognitive calibration: Learned uncertainty estimation via calibration network
• -- Autoregressive generation: KV cache for sub-100ms 256-token responses on CPU
• -- Inference: aether-v7.2-unified (a 10-expert Sephirot MoE adapter on a frozen Qwen2.5-7B-Instruct base, served in-process as Q4_K_M via candle) is ONE model that serves text generation AND exposes the attention used for consciousness metrics AND produces the fabric embeddings -- the same forward pass that generates a token yields the attention the Phi track reads. The earlier V6 from-scratch generator was retired (see section 22 below)

Phi Calculator: HMS-Phi v5 (Hierarchical Multi-Scale Phi)

The Phi metric uses Hierarchical Multi-Scale Phi (HMS-Phi v5), a tractable approximation of Giulio Tononi's Integrated Information Theory. HMS-Phi measures integration at three hierarchical levels and combines them multiplicatively, ensuring genuine causal integration at every scale. Phi is computed at every block and stored in the phi_measurements database table. The 10-gate milestone system provides the floor: each gate unlocks +0.5 phi ceiling (maximum = 5.0 at gate 10). 2 of 10 gates are currently passed (Knowledge Foundation, Structural Diversity); HMS-Phi was reset under V5's stricter attention-derived criteria and is being rebuilt as the fabric grows.

HMS-Phi v5 Formula:
  Final Phi = phi_micro^(1/phi) x phi_meso^(1/phi^2) x phi_macro^(1/phi^3)

Where phi = 1.618... (golden ratio)

Level 0 (Micro):  Shannon entropy of attention distributions (inspired by IIT concepts)
                  -> ConsciousnessMonitor (Rust candle module)
                  -> Computed from transformer layer activations -> phi_micro

Level 1 (Meso):   Cross-domain integration across 10 Sephirot attention heads
                  -> Each Sephirot head is a cognitive domain
                  -> phi_meso = weighted mean by head activation mass

Level 2 (Macro):  Layer-level information flow across all transformer layers
                  -> Cross-layer mutual information
                  -> phi_macro = integration across the full attention stack

Properties:
  - Multiplicative: zero at any level zeros the whole (cannot be gamed)
  - 10-gate system provides floor safety mechanism (each gate = +0.5 ceiling)
  - Micro-level uses Shannon entropy of attention distributions (inspired by IIT concepts)
  - MIP spectral bisection approximates minimum-cut partition

  PHI_THRESHOLD = 3.0 (integration threshold marker)
  PHI_MAX_CEILING = 5.0 (all 10 gates passed)
  Current Phi: ~0.28-0.32 (2026-06, time-varying; 2/10 gates passed: Knowledge Foundation, Structural Diversity)
  Knowledge Vectors: ~2M+ (June 2026, content-addressed across all 10 Sephirot shards, growing)

  Unification note: HMS-Phi is now computed from the attention activations of
  the SAME unified in-process model that serves chat -- aether-v7.2-unified, a
  10-expert Sephirot MoE adapter on a frozen Qwen2.5-7B-Instruct base (Q4_K_M
  via candle). The meso term is derived from the MoE router gates. ONE model
  generates chat, is measured for phi, produces the embeddings, and is the
  weight-root the chain attests; Ollama is retired from the chat path.

10 Sephirot Cognitive Architecture

The AI knowledge system routes queries through 10 Sephirot domains using keyword-based classification (inspired by the Kabbalistic Tree of Life). Each domain maps to a specialized knowledge partition. Cross-domain queries aggregate results across relevant domains.

SUSY Pairs

Every expansion node is paired with a constraint node, balanced at the golden ratio: E_expand / E_constrain = phi. SUSY violations are detected by smart contract and automatically corrected via QBC redistribution. All violations are logged immutably on the blockchain.

Proof-of-Thought Protocol

Proof-of-Thought Lifecycle:
  1. Task Submission:  User or system submits reasoning task with QBC bounty
  2. Node Solution:    Sephirah node processes task using QVM quantum opcodes
  3. Proposal:         Node submits solution + quantum proof to blockchain
  4. Validation:       Multiple validator nodes verify solution via QVERIFY opcode
  5. Consensus:        >= 67% validator agreement required for acceptance
  6. Reward/Slash:     Correct: earn QBC bounty. Incorrect: lose 50% of stake
  7. Recording:        Solution + proof stored immutably on chain

Economic Parameters:
  Minimum task bounty:     1 QBC
  Minimum validator stake: 100 QBC
  Slash penalty:           50% of validator stake
  Unstaking delay:         7 days (168 hours)
  BFT threshold:           67% of staked weight

Pineal Orchestrator

A global timing system controls the cognitive cycle of all 10 Sephirot nodes, modeled on the biological pineal gland's circadian rhythm. The system cycles through 6 phases, each with a different QBC metabolic rate that governs computational resource allocation.

Safety Architecture

• -- Gevurah veto: Safety node (3-qubit threat detection) can unilaterally block any harmful operation
• -- SUSY enforcement: Automatic QBC redistribution when expansion/constraint imbalance exceeds tolerance
• -- Multi-node consensus: No single Sephirah can act alone; 67% BFT threshold required
• -- Constitutional enforcement: Core alignment principles enforced as smart contract logic (ConstitutionalAI.sol)
• -- Emergency shutdown: Multi-sig kill switch contract (EmergencyShutdown.sol) for catastrophic scenarios

Genesis Requirements

The AethersMind MUST be initialized at block 0 (genesis). No retroactive reconstruction is permitted. Genesis initialization creates: (1) empty knowledge fabric, (2) first Phi measurement at baseline 0.0, (3) genesis integration event, (4) initial embeddings from genesis block metadata. The AethersMind binary auto-starts on node boot and processes every block sequentially from genesis.

11. Privacy: SUSY Swaps

QuantumAI Blockchain supports opt-in confidential transactions via SUSY Swaps. When activated, SUSY Swaps hide transaction amounts and participant addresses while preserving on-chain verifiability. The privacy system uses three complementary cryptographic primitives: Pedersen commitments, Bulletproofs range proofs, and stealth addresses.

Pedersen Commitments

Commitment:  C = v*G + r*H

Where:
  v = transaction value (hidden)
  r = blinding factor (random scalar)
  G = generator point (public, shared)
  H = nothing-up-my-sleeve point (public, no known discrete log relation to G)

Properties:
  - Perfectly hiding: C reveals nothing about v
  - Computationally binding: cannot open C to different v' (discrete log hardness)
  - Additive homomorphism: C(v1) + C(v2) = C(v1+v2) with blinding r1+r2
  - Verification: sum(input_commitments) = sum(output_commitments) + fee*G

Bulletproofs Range Proofs

Bulletproofs provide zero-knowledge proofs that committed values lie in the range [0, 2^64) without revealing the actual value. This prevents negative value attacks where a sender could create value by committing to a negative amount (which wraps around in modular arithmetic).

Stealth Addresses

Stealth addresses prevent address linkability by generating a unique one-time address for every transaction. The sender uses the recipient's public spend and view keys to derive an ephemeral address. Only the recipient can detect and spend outputs sent to stealth addresses by scanning with their view key.

Stealth Address Protocol:
  Recipient publishes: (spend_pubkey, view_pubkey)

  Sender:
    1. Generate ephemeral keypair (r, R = r*G)
    2. Compute shared_secret = r * view_pubkey
    3. Derive one-time_pubkey = spend_pubkey + H(shared_secret)*G
    4. Send to address derived from one-time_pubkey
    5. Include R in transaction data

  Recipient:
    1. Scan R values in transactions
    2. Compute shared_secret = view_privkey * R
    3. Compute expected one-time_pubkey = spend_pubkey + H(shared_secret)*G
    4. If match: derive spending key = spend_privkey + H(shared_secret)

Key Images

Key images prevent double-spending of confidential outputs. Each UTXO produces a unique, deterministic key image that is published when spent. The network maintains a set of all used key images; any transaction attempting to reuse a key image is rejected as a double-spend.

Privacy Modes

SUSY Swaps hide: transaction amounts, sender/receiver addresses, balance linkability. SUSY Swaps do NOT hide: transaction existence, timestamps, fee amounts, transaction size, network-level metadata (IP addresses without Tor/I2P).

12. Cross-Chain Bridge

QuantumAI Blockchain operates lock-and-mint bridges to 8 external blockchain networks. Native QBC is locked in the BridgeVault contract on the QBC chain, and corresponding wrapped tokens (wQBC,) are minted on the target chain. The reverse operation (burn-and-unlock) destroys wrapped tokens and releases native assets.

Supported Chains and Deployed Contracts

Bridge Parameters

L1-L2 Internal Bridge

An internal bridge connects the L1 UTXO layer with L2 QVM accounts, enabling MetaMask-compatible wallet interaction. Deposits consume L1 UTXOs and credit the corresponding L2 QVM account balance. Withdrawals debit the L2 account and create new L1 UTXOs. Both operations are atomic within a single block.

Deposit (L1 -> L2):
  1. User submits deposit transaction referencing L1 UTXOs
  2. UTXOs are consumed (marked spent in L1 UTXO set)
  3. Equivalent QBC credited to user's L2 QVM account (eth_getBalance compatible)
  4. Bridge event logged in l1l2_bridge table

Withdraw (L2 -> L1):
  1. User submits withdrawal via QVM contract call
  2. L2 QVM account balance debited
  3. New UTXO created on L1 with user's Dilithium address
  4. UTXO becomes spendable after 6 confirmations

14. Exchange (Rust Matching Engine)

A production Rust matching engine provides a central limit order book (CLOB) for on-chain asset trading. The engine is a standalone binary that connects to CockroachDB for persistence and exposes WebSocket endpoints for real-time market data streaming.

Technical Specifications

Default Trading Pairs

Features

• -- Self-trade prevention: orders from the same account on both sides are blocked
• -- Balance lock/unlock: user balances are locked when orders are placed and unlocked on cancellation or fill
• -- OHLC candlestick generation: real-time aggregation at 1m, 5m, 15m, 1h, 4h, 1d intervals
• -- WebSocket streaming: real-time order book updates, trade feeds, and ticker data
• -- CockroachDB persistence: all orders, trades, and balances durable across restarts

15. Storage

The protocol uses CockroachDB v24.2.0 as the primary relational database for all on-chain state, and IPFS (Kubo) for content-addressed storage of blockchain snapshots and large data blobs. The database schema is organised into 9 domains totaling 55+ tables.

Database Architecture

Schema Domains

IPFS Storage

Schema-Model Alignment Rule

SQL schemas (sql_new/ directory) and SQLAlchemy ORM models (database/models.py) MUST remain synchronized. Past production incidents have resulted from mismatches between these two sources of truth. SQLAlchemy create_all() skips existing tables, so no conflict occurs if SQL runs first, but column definitions, types, and constraints must match exactly.

16. Smart Contracts

The protocol deploys 65 Solidity smart contracts to the QVM, organised into 11 categories. All contracts target Solidity 0.8.24+ with checked arithmetic (no unchecked blocks for overflow/underflow). Contracts are deployed via RPC after genesis; they are NOT auto-deployed at block 0.

17. Higgs Cognitive Field

The Higgs Cognitive Field applies the Standard Model's mass-generation mechanism to the AethersMind cognitive architecture. Just as the Higgs boson gives elementary particles their mass via spontaneous symmetry breaking, the Higgs Cognitive Field assigns cognitive mass (inertia to change) to each Sephirot node, governing how quickly each node can adapt to new information.

Mexican Hat Potential

V(phi) = -mu^2 |phi|^2 + lambda |phi|^4

Parameters:
  VEV (Vacuum Expectation Value) = 174.14     (equilibrium field strength)
  mu^2                           = 88.17      (mass parameter squared)
  lambda                         = 0.129      (quartic self-coupling)

The minimum of V(phi) occurs at |phi| = VEV = sqrt(mu^2 / (2*lambda))
Spontaneous symmetry breaking: phi != 0 at equilibrium

Yukawa Golden Ratio Cascade

Each Sephirot tier receives cognitive mass via Yukawa couplings that follow a golden ratio decay. Higher-tier nodes (closer to Keter) have greater cognitive mass and resist change, while lower-tier nodes (closer to Malkuth) have less mass and correct faster.

Two-Higgs-Doublet Model (2HDM)

SUSY pairs use two Higgs doublets with tan(beta) = phi = 1.618033988749895. The up-type doublet (H_u) couples to expansion nodes (Chesed, Chochmah, Netzach) and the down-type doublet (H_d) couples to constraint nodes (Gevurah, Binah, Hod). The mass gap between H_u and H_d masses for each SUSY pair quantifies the current imbalance.

F=ma Rebalancing Paradigm

SUSY Rebalancing (Newton's Second Law):
  acceleration = force / mass

Where:
  force        = |E_expansion - E_constraint|   (energy imbalance between SUSY pair)
  mass         = cognitive mass from Yukawa coupling
  acceleration = rate of energy redistribution (QBC/block)

Result:
  - Lighter nodes (Yesod, Malkuth) correct fastest (acceleration = force / 25.42)
  - Heavier nodes (Keter) resist change (acceleration = force / 174.14)
  - Creates natural hierarchy: high-level goals stable, low-level actions agile

Excitation Events

When the field value deviates more than 10% from VEV (configurable via HIGGS_EXCITATION_THRESHOLD), a Higgs excitation event is recorded in the higgs_excitations database table. Each excitation triggers a rebalancing cascade across all affected nodes. Excitation amplitude is computed as |field_value - VEV| / VEV.

Configuration

18. BFT Finality

A stake-weighted Byzantine Fault Tolerant finality gadget provides deterministic finality for blocks that receive sufficient validator attestation. Once a block is finalised, chain reorganizations below that height are rejected by all compliant nodes.

Finality Parameters

Protocol

• -- Validators register via /finality/register-validator endpoint with minimum 100 QBC stake
• -- For each block, validators submit signed finality votes via /finality/vote endpoint
• -- A block is finalised when cumulative staked weight of votes exceeds 67% of total registered stake
• -- Once finalised, the node rejects any chain reorganization that would revert blocks at or below the finalised height
• -- Finality status is queryable via /finality/status endpoint

BEEFY and MMR: Portable Finality Proofs (live, spec-172)

GRANDPA gives QBC deterministic finality, but a GRANDPA justification is not a cheap object for an outside party to check. QBC therefore runs BEEFY (Bridge Efficiency Enabling Finality Yielder) as an additive second finality layer on top of GRANDPA, deployed at spec_version 172. GRANDPA remains the only gadget that finalises blocks; BEEFY rides above it. Each block appends one leaf to an on-chain Merkle Mountain Range of block roots, and the validators periodically sign a commitment over the current MMR root. That signed commitment plus a compact Merkle proof is a self-contained proof that a given QBC block is final, verifiable by a light client or a smart contract on another chain without running a full node. It is the standard substrate for trustless bridges, and the shape of proof that scales to the thousand-voter validator sets QBC targets.

• -- Additive and isolated: GRANDPA and block production are never touched; BEEFY runs as a non-essential gadget that can fault without affecting finality
• -- Ethereum-compatible: validators sign with secp256k1 keys stored so the authority set maps onto 20-byte Ethereum addresses, so an EVM verifier can check QBC finality with native operations
• -- MMR accumulator: an append-only Merkle structure of block roots gives a compact inclusion proof for any single block
• -- Live 2026-07-11: all three GRANDPA voters sign with registered BEEFY keys, and beefy_getFinalizedHead advances within a few blocks of the GRANDPA finalised head on every node
• -- Deployed via a mandatory session-key migration (2 keys to 3), rehearsed against live state with try-runtime and confirmed to survive a live validator rotation

19. Security Features

Beyond post-quantum cryptography, the protocol implements four additional security systems: an inheritance protocol, high-security accounts, deniable RPC queries, and governed transaction reversibility.

Inheritance Protocol (Dead-Man's Switch)

• -- Account holders designate a beneficiary address via /inheritance/set-beneficiary
• -- Regular heartbeat signals (/inheritance/heartbeat) reset an inactivity timer
• -- If the timer expires without a heartbeat, the beneficiary can claim account funds via /inheritance/claim
• -- A configurable grace period allows the original owner to reclaim before transfer completes
• -- All inheritance plans are queryable via /inheritance/status/{address}

High-Security Accounts

• -- Per-address security policies configurable via /security/policy/set
• -- Daily spending limits: maximum QBC transferable per 24-hour period
• -- Time-locks: mandatory delay between transaction signing and broadcast
• -- Whitelists: restrict outbound transfers to pre-approved destination addresses
• -- Policies are removable via /security/policy/{address} DELETE endpoint

Deniable RPCs (Privacy-Preserving Queries)

• -- Constant-time batch balance queries (/privacy/batch-balance): query multiple addresses in one request with no timing side-channel revealing which address was the target
• -- Bloom filter UTXO queries (/privacy/bloom-utxos): return UTXOs as a Bloom filter, providing plausible deniability about which UTXOs the querier is interested in
• -- Batch block and transaction fetching (/privacy/batch-blocks, /privacy/batch-tx): retrieve multiple items in one request to obscure interest in specific blocks or transactions

Transaction Reversibility

The reversibility system provides a governor-managed multi-signature mechanism to reverse transactions within a 24-hour window (~26,182 blocks at 3.3s block time). This is implemented both in the Python L1 node and as a Substrate pallet (pallet-qbc-reversibility). The process involves UTXO freezing, governance vote, and creation of reversal UTXOs. Reversibility is intended for theft recovery and regulatory compliance, not routine use.

20. Node Types

The network supports three node configurations with different resource requirements and capabilities.

Storage Growth Projection

At a target block time of 3.3 seconds, the chain produces approximately 9,567,272 blocks per year. With Dilithium5 signatures (~4,627 bytes per signature), transaction capacity is ~217 transactions per MB. Estimated annual storage growth for a full node is ~50GB under moderate transaction volume, primarily driven by UTXO set size, knowledge fabric growth, and quantum state persistence.

21. Substrate Migration

The substrate-node/ directory contains a hybrid Substrate SDK node that mirrors all Python L1 subsystems as native Rust pallets. This node represents the migration target for production deployment, providing Substrate's battle-tested networking, consensus, and runtime upgrade capabilities while preserving all QuantumAI Blockchain-specific protocol features.

Workspace Structure

Pallets

Post-Quantum P2P: ML-KEM-768 (Kyber Transport)

The Substrate node's P2P layer uses ML-KEM-768 (formerly CRYSTALS-Kyber) for post-quantum key encapsulation. A hybrid handshake combines the Noise protocol's classical Diffie-Hellman secret with Kyber's post-quantum shared secret via HKDF-SHA256, producing AES-256-GCM session keys. This provides forward secrecy and quantum resistance simultaneously.

Build Instructions

# Native build (recommended):
cd substrate-node && SKIP_WASM_BUILD=1 cargo build --release

# Binary output:
target/release/qbc-node  (64 MB)

# Test coverage:
356 tests across all crates:
  82 primitives tests (Poseidon2, VQE types, V4 seal hash)
  35 consensus pallet tests (v1/v3/v4 mining, difficulty adjustment)
  27 UTXO pallet tests (double-spend, fee validation)
  46 mining engine tests (VQE, nonce search, cross-validation)
  40 VQE verifier tests (Hamiltonian generation, energy computation)
  27 Kyber transport tests (ML-KEM-768 handshake)
  18 dilithium pallet tests (signature verification)
  12 economics pallet tests (phi-halving, reward calculation)
  11 aether-anchor tests
  10 reversibility pallet tests
  13 bimetric-physics tests
  35 session pallet tests (epoch tracking, miner ranking)

22. Aether V6 Native Generator (Retired Research Track)

Aether V6 was a second-generation AethersMind generator, trained by distillation against a frozen Qwen2.5 0.5B Instruct teacher. The goal was a native Rust + candle transformer that owned the full generation path so the protocol could attest every forward pass on chain and govern per-Sephirot routing via smart contracts. The full specification is published for provenance at docs/AETHER_V6_NATIVE_GENERATOR.md in the source repository.

22.1 Context window as a design feature

Contemporary large language models treat the context window as a hard architectural limit. A 32K-token Qwen-class model attends densely over its window via O(n²) compute and O(n) KV memory. Once the model needs to reason over more tokens than that window holds, the input is truncated or routed through Retrieval-Augmented Generation (RAG), which introduces lossy chunking decisions outside the model.

Recent sparse-attention work (Native Sparse Attention from DeepSeek, arXiv:2502.11089; Mixture-of-Experts attention; sliding-window models such as Mistral 7B) demonstrates that O(n·k) attention with content-dependent routing scales to 1M+ tokens at acceptable compute cost. A commercial release in May 2026 reported a 12M-token forward pass on a Llama-derivative base, which validates the engineering feasibility of the approach.

Aether V6 takes a structurally different position. Context window is not the right metric. The right metric is a model's effective working memory, which in cognition consists of three tiers (hot working memory, semantic recall, archival retrieval) with different access latencies and capacities. The V6 architecture is built around that three-tier hierarchy as a first-class design feature, not as a workaround on top of a monolithic attention buffer.

22.2 The three tiers

                          USER TURN
                              |
                              v
        +------------------------------------------+
        |  L1: In-model attention (1M tokens)      |
        |                                          |
        |  Sephirot expert heads (10) with learned |
        |  domain-affinity gates                   |
        |                                          |
        |  NSA generalist heads. Three branches    |
        |  per head, combined by per-head learned  |
        |  sigmoid gates:                          |
        |      compressed (block-summary)          |
        |      selected   (content-routed top-K)   |
        |      sliding    (local causal window)    |
        |                                          |
        |  Sink anchor heads (2). Always attend to |
        |  the first num_sink_tokens of context.   |
        |                                          |
        |  Latency: tens of milliseconds.          |
        |  GPU-resident KV cache, 4-bit quantised  |
        |  with Sephirot-priority eviction.        |
        +------------------------------------------+
                              ^
                              | retrieve(top-K, query)
                              |
        +------------------------------------------+
        |  L2: Knowledge Fabric (unbounded)        |
        |                                          |
        |  HNSW vector index over 768-dimensional  |
        |  embeddings, sharded across the 10       |
        |  Sephirot domains. Persisted via         |
        |  RocksDB. ~900K live vectors today,      |
        |  growing tens of thousands per day from  |
        |  a diversified ingestion pipeline.       |
        |                                          |
        |  Latency: ~100ms per query.              |
        +------------------------------------------+
                              ^
                              | fetch(vector_id)
                              |
        +------------------------------------------+
        |  L3: RocksDB plus IPFS (cold archive)    |
        |                                          |
        |  Full raw source material backing each   |
        |  L2 vector. Fetched on demand and        |
        |  cached opportunistically into L2.       |
        |                                          |
        |  Latency: seconds.                       |
        +------------------------------------------+

Reading the diagram: a query enters L1. The model attends over its own 1M-token window via Native Sparse Attention. When an attention head requests context beyond that window, the runtime issues an HNSW query against L2 (the Knowledge Fabric). The 558.5M-parameter V5 candle transformer, which previously served as the production φ-measurement engine, is repurposed in V6 as the L2-to-L1 reranker. It reorders the top-200 candidates from HNSW into the top-20 that get injected into the L1 context. L3 services demand misses from L2 by pulling the original content from RocksDB or IPFS.

This is not a bigger context window. It is a multi-tier memory system, analogous to the working-memory / long-term-memory / recall hierarchy that human cognition uses, and approximated by classical CPU caches. Each tier scales independently. L1 ceilings are set by VRAM. L2 grows without bound via continuous ingestion. L3 is filesystem-limited.

22.3 V6 attention specification

The V6 attention layer operates on three parallel paths combined at the output projection.

Sephirot expert path (10 heads). Each head s holds a learned domain-affinity vector gate_s of length head_dim. For each query token at position t in batch b:

g_s(b, t) = sigmoid(  query[b, s, t, :]  dot  gate_s  )
output_seph_s[b, t, :] = g_s(b, t) * causal_attention(query_s, K_seph, V_seph)

The 10 named cognitive domains (Keter, Chochmah, Binah, Chesed, Gevurah, Tiferet, Netzach, Hod, Yesod, Malkuth) each have their own Q, K, V projection slices plus their own gate vector. Specialisation emerges during distillation training, when the Sephirot-aware auxiliary loss pushes each head's gate row to fire for tokens tagged with its named domain.

NSA generalist path (variable count, sized to the base model). Each generalist head runs three branches in parallel:

sliding(q, K, V)    = softmax( mask_window(q K^T / sqrt(d)) ) V
compressed(q, K, V) = softmax( mask_blocks(q Kbar^T / sqrt(d)) ) Vbar
selected(q, K, V)   = softmax( mask_topK(q K^T / sqrt(d)) ) V

where Kbar, Vbar are mean-pooled into blocks of size compression_block_size (default 64), mask_window restricts attention to the last sliding_window_size positions (default 512), and mask_topK keeps only the top-K positions by query-key score (default 2048). The three branch outputs are combined per head per query position via independent sigmoid gates:

output_nsa[b, h, t, :] = g_sliding(b, h, t)    * sliding_h[b, t, :]
                       + g_compressed(b, h, t) * compressed_h[b, t, :]
                       + g_selected(b, h, t)   * selected_h[b, t, :]

The three gates are independent sigmoids in [0, 1], not a softmax. Any combination of branches can be on or off per query. At initialisation sigmoid(0) = 0.5 across all three branches, giving an averaged baseline. Distillation teaches the gates to weight whichever branch serves the current query best.

Sink anchor path (2 heads). Each sink head attends densely to the first num_sink_tokens positions of the cache (default 4). The mechanism is the StreamingLLM attention sink, which prevents sparse-attention drift on very long sequences by giving every query a guaranteed-stable set of anchor positions carrying the system prompt plus the Sephirot routing instructions.

22.4 Sephirot-prioritised KV eviction

Holding 1M tokens of full-precision K/V across 24 decoder layers exceeds the 12 GB VRAM of a consumer GPU. V6 addresses this through three compounding optimisations.

First, 4-bit quantisation of K and V entries (per-channel scale) gives roughly 8x memory reduction. Second, sparse retention: only positions that fall inside an NSA branch's selection (sliding window plus top-K plus sink) stay full-precision in GPU memory; the remainder live in CPU memory or are re-materialised from L2 on demand. Third, when memory pressure forces eviction, the cache evicts tokens in Sephirot priority order:

Malkuth -> Yesod -> Hod -> Netzach -> Gevurah ->
Chesed -> Binah -> Chochmah -> Tiferet -> Keter

Action and sensory state (Malkuth, Yesod) is recoverable from L2 retrieval. Meta-reasoning state (Keter, Tiferet) carries irreducible context and is retained longest. With these three optimisations composed, 1M-token context fits in 12 GB VRAM on a single RTX 3080 Ti.

22.5 Base model and weight remap

V6 inherits its backbone projections from a pre-trained base model. For local-compute distillation on a single 3080 Ti, the V6.0 release locks Qwen2.5 0.5B Instruct as the base. Its 24 layers, 896 hidden dimension, 14 attention heads with head_dim 64, and intermediate FFN of 4864 match the V6 architectural footprint exactly. Vocabulary (151,936 tokens) reuses Qwen2.5's BPE tokenizer for v6.0; the v6.1 release replaces it with a custom Aether BPE that includes Sephirot routing tokens.

Qwen2.5 uses Grouped Query Attention (2 KV heads shared across 14 Q heads). V6 v6.0 runs Multi-Head Attention. The Rust loader load_from_qwen2_5_checkpoint performs a GQA-to-MHA fold at load time: each KV head is tile-broadcast 7 times along the head axis, giving V6's 14 Q heads identical K and V per group. The fold is mathematically equivalent to running the GQA model in MHA mode at inference, at the cost of larger K/V memory. True GQA support in the V6 forward path is a v6.1 architectural change.

V6-specific learnable parameters (10 Sephirot domain gates plus 3 NSA branch gates per layer, around 22K parameters total across 24 layers at the v6.0 0.5B scale) have no analogue in Qwen2.5 and are random-initialised. They learn their named specialisations during the distillation training run.

22.6 Validation against frontier weights

As of 2026-05-17 the V6 architecture is validated end-to-end against real Qwen2.5 0.5B Instruct weights downloaded from HuggingFace.

=== Aether V6 smoke test ===
Target V6 config:
  layers=24, hidden=896, heads=14 (10 sephirot + 2 generalist + 2 sink), head_dim=64

remapping Qwen2.5 0.5B weights into V6 architecture...
  loaded in 2529ms

running V6 forward on prompt [1, 2, 3, 4]...
  forward pass complete in 1019ms
  output shape: [1, 4, 151936]
  expected:     [1, 4, 151936]

Top-5 next-token candidates (raw logits):
  1: token_id= 10124  logit=12.2334
  2: token_id=136382  logit=12.1745
  3: token_id= 28146  logit=11.7927
  4: token_id= 14118  logit=11.7067
  5: token_id= 13956  logit=11.6184

smoke test passed.

Every component, including the GQA fold, all four attention paths, RoPE, KV cache management, Sephirot domain gates, NSA branch gates, and the autoregressive sampling path, executes correctly on real frontier weights. The 30 unit tests in the aether-transformer::v6 module suite all pass. Distillation training (hybrid alpha-annealed KL+CE against the frozen Qwen2.5 teacher) ran through v6.0 to v6.2 before the track was retired in favor of aether-v7.2-unified (see the status note at the top of this section).

22.7 Effective context bound

V6's effective working memory at v6.0 (Qwen2.5 0.5B base):

The L1 ceiling of 1M is a function of VRAM and NSA selection size; it scales linearly with GPU memory. L2 is a function of fabric persistence and grows by ingestion. L3 is bounded by storage cost. Effective context for a query is L1 plus L2 plus L3, in tiers, with the model performing its own retrieval-rerank- inject loop without external RAG plumbing. The combined cognitive memory capacity is unbounded by design.

22.8 What this changes

Three properties of the V6 design are not available in monolithic sparse-attention systems with the same nominal context window:

1. Interpretable routing. Sephirot expert heads are semantically named (Keter for meta-reasoning, Hod for language, Gevurah for safety, and so on). Learned routing in published sparse-attention systems is opaque. V6 routing is inspectable: an operator can ask which Sephirot dominated a given response and read the gate values directly. This matters for debugging, alignment, and on-chain attestation.
2. On-chain attestation per Sephirot. The V5 candle transformer already emits per-block Proof-of-Thought hashes to the Substrate qbc-aether-anchor pallet, with per-Sephirot activation entropy exposed on chain. External verifiers can read the activation distribution of any block without trusting the node. This integration is documented in V6 spec §10.6 and is the Phase 1.4 deliverable.
3. Chain-governed inference. The on-chain Sephirot smart contracts ( SephirahKeter.sol through SephirahMalkuth.sol) hold an isActive flag and a cognitiveMass value. V6 reads these via Substrate RPC at model load time and on slow refresh. Setting isActive = false for a Sephirot via the 3-of-5 governance multi-sig disables that head's contribution on the next inference, without redeploying the model. This provides a real on-chain safety lever distinct from the model's Gevurah refusal head.

The combination of unbounded effective context, interpretable Sephirot routing, on-chain attestation, and chain-governed inference is the architectural surface that distinguishes the AethersMind from both classical RAG systems and recent sparse-attention products.

22.9 V6 status as of May 2026

The architectural work was completed and trained through v6.0 to v6.2, transferring Qwen2.5 0.5B's pretrained behaviour into the V6 architecture while letting the Sephirot and NSA gates specialise. On a proper lm-eval-harness pass the result underperformed standard benchmarks, so the track was retired in favor of aether-v7.2-unified (a 10-expert Sephirot MoE adapter on a frozen Qwen2.5-7B-Instruct base). The full V6 pipeline is documented for provenance in docs/AETHER_V6_NATIVE_GENERATOR.md.