Quantix/Documentation

Quantix Protocol

Complete technical documentation for the post-quantum Layer 1 blockchain.

01Overview

Quantix is an open-source, post-quantum secure blockchain Layer 1 protocol written in Go. It is designed to provide cryptographic security that remains robust against both classical and quantum computing threats — including attacks from sufficiently powerful quantum computers running Shor's or Grover's algorithms.

Traditional blockchains rely on ECDSA (Elliptic Curve Digital Signature Algorithm) for transaction signing. ECDSA is vulnerable to Shor's algorithm, which a quantum computer could use to derive private keys from public keys. Quantix eliminates this attack surface by replacing ECDSA with SPHINCS+, a stateless hash-based signature scheme standardized by NIST as a post-quantum standard.

🐹

Language

Go 1.24

⚖️

Consensus

PBFT + PoS

🔐

Signature

SPHINCS+

◈

Symbol

QTX

💎

Max Supply

5 Billion QTX

🌐

Chain ID

Devnet: 73310

Core Beliefs

◆Privacy is a fundamental human right, not a luxury — enforced by mathematics, not trust.
◆Sovereignty means individuals should have complete control over their digital assets and identity.
◆Humanity must be preserved through technology that serves people, not surveillance systems.

02Architecture

Quantix is structured as a modular Go codebase with clear separation between layers:

Architecture Stack

Application Layer→CLI, HTTP API, WebSocket, RPC

Consensus Layer→PBFT + PoS + RANDAO/VDF

Execution Layer→SVM (Sphinx VM), State Execution

State Layer→Account balances, Nonces, State root

Transaction Layer→Mempool, Validation, UTXO

Cryptography Layer→SPHINCS+, Kyber768, SWIFFTX, STARK

Network Layer→P2P, DHT, TCP/UDP, WebSocket

Storage Layer→LevelDB (blocks, state, keys)

Key Modules

src/consensus/PBFT engine, RANDAO beacon, VDF computation, validator set management, slashing

src/core/Blockchain state, block execution, genesis, transaction types, wallet, SVM opcodes

src/crypto/SPHINCS+ implementation, SWIFFTX hash, STARK proofs, WOTS+ signatures

src/handshake/X25519 + Kyber768 hybrid key exchange for node-to-node encryption

src/p2p/Peer discovery, connection management, message routing

src/dht/Distributed Hash Table for peer discovery using 32-byte crypto secrets

src/pool/Mempool with nonce replay protection, balance checks, gas enforcement

src/state/Storage abstraction, account state, LevelDB interface

03Consensus

Quantix uses a hybrid consensus mechanism combining PBFT (Practical Byzantine Fault Tolerance) with Proof-of-Stake and VDF-based RANDAO for unpredictable, manipulation-resistant randomness.

PBFT + PoS

PBFT provides immediate finality — once a block is committed, it cannot be reversed. The protocol requires ⌊2N/3⌋ + 1 votes (strictly more than two-thirds) for both prepare and commit phases. This ensures safety even if up to ⌊(N-1)/3⌋ validators are Byzantine.

// Correct quorum threshold

required = floor(2 × totalStake / 3) + 1

RANDAO + VDF

Leader election uses a Verifiable Delay Function (VDF) over a class group to produce unbiasable randomness. The VDF requires sequential computation (~1,048,576 squarings) that cannot be parallelized, preventing last-revealer grinding attacks.

→No commit/reveal phases — VDF input is public at slot 0
→1022-bit discriminant — canonical derivation from genesis
→VDF proofs verified — all sync messages require valid Wesolowski proof

Staking Parameters

Min Stake

32 QTX

Block Time

10 seconds

Epoch Length

100 slots

Max Validators

100

Active Set

Unbonding

7 days

Double-sign Slash

0.5 QTX

Block Reward

5 QTX

04Cryptography

Every cryptographic primitive in Quantix is chosen to resist quantum attacks. This is not a future upgrade — it is the current implementation.

SPHINCS+

Transaction Signatures

A stateless hash-based signature scheme standardized by NIST as FIPS 205. Unlike ECDSA, SPHINCS+ security is based entirely on the collision resistance of hash functions — which quantum computers cannot efficiently attack. Key sizes are larger than ECDSA but the security guarantees are provably post-quantum.

Security: 256-bit post-quantumBased on: SHA-256 hash functionsNIST Standard: FIPS 205Stateless: no state to manage

Kyber768

Node Key Exchange

CRYSTALS-Kyber (now ML-KEM, NIST FIPS 203) is a lattice-based key encapsulation mechanism. Quantix uses a hybrid X25519 + Kyber768 handshake: the X25519 component provides classical security while Kyber768 provides post-quantum security. Both must be broken for the handshake to be compromised.

NIST Standard: FIPS 203 (ML-KEM)Hybrid: X25519 + Kyber768Security level: 3 (AES-192 equivalent)Based on: Module Learning With Errors

SWIFFTX

State Hashing

A lattice-based hash function candidate with provable security under worst-case lattice hardness assumptions. Used for block hashing and state root computation. Its security reduces to the hardness of SIVP (Shortest Independent Vectors Problem) on certain lattices.

Provable security under lattice assumptionsSIVP hardness reductionFast: SWIFFT base + HAIFA modeMultiple output sizes: 224/256/384/512

libSTARK

Zero-Knowledge Proofs

Scalable Transparent ARguments of Knowledge. STARKs require no trusted setup (transparent), use only hash functions (post-quantum secure), and produce succinct proofs that can be verified quickly. Used for proving computational integrity without revealing the computation itself.

No trusted setup requiredTransparent: public randomness onlyPost-quantum: hash functions onlyScalable: O(log² n) verification

05Tokenomics

Token Details

