Three foundational decisions have been formalized in this version. We are transparent about what changed, why we made these choices, and why we believe this version of XInfinitum represents a superior, more trustworthy, and more durable network design.
1. Mandatory KYC for all wallet creation. Every wallet address issued on the XInfinitum network requires verified identity before activation. Your identity is never public, never stored by Pilon Laboratories, and only accessible through DAO-governed legal process — exactly as your bank account works. This eliminates anonymous-wallet-dependent crime at the protocol level. See Section 6.
2. PQC-only bridge policy. Only assets secured by post-quantum cryptography may bridge natively to the XInfinitum network. Classical-cryptography assets (BTC, ETH in their current form) use ECDSA custody wallets — which Shor's algorithm can break. Allowing them to bridge would introduce the exact quantum vulnerability XInfinitum was built to eliminate. A network is only as strong as its weakest link. See Section 6.4.
3. Roadmap revised to reflect realistic timelines. Planned Testnet: Q2 2027. Planned Mainnet: Q1 2028. Building the most secure blockchain infrastructure ever created takes time we are not willing to compromise on. We believe the community will understand and appreciate this candour. See Section 14.
Abstract
"XInfinitum" — Without end, without limit. A network whose keys are born from quantum infinity and vanish just as fast.
Every transaction signed by a key that has never existed before and will never exist again.
XInfinitum is a novel Layer 1 blockchain that combines AI-driven consensus, zero-knowledge machine learning (zkML) proofs, quantum-derived transaction keys, and post-quantum encrypted token storage to produce a network that is simultaneously transparent in its decision-making, accountable in its transaction history, and the most secure signing infrastructure ever built for a public blockchain.
The XInfinitum network replaces traditional Proof-of-Stake validators with a diverse ecosystem of staked AI agent validators, each running distinct proprietary models. These agents reach Byzantine Fault Tolerant (BFT) consensus on block validity and publish cryptographic proofs of every decision to a public proof ledger — making the consensus process independently verifiable by anyone, anywhere, without revealing the AI models themselves.
Every wallet address on XInfinitum belongs to a verified unique human being. Identity is confirmed once at onboarding through a zero-knowledge KYC process — your legal identity is never public, never stored after verification, and only accessible through DAO-governed legal process. Wallet addresses are private (not publicly broadcast) and known only to counterparties you transact with. This is financial accountability without surveillance: the same model as your bank account, with far stronger cryptographic privacy guarantees. No classical encryption is permitted anywhere on the XInfinitum network — every component, from transaction signatures to bridge custody, uses NIST-standardized post-quantum cryptography.
Most distinctively, XInfinitum introduces Quantum State Keys — wallet signing keys that do not exist in persistent storage. Derived from quantum random number generation at the exact moment of signing and immediately discarded thereafter, Quantum State Keys make it cryptographically impossible to steal a private key that never persisted long enough to be stolen.
1 · The Problem
1.1 The Validator Trust Problem
Proof-of-Stake consensus relies on economic incentives to align validator behavior with network interests. This model carries structural weaknesses:
- Software homogeneity: Most validators run identical client software. A single zero-day exploit can cascade across the entire validator set simultaneously.
- Validator concentration: The largest stakers exert disproportionate influence over both consensus and governance.
- No active intelligence: Deterministic validators check whether transactions follow rules but cannot detect novel attack patterns, flash loan attacks in formation, or emerging threats before they execute.
- Opaque decision-making: There is no public record of how a validator reached its decision — only what was decided.
1.2 The Key Storage Problem
Every classical wallet — software, hardware, paper — stores a static private key. This key signs every transaction the wallet ever makes. A single breach exposes the wallet's entire history and all future funds permanently. There is no forward secrecy and no recovery.
1.3 The Quantum Threat
Current blockchain cryptography (ECDSA, secp256k1) is vulnerable to Shor's algorithm on a sufficiently powerful quantum computer. The threat of harvest now, decrypt later attacks is immediate — adversaries can collect blockchain data today and decrypt it retroactively once quantum hardware matures. Any blockchain launched today with classical cryptography will have its entire transaction history exposed within a generation.
1.4 The Verifiability Gap
No existing system achieves: verifiable, provable decision-making at the consensus layer; quantum-resistant signing at the wallet layer; and user-controlled privacy at the transaction layer — simultaneously. XInfinitum is built to close this gap entirely.
2 · Vision & Design Philosophy
XInfinitum is built on five foundational principles:
Every wallet on XInfinitum belongs to a verified unique human being. Identity is confirmed once at onboarding — your legal identity is never public, never stored by Pilon Laboratories, and only accessible through DAO-governed legal process. This is identical to how your bank account works: fully accountable to law where law demands it, fully private from everyone else. Anonymous wallets are not a privacy tool — they are a crime tool. XInfinitum eliminates one while fully protecting the other. A network is only as strong as its weakest link; one anonymous wallet is enough to attract bad actors who poison the entire ecosystem.
Anyone must be able to verify that the network is functioning correctly without being able to see transaction details, validator model internals, or user identities. Zero-knowledge proofs make this possible.
Post-quantum cryptography is not an upgrade XInfinitum will apply later. It is foundational from genesis block. No transaction on XInfinitum will ever be vulnerable to future quantum decryption, including harvest-now-decrypt-later attacks.
Rule-based validation is a solved problem. XInfinitum consensus adds active intelligence: anomaly detection, attack pattern recognition, cross-chain threat correlation, and real-time adaptive response.
A private key that never persists cannot be compromised. Quantum State Keys exist only at the quantum moment of signing — generated, used, and destroyed in a single atomic operation leaving no recoverable trace.
3 · Architecture Overview
XInfinitum is a Layer 1 blockchain. It does not inherit security, consensus, or data availability from any other network. Every component operates at the base protocol layer.
4 · AI Consensus Layer
XInfinitum replaces homogeneous software validators with a diverse ecosystem of staked AI agent validators. Traditional PoS achieves economic alignment through staking but fails at behavioral diversity — all validators run nearly identical software and fail in identical ways. XInfinitum achieves both: economic alignment through mandatory staking with slashing, and behavioral diversity through the requirement that each validator run an architecturally distinct, proprietary model.
4.1 Validator Requirements
| Requirement | Specification |
|---|---|
| Minimum stake | $33,333 USD equivalent in XFIN — maintained continuously at all times |
| Stake floor enforcement | Automatic suspension if stake drops below USD floor; validator must top up within 72 hours or be deactivated |
| Initial lock period | 1 year minimum from activation date |
| Model uniqueness | Architecture must be demonstrably distinct via zkML model commitment hash |
| Model type | Proprietary closed-source weights required |
| Uptime SLA | ≥ 99.5% over any 30-day period |
| Response latency | Median block validation ≤ 500ms |
| Proof submission | zkML proof submitted with every validation vote |
| DAO approval | New validators approved by DAO governance vote |
4.1.1 Validator Staking Rewards
Validator staking rewards (25–40% APY on staked position) serve three practical functions:
- Compute cost coverage: Running a proprietary AI model at 99.5% uptime with ≤500ms response latency requires significant compute infrastructure. Rewards are sized to cover these costs at healthy margins.
- Slashing risk premium: Validators put capital at risk. Rewards compensate for this exposure.
- Profit and reinvestment: Any surplus beyond costs is the validator's to keep, withdraw, or compound back into their staked position.
Validator rewards are paid from the network fee pool (50% of all network fees) and are entirely separate from the Praemium surplus. The two pools cannot cannibalize each other by design.
4.1.2 XInfinitum Validator Bootstrap Grant Program
The $33,333 USD staking requirement is intentionally set at a level that aligns validator economics with network success — but the XInfinitum Foundation recognizes that talented AI researchers and independent model developers may not have this capital available at the time of application. The Validator Bootstrap Grant Program addresses this directly.
- Eligibility: Applicant must pass DAO technical review — demonstrating a genuinely distinct, functional AI model with a verified zkML commitment hash.
- Grant structure: Up to $33,333 USD equivalent in XFIN provided as a staking grant. The XFIN is staked directly to the validator's position on activation — it is not paid as cash.
- Repayment: A fixed percentage of the validator's earned rewards (governed by DAO, typically 20–30%) is automatically withheld and returned to the Treasury until the full grant amount is repaid.
- Exit before repayment: If a validator exits or is slashed before full repayment, the outstanding balance is recovered from their staked position before any remainder is returned to the validator.
- Full ownership on repayment: Once the grant is fully repaid, the validator retains 100% of all future rewards with no further obligation to the Foundation.
4.2 Byzantine Fault Tolerance
XInfinitum uses a Tendermint-derived BFT consensus adapted for AI validators. The network tolerates up to f Byzantine validators where f < n/3:
| Phase | Validators | Byzantine Tolerance |
|---|---|---|
| Testnet launch | 7 validators | 2 Byzantine |
| Mainnet genesis | 15 validators | 4 Byzantine |
| Growth target | 51 validators | 16 Byzantine |
| Mature network | 100+ validators | 33+ Byzantine |
4.3 Anomaly Detection & Real-Time Response
| Severity | Score Range | Automated Response |
|---|---|---|
| Low | 0.85 – 0.92 | Flag transaction, defer to next block, log publicly |
| Medium | 0.92 – 0.97 | Pause transaction, require 2/3 validator quorum, DAO notified |
| High | 0.97 – 1.0 | Network-wide alert, temporary mempool freeze, DAO emergency session triggered |
4.4 Block Time, TPS & Finality
XInfinitum targets a 2-second block time using its Tendermint-derived BFT consensus. BFT consensus provides single-block finality — a transaction included in a finalised block is mathematically irreversible with no waiting for additional confirmations. There are no chain reorgs on XInfinitum.
| Metric | Value | Notes |
|---|---|---|
| Target block time | 2 seconds | Consistent across all validator set sizes |
| Finality type | Instant (BFT) | One block = final. No probabilistic confirmation waiting. |
| Finality time | ~2 seconds | Transaction is irreversibly settled at block inclusion |
| Block size target | 128 MB | Conservative design target to accommodate zkML validator proof submissions. Proof sizes vary with model architecture and proof system; 128 MB provides headroom across the expected range. Individual transaction ZK proofs are ~300–500 bytes. |
4.4.1 TPS by Network Phase
Base layer throughput is governed by BFT consensus coordination overhead — O(n²) message complexity means larger validator sets exchange more messages per round. TPS decreases modestly as validators are added, while fault tolerance and network resilience increase substantially. L2 rollup layers (Phase 3 onward) decouple effective throughput from the validator count entirely.
| Phase | Validators | Base Layer TPS | With L2 Rollups |
|---|---|---|---|
| Testnet | 7 | ~5,000 TPS | — |
| Mainnet genesis | 15 | ~4,000 TPS | — |
| Growth (Phase 3) | 51 | ~3,000 TPS | ~500,000+ effective TPS |
| Mature network (Phase 4) | 100+ | ~2,000 TPS | ~1,000,000+ effective TPS |
4.4.2 Competitive Throughput Comparison
| Network | TPS | Finality | Post-Quantum |
|---|---|---|---|
| Bitcoin | ~7 | 60+ min (probabilistic) | No |
| Ethereum | ~15–25 | ~12–15 min | No |
| Solana | ~65,000 claimed / 2–4K sustained | ~0.4s (optimistic) | No |
| Visa network | ~24,000 avg | Immediate (centralised) | N/A |
| XInfinitum — genesis | ~4,000 TPS | ~2s (BFT — mathematical) | Yes — NIST Level 5 |
| XInfinitum — Phase 3 (L2) | ~500,000+ effective TPS | ~2s (batch settled to L1) | Yes — NIST Level 5 |
4.4.3 How XInfinitum Scales — ZK Rollup Architecture
The 4,000 TPS figure at mainnet genesis is the base layer ceiling — the number of transactions the L1 validator network can individually process and reach BFT consensus on per second. It is a strong number for a decentralized L1. The path from 4,000 TPS to 500,000+ effective TPS is through ZK rollup layers: a second processing layer (L2) that runs on top of the base chain.
What is an L2 rollup? Instead of submitting every transaction individually to L1 validators for consensus, a rollup layer collects thousands of transactions, processes them off the main chain, and generates a single cryptographic proof that all of them are valid. That one compact proof is then submitted to L1 as a single entry. L1 validators verify one proof per batch — not thousands of individual transactions. The batch can contain hundreds or thousands of transactions; the L1 cost is effectively constant regardless of batch size. Effective throughput multiplies by the batch factor.
Why XInfinitum's architecture is ideal for ZK rollups: Every XInfinitum transaction already produces a PLONK zero-knowledge proof as a native part of its signing process — this is not an add-on, it is the base protocol. L2 rollup layers for XInfinitum use recursive ZK proofs (proofs that prove the validity of other proofs) to aggregate thousands of individual transaction proofs into a single batch proof. No new cryptographic infrastructure is required. The L2 layer is a natural extension of the same PLONK proof system already operating at L1 for every transaction.
| Layer | What happens | Result |
|---|---|---|
| L2 — collection | Users submit transactions to the L2 sequencer. Transactions are processed and ordered off-chain at high speed. | No L1 load — transactions never hit the base chain individually |
| L2 — proof aggregation | The L2 takes all individual PLONK transaction proofs and recursively aggregates them into a single batch proof using recursive ZK composition. | N transactions → 1 compact proof |
| L1 — batch submission | The single batch proof + updated state root is submitted to L1 as one transaction. L1 validators verify it in milliseconds. | ~500 bytes per batch, regardless of batch size |
| L1 — finality | The batch proof is included in an L1 block and achieves BFT finality in ~2 seconds. All transactions in the batch are simultaneously and permanently settled. | Mathematical finality for all batched transactions |
The scaling arithmetic: At Phase 3 (51 validators), the base layer processes ~3,000 L1 slots per second. Each L1 slot can carry a batch proof representing ~167 L2 transactions. Effective throughput: 3,000 × 167 ≈ 500,000 effective TPS. As zkML ASIC hardware reduces proof generation time from ~30s (GPU) to ~2s (ASIC) in Phase 4, batch sizes increase further — approaching 1,000,000+ effective TPS on a 100+ validator mature network, while base-layer security and finality remain unchanged.
5 · zkML Proof System
For every block validation vote, each XInfinitum AI validator generates a zero-knowledge machine learning proof asserting that it possessed its DAO-approved model, ran the block data through it, and produced the stated validation decision — without revealing the model's weights, internal computation, or any other data.
5.1 Proof System: PLONK
| Parameter | Specification |
|---|---|
| Proof generation time | Target < 30 seconds (GPU-accelerated) |
| Proof size | ~500 bytes |
| Verification time | ~2ms on any standard node |
| Model commitment | SHA3-256(architecture_spec ‖ weight_merkle_root ‖ version ‖ timestamp) |
5.2 The Public Proof Ledger
Every block includes a complete consensus record published to the Public Proof Ledger: every validator's vote, every zkML proof hash, every anomaly flag, and every resolution. This is unprecedented transparency in blockchain consensus — XInfinitum proves not just that consensus was reached, but how it was reached, mathematically, publicly, permanently.
6 · Identity & Compliance Layer
6.1 Why We Made This Decision
XInfinitum was designed from genesis block to be the financial infrastructure of the next era — not a tool for the last era's crime wave. In the history of cryptocurrency, anonymous wallets have enabled ransomware that shut down hospitals, trafficking payments, terrorism financing, and exchange frauds that cost ordinary people billions. These are not edge cases — they are the primary use case of anonymous crypto in practice, and every legitimate user pays the price through regulatory crackdowns, exchange delistings, and industry-wide reputational damage.
The decision is simple: a network is only as strong as its weakest link. If one wallet in a thousand is anonymous, that wallet becomes the preferred attack vector for every criminal operating on the platform. The anonymous minority destroys the environment for the compliant majority. XInfinitum eliminates this tradeoff entirely. Every participant is a verified unique human being. No exceptions. No dark corners.
We hope the community understands and embraces this decision. The people who built wealth on Bitcoin and Ethereum — the legitimate majority — were never served by anonymity. They were hurt by it. The regulatory pressure, the exchange delistings, the banking refusals, the tainted-coin blacklists — all of it traces back to the same root cause: anonymous wallets made crypto a preferred tool for financial crime, and the industry as a whole paid the price. XInfinitum was designed from the first line of code to be the network where that story ends.
| Crime Type | Why It Requires Anonymity | What Changes on XInfinitum |
|---|---|---|
| Ransomware payments | Attacker needs untraceable receive wallet | Every receive wallet is a verified identity. First payment = immediate law enforcement identification. |
| Money laundering | Requires anonymous layering and tumbling across multiple addresses | Every address is a real person. No layering possible. Every hop is traceable to a verified individual. |
| Terrorism financing | Funding flows must be untraceable to source | Every funding source is an identified person. Wire transfer to an anonymous crypto address is impossible. |
| Sanctions evasion | Sanctioned entities need wallets that don't reveal their identity | Wallet issuance is identity-verified. Sanctioned individuals and entities cannot receive wallet addresses. |
| Rug pulls / exit scams | Project founders need untraceable withdrawal addresses | Every founder, developer, and project wallet is KYC'd. Identity is on-chain. Fraud is legally actionable from day one. |
| Market manipulation | Wash trading requires thousands of fake wallet addresses | Each wallet is a real, unique verified human. Creating fake volume requires real identities — impossible at scale. |
| Darknet commerce | Buyers and sellers need mutual anonymity | Every buyer and seller is a verified person. Pseudonymous darknet commerce cannot function. |
| Exchange fraud | Fraudulent accounts require anonymous wallets | One wallet per verified human. Account farming and sybil attacks are structurally eliminated. |
6.2 What KYC Means for Legitimate Users
For the overwhelming majority of users — people who have never wanted to do any of the above — mandatory KYC delivers concrete advantages that pseudonymous networks cannot offer:
- No regulatory risk: Your transactions are architecturally compliant. No retroactive exchange delisting, no "tainted coin" blacklisting, no surprise regulatory action against your holdings.
- Institutional access: Pension funds, family offices, endowments, and regulated financial institutions can hold XFIN without legal compliance concerns. The institutional capital that has been blocked from pseudonymous crypto is now accessible.
- Insurance eligibility: Financial regulators and insurers can cover XFIN holdings. Insured crypto custody becomes a standard offering, not an exception.
- Banking relationships: KYC-compliant networks can maintain banking partnerships that pseudonymous chains cannot. Fiat on/off ramps are simpler, cheaper, and more reliable.
- Exchange listings: Regulated exchanges (Coinbase, Kraken, Binance) are under FATF Travel Rule compliance requirements. XInfinitum's built-in KYC model may make it the most exchange-friendly Layer 1 ever launched.
- Card program access: The XInfinitum Card Program integrates seamlessly because the KYC is already done. No separate onboarding for spending functionality.
- You already KYC everywhere that matters: Your bank, your brokerage, your phone carrier, your exchange. The only places that don't require it are the ones that attract fraud. XInfinitum is different from the beginning.
6.3 KYC Onboarding Flow — Step by Step
Wallet creation takes approximately 5–10 minutes for most applicants. The process is identical whether you are using the PALLAS QSSK hardware device or the software wallet app. No biometric data, identity documents, or personally identifiable information is ever stored by Pilon Laboratories — all verification is processed by our ZK-KYC partner with immediate deletion after proof generation.
Download the PALLAS Wallet App or visit the onboarding portal at xinfinitum.com. Your identity verification is processed entirely within the secure application layer. No data is transmitted to or stored by Pilon Laboratories.
Present a valid government-issued identity document from your country of residence: passport, driver's licence, or national identity card. Photos are captured securely within the app. Your document is processed once and permanently deleted — it is never stored, sold, or shared with any third party. Only a cryptographic hash of the verification event is retained.
A brief biometric liveness verification confirms you are a real, live human — not a photograph, deepfake video, or AI-generated image. PALLAS QSSK hardware users perform this on-device using the Synaptics FS7600 hardware biometric sensor inside the EAL6+ secure element (hardware liveness detection — not defeatable by AI spoofing). Software wallet users perform liveness verification via phone camera and the device TEE.
After verification, a Zero-Knowledge Enrollment Proof is generated. This cryptographic proof asserts exactly one claim: "This wallet belongs to a unique verified human being who passed identity verification." It reveals nothing about who you are, what document you used, your nationality, your age, or any other personally identifiable information.
A non-reversible cryptographic nullifier is derived from your verification and stored in the DAO-governed identity registry. This prevents duplicate enrollment (one human cannot create two XFIN wallets) without storing your identity anywhere. Your original identity document has been permanently deleted by this point.
Your wallet address is derived from your ZK enrollment proof combined with fresh quantum entropy from the QRNG. The address is a 64-character hexadecimal string. It is not publicly broadcast on the network — it exists in the ledger only when participating in transactions, and is known only to you and counterparties you choose to share it with.
Register a human-readable short address (e.g. derek.xfin) through the address shortening service. Your .xfin username resolves to your full wallet address for counterparties you share it with. Short addresses are not publicly discoverable by default and do not appear in public blockchain explorers without your permission.
Your wallet is fully active. You may now: send and receive XFIN · stake XFIN (flexible, LP, or validator) · enroll in the Praemium Program (universal dividend) · participate in DAO governance (requires PALLAS QSSK + minimum stake) · register for the XInfinitum Card Program (fiat spending).
Estimated onboarding time: 5–10 minutes. Free of charge. Supported document types: passports, driver's licences, and national ID cards from all jurisdictions.
6.4 PQC Bridge Policy — A Network Is Only As Strong As Its Weakest Link
XInfinitum is the most quantum-secure blockchain ever built. CRYSTALS-Dilithium5 transaction signatures. Ephemeral Quantum State Keys that never persist. CRYSTALS-Kyber encrypted token storage. Every component has been designed so that no quantum computer — present or future — can compromise it.
But a network's security ceiling is set by its weakest component. If XInfinitum were to allow BTC or ETH to bridge in via a custody wallet — that custody wallet uses ECDSA. ECDSA is fully broken by Shor's algorithm. A sufficiently powerful quantum computer could drain every satoshi and every ether in that bridge custody wallet in a single attack. In an instant. Forever. The ECDSA-locked bridge becomes a $20–100 billion target with a known mathematical vulnerability — the single weakest link that invalidates everything else XInfinitum was built to protect.
| Bridge Requirement | Specification |
|---|---|
| Source chain consensus | Must use PQC signatures (CRYSTALS-Dilithium5 or equivalent NIST FIPS 204 standard) |
| Bridge custody wallet | Must use PQC key management — no ECDSA, no secp256k1, no RSA |
| Bridge protocol encryption | All protocol communications must use NIST-approved PQC key exchange — no TLS with ECDH |
| Bridge approval | Every new bridge must pass DAO security review and governance vote before activation |
| Classical assets (BTC, ETH) | Not eligible for native bridge. May be acquired via fiat on-ramp → XFIN purchase. Bridge eligibility conditional on source chain PQC upgrade. |
The XInfinitum bridge is not a workaround for chains that have not made the commitment to post-quantum security — it is a gate that enforces it. No chain enters the network without meeting the full PQC standard. Users who wish to participate in the XInfinitum network should acquire XFIN through the fiat on-ramp. No wrapped assets. No ECDSA custody wallets. No quantum attack surface.
6.5 No Classical Encryption on the XInfinitum Network
XInfinitum enforces a complete post-quantum cryptography requirement across every network component. Classical encryption algorithms (ECDSA, RSA, Diffie-Hellman, secp256k1) are not supported anywhere on the network, at any layer, under any circumstances. This is not a roadmap item. It has been the architectural requirement since genesis block design.
| Network Function | Classical Equivalent (Banned) | XInfinitum Standard |
|---|---|---|
| Transaction signatures | ECDSA / secp256k1 | CRYSTALS-Dilithium5 (NIST FIPS 204 · Level 5) |
| Key exchange / encapsulation | Diffie-Hellman / ECDH | CRYSTALS-Kyber (NIST FIPS 203) |
| Token storage encryption | RSA encryption | CRYSTALS-Kyber + AES-256-GCM |
| P2P network encryption | TLS with ECDH cipher suites | PQC key exchange + CRYSTALS-Dilithium5 auth |
| Validator communications | Classical TLS / ECDSA certs | All PQC-secured — no classical cipher suites |
| Smart contract signatures | ECDSA-compatible contract addresses | CRYSTALS-Dilithium5 — no ECDSA contract keys |
| Bridge custody wallets | ECDSA custody locks | PQC wallets only — no ECDSA bridge locks permitted |
| Identity registry | Classical PKI / RSA certificates | PQC-secured ZK proof verification |
7 · Quantum State Keys
Every private key ever generated for any classical wallet shares one fatal property: it was stored somewhere. Storage is exposure risk. A key that exists can be found. Quantum State Keys do not exist until the moment they are needed.
7.1 Security Properties
| Property | Guarantee |
|---|---|
| Pre-existence | Does not exist before the moment of transaction signing |
| Entropy source | Generated from quantum measurement — true randomness, not algorithmic |
| Transaction binding | Derived to be specific to exactly one transaction |
| Destruction | Immediately and permanently destroyed after signing |
| Ownership proof | ZK proof proves wallet ownership without revealing key derivation path — only the proof is transmitted, never the signature |
| Network transmission | Zero key material on the wire — only the ZK proof (π) leaves the device; the raw Dilithium signature (σ) is destroyed before any network transmission occurs |
| Traceability | Leaves no recoverable trace in any storage medium |
| Uniqueness | Different for every transaction — no two are ever alike |
| Non-reproducibility | Cannot be predicted, reconstructed, or reverse-engineered |
7.2 Protocol — Transaction Signing
7.3 Attack Resistance Matrix
| Attack Vector | Classical Hardware Wallet | Quantum State Key |
|---|---|---|
| Device theft | Full historical compromise | No past keys recoverable — destroyed at use |
| Memory forensics | Key may be extractable | Key existed for microseconds — forensically irrecoverable |
| Malware / keylogger | Key captured at use | Key exists for < 1ms — no logging surface |
| Supply chain compromise | Persistent key exposed | No persistent key to expose |
| Quantum computer (Shor) | ECDSA fully broken | CRYSTALS-Dilithium5 is quantum-resistant (NIST Level 5) |
| Database breach | Stored keys compromised | Nothing to breach — no key database |
| Harvest-now-decrypt-later | All past transactions exposed | Nothing to harvest — key never existed in ciphertext |
7.4 Perfect Forward Secrecy — Transaction Level
XInfinitum is designed to be the first public blockchain to achieve post-quantum forward secrecy for signing authority at the individual transaction granularity — a security property stronger than anything offered by existing blockchains, messaging protocols, or financial systems. Understanding why this matters requires understanding what this means, what it protects against, and why no other blockchain has been designed to provide it.
What Perfect Forward Secrecy Means
Perfect Forward Secrecy is a guarantee about your history. It answers the question: "If an adversary compromises something today, can they reach backward and expose what I did before?"
On Bitcoin, Ethereum, Solana, and every other major blockchain today, the answer is yes. Each wallet has one keypair that signs every transaction it ever makes. That single key protects your entire transaction history — past, present, and future. If that key is ever compromised through theft, forensic analysis, a hardware vulnerability, or a future quantum computer using Shor's algorithm — every transaction you have ever made is exposed simultaneously.
Nation-state intelligence agencies are already exploiting this through harvest now, decrypt later strategy: recording blockchain data and signed transactions today, then waiting until quantum computers powerful enough to break ECDSA become available. Every Bitcoin and Ethereum transaction ever broadcast is potentially sitting in an archive, waiting for the decryption technology to arrive. When it does, pseudonymous identities will be linked, wallet histories fully exposed, and the assumption of financial privacy retroactively shattered.
XInfinitum's Quantum State Keys eliminate this attack surface completely. Because every transaction is signed by a key that is generated and destroyed within the same atomic operation, there is no key to harvest, no archive to decrypt, and no historical exposure to worry about — ever.
Why Other Blockchains Cannot Offer This
Perfect Forward Secrecy requires three things that no other blockchain has simultaneously built into its design:
- A different key per transaction: Using a different signing key for every transaction means no single compromise exposes multiple transactions. Classical blockchains use one keypair forever, by design — changing this would break wallet address continuity and the entire UTXO/account model.
- True random entropy per signing event: The per-transaction key must be derived from entropy that did not exist before the transaction and cannot be reproduced. Algorithmic pseudorandomness (PRNG) fails this test — a seed can be recorded or predicted. Hardware QRNG from genuine quantum physical measurements satisfies this requirement; software systems cannot.
- Verified hardware destruction: The ephemeral private key must be confirmed gone by hardware, not merely deleted by software. Software deletion leaves memory residue recoverable by forensic tools. Only a secure element with hardware-enforced zeroization and destruction verification closes this gap.
XInfinitum is the only blockchain designed from genesis with all three properties: every transaction uses a unique Quantum State Key (requirement 1), seeded by a hardware QRNG at the moment of signing (requirement 2), and the key is cryptographically zeroized inside the EAL6+ SLE97 Secure Element and confirmed destroyed by the PALLAS device's independent MCU (requirement 3). The math checks out, the hardware enforces it, and the certification validates it.
| Property | Bitcoin / Ethereum | Messaging (TLS 1.3) | XInfinitum QSK |
|---|---|---|---|
| Keys per session/transaction | One key — forever | Ephemeral per session | Ephemeral per transaction |
| Entropy source | Software PRNG / seed phrase | OS CSPRNG | Hardware QRNG — quantum vacuum |
| Key destruction | Never — key persists indefinitely | Software — OS managed | Hardware zeroization · SLE97 EAL6+ · MCU-verified |
| Quantum-resistant signature | No — ECDSA breakable by Shor | Partially (depends on suite) | Yes — CRYSTALS-Dilithium5 (NIST Level 5) |
| Forward secrecy scope | None | Session-level | Per-transaction — maximum granularity |
| Historical exposure on compromise | All past & future transactions | Prior sessions safe (computational) | Zero — past keys do not exist |
| Harvest-now-decrypt-later resilient | No | Partially (session keys ephemeral) | Yes — no key material ever persists in any form |
What This Means for XInfinitum Users
For every person who transacts on XInfinitum, Perfect Forward Secrecy provides a form of peace of mind that has never existed in cryptocurrency before:
- Your transaction history is permanently yours, locked by keys that no longer exist. No adversary — regardless of future computing power — can go backward through your XInfinitum history, because the keys that signed your past transactions are gone from the universe.
- A lost or stolen PALLAS device exposes only the future, not the past. And even the future requires your live fingerprint to access. The breach radius of a single compromise is bounded to a single transaction at worst.
- No archive attack is possible. Even if every XInfinitum transaction ever broadcast were recorded by an adversary today, there is nothing to decrypt retroactively — the signing keys never existed long enough to be captured, and there is no persistent key to recover.
- AI validators sign with the same guarantee. Every validator vote and consensus message uses a Quantum State Key that is generated and destroyed per event. The entire network — not just users — operates under transaction-level forward secrecy.
7.5 Signing Tiers
KYC identity verification is required for all human wallet creation. Biometric liveness is required for Praemium Program enrollment and DAO governance voting. The core signing security property — ephemeral, quantum-derived, single-use keys — is fully preserved at every tier regardless of biometric requirement.
| Signing Tier | Who | Entropy Source | KYC / Biometric | Use Cases |
|---|---|---|---|---|
| Tier 1 — Hardware | Human with PALLAS QSSK | On-device hardware QRNG (ID Quantique IDQ6MC1) | KYC required for wallet activation · Hardware biometric liveness inside secure element required for Praemium + governance | All transactions · Praemium enrollment · DAO governance voting |
| Tier 2 — Software | Human, software wallet | QRNG API (ID Quantique cloud / ANU QRNG) | KYC required for wallet activation · Device biometric via phone TEE required for Praemium + governance | All standard transactions · Praemium enrollment · DAO governance voting |
| Tier 3 — Programmatic | AI validators, smart contracts, automated signers | QRNG API | None — validators identified by staked position + DAO-approved zkML commitment hash | Block validation votes · Consensus messages · Reward distributions · Contract execution |
7.6 Transaction Size & Block Design
CRYSTALS-Dilithium5 private keys are generated ephemerally inside the PALLAS Secure Element, used to sign once, and immediately hardware-destroyed — they never leave the device. What travels the XInfinitum network is not a raw PQC signature but a compact PLONK zero-knowledge proof that cryptographically proves the signature was valid, without revealing the key or the signature itself. This is the core architectural difference that makes XInfinitum transactions dramatically smaller than a naive PQC implementation would require.
| Data Element | Naive PQC (raw signature) | XInfinitum (ZK proof) |
|---|---|---|
| Signing key transmitted | Public key: 2,592 bytes | Not transmitted — never leaves device |
| Signature transmitted | 4,595 bytes (Dilithium5) | Not transmitted — input to proof, then destroyed |
| Proof transmitted | — | PLONK ZK proof: ~256–384 bytes |
| Transaction payload | ~200–300 bytes (recipient, amount, nonce) | ~200–300 bytes (recipient Kyber ciphertext, amount, nonce) |
| Total per transaction | ~7,400 bytes (~7.2 KB) | ~500–700 bytes |
7.6.1 Block Size Design
XInfinitum targets a 128 MB block size. Despite the small per-transaction footprint (~300–500 bytes per transaction), block size is dominated by zkML validator proof submissions — each validator submits a PLONK proof of their AI model inference alongside every block vote. Neural network inference circuits are substantially more complex than a single signing operation; zkML proof sizes vary with model architecture and the specific proof system implementation. 128 MB is a conservative design target that provides headroom across the expected range of validator model complexity, with the expectation that zkML proof sizes will be refined as the proof system matures toward mainnet.
| Block Component | Size | Notes |
|---|---|---|
| Transaction data (8,000 txns × ~600 bytes) | ~4.8 MB | PLONK ZK proofs + payload — kept small by ZK architecture |
| zkML validator proofs | ~120+ MB (est.) | AI model inference proofs submitted with every validator vote — dominant driver of block size; exact size varies with model complexity and proof system |
| Block header, state root, trie updates | ~1–2 MB | Standard chain overhead |
| Target block size | 128 MB | Conservative design target to accommodate zkML proof submissions |
| Sustained network bandwidth (full nodes) | ~512 Mbps peak | Data-centre or enterprise-grade connectivity required |
7.6.2 Block Efficiency Roadmap
XInfinitum's Phase 3 and Phase 4 roadmap includes mechanisms to improve block efficiency as the network scales:
- zkML ASIC hardware (Phase 4): Custom ASIC hardware reduces zkML proof generation from ~30s (GPU) to ~2s (ASIC) — enabling faster block times and larger L2 batch sizes on the same validator infrastructure without increasing block size.
- zkML proof aggregation: As validator sets grow, recursive proof aggregation can combine multiple validator zkML proofs into a single verifiable proof — reducing the per-block validator proof footprint while maintaining verifiability guarantees.
- L2 rollup compression: Layer 2 rollups aggregate thousands of transactions into a single L1 entry with one batch proof — the primary throughput scaling mechanism. The small base transaction size (~500–700 bytes) makes XInfinitum's L2 batch efficiency exceptionally high.
8 · Token & Tokenomics
| Parameter | Value |
|---|---|
| Name | XFIN |
| Network | XInfinitum (native L1) |
| Total Supply | 1,000,000,000 XFIN — hard cap, permanently fixed |
| Decimals | 22 |
| Base unit | 1 Quantum = 0.0000000000000000000001 XFIN (10⁻²²) |
| Supply type | Fixed cap with mild deflationary pressure via fee burn (3% of every fee burned) |
8.1 Token Distribution
| Allocation | Amount (XFIN) | % | Notes |
|---|---|---|---|
| Staking & Liquidity Rewards Pool | 400,000,000 | 40% | Distributed over 15 years, declining schedule |
| Grants & Ecosystem Development | 200,000,000 | 20% | DAO-controlled, milestone-gated |
| Founders | 100,000,000 | 10% | 4-year vesting, 1-year cliff, monthly unlock |
| Team Pool | 100,000,000 | 10% | Employee grants, advisors & future hires — unused balance to treasury |
| Treasury (Foundation DAO) | 100,000,000 | 10% | DAO-governed operations, legal, R&D |
| Public Sale — Mainnet Launch | 100,000,000 | 10% | Via XInfinitum Foundation upon mainnet activation (Q1 2028) |
8.2 Token Utility
- Transaction fees (denominated in Quanta for micro-payments)
- AI validator staking (minimum $33,333 USD equivalent in XFIN — Bootstrap Grant Program available)
- Storage node staking (to host encrypted token shards)
- DAO governance voting (1 human = 1 vote, PALLAS QSSK biometric verification required)
- Liquidity pool participation and LP token staking
- DeFi protocol participation (lending, borrowing, yield farming)
- Fungible token issuance (deploy custom tokens using the XFIN token standard)
- NFT minting and trading (native NFT standard)
- Access to priority mempool lanes (optional fee premium)
9 · Fee Structure
XInfinitum fees are proportional to transaction value — not flat. Transactions of $25 USD or less are fee-free (base gas only) — making XInfinitum the optimal network for micropayments, tipping, and small remittances.
| Component | Rate | Recipient |
|---|---|---|
| Network fee | 0.0025% of USD transaction value | 50% validators · 37% staking & liquidity rewards · 10% treasury · 3% burned |
| Wallet fee | 0.000625% of USD value (25% of network fee) | 100% wallet operator |
| Base gas | 0.00005 XFIN flat (all transactions) | 50% validators · 37% staking & liquidity rewards · 10% treasury · 3% burned |
| Free tier | Transactions ≤ $25 USD | Percentage fee waived; base gas only |
9.1 Competitive Comparison — $250 Remittance
| Provider | Fee | % of $250 |
|---|---|---|
| Western Union | ~$12.50 | 5.0% |
| Bank wire / SWIFT | ~$25–45 | 10–18% |
| Bitcoin | ~$1.00 | 0.4% |
| XInfinitum | $0.0078 | 0.00313% |
XInfinitum is 1,600× cheaper than Western Union on a $250 remittance. The recipient's family keeps an extra $12.49 per transfer — $149.88/year at one transfer per month.
10 · Staking & Rewards
| Staking Type | Base APY | Lock Period |
|---|---|---|
| Flexible staking | 5.0% | None — withdraw anytime |
| Liquidity pool participation | 7.7% | None |
| LP token staking | 8.0% | None |
| AI Validator staking | 25–40% estimated | 1 year minimum (includes slashing risk) |
10.1 Extended Lock Multipliers
| Lock Period | Multiplier | Flexible (5%) | LP Part. (7.7%) | LP Token (8%) |
|---|---|---|---|---|
| 1 year | 1.3× | 6.5% | 10.0% | 10.4% |
| 1.5 years | 1.6× | 8.0% | 12.3% | 12.8% |
| 2 years | 1.9× | 9.5% | 14.6% | 15.2% |
| 2.5 years | 2.2× | 11.0% | 16.9% | 17.6% |
| 3 years | 2.5× | 12.5% | 19.3% | 20.0% |
Multipliers apply to accumulated rewards only — staked principal is always returnable in full at end of lock period. Early unlock is permitted; however, 50% of accumulated rewards earned to date are forfeited and redistributed to the staking rewards pool. Principal is never at risk from an early exit.
11 · The XInfinitum Praemium Program
XFIN — The Cryptocurrency That Pays You.
One human. One wallet. One equal share. Every month.
The XInfinitum Praemium Program is a foundational economic feature made possible exclusively by the AI consensus architecture. After AI validators pay their verified compute costs, everything left over belongs to the network's people — divided equally, every month, automatically.
This program cannot exist on a proof-of-work or proof-of-stake chain. In both models, all surplus revenue flows to miners or stakers in proportion to capital investment. In XInfinitum's AI consensus, validators are software agents whose entire economic requirement is their verified compute cost. Any earnings above those costs represent genuine network surplus — which the Praemium Program distributes equally to every verified human on the network.
11.1 Proof of Personhood
- Tier 1 — PALLAS QSSK Device Enrollment (Automatic): Holders of PALLAS QSSK hardware devices are automatically eligible. The biometric verification is performed on-chip; no biometric data leaves the device. Hardware enforces one-person-one-wallet at the physical layer.
- Tier 2 — KYC Identity Enrollment (Universal Access): Any government-issued ID from any jurisdiction accepted. Free of charge. The KYC service generates a Zero-Knowledge Enrollment Proof — proving "this wallet belongs to a unique verified human" without revealing who. The identity document is permanently deleted after verification.
11.2 Projected Monthly Distributions
| Network Scale | Daily Transactions | Monthly Surplus | Per Address / Month | Per Address / Year |
|---|---|---|---|---|
| Early Stage | 1,000,000 | ~$600 | ~$0.00012 | ~$0.04 |
| Growth Phase | 10,000,000 | ~$8,000 | ~$0.0016 | ~$0.58 |
| Streaming Scale | 100,000,000 | ~$92,000 | ~$0.018 | ~$6.60 |
| Mature Network | 500,000,000 | ~$475,000 | ~$0.095 | ~$34 |
| Full Scale | 1,000,000,000+ | ~$950,000+ | ~$0.19+ | ~$69+ |
Assumes average transaction fee of $0.001 USD and 5,000,000 enrolled addresses.
12 · Governance — The XInfinitum Foundation DAO
XInfinitum is built by Pilon Laboratories Inc., a private Canadian corporation. Protocol governance is progressively transferred to the XInfinitum Foundation DAO as network milestones are achieved.
| Phase | Control |
|---|---|
| Phase 1 — Testnet | Pilon Labs holds full protocol control |
| Phase 2 — Mainnet | DAO controls validator admission and treasury |
| Phase 3 — Growth | DAO controls protocol parameters and upgrades |
| Phase 4 — Maturity | Full DAO governance; Pilon Labs = service provider only |
12.1 DAO Participation
DAO governance requires: (1) minimum staked XFIN equivalent to $10,000 USD; (2) registered PALLAS QSSK device with biometric verification at time of voting; (3) on-chain biometric commitment. Every qualifying participant receives exactly 1 vote regardless of stake amount — wealth buys more yield, not more governance influence.
12.2 Proposal Thresholds
| Proposal Type | Fee | Quorum | Approval |
|---|---|---|---|
| Parameter adjustment | $50 USD equiv. in XFIN | 5% | 60% |
| AI model training approval | $75 USD equiv. in XFIN | 7% | 66% |
| Protocol upgrade | $120 USD equiv. in XFIN | 10% | 75% |
| Constitutional amendment | $150 USD equiv. in XFIN | 20% | 80% |
| Identity disclosure request | $200 USD equiv. in XFIN | 15% | 75% |
| Estate recovery / claims override | $200 USD equiv. in XFIN | 15% | 75% |
12.3 Special Circumstances — Estate Recovery & Deceased Wallet Protocol
When a verified XInfinitum wallet holder is confirmed deceased, their token holdings do not become permanently inaccessible. XInfinitum provides a DAO-governed estate recovery process that transfers the deceased's claims to a designated beneficiary while maintaining the network's identity and compliance standards.
This process requires DAO authorization and DAO Oracle decryption, ensuring no single party — including Pilon Laboratories — can unilaterally access or reassign another person's holdings. Every step is recorded immutably on the network's audit ledger.
12.3.1 Eligibility & Required Documentation
- Government-issued death certificate for the wallet holder
- Legal estate authority — probate order, letters of administration, or equivalent legal instrument establishing the executor or beneficiary's authority over the estate
- Beneficiary wallet — the recipient must hold a KYC-verified XInfinitum wallet in good standing
- Notarized submission — all documents submitted to the DAO through the official legal portal, notarized and verified by DAO-approved legal counsel
12.3.2 Process Flow
| Step | Who Acts | Reversible? |
|---|---|---|
| Documentation submission | Executor / beneficiary | Yes — can be withdrawn before vote closes |
| DAO vote | All qualifying DAO members | No — vote result is permanent on-chain |
| 90-day hold | Automatic | Extended by verified objections, never shortened |
| Oracle decryption | M-of-N DAO Oracle devices | No — audit record is permanent |
| Claims transfer | Smart contract (DAO-authorized) | No — immutable on-chain action |
13 · Security Model & Post-Quantum Cryptography
| Function | Algorithm | Standard |
|---|---|---|
| Transaction signatures | CRYSTALS-Dilithium5 (ML-DSA) | NIST FIPS 204 · Level 5 |
| Key encapsulation | CRYSTALS-Kyber (ML-KEM) | NIST FIPS 203 |
| Token storage encryption | CRYSTALS-Kyber + AES-256-GCM | NIST FIPS 197 |
| Shard distribution | Shamir Secret Sharing (3-of-5) + decoy shards | Information-theoretic security |
| zkML proofs | PLONK universal proof system | ZK-SNARK |
| Entropy source | QRNG — ID Quantique Quantis / ANU API | NIST SP 800-90B |
| Hashing | SHA3-256, SHA3-512 | NIST FIPS 202 |
| Key derivation | HKDF-SHA3-512 | RFC 5869 |
13.1 Perpetual Token Encryption Architecture
XInfinitum tokens are never stored in plaintext anywhere on the network at any time. Every XFIN token in existence undergoes the following lifecycle immediately upon issuance and remains in this state permanently:
- Compression: Token data is compressed before encryption to reduce shard size and network overhead.
- Encryption: Each token is individually encrypted using CRYSTALS-Kyber key encapsulation + AES-256-GCM symmetric encryption. The encryption key is derived from network consensus entropy — no single party holds it.
- Sharding: The encrypted token is split into shards using Shamir Secret Sharing (3-of-5). Any 3 shards can reconstruct the token; 2 or fewer shards reveal nothing.
- Decoy shard injection: For every real shard distributed to the network, additional cryptographically indistinguishable decoy shards are distributed alongside it. An adversary cannot distinguish real shards from decoys.
- Distribution: Real and decoy shards are distributed across geographically diverse storage nodes. No single node holds a complete token or enough real shards to reconstruct one.
13.2 DAO Oracle Network — Transaction Privacy & Identity Disclosure
Every transaction on XInfinitum commits sender and receiver identity as an encrypted value on the public ledger — visible to all, readable by none. The only entities capable of decrypting these commitments are a set of registered DAO Oracle PALLAS devices operating under a threshold scheme. No single device, no single person, and no single government can decrypt transaction identities unilaterally.
13.2.1 The Commitment Scheme
When a transaction is broadcast, the sender encrypts both wallet addresses to the DAO Oracle network's combined threshold public key using CRYSTALS-Kyber (ML-KEM). The ZK validity proof confirms both commitments correspond to real, KYC-verified wallets with sufficient balance — without revealing what those wallets are.
No wallet address appears in plaintext on any public ledger entry. The encrypted commitments cannot be decrypted without the cooperation of M-of-N registered DAO Oracle devices.
13.2.2 DAO Oracle Device Registration
DAO Oracle devices are standard retail PALLAS QSSK units — there is no special hardware variant. The Oracle role is conferred entirely by software registration and DAO governance vote, not by the physical device. This is directly analogous to FIDO2 security keys: the same YubiKey hardware can be registered as a credential on any number of platforms; what differs is the registration record, not the chip. A PALLAS device enrolled as a DAO Oracle is the same device its owner uses to sign their own transactions — the DAO Oracle software registration is what grants it the additional network role.
The PALLAS QSSK has no wireless capability — all interaction occurs over a wired USB connection to a terminal running the DAO Oracle software. Registration does not require travel or physical ceremony; the oracle member connects their device to their own terminal, runs the registration flow, and the PALLAS secure element generates a remote attestation proof confirming that the oracle public key was generated inside a genuine tamper-resistant secure element and that the corresponding private key has never left the hardware.
13.2.3 Ephemeral Threshold Decryption
When a DAO governance vote authorizes identity disclosure — for legal compliance, a court order, or estate recovery — decryption uses the same ephemeral key derivation model as transaction signing. No static private decryption key ever exists anywhere on any device or server.
The PALLAS QSSK is a wired hardware device with no wireless capability. To participate in a decryption event, an oracle member must physically connect their PALLAS device to a terminal running the DAO Oracle software via USB. The device performs all cryptographic operations internally — the terminal handles only network communication and display. No cryptographic material passes through the terminal; only the encrypted input and the partial decryption output cross the device boundary.
13.2.4 Oracle Network Parameters
| Parameter | Value | Rationale |
|---|---|---|
| Oracle set size (N) | 9 devices | Odd number prevents deadlock; large enough for jurisdiction diversity |
| Decryption threshold (M) | 5-of-9 | Majority required; tolerates 4 simultaneous failures or refusals |
| Jurisdiction requirement | Minimum 5 distinct legal jurisdictions | Prevents single-government compelled disclosure |
| Device hardware | PALLAS QSSK (same as signing hardware) | Consistent security model; no new attack surface introduced |
| Encryption algorithm | CRYSTALS-Kyber-1024 (ML-KEM) | NIST FIPS 203 · 256-bit post-quantum security |
| Decryption trigger | DAO governance vote — 15% quorum · 75% approval | Cannot be compelled by any single party or government |
| Audit log | Immutable on-chain record of every decryption event | Full accountability; oracle members cannot act secretly |
13.2.5 Oracle Member Rotation
Oracle membership changes — adding a new member, replacing a departed one — are handled through a proactive secret sharing refresh. This is a fully remote, message-passing cryptographic ceremony where existing oracle devices update the threshold parameters to include or exclude a device. No travel is required, no historical transaction commitments need re-encrypting, and the process leaves a complete on-chain record. New parameters apply to all future transactions and decryption requests; retired oracle devices lose all decryption capability immediately upon removal.
13.3 Mempool Privacy Architecture
A blockchain mempool — the waiting room where unconfirmed transactions are held before inclusion in a block — is a significant attack surface on classical chains. On Ethereum and Bitcoin, the entire mempool is public. Validators (miners) can see destination addresses, amounts, and timing for all pending transactions. This enables front-running, MEV (maximal extractable value) extraction, and targeted address surveillance. XInfinitum addresses all three at the protocol level.
Private destination addresses in the mempool: When a sender submits a transaction to the XInfinitum mempool, the recipient address is not included in plaintext. Instead, the sender includes a one-time stealth address derived from the recipient's public spend key using Diffie-Hellman key exchange on a post-quantum curve. Only the intended recipient — who holds the corresponding private spend key — can recognize that the stealth address belongs to them. Validators process and include the transaction without knowing who the recipient is. The recipient's wallet scans incoming blocks and identifies transactions directed to them by performing the same derivation locally.
Dandelion++ transaction propagation: XInfinitum uses Dandelion++ for all transaction broadcasting. In a standard gossip network, a transaction is broadcast simultaneously to all peers — making it trivial to identify the originating node (and by extension, the sender's IP address) by timing analysis. Dandelion++ first routes the transaction through a random "stem" path (a single random relay chain) before entering "fluff" phase (standard broadcast). This anonymizes the origin node by making timing analysis statistically unreliable. Combined with the stealth address, a passive network observer cannot link a transaction to either the sender's IP or the recipient's wallet address.
ZK proof of valid destination: Because destination addresses are private in the mempool, validators cannot verify that the recipient address is a valid, registered XInfinitum wallet from the plaintext alone. XInfinitum solves this with a zero-knowledge proof attached to each transaction — a succinct PLONK proof that attests: "This stealth address corresponds to a registered, valid wallet, and the sender's claim balance is sufficient to cover this transaction amount" — without revealing either the recipient's identity or the sender's full balance. Validators verify the proof (fast, ~5ms) and include the transaction without ever learning the recipient's on-chain identity.
| Threat | XInfinitum Countermeasure |
|---|---|
| Front-running / MEV extraction | Encrypted destination + stealth addresses — validators cannot see recipient to reorder profitably |
| Address surveillance | One-time stealth address per transaction — no two transactions point to the same visible address |
| Network-level IP deanonymization | Dandelion++ stem phase obscures the originating node from timing analysis |
| Transaction linkage | Stealth address unlinkability — external observers cannot link sender + recipient across transactions |
| Invalid destination spam | ZK proof of valid destination — validators reject transactions without a valid proof; no lookup table exposed |
13.4 Network Fork Policy & Safety Guarantees
XInfinitum's BFT consensus (Tendermint-based) provides a fundamentally different safety model than proof-of-work chains. Bitcoin's safety is probabilistic — a transaction is "final" only in a statistical sense after 6+ blocks, because a fork can theoretically still replace it. XInfinitum provides mathematical, single-block finality: once a block is committed by a supermajority (>=2/3 + 1 of validators), it cannot be reversed under any conditions that don't simultaneously require controlling >=1/3 of all voting power.
Fork freedom guarantee: In Tendermint BFT, two conflicting blocks at the same height can only both achieve commit status if >=1/3 of validators sign both — which constitutes provable double-signing and triggers automatic slashing. A fork requires either: (a) >=1/3 of validators to commit slashable equivocation, permanently destroying their staked capital; or (b) a network partition where both sides believe the other is offline. Case (a) is economically irrational and immediately punished on-chain. Case (b) is handled by the safety-over-liveness rule described below.
Safety over liveness — partition behavior: When the network detects that consensus cannot be achieved (validator quorum unreachable — e.g. due to a network partition), XInfinitum halts block production rather than allowing either partition to continue independently. This is the "safety over liveness" choice in the CAP theorem: XInfinitum guarantees consistency (no conflicting chain heads) at the cost of availability during a partition. Once the partition heals and >=2/3 + 1 of validators can communicate, block production resumes automatically from the last committed block. No manual intervention or chain rollback is required.
Validator set changes and governance forks: Protocol upgrades that require validator software changes follow a two-phase governance process: (1) DAO proposal passes with >=75% approval and 10% quorum; (2) validators have a mandatory 14-day upgrade window before the switchover block height. If fewer than 2/3 of validators have upgraded by the switchover block, the upgrade is automatically postponed by 7-day increments until quorum is achieved. This eliminates "contentious hard fork" scenarios — an upgrade either achieves supermajority adoption or it doesn't proceed.
14 · Network Phases & Roadmap
| Phase | Target | Key Milestones |
|---|---|---|
| Phase 1 — Testnet | Q2 2027 | 7 AI validators · zkML proof system · PALLAS QSSK wallet integration · KYC onboarding system · Praemium enrollment testing · PQC bridge framework · Software QRNG mode |
| Phase 2 — Mainnet Genesis | Q1 2028 | 15 validators · Public token launch · Praemium Program live · DAO treasury control · XFIN exchange listings · XInfinitum Foundation incorporated (Cayman Islands) |
| Phase 3 — Growth | 2029 | 51 validators · EVM compatibility layer · DEX launch · XInfinitum Card Program · XFINUSD stablecoin launch · XFIN perpetuals market · First DAO-approved PQC-chain native bridges |
| Phase 4 — Maturity | 2030+ | 100+ validators · Full DAO governance · L2 rollup support · .xinfinitum domain service · zkML ASIC hardware · XFINCAD stablecoin · Expanded PQC-native multi-chain bridge ecosystem |
15 · Planned Protocol Extensions
15.1 XFINUSD & XFINCAD — Delta-Neutral Stablecoins
XInfinitum plans to launch two native delta-neutral stablecoins in Phase 3: XFINUSD (pegged to the US Dollar) and XFINCAD (pegged to the Canadian Dollar). Unlike centralized stablecoins such as USDC or USDT — which require trust in a bank custodian and are subject to account freezes, debanking risk, and regulatory seizure — XInfinitum stablecoins are maintained entirely on-chain through a hedged collateral mechanism.
15.1.1 How Delta-Neutral Pegging Works
- User deposits XFIN as collateral into the stablecoin protocol smart contract.
- The protocol simultaneously opens a short position on an equivalent XFIN value via the XInfinitum perpetuals market — cancelling out price exposure.
- XFINUSD or XFINCAD is minted to the user in the equivalent pegged amount.
- Redemption reverses the process — stablecoin is burned, short is closed, XFIN collateral is returned.
15.1.2 Why XFINCAD Is Strategically Significant
No major blockchain currently has a widely adopted, natively issued CAD-pegged stablecoin. XFINCAD would be the first serious Canadian-dollar stablecoin on a purpose-built Layer 1 — directly aligned with Pilon Laboratories' Canadian origin, and positioned to attract Canadian institutional participants, remittance corridors, and regulated financial services that require CAD settlement.
15.2 XInfinitum Card Program
| Card Type | Fee | Features |
|---|---|---|
| Virtual Card | $9.00 CAD / year | Instant issuance · Online payments · Apple Pay / Google Pay compatible |
| Physical Card | $22.00 CAD one-time | Tap-to-pay NFC · Worldwide acceptance · Apple Pay / Google Pay compatible |
15.2.1 PALLAS QSSK — NFC Payment Integration
The PALLAS QSSK hardware device is designed with an NFC module, enabling it to function as a contactless payment device at any NFC-enabled terminal. Payment is triggered by the biometric fingerprint sensor — the same liveness-verified touch that authorizes all other device functions. Card credentials are tokenized inside the secure element before transmission, matching the security model of Apple Pay.
16 · Revenue Model & Network Economics
XInfinitum generates protocol revenue through five independent streams. These streams are structurally separate — no single stream's performance affects the others, and each feeds into distinct network pools (validator rewards, treasury, Praemium, burn).
16.2 Address Shortening Service — .xfin Domains
| Tier | Annual Fee | Description |
|---|---|---|
| Standard address (5+ characters) | $7.00 USD/year | e.g. derek.xfin, alice.xfin |
| Short address (3–4 characters) | $35.00 USD/year | e.g. ace.xfin, zk.xfin |
| Single character (1–2 characters) | $200.00 USD/year | Reserved for auction; high-demand identifiers |
16.6 Projected Revenue Summary
| Stream | Phase 2 (2028) | Phase 3 (2029) | Phase 4 (2030+) |
|---|---|---|---|
| Network transaction fees (treasury 10%) | ~$50K/mo | ~$500K/mo | ~$5M+/mo |
| .xfin address registrations | — | ~$100K/mo | ~$700K+/mo |
| PALLAS Wallet App fees | ~$20K/mo | ~$200K/mo | ~$2M+/mo |
| XInfinitum Card fees | — | ~$75K/mo | ~$300K+/mo |
| Stablecoin protocol fees | — | ~$250K/mo | ~$3M+/mo |
Revenue figures are forward-looking estimates based on comparable network growth trajectories and do not constitute a guarantee of future performance. All figures in USD equivalent.
17 · PALLAS QSSK — Quantum State Security Key Hardware Device
The PALLAS QSSK hardware device is the physical embodiment of the Quantum State Key protocol. Manufactured by Pilon Laboratories Inc. under the PALLAS product line, it provides the highest security tier for XInfinitum wallet operations and serves as the hardware Proof-of-Personhood credential for DAO governance and Praemium enrollment.
- Embedded QRNG: ID Quantique IDQ6MC1 — certified quantum entropy, physically non-deterministic
- Secure Element: Infineon SLE97 · Common Criteria EAL 6+ — all key operations inside the SE, never exported
- Biometric sensor: Synaptics FS7600 · Hardware liveness detection — single biometric = single governance identity
- Signature algorithm: CRYSTALS-Dilithium5 (NIST FIPS 204) — quantum-resistant at Level 5
- Multi-function: XInfinitum hardware wallet · FIDO2 security key · Encrypted data vault · NFC payment terminal
18 · Storage Node Network
Storage nodes are a dedicated class of XInfinitum network participant responsible for storing the encrypted token shards that make up the Perpetual Token Encryption Architecture (Section 13.1). They are distinct from AI validators — validators achieve consensus and produce blocks; storage nodes persist the encrypted shard data that the blockchain's ownership ledger points to. Both roles are essential and separately compensated.
18.1 Storage Node Requirements
| Requirement | Specification | Notes |
|---|---|---|
| Minimum stake | 5,000 XFIN (held continuously) | Slashed on provable data unavailability or tampering. Stake acts as collateral guaranteeing data integrity. |
| Storage hardware | 4 TB+ NVMe SSD (minimum); 16 TB+ recommended | Encrypted shard data grows with network usage. Storage capacity determines shard assignment ceiling. |
| Memory | 16 GB RAM minimum · 32 GB recommended | Required for efficient shard serving and proof generation under load. |
| Network | 100 Mbps symmetric · low latency (<50ms to nearest validator region) | Storage nodes must serve shard requests during transaction processing windows. High latency causes missed serving windows and reduced rewards. |
| Uptime SLA | 99.5% (measured monthly) | Nodes falling below 99.5% uptime in any 30-day window are penalized by reduced reward weight. Nodes below 95% for 7 consecutive days enter an automatic cooldown and lose shard assignments. |
| Software | XInfinitum Storage Node Client (open source) | Runs as a background service; supports Linux, Windows Server, macOS. No GPU required. |
18.2 Shard Assignment & Redundancy
Each encrypted token is sharded into 5 pieces using Shamir Secret Sharing (3-of-5 threshold). Real shards and decoy shards are assigned to storage nodes by the protocol using a deterministic but unpredictable assignment function derived from the block hash at the time of shard creation. No storage node is informed which of the shards it holds are real versus decoy — this is a structural privacy guarantee.
The protocol maintains a minimum of 3× geographic redundancy for each real shard — meaning the same real shard is held by at least 3 storage nodes in at least 2 different continental regions. This redundancy is continuously verified by the validator network via probabilistic shard availability proofs. If a node fails to produce a valid availability proof when challenged, it is flagged and its shard assignments redistributed within one consensus round.
18.3 Storage Node Compensation
Storage nodes are compensated from two sources: a share of the network fee allocation, and a dedicated storage subsidy funded from the Foundation Treasury during the network's early growth phase when transaction volume is still building.
| Compensation Component | Rate / Mechanism | Phase |
|---|---|---|
| Network fee share | Storage nodes collectively receive 5% of total network fees, distributed proportionally by verified storage capacity and uptime score | All phases |
| Foundation storage subsidy | Fixed monthly XFIN grant from Treasury — declining schedule over 4 years as transaction fee revenue scales to cover storage costs organically | Phase 2–3 (tapering) |
| Uptime performance bonus | Nodes maintaining 99.9%+ uptime for 90 consecutive days receive a 1.25× reward multiplier for that quarter | All phases |
| Shard serving fees | Micro-fee paid per shard served during transaction reconstruction — paid by the transacting wallets as part of base gas | Phase 3+ |
Storage nodes do not require GPU hardware and have significantly lower capital requirements than AI validator nodes. The 5,000 XFIN staking requirement and commodity hardware specifications are intentional — XInfinitum's storage layer is designed to be run by individuals, not exclusively by data centres, preserving geographic decentralization of the shard network.
18.4 Becoming a Storage Node Operator
Storage node registration opens during Phase 1 (Testnet, Q2 2027). Operators submit a node registration transaction staking their 5,000 XFIN, declare their storage capacity and geographic region, and install the XInfinitum Storage Node Client. The protocol assigns initial shard responsibilities within one epoch of registration. A Bootstrap Grant Program (mirroring the AI Validator Bootstrap Grant) will be available for qualifying operators who demonstrate adequate hardware but lack sufficient XFIN to meet the staking requirement at genesis.
19 · References
The following papers, standards, and protocols form the technical foundation of the XInfinitum design. Where a referenced work has been updated or superseded, the most current version cited here was current as of the whitepaper revision date.
19.1 Consensus & BFT
- Buchman, E., Kwon, J., & Milosevic, Z. (2018). The latest gossip on BFT consensus. arXiv:1807.04938. — Tendermint BFT consensus protocol, the formal basis for XInfinitum's consensus layer.
- Castro, M. & Liskov, B. (1999). Practical Byzantine Fault Tolerance. OSDI '99. — Original PBFT paper establishing BFT foundations.
- Fischer, M. J., Lynch, N. A., & Paterson, M. S. (1985). Impossibility of Distributed Consensus with One Faulty Process. JACM 32(2). — FLP impossibility theorem establishing the fundamental liveness/safety tradeoff.
19.2 Post-Quantum Cryptography
- NIST FIPS 203 (2024). Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM / CRYSTALS-Kyber). National Institute of Standards and Technology. — Key encapsulation standard used for token encryption and key derivation.
- NIST FIPS 204 (2024). Module-Lattice-Based Digital Signature Standard (ML-DSA / CRYSTALS-Dilithium). National Institute of Standards and Technology. — Digital signature standard used for all XInfinitum transaction signing (Dilithium5, Level 5).
- NIST FIPS 205 (2024). Stateless Hash-Based Digital Signature Standard (SLH-DSA / SPHINCS+). National Institute of Standards and Technology. — Hash-based signature fallback standard.
- NIST FIPS 206 (2024). Module-Lattice-Based Key-Encapsulation Mechanism Standard (FN-DSA / FALCON). National Institute of Standards and Technology. — Compact lattice signature standard.
- NIST SP 800-90B (2018). Recommendation for the Entropy Sources Used for Random Bit Generation. NIST. — Standard governing QRNG entropy source certification (ID Quantique IDQ6MC1 compliance reference).
- Shor, P. W. (1994). Algorithms for Quantum Computation: Discrete Logarithms and Factoring. FOCS '94. — Mathematical basis for quantum vulnerability of ECDSA and RSA.
19.3 Zero-Knowledge Proofs
- Gabizon, A., Williamson, Z. J., & Ciobotaru, O. (2019). PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge. IACR ePrint 2019/953. — Universal ZK-SNARK proof system used for zkML proofs, transaction validity proofs, and ZK-KYC enrollment proofs.
- Groth, J. (2016). On the Size of Pairing-based Non-interactive Arguments. EUROCRYPT 2016. — Groth16 proof system; reference for proof size optimization comparisons.
19.4 Network Privacy
- Fanti, G., Venkatakrishnan, S. B., Bakshi, S., Bhatt, B., Bhatt, S., Pâris, M., & Viswanath, P. (2018). Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees. Proc. ACM Meas. Anal. Comput. Syst. 2(2). — Dandelion++ transaction propagation protocol used for IP-level anonymization of transaction origin.
- Noether, S. (2015). Ring Signature Confidential Transactions for Monero. IACR ePrint 2015/1098. — Reference for stealth address design and one-time address derivation concepts adapted for XInfinitum's mempool privacy.
19.5 Secret Sharing & Key Management
- Shamir, A. (1979). How to Share a Secret. CACM 22(11). — Shamir Secret Sharing (3-of-5), used for encrypted token shard distribution across storage nodes.
- Krawczyk, H. & Eronen, P. (2010). HMAC-based Extract-and-Expand Key Derivation Function (HKDF). RFC 5869. IETF. — Key derivation function (HKDF-SHA3-512) used for session key and shard encryption key derivation.
19.6 Hardware & Entropy
- ID Quantique. (2023). IDQ6MC1 Quantum Random Number Generator — Datasheet v2.1. ID Quantique SA, Geneva. — QRNG module specification for the embedded hardware entropy source in the PALLAS QSSK device.
- Australian National University (ANU) Quantum Optics Group. ANU QRNG — Real-time quantum random numbers. qrng.anu.edu.au. — Software-mode entropy API used when hardware QRNG is not present (testnet and software wallet fallback).
- Infineon Technologies. (2022). SLE97 Security Controller — Product Brief. Infineon Technologies AG. — Secure element specification (Common Criteria EAL 6+) for the PALLAS QSSK device.
19.7 Protocol Inspirations & Comparable Works
- Kwon, J. & Buchman, E. (2016). Cosmos: A Network of Distributed Ledgers. cosmos.network/whitepaper. — Tendermint consensus reference implementation context.
- Guy, T. & Diamandis, N. (2023). Ethena: Delta-Neutral Synthetic Dollar Protocol. ethena.fi/Ethena.pdf. — Delta-neutral stablecoin mechanism reference (Ethena USDe) for the XFINUSD / XFINCAD design in Section 15.1.
- Buterin, V. (2013). Ethereum White Paper. ethereum.org. — Smart contract platform reference for EVM compatibility layer and ERC-20/ERC-721 equivalents planned in Phase 3.
- Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. bitcoin.org. — Original Bitcoin paper; referenced in Section 4.5 finality comparison (probabilistic vs. mathematical finality).
This whitepaper is a living document. References will be updated as standards are finalized and new peer-reviewed work is published. The most current version of this document is always available at xinfinitum.com/whitepaper.html and pilonlaboratories.com/xinfinitum.html. Whitepaper version: v2.3. Last revised: May 2026.