# Quantix Protocol: A Post-Quantum Sovereign Blockchain for the Age of Artificial Intelligence **Authors:** Quantix Core Team **Version:** v1.0.0 — April 2026 **Contact:** research@qpqb.org **Repository:** https://github.com/qpqb-org/quantix --- ## Abstract The next decade will be defined by two converging technological forces: the maturation of quantum computing and the proliferation of artificial intelligence. Together, they pose an existential threat to the cryptographic foundations upon which modern blockchain networks are built. Elliptic curve cryptography—the backbone of Bitcoin, Ethereum, and virtually every major distributed ledger—is provably vulnerable to Shor's algorithm running on a sufficiently powerful quantum computer. At the same time, AI-driven adversaries can now synthesize identities, forge behavioral patterns, and generate fraudulent transactions at scale, undermining the social and economic trust that blockchains are designed to formalize. Existing blockchain protocols were not designed for this threat landscape. Their cryptographic primitives were selected for computational efficiency in a classical world, not resilience against quantum adversaries. Proposed upgrades are largely additive—layered on top of architectures that remain fundamentally classical at their core. They treat post-quantum cryptography as an optional extension rather than a foundational requirement. Quantix Protocol is built differently. Originally conceived as the Sphinx Protocol and refined over two years of research and development, Quantix is a Layer 1 blockchain designed from first principles for post-quantum security and sovereign identity. Every component—signatures, key exchange, hashing, randomness generation, and zero-knowledge proofs—is selected specifically for resistance to quantum attack, with formal security reductions where available. This whitepaper presents the Quantix Protocol in full technical detail: its threat model, cryptographic foundations, consensus mechanism, tokenomics, and network architecture. It also introduces the integration with the Universal Sovereign Identity (USI) system, a companion protocol developed by Kusuma that elevates identity to a first-class primitive within the Quantix ecosystem. Together, Quantix and USI form a coherent vision: a blockchain that is not merely quantum-resistant, but cryptographically sovereign—where identity, transactions, and state are protected by mathematics that will remain hard not just today, but for decades to come. Quantix is implemented in Go 1.24, audited by an independent security firm (April 2026, 27 findings resolved), and is currently progressing through a structured roadmap toward public testnet launch. --- ## Table of Contents 1. Introduction 2. Threat Model 3. Cryptographic Foundations 4. Consensus Mechanism 5. Tokenomics 6. Network Architecture 7. Universal Sovereign Identity Integration 8. Security Analysis 9. Roadmap 10. Conclusion 11. References --- ## 1. Introduction ### 1.1 The Dual Threat Blockchain technology rests on a deceptively simple promise: that cryptographic hardness guarantees make certain computations infeasible. Transfer ownership of a digital asset and the world can verify it; attempt to forge or reverse that transfer and the mathematics will stop you. This promise has held for over fifteen years across hundreds of billions of dollars of economic activity. It is now under threat from two directions simultaneously. **The quantum threat** is well-documented in cryptographic literature, though its urgency is frequently underestimated in blockchain discussions. The Elliptic Curve Digital Signature Algorithm (ECDSA), used by Bitcoin, Ethereum, and the vast majority of deployed blockchains, derives its security from the assumed hardness of the elliptic curve discrete logarithm problem (ECDLP). Shor's algorithm, when run on a cryptographically relevant quantum computer (CRQC), solves ECDLP in polynomial time—rendering ECDSA signatures forgeable. A sufficiently powerful quantum adversary could derive private keys from public keys, sign arbitrary transactions on behalf of any address, and drain accounts at will. The timeline for CRQCs is contested, but the direction of travel is not. IBM's quantum roadmap targets error-corrected logical qubits in the late 2020s. Google's recent demonstrations of quantum advantage, while not cryptographically relevant, demonstrate exponential improvement trajectories. NIST's decade-long post-quantum standardization effort—culminating in the publication of FIPS 203, 204, and 205 in 2024—represents an institutional acknowledgment that the threat is real and the migration window is finite. Critically, blockchain data recorded today may be harvested now and decrypted later: a "harvest now, decrypt later" attack means the quantum threat to blockchain is not merely future—it is present. **The AI threat** is newer and less formalized, but no less serious. Large language models and generative AI systems can now produce synthetic text, audio, video, and behavioral patterns indistinguishable from human-generated content. In the blockchain context, this creates several attack vectors: AI-generated phishing attacks that convincingly impersonate protocol developers or validators; synthetic identities that pass KYC checks and accumulate governance power; AI-optimized transaction patterns designed to exploit MEV, gaming fee markets, or triggering oracle manipulation. Perhaps most concerning is the application of AI to social engineering attacks against validators—where a sufficiently convincing synthetic persona could influence off-chain coordination in ways that undermine on-chain consensus. ### 1.2 Why Existing Solutions Are Insufficient The blockchain industry has not been idle. Projects such as the Ethereum Foundation's post-quantum research group, the QRL (Quantum Resistant Ledger), and various academic proposals have begun addressing the quantum threat. However, these approaches share a common structural limitation: they retrofit post-quantum primitives onto architectures designed around classical cryptography. The result is analogous to fitting modern armor to a medieval castle—the armor may be stronger, but the underlying structure was not built to support it. Consider Ethereum's roadmap toward post-quantum signatures: the plan involves replacing ECDSA at the account level while leaving vast portions of the protocol stack—P2P encryption, validator communication, internal hashing—reliant on classical constructions. This creates a security boundary that is quantum-resistant at precisely one interface while remaining vulnerable elsewhere. An adversary need only find the weakest link. The AI threat is even less addressed. No major blockchain protocol has incorporated identity primitives that are resistant to AI-synthesized impersonation. Governance systems remain vulnerable to coordinated Sybil attacks using synthetic identities. Identity is typically either absent (pseudonymous addresses) or outsourced to off-chain systems that apply no cryptographic guarantees. ### 1.3 Quantix's Approach: Cryptographic Sovereignty at the Protocol Level Quantix takes a different approach: post-quantum security is not a feature added to the protocol—it is the protocol. Every cryptographic primitive was selected before a single line of production code was written. The threat model informed the architecture, not the other way around. "Cryptographic sovereignty" is Quantix's design principle: the idea that a user's digital identity, assets, and actions should be secured by cryptographic primitives over which they have full control, which are verifiable by anyone, and which remain hard to break for any adversary—classical or quantum—operating within the constraints of physics. It means that sovereignty is not merely legal or political but mathematical. This extends to the identity layer. Quantix's native address space is designed for compatibility with the Universal Sovereign Identity (USI) system, described in a companion whitepaper by Kusuma (v0.0.1, March 2026). USI defines a framework for post-quantum self-sovereign identity that anchors cryptographic fingerprints to a user's long-term identity, without reliance on centralized identity providers. Section 7 of this document describes how Quantix and USI integrate. ### 1.4 Document Scope This whitepaper covers the Quantix Protocol at the Layer 1 level: cryptographic primitives, consensus mechanism, token economics, network architecture, and security analysis. It is intended for a technically sophisticated audience—protocol engineers, cryptographers, institutional validators, and serious developers. Readers interested in the identity layer specifically are directed to Kusuma's USI whitepaper. Readers interested in application-layer development will find API documentation at the Quantix developer portal. --- ## 2. Threat Model ### 2.1 The Quantum Adversary The primary cryptographic threat to legacy blockchain systems is a cryptographically relevant quantum computer (CRQC) capable of running Shor's algorithm at scale. To understand the severity, consider the mathematics. ECDSA security rests on the computational intractability of the elliptic curve discrete logarithm problem: given points G and Q on an elliptic curve where Q = kG, find the scalar k. On a classical computer, the best known algorithms (Pollard's rho, baby-step giant-step) require O(√n) time, where n is the group order—on the order of 2^128 operations for a 256-bit curve. This is computationally infeasible with any classical hardware. Shor's algorithm, executed on a CRQC, reduces this to polynomial time: O((log n)^3). For a 256-bit elliptic curve, this requires on the order of 2,000-4,000 logical qubits with full error correction. While today's quantum computers operate with hundreds of noisy physical qubits, the scaling trajectory and continued investment in quantum error correction make a CRQC a matter of engineering, not physics. The "harvest now, decrypt later" attack vector deserves special emphasis. All public blockchain transactions are permanently recorded and publicly accessible. An adversary can today collect the public keys of every Bitcoin and Ethereum address, store them at trivial cost, and decrypt them when a CRQC becomes available. This means that assets held in wallets with exposed public keys (which includes any address that has ever sent a transaction) are already at long-term risk. The migration window for blockchain systems is not years—it is the time remaining before CRQCs arrive, minus the time needed to migrate. ### 2.2 The AI Adversary The AI threat to blockchain is less mathematical and more systemic, but no less serious. We identify three primary attack surfaces: **Synthetic identity attacks:** AI systems can now generate synthetic personas with consistent histories, behavioral patterns, and even voice/video representations. In blockchain governance, this enables the creation of coordinated fleets of synthetic validators or governance participants that appear independent but are controlled by a single adversary. Without strong identity primitives anchored in hard cryptographic assumptions, governance systems are vulnerable to such attacks at scale. **AI-optimized transaction attacks:** Machine learning systems can analyze mempool dynamics, validator behavior, and smart contract logic to identify and exploit economic vulnerabilities—MEV extraction, oracle manipulation, fee market gaming—far more efficiently than human adversaries. The Quantix consensus design limits these attack surfaces through deterministic finality and epoch-based randomness. **Social engineering of validators:** Validators are human operators. AI-generated communications—convincingly impersonating protocol developers, other validators, or institutional partners—can influence off-chain coordination in ways that have on-chain consequences. Quantix's mandatory SPHINCS+ signatures on all protocol communications ensure that any authenticated message can be verified against a registered public key, making impersonation cryptographically detectable. ### 2.3 Cryptographic Sovereignty in Practice "Cryptographic sovereignty" in the Quantix context means: 1. **Self-custody is cryptographically enforced:** No third party can sign on a user's behalf without their SPHINCS+ private key. There is no backdoor, no escrow, no threshold recovery scheme that reintroduces a trusted third party. 2. **Quantum resistance is complete, not partial:** All cryptographic operations—signatures, key exchange, hashing, randomness—use post-quantum or quantum-resistant constructions. There is no classical weak link. 3. **Identity is verifiable without disclosure:** Through libSTARK zero-knowledge proofs, users can prove properties about their identity (membership, credential validity, stake ownership) without revealing the underlying data. 4. **Randomness is unbiasable:** The VDF-based RANDAO ensures that validator selection and epoch randomness cannot be manipulated by any validator or coalition of validators, preserving the integrity of the consensus process. --- ## 3. Cryptographic Foundations The cryptographic design of Quantix is the product of selecting the strongest available post-quantum primitives for each role in the protocol. This section describes each primitive in detail. ### 3.1 SPHINCS+: Stateless Hash-Based Signatures Transaction and block signatures in Quantix use SPHINCS+, standardized by NIST as FIPS 205 (SLH-DSA) in August 2024. SPHINCS+ belongs to the family of hash-based signature schemes, whose security rests on a single assumption: the collision resistance and preimage resistance of the underlying hash function. Unlike lattice-based or code-based schemes, hash-based signatures do not require novel mathematical hardness assumptions—their security reduces to the hardness of inverting a hash function, which is believed to be quantum-resistant (Grover's algorithm provides only a quadratic speedup for preimage search, requiring a 256-bit hash to provide 128-bit post-quantum security). The key innovation of SPHINCS+ over earlier hash-based schemes (XMSS, LMS) is that it is *stateless*. Stateful hash-based schemes require the signer to track which one-time key pairs have been used, creating operational complexity and catastrophic failure modes if state is lost or replicated. SPHINCS+ uses a hypertree structure—a multi-layer tree of few-time signature schemes (FORS) and Winternitz one-time signatures—that eliminates the state requirement entirely. A signer can generate signatures independently and in parallel without any risk of key reuse. **Trade-offs:** SPHINCS+ signatures are larger than ECDSA signatures—approximately 7-49 KB depending on the parameter set, compared to 64 bytes for ECDSA. Quantix uses the SPHINCS+-SHAKE-256f parameter set, which provides 128-bit post-quantum security with a signature size of approximately 49 KB and signing time under 10 milliseconds on modern hardware. The fee model (Section 5.4) accounts for this overhead explicitly, ensuring that the larger signature size does not create an unfair economic burden on users. **Example:** When Alice sends 100 QTX to Bob, her transaction is signed with her SPHINCS+ private key. Any node in the network can verify this signature using only Alice's registered public key and the SHAKE-256 hash function. Even a CRQC running Shor's algorithm cannot forge Alice's signature—there is no algebraic structure to exploit, only hash function preimages. ### 3.2 Kyber768 + X25519: Hybrid Key Exchange Peer-to-peer encrypted communication in Quantix uses a hybrid key exchange combining X25519 (classical Diffie-Hellman on Curve25519) and Kyber768 (NIST FIPS 203, ML-KEM), implemented as a dual-encapsulation scheme. The hybrid approach is deliberate and principled. X25519 provides excellent performance and well-understood classical security (the Decisional Diffie-Hellman assumption on Curve25519). Kyber768 provides post-quantum security based on the Module Learning With Errors (MLWE) problem, which is conjectured to be hard for both classical and quantum adversaries. Combining them means that an adversary must break *both* schemes to compromise the session key—a "belt and suspenders" approach that protects against the possibility that either primitive turns out to be weaker than expected. Concretely, during a handshake between two Quantix nodes, both parties perform an X25519 key exchange and a Kyber768 key encapsulation. The resulting shared secrets are combined using a KDF (SHAKE-256), producing a session key that is secure if either X25519 or Kyber768 is secure. This design future-proofs the network: if X25519 falls to a CRQC, Kyber768 continues to protect communications; if Kyber768 is broken by a classical mathematical advance, X25519 continues to provide security. Kyber768 offers 128-bit post-quantum security, with public key size of 1,184 bytes and ciphertext size of 1,088 bytes—modest overhead for a key exchange that occurs once per connection. ### 3.3 SWIFFTX: Lattice-Based Hashing Internal state hashing in Quantix—including Merkle tree construction, block header hashing, and state root computation—uses SWIFFTX, a lattice-based hash function designed as a candidate for the NIST SHA-3 competition. SWIFFTX is built on the SWIFFT family of hash functions, whose security has a provable reduction to the Short Integer Solution (SIS) problem over ideal lattices, which is in turn related to the Shortest Independent Vectors Problem (SIVP) in the worst case. This is a significant security property: breaking SWIFFTX is at least as hard as solving worst-case lattice problems, which are believed to be hard for quantum computers. Grover's algorithm does not apply efficiently to lattice problems, unlike discrete logarithm or factoring. The provable security reduction distinguishes SWIFFTX from cryptographic hash functions like SHA-256 or Keccak, whose security is based on heuristic evidence and cryptanalytic resistance rather than formal reductions. In a post-quantum setting where our confidence in classical hardness assumptions is being reconsidered, the provable security of SWIFFTX is a meaningful advantage. **Performance:** SWIFFTX achieves throughput comparable to SHA-256 on modern hardware, making it practical for the high-frequency hashing required in block processing. Quantix nodes hash thousands of transactions per epoch; SWIFFTX's performance characteristics ensure this does not become a bottleneck. ### 3.4 libSTARK: Transparent Zero-Knowledge Proofs Quantix integrates libSTARK for zero-knowledge proof generation and verification. STARKs (Scalable Transparent ARguments of Knowledge) provide several properties critical for a sovereign blockchain: **Transparency:** STARKs require no trusted setup. Unlike SNARKs (used in Zcash and similar systems), which require a structured reference string generated in a trusted ceremony, STARKs derive their security from the random oracle model alone. There is no "toxic waste"—no set of secrets whose compromise would allow forgery of proofs. This is essential for a system claiming cryptographic sovereignty: a trusted setup ceremony is itself a point of centralization and potential compromise. **Post-quantum security:** STARK security relies on the collision resistance of hash functions (specifically, the FRI proximity protocol uses Merkle commitments). As with SPHINCS+, Grover's algorithm provides only a quadratic speedup against hash function preimage search, maintaining the essential security of STARKs against quantum adversaries when sufficiently large hash outputs are used. **Scalability:** STARKs have proof size O(log² n) and verification time O(log² n) in the computation size n. While proofs are larger than SNARKs in the concrete setting, their verification is fast and their generation can be parallelized efficiently. In Quantix, libSTARK is used for: (1) proving stake ownership without revealing wallet contents, (2) validating membership in the active validator set without exposing the full set, and (3) enabling the USI identity layer to prove credential properties without disclosure. Future protocol versions will extend STARK usage to full execution trace verification for smart contract execution. ### 3.5 VDF-Based RANDAO: Unbiasable Randomness Validator selection and epoch transitions in Quantix require publicly verifiable, unbiasable randomness. Quantix uses a VDF-enhanced RANDAO scheme based on class group sequential squarings. **The RANDAO problem:** A naive RANDAO (where validators contribute randomness by revealing pre-committed values) is vulnerable to last-revealer attacks: the last validator to reveal their contribution can compute the outcome before committing, and choose to withhold their contribution if the outcome is unfavorable, biasing the randomness at the cost of losing their block reward. **Quantix's VDF solution:** Each epoch's randomness seed is processed through a Verifiable Delay Function (VDF) based on repeated squaring in a class group of imaginary quadratic fields. The class group has a 1022-bit discriminant, and the VDF requires T = 2^20 sequential squarings—a computation that takes a fixed, predictable amount of time regardless of the hardware used (because squarings are inherently sequential; they cannot be parallelized). The output of the VDF is accompanied by a Wesolowski proof, which allows any node to verify in O(log T) time that the VDF was computed correctly, without repeating the computation. This provides succinct verifiability for an otherwise expensive sequential computation. **Why this eliminates last-revealer bias:** By the time any validator could compute the VDF output corresponding to a manipulated RANDAO seed, the window for influencing that seed has long passed. The sequential squaring time (calibrated to span multiple blocks) ensures that VDF output cannot be predicted in advance of the RANDAO closing. Validators gain nothing by withholding: the VDF output is determined before they would benefit from the information. **Post-quantum security:** The hardness of the VDF relies on the sequential squaring assumption in class groups—specifically, that there is no algorithm significantly faster than sequential squaring. This assumption is believed to be quantum-resistant: Shor's algorithm does not apply to class group order computation in the general case, and no quantum speedup for sequential squaring is known. --- ## 4. Consensus Mechanism ### 4.1 PBFT Overview Quantix uses Practical Byzantine Fault Tolerance (PBFT), introduced by Castro and Liskov in 1999, as its core consensus protocol, enhanced with a Proof-of-Stake validator selection mechanism. PBFT is a state machine replication protocol designed to tolerate up to f Byzantine (arbitrarily malicious) failures in a system of N = 3f + 1 or more replicas. It provides strong consistency guarantees: once a block is committed by PBFT, it is final—there are no forks, no probabilistic finality, no need to wait for additional confirmations. This deterministic finality is essential for financial applications and identity systems where transaction irreversibility must be guaranteed. PBFT operates in three phases for each block proposal: - **Pre-prepare:** The primary (proposer) broadcasts a block proposal with a sequence number and view number. - **Prepare:** Validators broadcast prepare messages confirming they have received and validated the proposal. - **Commit:** Once a validator has collected a quorum of prepare messages, it broadcasts a commit message. Once a quorum of commit messages is collected, the block is finalized. The protocol tolerates up to f = ⌊(N-1)/3⌋ Byzantine validators. With N = 21 active validators, Quantix tolerates up to 6 Byzantine validators while maintaining liveness and safety. ### 4.2 Proof-of-Stake Integration Quantix's active validator set is selected through Proof-of-Stake. The protocol maintains a registered validator pool of up to 100 validators and an active committee of 21 validators per epoch. **Staking requirements:** - Minimum stake: 32 QTX - Stake is locked for the duration of the epoch; unstaking is processed at epoch boundaries - Validators submit a registration transaction including their SPHINCS+ public key, Kyber768 public key, and stake amount **Validator selection:** At each epoch boundary, the VDF-based RANDAO (Section 3.5) produces an unbiasable seed used to select 21 active validators from the registered pool. Selection is stake-weighted: a validator controlling 10% of total staked QTX has a 10% probability of being included in the active committee, adjusted for the committee size constraint. **Why 21 active validators:** The active committee size of 21 balances security, liveness, and communication complexity. PBFT's message complexity is O(N²) per block; 21 validators require at most 441 messages per round—well within network capacity at 10-second block times. Larger committees increase security but degrade performance; 21 provides f = 6 Byzantine fault tolerance, which is conservative for an initial deployment. ### 4.3 Correct Quorum: ⌊2N/3⌋ + 1 A subtle but critical implementation detail in Quantix's consensus is the correct computation of the Byzantine fault-tolerant quorum threshold. The quorum required for PBFT prepare and commit phases is: ``` quorum = ⌊2N/3⌋ + 1 ``` This is distinct from the naively rounded `⌈2N/3⌉` or the floating-point `round(2N/3)`. With N = 21: - `⌊2×21/3⌋ + 1 = ⌊14⌋ + 1 = 15` - `⌈2×21/3⌉ = ⌈14⌉ = 14` (incorrect—one short of the required threshold) The difference matters: with quorum = 14, an adversary controlling 7 of 21 validators (one more than the f = 6 tolerance) could potentially form two non-overlapping quorums, violating safety. With quorum = 15, any two quorums of 15 must share at least one honest validator, preserving the PBFT safety invariant. This precise computation—integer floor division followed by explicit addition of 1—was a finding in the April 2026 security audit and has been corrected in the production implementation. The audit finding underscores that Byzantine fault tolerance is a precise mathematical requirement, not an approximation. ### 4.4 View Change Protocol PBFT's liveness depends on an eventual change to a new primary when the current primary is faulty or unavailable. Quantix implements the PBFT view change protocol with the following parameters: - **View change timeout:** If a validator does not observe a valid block proposal within one slot (10 seconds), it broadcasts a `VIEW-CHANGE` message for view v+1. - **New view threshold:** A new primary is established when ⌊2N/3⌋ + 1 validators have broadcast VIEW-CHANGE messages for the same new view. - **New primary selection:** The primary for view v is validator[v mod N] from the current active committee, ordered by stake weight (descending) with ties broken by public key hash. View changes are infrequent in practice—they occur only when the primary fails to produce a valid block within the slot window. During normal operation, the protocol proceeds through pre-prepare/prepare/commit without interruption. ### 4.5 Slashing and Accountability Quantix enforces validator accountability through slashing: the automatic reduction of a validator's stake for provable misbehavior. Slashable offenses include: - **Double voting:** Signing two different blocks at the same height and view (equivocation). Evidence: two valid SPHINCS+ signatures on conflicting blocks from the same validator. - **Invalid block proposal:** Proposing a block with an invalid state transition or invalid SPHINCS+ signature. - **RANDAO withholding:** Failing to submit a required RANDAO contribution during an epoch (penalized with a partial stake reduction, not full slashing). Slashing evidence is submitted on-chain and verified by the protocol. A slashed validator loses a configurable fraction of their stake (initially 50% for equivocation) and is removed from the validator pool for a cooldown period of 10 epochs. ### 4.6 Epoch Structure Quantix organizes time into epochs of 100 slots, each slot being 10 seconds: ``` Epoch duration = 100 slots × 10 seconds/slot = 1,000 seconds ≈ 16.7 minutes ``` At each epoch boundary: 1. The VDF computation for the new epoch's randomness is finalized and verified. 2. New active validators are selected from the registered pool using the fresh randomness. 3. Pending stake operations (registrations, unstaking requests) are processed. 4. Slashing evidence accumulated during the epoch is processed. 5. Block rewards are distributed to the active validators of the concluding epoch. The epoch boundary is a clean separation between operational periods, simplifying the implementation of stake management, validator rotation, and reward distribution. --- ## 5. Tokenomics ### 5.1 QTX Token Design The native token of the Quantix Protocol is QTX. It serves three functions: staking collateral for validators, payment of transaction fees, and governance participation (in future protocol versions). **Supply parameters:** - Maximum supply: 5,000,000,000 QTX (5 billion) - Base unit: nQTX (nano-QTX), where 1 QTX = 10^18 nQTX - All protocol-internal arithmetic is performed in nQTX to avoid floating-point errors The 10^18 precision matches Ethereum's wei denomination, enabling straightforward tooling compatibility while maintaining Quantix's independent security model. The large precision prevents rounding attacks in fee computation and ensures that even very small transaction values can be represented exactly. ### 5.2 Block Rewards Each successfully finalized block distributes a reward of 5 QTX, split among the active validators according to their participation in that block's consensus: - **Primary (block proposer):** 40% of block reward (2 QTX) - **Remaining active validators who submitted valid prepare/commit signatures:** 60% divided equally At the current block time of 10 seconds, the annual block reward issuance is approximately: ``` 5 QTX/block × 6 blocks/minute × 60 minutes/hour × 24 hours/day × 365 days/year ≈ 157,680,000 QTX/year ``` This represents approximately 3.15% annual issuance against the maximum supply in the first year, declining as a percentage as more of the supply is distributed. ### 5.3 Token Distribution | Allocation | Percentage | Amount (QTX) | Vesting | |---|---|---|---| | Public Sale | 30% | 1,500,000,000 | TGE + 12 months linear | | Staking Rewards | 25% | 1,250,000,000 | Emitted via block rewards | | Ecosystem Fund | 20% | 1,000,000,000 | 36 months linear, DAO-governed | | Core Team | 15% | 750,000,000 | 12-month cliff, 36 months linear | | Protocol Reserve | 10% | 500,000,000 | DAO-governed, emergency use | The staking rewards allocation represents the protocol's commitment to validator sustainability beyond early block reward issuance. As block rewards decline over time (through governance-adjustable parameters), the staking rewards pool provides long-term incentives for network security. ### 5.4 Fee Model Transaction fees in Quantix are denominated in nQTX and computed as: ``` fee = gas_used × gas_price ``` where `gas_used` reflects the computational and storage cost of the transaction, and `gas_price` is set by the transaction sender (with a protocol-enforced minimum floor that adjusts with network load). **SPHINCS+ overhead accounting:** Because SPHINCS+ signatures are significantly larger than ECDSA signatures (approximately 49 KB vs. 64 bytes), the gas model explicitly accounts for the bandwidth and storage cost of signature verification. The base transaction gas cost includes a SPHINCS+ verification component, ensuring that the economics of the network reflect its actual resource consumption. This prevents the larger signature size from being a hidden tax on users—it is priced transparently. Transaction fees are split: - 70% burned (reducing circulating supply) - 30% distributed to the block's active validator set The burn mechanism creates deflationary pressure that partially offsets block reward issuance over time. ### 5.5 Inflation and Sustainability The net inflation rate of QTX depends on the balance between block reward issuance and fee burning. At steady-state network usage, the protocol is designed to approach a neutral or slightly deflationary supply trajectory within 5-7 years. The specific parameters (block reward, burn fraction, minimum gas price) are adjustable through on-chain governance, allowing the community to adapt to changing economic conditions. The protocol's economic design philosophy prioritizes long-term validator sustainability over short-term token price. A network with insufficient validator rewards will degrade in security as validators exit; Quantix's staking rewards pool provides a runway of approximately 8 years of block reward equivalent even if all other revenue sources ceased. --- ## 6. Network Architecture ### 6.1 P2P Layer Quantix's peer-to-peer network is built on a Distributed Hash Table (DHT) for peer discovery and routing, with separate transport protocols optimized for different message types: - **TCP:** Used for block propagation, transaction relay, and state synchronization. TCP's reliability guarantees are important for these large, ordered messages. - **UDP:** Used for peer discovery, gossip, and time-sensitive consensus messages where low latency matters more than guaranteed delivery. Each node generates a 32-byte cryptographically random DHT secret using Go's `crypto/rand` package (not the weaker `math/rand`). This secret is used to derive the node's DHT identity key, which determines its position in the routing table and prevents Sybil attacks in peer discovery—an adversary cannot cheaply generate DHT identities that cluster around a target without a corresponding cost in random key generation. The use of `crypto/rand` for DHT secret generation was a specific finding in the April 2026 security audit (corrected from an earlier use of `math/rand`). Predictable DHT identities would allow an adversary to systematically eclipse honest nodes from the network. ### 6.2 Hybrid Handshake All node-to-node connections are established using the hybrid X25519 + Kyber768 handshake described in Section 3.2. The handshake proceeds as follows: 1. **Initiator** generates an X25519 ephemeral keypair and a Kyber768 keypair. 2. **Initiator** sends their X25519 public key and Kyber768 public key to the responder. 3. **Responder** performs X25519 key agreement and Kyber768 encapsulation, generating two shared secrets. 4. **Responder** sends their X25519 public key and the Kyber768 ciphertext to the initiator. 5. **Initiator** performs X25519 key agreement and Kyber768 decapsulation, recovering both shared secrets. 6. Both parties derive the session key as `SHAKE-256(X25519_secret || Kyber768_secret || nonce)`. The combined session key is secure as long as either X25519 or Kyber768 is secure. The nonce prevents replay attacks across sessions. ### 6.3 API Layer Quantix exposes three API interfaces for external integrations: - **JSON HTTP API:** A RESTful API for standard operations (submit transaction, query balance, get block, get transaction). Endpoints follow a conventional `/v1/` prefix structure. Suitable for wallets, explorers, and light clients. - **WebSocket:** A subscription API for real-time event streams—new blocks, pending transactions, validator set changes. WebSocket connections use the same hybrid handshake as P2P connections for encrypted transport. - **RPC:** A lower-level interface for node operators and advanced integrations, providing direct access to consensus state, validator information, and network diagnostics. All API responses include SPHINCS+ signatures from the responding node, allowing clients to verify that responses have not been tampered with in transit. ### 6.4 Storage Node state is persisted using LevelDB, a key-value store optimized for write-heavy workloads with sequential read performance. Quantix organizes its LevelDB instances into logically separate namespaces: - **Chain store:** Block headers, transaction receipts, block bodies - **State store:** Current account balances, nonces, and staking information - **Validator store:** Registered validator records, stake amounts, slash history - **DHT store:** Peer routing table entries State transitions are written as atomic LevelDB batches: all changes from a block (balance updates, nonce increments, reward distributions) are committed atomically or not at all. This prevents partial state updates from corrupting the database in the event of a crash during write. The account model (as opposed to UTXO) stores state as (address → {balance, nonce}) tuples. This is simpler to reason about for application developers and more efficient for the common case of account-based interactions. ### 6.5 Network Environments Quantix defines three network environments, each with a distinct Chain ID: | Environment | Chain ID | Purpose | |---|---|---| | Mainnet | 7331 | Production network | | Testnet | 17331 | Pre-production validator testing | | Devnet | 73310 | Local development and protocol research | Chain IDs are included in transaction signatures, preventing replay attacks across networks: a transaction signed for Devnet cannot be replayed on Mainnet. --- ## 7. Universal Sovereign Identity Integration ### 7.1 Overview and Companion Work Identity is not an afterthought in Quantix—it is a first-class protocol primitive. The Universal Sovereign Identity (USI) system, described in a companion whitepaper by Kusuma (USI v0.0.1, March 2026), defines a framework for post-quantum self-sovereign identity anchored to cryptographic fingerprints. Quantix is designed from the ground up to serve as the settlement and verification layer for USI identities. The core insight shared by both systems is that traditional identity—whether government-issued, platform-issued, or even blockchain address-based—relies on institutional trust that is increasingly vulnerable to AI-driven forgery and quantum cryptographic attacks. USI addresses this by defining identity as a cryptographic object: a fingerprint derived from post-quantum keys that can be proven, transferred, and verified without reference to any trusted authority. ### 7.2 Address Mapping and USI Fingerprints Quantix addresses are 32-byte values derived from the SHAKE-256 hash of a user's SPHINCS+ public key: ``` address = SHAKE-256(sphincs_public_key)[0:32] ``` This derivation is compatible with USI fingerprint construction: a USI fingerprint is a canonical representation of a user's long-term identity, derived from their post-quantum key material. Quantix addresses are valid USI fingerprints, and USI fingerprints can be directly used as Quantix recipient addresses. This mapping means that a user with a USI identity can receive QTX, participate in governance, and interact with Quantix-native applications without creating a separate identity. The address space is unified. ### 7.3 .usimeta and .vault Compatibility USI defines two file formats for identity portability: - **.usimeta:** A structured metadata file containing a user's public key material, fingerprint, and attestations. Quantix nodes can parse `.usimeta` files to register identities on-chain without requiring users to manually construct registration transactions. - **.vault:** An encrypted container for private key material, using Kyber768 for key encapsulation. Quantix wallets natively support `.vault` import and export, ensuring that users can migrate their identity between implementations without exposing private keys. The `.vault` format's use of Kyber768 for encryption is consistent with Quantix's hybrid handshake, meaning that the same key material and tooling serve both the wallet and the network identity contexts. ### 7.4 Identity as a Protocol Primitive In Quantix, identity is not merely an application-layer concern. The protocol enforces: - **Authenticated messages:** All validator communications (block proposals, prepare/commit messages, view changes) are signed with the validator's registered SPHINCS+ key. The protocol rejects messages from unregistered keys. - **Stake-identity binding:** A validator's stake is bound to their USI fingerprint. Slashing evidence is verified against the fingerprint, making it impossible for a validator to escape accountability by generating a new key. - **ZK identity proofs:** Using libSTARK, users can prove membership in identity sets (e.g., "this address is a registered validator") without revealing their full public key, enabling privacy-preserving interactions. ### 7.5 Future: On-Chain Identity Registry The Quantix roadmap includes an on-chain USI identity registry—a native smart contract that stores USI fingerprints, public key commitments, and cross-chain attestations. This registry will enable: - **Portable reputation:** Attestations from one application are verifiable across all Quantix-native applications. - **Cross-chain identity:** Bridges to other post-quantum networks can reference the Quantix USI registry for identity verification. - **DAO membership:** Governance participation can be gated by verified USI identity, providing Sybil resistance without revealing personal information. The identity registry is planned for deployment in Phase 3 of the roadmap (Section 9). --- ## 8. Security Analysis ### 8.1 Quantum Resistance Guarantees Quantix's security against quantum adversaries is grounded in formal hardness reductions where available: | Component | Hardness Assumption | Quantum Speedup | |---|---|---| | SPHINCS+ signatures | Hash function preimage resistance | Quadratic (Grover) | | Kyber768 key exchange | Module-LWE | None known | | SWIFFTX hashing | Worst-case SIVP | None known | | libSTARK proofs | Hash function collision resistance | Quadratic (Grover) | | VDF randomness | Sequential squaring in class groups | None known | For SPHINCS+ and libSTARK, the relevant quantum speedup is Grover's algorithm, which provides a quadratic speedup for unstructured search. This is accounted for in the parameter selection: SPHINCS+-SHAKE-256f provides 128-bit post-quantum security (equivalent to 256-bit classical security against Grover). For SWIFFTX and Kyber768, no quantum speedup is known beyond generic quantum search, and their security reductions to lattice problems (SIVP, MLWE) are believed quantum-resistant. **Concrete security estimates:** - SPHINCS+ forgery: requires > 2^128 quantum operations - Kyber768 decapsulation without key: requires solving MLWE with n=768 dimension (> 2^178 classical, > 2^150 quantum per current estimates) - SWIFFTX collision: requires solving SIS in dimension n=64 over ring Z/pZ (provably hard under SIVP) ### 8.2 April 2026 Security Audit Quantix commissioned an independent security audit completed in April 2026. The audit reviewed the Go 1.24 codebase, cryptographic implementations, consensus logic, and network stack. The audit identified 27 findings across severity levels: | Severity | Count | Status | |---|---|---| | Critical | 3 | All resolved | | High | 8 | All resolved | | Medium | 12 | All resolved | | Low/Informational | 4 | All resolved | **Key findings and resolutions:** 1. **RANDAO authentication bypass (Critical):** The original RANDAO contribution handler did not verify the SPHINCS+ signature on contributions before processing them. An adversary could submit forged RANDAO contributions under a different validator's identity, biasing the randomness. **Resolution:** All RANDAO contributions are now verified against the contributing validator's registered SPHINCS+ public key before processing. 2. **Quorum calculation integer overflow (Critical):** The quorum threshold was computed as `(2 * N / 3)` using integer arithmetic with potential overflow for large N, producing incorrect quorum values. **Resolution:** The computation was rewritten as `(2*N)/3 + 1` with explicit overflow checks. See Section 4.3 for the mathematical justification. 3. **DHT secret using weak randomness (High):** Node DHT identities were derived from `math/rand` seeds, making them predictable and enabling Sybil attacks in peer discovery. **Resolution:** DHT secrets are now generated using `crypto/rand`, producing cryptographically unpredictable 32-byte identities. 4. **Duplicate VDF implementations (High):** Two independent VDF implementations existed in the codebase with subtly different parameter handling, allowing potential inconsistency in randomness verification between nodes. **Resolution:** Both implementations were unified into a single canonical VDF module with comprehensive test coverage. 5. **Missing view change authentication (Medium):** VIEW-CHANGE messages were not authenticated before being counted toward the quorum threshold. **Resolution:** All consensus messages, including VIEW-CHANGE, now require valid SPHINCS+ signatures from registered validators. ### 8.3 Remaining Defense-in-Depth Work The audit identified several areas for ongoing improvement that do not represent immediate security vulnerabilities but strengthen the defense-in-depth posture: - **Execution layer signature verification:** The smart contract execution layer currently uses a simplified signature verification path that does not fully enforce SPHINCS+ verification for all internal calls. This is targeted for resolution in Phase 3 (Section 9.3). - **Rate limiting on API endpoints:** The JSON HTTP API lacks rate limiting, creating a potential denial-of-service surface. Rate limiting middleware is scheduled for implementation before public testnet launch. - **Formal verification of consensus state machine:** The PBFT state machine implementation has not been formally verified. The team is evaluating TLA+ modeling for the critical state machine components. ### 8.4 Comparison: Bitcoin/Ethereum vs. Quantix | Property | Bitcoin | Ethereum | Quantix | |---|---|---|---| | Signature scheme | ECDSA (secp256k1) | ECDSA (secp256k1) | SPHINCS+ (NIST FIPS 205) | | Key exchange | None (UTXO) | None (account) | Kyber768 + X25519 | | Hashing | SHA-256 | Keccak-256 | SWIFFTX (lattice-based) | | ZK proofs | None native | SNARKs (trusted setup) | STARKs (no trusted setup) | | Randomness | PoW difficulty | RANDAO (last-revealer risk) | VDF-RANDAO (unbiasable) | | Quantum resistance | None | Partial (planned) | Full protocol-level | | Identity primitive | None | None | USI-native | | Post-quantum roadmap | None announced | In research | Deployed | --- ## 9. Roadmap ### Phase 1: Foundation (April – May 2026) The immediate priority is completing the core protocol implementation to production quality: - **State execution engine:** Finalize the account model state machine, ensuring correct handling of all transaction types (transfer, stake, unstake, slash, validator registration). - **Persistent state:** Complete the LevelDB integration with atomic batch writes for all state transitions. Implement state snapshot and restore for node recovery after crashes. - **Test coverage:** Achieve >80% unit test coverage on all cryptographic modules (SPHINCS+, Kyber768, SWIFFTX, libSTARK, VDF). Implement integration tests for full block processing cycles. - **Audit resolution:** Complete implementation of all 27 audit findings. Verify resolutions with the auditing firm. Deliverables: production-ready single-node binary, comprehensive test suite, updated developer documentation. ### Phase 2: Multi-Node Testnet (May – June 2026) With a solid single-node foundation, Phase 2 establishes a functioning multi-validator network: - **Four-validator testnet:** Deploy a testnet with a minimum of 4 geographically distributed validators, exercising the full PBFT consensus loop including view changes. - **Network synchronization:** Implement and test block synchronization for nodes that fall behind or restart from genesis. Ensure that new validators can join the network and sync to the current head without manual intervention. - **Docker deployment:** Publish Docker images and Compose configurations for one-command validator deployment, lowering the barrier to entry for community validators. - **Chain ID enforcement:** Verify that all three environments (Devnet 73310, Testnet 17331, Mainnet 7331) are correctly isolated and that cross-network replay attacks are prevented. Deliverables: live testnet network, Docker deployment tooling, validator onboarding guide. ### Phase 3: Hardening (June – July 2026) Phase 3 focuses on production readiness through stress testing and external review: - **Load testing:** Simulate high transaction throughput (target: 1,000 transactions per block sustained over 24 hours) and measure consensus latency, memory usage, and storage growth. Identify and resolve performance bottlenecks. - **Second external audit:** Commission a follow-up security audit focused specifically on the multi-validator consensus path and the smart contract execution layer, including the remaining execution layer signature verification work from Phase 1. - **On-chain identity registry:** Deploy the initial version of the USI identity registry contract, enabling validator identity binding and cross-application attestations. - **Documentation:** Complete API reference documentation, validator operations guide, and developer SDK documentation. Deliverables: hardened testnet, published audit report, on-chain identity registry, complete documentation. ### Phase 4: Public Testnet (July 2026+) The final phase before mainnet opens the network to community participation: - **Open validator onboarding:** Any operator meeting the minimum stake requirement (32 QTX in testnet tokens) can register as a validator. The validator set expands toward the 100-validator maximum. - **Bug bounty program:** Launch a public bug bounty program with rewards denominated in QTX mainnet allocation. Critical findings reward up to $50,000 equivalent. - **Governance framework:** Implement the on-chain governance module for protocol parameter upgrades, with voting weight determined by stake. - **Mainnet readiness review:** Conduct a final internal review against the mainnet checklist, including chain ID configuration, genesis block parameters, and token distribution schedule verification. Deliverables: public testnet with open validator onboarding, bug bounty program, governance module, mainnet readiness report. --- ## 10. Conclusion Quantix Protocol represents a deliberate response to a convergence of threats that the blockchain industry has been slow to address. The quantum computing horizon is approaching. AI-driven adversaries are already active. The cryptographic foundations of legacy blockchain networks—built in a world where ECDSA was considered secure indefinitely—are not adequate for the decade ahead. What distinguishes Quantix from incremental approaches is the decision to treat post-quantum security as a foundational requirement rather than a retrofit. SPHINCS+ signatures, Kyber768 hybrid key exchange, SWIFFTX lattice-based hashing, libSTARK transparent proofs, and VDF-based unbiasable randomness were chosen together, as a coherent cryptographic stack, before the first line of production code. The result is a protocol where quantum resistance is not a feature—it is the architecture. The April 2026 security audit, with 27 findings resolved, represents a significant step in the transition from research prototype to production system. The findings themselves—a RANDAO authentication bypass, a quorum calculation error, weak DHT randomness, duplicate VDF implementations—illustrate exactly why this kind of rigorous review is essential for protocols claiming strong security properties. Quantix is stronger for having been challenged. The integration with the Universal Sovereign Identity system extends the protocol's reach beyond financial applications into the deeper problem of identity in the age of AI. When AI can synthesize any human-generated content, the only reliable anchor for identity is mathematics. Quantix and USI together provide that anchor: identity credentials whose validity is proven by cryptographic computation, not institutional assertion. The timeline matters. The window for blockchain networks to migrate to post-quantum cryptography before CRQCs arrive is measured in years, not decades. Data recorded on classical blockchains today is already at long-term risk. Projects that defer post-quantum migration until the threat becomes concrete will face a costly, disruptive transition under adversarial pressure. Quantix is built for the world that is coming. We invite validators, developers, researchers, and cryptographers to participate in the public testnet, contribute to the protocol, and help build the infrastructure of cryptographic sovereignty. **Get involved:** research@qpqb.org --- ## 11. References 1. **NIST FIPS 203** — National Institute of Standards and Technology. *Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)*. Federal Information Processing Standard 203, August 2024. https://csrc.nist.gov/publications/detail/fips/203/final 2. **NIST FIPS 205** — National Institute of Standards and Technology. *Stateless Hash-Based Digital Signature Standard (SLH-DSA)*. Federal Information Processing Standard 205, August 2024. https://csrc.nist.gov/publications/detail/fips/205/final 3. **SWIFFTX** — Danilo Gligoroski, Rune Steinsmo Ødegård, Marija Mihova, Svein Johan Knapskog, Ljupco Kocarev, and Aleš Drápal. *SWIFFTX: A Proposal for the SHA-3 Competition*. Submission to NIST SHA-3 competition, 2008. 4. **libSTARK** — Eli Ben-Sasson, Iddo Bentov, Ynon Horesh, and Michael Riabzev. *Scalable, transparent, and post-quantum secure computational integrity*. IACR Cryptology ePrint Archive, Report 2018/046. https://eprint.iacr.org/2018/046 5. **PBFT** — Miguel Castro and Barbara Liskov. *Practical Byzantine Fault Tolerance*. Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI), 1999, pp. 173–186. 6. **Wesolowski VDF** — Benjamin Wesolowski. *Efficient Verifiable Delay Functions*. Proceedings of Advances in Cryptology – EUROCRYPT 2019, Lecture Notes in Computer Science vol. 11478, Springer, pp. 379–407. https://eprint.iacr.org/2018/623 7. **Shor's Algorithm** — Peter W. Shor. *Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer*. SIAM Journal on Computing, 26(5):1484–1509, 1997. 8. **CRYSTALS-Kyber** — Roberto Avanzi, Joppe Bos, Léo Ducas, Eike Kiltz, Tancrède Lepoint, Vadim Lyubashevsky, John M. Schanck, Peter Schwabe, Gregor Seiler, and Damien Stehlé. *CRYSTALS-Kyber Algorithm Specifications and Supporting Documentation*. NIST PQC Round 3 Submission, 2021. https://pq-crystals.org/kyber/ 9. **Kusuma (2026)** — Kusuma. *Universal Sovereign Identity (USI): A Post-Quantum Framework for Self-Sovereign Identity*. Quantix Ecosystem Whitepaper v0.0.1, March 2026. Quantix Protocol Research. 10. **Class Group VDFs** — Lior Rotem and Gil Segev. *Generically Speeding-Up Repeated Squaring is Equivalent to Factoring: Sharp Thresholds for All Cryptographic Relevant Exponents*. Proceedings of Advances in Cryptology – CRYPTO 2020. 11. **SPHINCS+** — Jean-Philippe Aumasson, Daniel J. Bernstein, Ward Beullens, Christoph Dobraunig, Maria Eichlseder, Scott Fluhrer, Stefan-Lukas Gazdag, Andreas Hülsing, Panos Kampanakis, Stefan Kölbl, Tanja Lange, Martin M. Lauridsen, Florian Mendel, Ruben Niederhagen, Christian Rechberger, Joost Rijneveld, Peter Schwabe, and Bas Westerbaan. *SPHINCS+: Submission to the NIST Post-Quantum Project*, v3.1, 2022. https://sphincs.org/ --- *This document is released under Creative Commons Attribution 4.0 International (CC BY 4.0). You are free to share and adapt this material with appropriate attribution.* *© 2026 Quantix Core Team. research@qpqb.org*