NameQuantix

SymbolQTX

Base UnitnQTX (nano-QTX)

Precision1 QTX = 10¹⁸ nQTX

Max Supply5,000,000,000 QTX

Block Reward5 QTX

BIP44 Coin Type7331

Supply Distribution

Public Sale30%

Staking Rewards25%

Ecosystem Fund20%

Team & Advisors15%

Reserve10%

Fee Structure

Transaction fees in Quantix use a gas model similar to Ethereum but with post-quantum signature overhead accounted for in gas calculations. Gas limit and gas price are set by the transaction sender. Block gas limit is 10,000,000 units per block.

// Fee calculation

fee = gas_used × gas_price (in nQTX)

// SPHINCS+ signature overhead

sig_gas = 21000 base + 10000 sphincs_overhead

06Network

MainnetPlanned

Chain ID7331

P2P Port32307

HTTP Port8560

WS Port8700

TestnetPlanned

Chain ID17331

P2P Port32308

HTTP Port8560

WS Port8700

DevnetActive

Chain ID73310

P2P Port32309

HTTP Port8560

WS Port8700

P2P Protocol

Nodes communicate via TCP for block propagation and consensus messages, and UDP for peer discovery via DHT. All node-to-node communication is encrypted using the hybrid X25519 + Kyber768 handshake. DHT authentication uses 32-byte cryptographic secrets generated via crypto/rand.

07Run a Node

Prerequisites

✓Go 1.24 or higher
✓Linux or macOS (Windows experimental)
✓4GB RAM minimum (8GB recommended)
✓50GB disk space
✓Stable internet connection

Build from Source

terminal

# Clone the repository
git clone https://github.com/ramseyauron/quantix.git
cd quantix

# Build the binary
go build -o bin/quantix ./src/cli/main.go

# Run a devnet validator node
./bin/quantix \
  -nodes 1 \
  -node-index 0 \
  -roles validator \
  -datadir ./data \
  -http-port 0.0.0.0:8560 \
  -udp-port 32421 \
  -tcp-addr 0.0.0.0:32421

CLI Flags

-nodesNumber of nodes to initialize (default: 1)

-node-indexIndex of the node to run (0 to N-1) (default: 0)

-rolesComma-separated roles: validator, sender, receiver, none (default: none)

-datadirDirectory for LevelDB storage (default: ./data)

-http-portHTTP port for JSON API (default: 127.0.0.1:8560)

-tcp-addrTCP address for P2P communication (default: 0.0.0.0:32307)

-udp-portUDP port for peer discovery (default: 32308)

-ws-portWebSocket port (default: 127.0.0.1:8600)

-seedsComma-separated seed node UDP addresses

08API Reference

The Quantix node exposes a JSON HTTP API on port 8560 by default.

GET/Node status, blockchain info, available endpoints

GET/blockcountReturns current block count

GET/bestblockhashReturns the hash of the latest block

GET/block/:idReturns full block data by height (0-indexed)

GET/address/:addrReturns balance, total sent/received, tx count for an address

GET/address/:addr/txsReturns all transactions for an address with direction (IN/OUT)

GET/latest-transactionReturns the most recently submitted transaction

GET/metricsPrometheus metrics endpoint

POST/transactionSubmit a new transaction

POST/mineTrigger devnet block mining (requires DEVNET_MINE_SECRET header)

Transaction Format

POST /transaction

{
  "id": "tx-unique-identifier",
  "sender": "0xSenderAddress",
  "receiver": "0xReceiverAddress", 
  "amount": 1000000000000000000,  {/* in nQTX (1 QTX = 10^18) */}
  "gas_limit": 21000,
  "gas_price": 1000000000,       {/* in nQTX */}
  "nonce": 1,                    {/* must be > last nonce */}
  "timestamp": 1712000000,
  "signature": ""                {/* SPHINCS+ signature (devnet: empty) */}
}

09Security

Quantix underwent a comprehensive internal security audit in April 2026 covering cryptographic correctness, consensus safety, transaction validation, network security, and code quality. All 27 findings were resolved before devnet launch.

Critical

✓ 4 fixed

High

✓ 7 fixed

Medium

✓ 8 fixed

Low + Info

✓ 8 fixed

Key Security Properties

✓PBFT quorum uses ⌊2N/3⌋ + 1 (correct BFT threshold)
✓RANDAO sync requires VDF proof verification — no unauthenticated state overwrites
✓DHT uses 32-byte crypto/rand secrets — not brute-forceable
✓All node key material is never logged (removed from all code paths)
✓HTTP rate limiting: 100 req/s per IP with burst cap of 20
✓CORS restricted to configured origins (via CORS_ALLOWED_ORIGINS env var)
✓Transaction nonce replay protection in mempool
✓/mine endpoint requires DEVNET_MINE_SECRET header
✓VDF parameters unified to single strong code path (1022-bit discriminant)

10Roadmap

Phase 1Foundation

Apr–May 2026In Progress

→Real state execution (ExecuteBlock)
→Persistent account state (LevelDB)
→Balance validation in mempool
→CI/CD pipeline
→Unit test coverage ≥70%

Phase 2Multi-Node Testnet

May–Jun 2026Planned

→4-validator PBFT consensus
→Node sync protocol
→Network partition handling
→Docker multi-node setup
→Prometheus + Grafana monitoring

Phase 3Hardening

Jun–Jul 2026Planned

→Production DHT peer discovery
→Validator join/leave protocol
→Load testing (1000 tx/s)
→External security audit
→Complete documentation

Phase 4Public Testnet

Jul 2026+Planned

→Public validator onboarding
→Bug bounty program
→Faucet for test QTX
→Block explorer public launch
→Community governance proposal

← Back to Home Edit on GitHub →