1. Introduction: The Parallax Vision
Parallax Network is a decentralized multi-application network engineered to function as a unified hub for digital ownership. The core objective is to bridge the gap between complex cryptographic systems and everyday usability. Parallax empowers users to access decentralized applications (dApps), process transactions, and manage digital assets within a singular, frictionless ecosystem. The guiding principle of the architecture is maximum power through cryptographic abstraction, ensuring the backend handles the complexity while the frontend delivers pure utility.
Technology Foundation: Our Own Blockchain, Built on Move
Parallax is not a token issued on top of someone else's chain. It is its own Layer 1 blockchain, and its on-chain layer is written in Move, the resource-oriented smart-contract language created for the Diem project at Meta and released under the Apache License 2.0. Move is the same open-source foundation behind Aptos, Sui, Starcoin, and Open Libra (0L). The Parallax framework is an open fork and rebrand of the Open Libra (0L) "libra-framework", used under Apache 2.0 with full attribution to the Diem and Open Libra authors (see our NOTICE and LICENSE).
It is worth being precise about what Parallax inherits and what it builds itself. From that lineage Parallax reuses the language and the framework structure: the Move language, the Move virtual machine and its resource and account model, and the module structure of the framework (accounts, the standard library, slow-wallet unlocking, and similar primitives). This is a mature, audited, formally verifiable execution layer, and there is no reason to reinvent it.
The blockchain engine itself, however, is original Parallax technology. Parallax does not inherit the 0L consensus and runtime engine. 0L runs a classic validator-set BFT engine (DiemBFT, derived from HotStuff) built for a fixed set of full-node validators, and that design does not fit the Parallax mobile-first model, where emission is computed off-chain through everyday participation and the network is organized as a Graph of Trust that routes validation work to Desktop Validator Nodes. Because of that mismatch, the Parallax consensus, validation topology, and networking layer are being built from the ground up as new technology, not adapted from 0L.
This separation, keeping a proven Move execution layer while building a new engine beneath it, is exactly the path taken by Sui and Aptos: both share the Diem lineage of Move yet run completely different engines. Parallax follows the same principle: inherit the language, build the engine. The specific mechanics of the Parallax engine (the Proof-of-Time and Graph-of-Trust validation model) are described at the design level in this paper and will be finalized and hardened during the Testnet Era, before Mainnet.
2. The Structural Problem: The UX Trilemma & The Mobile Bridge
Historically, the evolution of blockchain technology has been plagued by a critical barrier: the friction of user experience (UX). While early blockchains struggled with scalability, modern networks have introduced a new vulnerability: extreme complexity.
The requirement for users to manage non-custodial private keys, comprehend transaction hashes, calculate gas fees, and navigate fragmented security protocols has created a systemic barrier to entry. If interacting with a decentralized ledger requires technical expertise, true mass adoption is mathematically impossible. Parallax operates on the premise that for Web3 to achieve global ubiquity, the underlying blockchain mechanics must become entirely invisible to the end-user.
The Solution: Frictionless Onboarding via "Free Mining"
To dismantle this barrier and drive widespread adoption, Parallax Network introduces a "Free Mining" ecosystem. Instead of requiring users to purchase tokens or configure complex hardware, individuals can join the network simply by downloading and interacting with the Parallax mobile application.
While mobile users do not expend computational power (CPU/GPU hashing), they are a structural necessity for the blockchain's architecture. By interacting with the app, mobile users generate vital static data that builds their Trust Score. This Trust Score serves as the cryptographic routing mechanism for the network: it determines how validation workloads and block proposals are distributed to the actual Node Validators (users running the core software on desktop machines). In essence, the mobile users build the map of trust, and the desktop nodes execute the computational heavy lifting based on that map.
A Unified, Invisible Web3 Experience
For the everyday user, the Web3 learning curve is completely eradicated. The Parallax application is engineered for pure simplicity. There is no confusion over finding decentralized applications (dApps), no tedious multi-chain or cross-chain integrations, and no need to understand underlying blockchain infrastructure.
Users earn token rewards, which will be fully convertible to mainnet assets, simply through participation. Furthermore, the application is designed with forward compatibility. As the ecosystem matures, the app will seamlessly evolve into a unified, secure digital wallet. It will allow users to store, manage, and spend their tokens in an interface as intuitive as traditional banking apps, completely shielding them from cryptographic friction.
3. Sybil Resistance & Privacy: Biometric Identity Hashing and Liveness Verification
The Parallax Network's biometric uniqueness mechanism is designed exclusively to prevent multi-account abuse when users migrate to the mainnet. It is optional: logging in, holding tokens, and mining never require it. The full system, planned for Phase 2 prior to Mainnet, operates in the following stages:
1. Liveness Verification (Planned, Phase 2)
A real-time liveness detection process will verify that the user is physically present during enrollment and not presenting:
- photographs
- video recordings
- screen replays
- synthetic media
This step is designed to ensure the authenticity of the biometric capture event. Liveness and anti-spoofing are planned safeguards and are not active in the current rollout.
2. Local Facial Feature Vectorization
Following successful liveness verification, the client device performs local facial feature extraction by:
- mapping structural facial landmark points
- calculating proportional geometric relationships
- deriving a numerical facial feature vector
No facial image is stored or transmitted to the network. Only a mathematically derived feature vector is produced.
3. Irreversible Cryptographic Hash Generation
The extracted facial feature vector is immediately converted into an irreversible cryptographic hash. Only this hash is stored by the network. The original biometric data:
- is never transmitted
- is never stored
- cannot be reconstructed from the hash
Because facial geometry contains natural micro-variations even between identical twins, the generated hashes provide high probabilistic uniqueness sufficient for Sybil-resistance purposes per individual. This mechanism therefore functions only as a uniqueness anchor, not as a biometric identity database. The hash output size is specified with quantum adversaries in mind: Grover's algorithm reduces the effective preimage resistance of an n-bit hash to n/2 bits, and parameters are selected so that the residual margin remains beyond practical reach. Hash-based constructions are not broken by quantum attacks, and this component therefore does not belong to the critical exposure surface described in Section 12.
The Mainnet Migration Mandate
While the exact deployment date for Phase 2 is pending, Fuzzy Biometric Hashing will be officially launched prior to the Mainnet release. It is a uniqueness verification step required only for migration: users must complete the biometric hashing process to migrate their mined tokens (Verified Balance) to the mainnet, and accounts that fail to generate a valid human hash will forfeit their right to token migration. Mining itself never requires the biometric: a user can keep mining for months, even after Mainnet, and complete the Fuzzy Biometric Hash only when they decide to migrate their balance.
Strict Network Rules: One Human, One Node
The protocol enforces an absolute 1:1 human-to-account ratio at migration. The system is designed to include advanced anti-spoofing mechanisms (planned for Phase 2) to detect presentation attacks such as photographs, digital screens, or 3D masks. Any user caught attempting to bypass the biometric verification or register multiple accounts will face a permanent exclusion from migration eligibility and reward distribution.
Biometric Tolerance (The "Fuzzy" Mechanics)
A common concern regarding biometric hashing is the natural physical evolution of the user. The "Fuzzy" architecture of the algorithm is specifically designed to accommodate biometric drift. The mathematical model allows for minor physiological deviations; meaning natural changes like haircuts, weight fluctuations, or aging will still resolve to the identical core cryptographic hash. Users are protected against being locked out due to the natural passage of time. All biometric processing occurs locally on the user's device before hash generation.
Identity Decoupling and Wallet Replacement
In traditional Web3 architectures, the user's identity and reputation are irreversibly bound to their cryptographic keypair. Parallax disrupts this rigid structure by decoupling the Identity Layer from the Custody Layer. The user's Trust Score and migration eligibility are tethered to their Parallax Account (secured via Email and password, with the Biometric Hash serving as the proof of humanity at migration), while the generated PAX tokens are held in the linked non-custodial Wallet (secured via the Seed Phrase). In the event of a security breach where a user's Seed Phrase is compromised, the attacker only gains access to the current funds, but cannot hijack the user's network identity. The legitimate user simply logs into the Parallax application and, using their account (and biometric anchor once enrolled), unlinks the compromised wallet, and binds a newly generated Seed Phrase to their account. This ensures that the user's hard-earned Trust Score and network reputation remain permanently protected and fully portable, completely eliminating the "risk of ruin" associated with exploits against legacy wallets. The same property governs cryptographic migration. Because identity is not bound to a key pair, the protocol can require rotation to a different signature scheme without users losing accumulated Trust Score or migration eligibility, a path structurally unavailable to architectures in which the address itself is the identity. This mechanism forms the basis of the agility model described in Section 12.
4. Consensus Mechanics: Proof-of-Time (PoT) & Graph of Trust (GoT)
Parallax redefines how network participation is valued. Instead of relying exclusively on capital-intensive Proof-of-Stake (PoS) or energy-intensive Proof-of-Work (PoW), Parallax utilizes a hybrid and behavioral validation approach:
- Proof-of-Time (PoT): Validates the continuous, active presence of a node (user) within the network. Even passive engagement, such as syncing balances, contributes to the temporal validation of the ledger.
- Graph of Trust (GoT): A localized reputation matrix. Users build cryptographic weight not just by holding assets, but through their verifiable, consistent interactions with the network over time.
The Behavioral Metric: Human Imperfection vs. Automation
The 4-hour mining cadence is not arbitrary. It is mathematically designed to act as a behavioral liveness filter. Humans are inherently unpredictable and do not remain active 24 hours a day. While it is theoretically possible to complete six full mining cycles daily, constant and uninterrupted execution of this metric strongly indicates automation.
In this consensus model, accounts exhibiting robotic perfection receive a severe penalty to their Trust Score. Conversely, organic users who perform fewer daily cycles and occasionally miss interactions, yet maintain long-term consistency, are rewarded with a significantly higher Trust Score. Currently, the exact calculation of this score is kept closed-source for now to prevent reverse engineering by script creators but it will have an auditable cryptographic mask during the testnet and mainnet periods.
Workload Allocation for Validator Nodes
The Trust Score is the backbone of the network's validation system. It is crucial to distinguish that Mobile Nodes (app users) are not blockchain validators. The structural validation of the network state occurs on Desktop Nodes (Validator Nodes). These require real computational expenditure, though at magnitudes far lower than traditional protocols.
To optimize this computational output and ensure security, Desktop Nodes utilize the Graph of Trust as a workload routing mechanism. The allocation of work, and consequently the rewards, for a validator node is directly proportional to the density and quality of its local network, which includes invited users and subsequent branches.
In practical terms: the higher the aggregated Trust Score of a validator's base (meaning more "human" and organic interactions within their branch), the greater the volume of validations directed to that specific node. This creates an unbreakable economic incentive for validators to build and maintain strictly human communities, naturally isolating any Sybil attack or bot proliferation.
Sporadic Liveness Checks (Planned Anti-Delegation Filter)
To further deter the outsourcing of validated accounts to human click-farms (Account Delegation), Parallax is researching, for Phase 2, optional sporadic liveness re-checks for accounts that have already completed their biometric verification. This is a planned safeguard and is not active in the current rollout.
Crucially, these re-checks never block mining: users who have not completed the biometric can keep mining normally, and they never interfere with standard asset transfers, wallet recoveries, or dApp interactions. Their sole purpose is to protect the integrity of a verified account's migration eligibility. The process is designed to be fully autonomous, with no manual review or centralized arbitration: if an account repeatedly fails the re-check, the network automatically discards its stored biometric data and the user must re-enroll their Fuzzy Biometric Hash from scratch. After re-enrolling, the account must pass several successful re-check sessions before migration is unlocked again, preserving the 1:1 human guarantee autonomously.
5. Dual-Layer Access: Sovereignty vs. Ecosystem Integrity
The Parallax Network distinguishes between Network Participation (holding/transferring assets) and Network Contribution (mining/earning PAX).
5.1. The Sovereign Wallet Layer (Permissionless)
Parallax remains a truly decentralized blockchain. Any user can generate a standard ECDSA (Elliptic Curve Digital Signature Algorithm) key pair and a corresponding Seed Phrase. The signature scheme is a versioned protocol parameter rather than a fixed property of the account model: ECDSA is the initial scheme, and accounts carry an explicit scheme identifier so that additional schemes, including the post-quantum candidates described in Section 12, can be introduced and retired without invalidating established history.
- Universal Access: Users can create wallets, receive tokens, and interact with the blockchain without any biometric verification.
- Full Custody: The Seed Phrase remains the ultimate "master key." If a user chooses to manage their keys manually, they have 100% control over their assets, consistent with Web3 core values.
5.2. The Migration Gatekeeper (The Biometric Mandate)
Mining and holding tokens are open to everyone. Migrating your mined balance to the mainnet is what is strictly reserved for verified humans.
- Verification-Gated Migration: Mining is open to all accounts, but transferring your mined balance (Verified Balance) to the mainnet blockchain will only be authorized for accounts that have generated a valid Fuzzy Biometric Hash.
- Anti-Dilution: This ensures that the 10 Billion PAX supply migrates into the hands of unique individuals, preventing "ghost nodes" or bot farms from carrying diluted balances onto the mainnet.
- Hybrid Onboarding: For the average user, the Biometric/Email flow handles the key management in the background. For the "Power User," the Seed Phrase can be exported or used for cold-storage recovery.
6. Parallax Consensus Protocol (Proof-of-Trust Validation Model)
1. Overview
The Parallax Network operates under a distributed consensus architecture called Proof-of-Trust (PoT), designed to achieve fast transaction finality, deterministic ordering, and scalable parallel validation without relying on Proof-of-Work or classical stake-weighted leader election.
Instead of global validator competition, the network assigns small trust-weighted validation groups that locally verify transactions before they are packaged and permanently stamped by upgraded Core Nodes.
This architecture separates:
- transaction validation
- transaction ordering
- ledger stamping
into distinct coordinated stages.
2. Network Roles
2.1 Validator Nodes
Validator Nodes are responsible for:
- receiving transactions
- participating in trust-based validation groups
- verifying transaction correctness
- voting on transaction acceptance
Validators do not mine blocks and do not solve cryptographic puzzles. Their influence derives from their accumulated trust score within the network graph.
2.2 Core Nodes
Core Nodes are upgraded Validator Nodes that:
- accumulated high trust reputation
- locked a required collateral amount of PAX tokens
- were promoted automatically by network rules
Core Nodes are responsible for:
- aggregating validated transactions
- assembling transaction batches
- stamping the canonical ledger
Core Nodes do not re-validate transaction logic. They finalize already-validated transaction sets.
3. Trust Graph and Validator Selection
The Parallax Network maintains a dynamic trust graph linking participants through:
- direct referrals
- indirect referral chains
- historical validation accuracy
- behavioral reliability
For each incoming transaction:
- The network selects a validation group of fixed size (fixed committee size: 47 validators).
- Validators are drawn probabilistically.
- Selection probability equals the combined trust weight of candidate clusters.
Thus, validation power emerges from distributed trust density rather than stake concentration. Committee size is intentionally fixed at 47 to balance adversarial resistance, network latency, and validator distribution efficiency under expected network scale.
Validator Group Formation and Rotation
Transactions are validated by dynamically assigned validator committees composed of 47 validator nodes. Validator committees remain active for a fixed operational window of 10 successfully finalized blocks, after which a new committee is selected using the same cryptographic randomness mechanism employed for Core Node batch selection.
Given an average block finalization time of approximately 10 seconds, validator committees rotate roughly every 100 seconds, ensuring continuous reshuffling of trust relationships and minimizing the probability of persistent adversarial coordination.
This rotation mechanism guarantees:
- continuous redistribution of validation responsibility
- prevention of long-term validator capture
- probabilistic fairness in committee assignment
- long-term decentralization of trust influence
4. Transaction Lifecycle
Each transaction passes through five deterministic stages.
Stage 1: Submission
A user submits a transaction containing: sender address, recipient address, value, sequential account nonce, and digital signature.
Stage 2: Sequential Nonce Enforcement
Each account maintains: last_confirmed_nonce. A transaction is considered eligible only if: nonce = last_confirmed_nonce + 1.
Future nonce handling: If nonce > expected_nonce, the transaction enters a temporary sequence buffer. The buffer retention window is strictly bounded. The transaction remains in the buffer for up to 2 block completions (approx. 20 seconds). If the missing preceding nonce does not appear within this interval, the buffered transaction is rejected. This prevents indefinite queue growth while tolerating network propagation disorder.
Stage 3: Account Pending Lock
Once a transaction with the correct next nonce enters validation: account_pending_lock = TRUE. While locked: additional future transactions may be received, but only the lowest nonce transaction may enter validation consensus. This guarantees strict chronological execution per account. This mechanism prevents: double spending attempts, parallel conflicting validations, and cross-group sequence violations.
Stage 4: Local Trust-Weighted Group Validation
Upon passing sequential eligibility checks, the transaction is assigned to a randomly selected validator group derived from the network trust graph.
Example structure:
- total validators: 500
- group size: 47
Excess users who were not drawn in a group are excluded from validations and await the next rotation of validators after 10 blocks.
The assigned group independently verifies:
- signature authenticity
- balance sufficiency
- nonce correctness
- protocol rule compliance
Each validator broadcasts a signed approval or rejection vote. If signature aggregation is introduced to reduce the bandwidth cost of committee validation, it will not be built on elliptic-curve pairings. Pairing-based aggregation is efficient, but it is the specific dependency that currently constrains post-quantum migration in established consensus layers, and the restriction is recorded here because the Parallax consensus layer remains unimplemented and is therefore free of that dependency. See Section 12.
Validation Time Window
Each validator committee is given a target validation window of approximately 3 seconds, dynamically adjustable by protocol parameters according to observed network latency, to submit signed approval or rejection votes for a transaction. Votes received after this window are discarded and do not contribute to the consensus decision. This bounded validation interval ensures deterministic latency guarantees and prevents indefinite transaction stalling.
Partial Validator Response Handling
If more than 30% of validators fail to respond before timeout expiration (15 or more), the transaction is automatically marked as: the validation timeout has expired, and the validation has been allocated to another group. The user may resubmit the transaction afterward using the same sequential nonce value. This rule prevents validation deadlock while maintaining strict responsiveness guarantees across the network.
A transaction is considered locally finalized once a strict simple majority of validators within the assigned group approve it:
approved_votes > group_size / 2
The majority threshold is always calculated against the full committee size, not against the number of received votes. This majority-based validation implements a localized Byzantine fault-tolerant agreement model executed within dynamically selected validator committees.
Instead, security derives from three combined mechanisms:
- randomized validator assignment per transaction
- trust-weighted selection derived from long-term behavioral reliability
- cryptographic vote signing and public verification
Because validator groups are: independently selected, probabilistically trust-distributed, and continuously reshuffled per transaction, the probability of coordinated malicious majority capture becomes statistically negligible under normal network trust distribution. This model therefore provides: probabilistic adversarial resistance through randomized trust-weighted local consensus, rather than classical deterministic Byzantine Fault Tolerance guarantees.
Because groups are small and validation is localized:
- consensus latency remains extremely low
- network throughput scales horizontally
- multiple validator groups may process independent transactions simultaneously
Stage 5: Ledger Stamping by Core Nodes
Approved transactions are not immediately written to the global ledger. Instead: validated transactions enter the global validated pool, Core Nodes aggregate them into ordered batches, and batches are stamped onto the canonical ledger. Stamping establishes: permanent ordering, global finality, and state transition.
6.1 Verifiable Random Core Node Selection
To guarantee neutrality, unpredictability, and resistance to manipulation, the Parallax Network employs a Verifiable Random Selection mechanism for choosing the Core Node responsible for assembling and stamping each ledger batch.
This mechanism combines:
- a distributed entropy pool generated collectively by active validators
- a cryptographic Verifiable Random Function (VRF) executed independently by each eligible Core Node
This hybrid approach ensures that batch assembly authority cannot be predicted, influenced, or monopolized.
6.1.1 Distributed Entropy Generation
At regular protocol intervals, the network generates a fresh epoch seed through a commit-reveal entropy process. During this process: Active validator nodes locally generate a random value. Each validator first broadcasts the cryptographic hash of its value (commit phase). After the commit window closes, validators reveal the original values (reveal phase). The protocol aggregates all revealed values and computes: epoch_seed = HASH(all_revealed_values).
Because no participant can predict the combined output in advance, the resulting seed becomes a collectively generated unpredictable randomness source. Validators that fail to reveal their committed value within the allowed window are excluded from the entropy round and may incur trust penalties.
6.1.2 Verifiable Random Function Execution
Once the epoch seed is finalized, every eligible Core Node independently computes: vrf_output = VRF(core_private_key, epoch_seed).
The VRF produces: a pseudo-random numerical output and a cryptographic proof allowing any network participant to verify correctness. This guarantees that the result cannot be fabricated, cannot be modified after generation, and remains publicly verifiable without revealing the node's private key. These guarantees hold under the assumption that the VRF private key cannot be derived from public data, an assumption that classical elliptic-curve constructions do not satisfy against a quantum adversary. The distributed entropy process described in 6.1.1 is hash-based and is not subject to this limitation. The selection of a post-quantum verifiable random function, and the corresponding weighting between the two sources, is addressed in Section 12.
6.1.3 Core Node Selection Rule
After all VRF outputs are broadcast: the network compares the numerical VRF outputs, the Core Node with the lowest valid output is deterministically selected, and ties are resolved using deterministic address ordering. Because every Core Node uses the same unpredictable seed, and because VRF outputs are provably authentic, the selection process remains: fully decentralized, unpredictable prior to execution, and immune to manual manipulation. All eligible Core Nodes participate with equal weight in this selection process. Trust score does not influence Core Node lottery probability.
6.1.4 Security Guarantees
- Unpredictability: No node can know the selection outcome before the entropy reveal phase completes.
- Manipulation resistance: No single participant controls the seed generation.
- Public verifiability: All VRF outputs and entropy inputs can be independently validated.
- Equal opportunity selection: All Core Nodes share identical selection probability.
6.1.5 Consensus Design Rationale
The Parallax Network intentionally separates: transaction validation authority (Validator Nodes) and ledger organization authority (Core Nodes). Because transactions are already finalized prior to stamping, the Core Node selection mechanism does not determine transaction validity, but strictly determines ledger assembly responsibility. This design allows the network to maintain deterministic transaction finality while still preserving decentralized and unpredictable ledger organization.
6.2 Core Node Batch Stamping and Finalization
Deterministic Transaction Finality
In the Parallax Network, transaction finality does NOT occur at the ledger stamping stage. A transaction is considered FINAL once:
- it has been validated by its assigned validator group
- the majority Byzantine threshold (>50%) has been reached
- the signed validation result has been broadcast to the network
A transaction reaches consensus finality after validator approval and becomes permanently recorded once stamped into the canonical ledger. Core Nodes do not participate in transaction decision logic and cannot overturn validated results. Their role is strictly organizational.
Separation Between Validation and Ledger Organization
The Parallax architecture explicitly separates: Transaction validation (performed by Validator Nodes) and Ledger organization and stamping (performed by Core Nodes).
- Validator Nodes: verify signatures, verify balances, verify nonce ordering, vote on acceptance.
- Core Nodes: collect already-validated transactions, assemble ordered batches, stamp the canonical blockchain. Core Nodes never independently approve or reject transactions.
Random Core Node Selection
To assemble each ledger batch, the network performs a uniform random selection among all eligible Core Nodes. Rules: every Core Node has equal probability, no trust weight advantage exists at this stage, selection is fully protocol-driven, manual selection is impossible. This guarantees that ledger stamping power cannot accumulate through trust concentration or capital dominance.
Single Active Batch Rule
The network enforces a single active stamping process at any given moment. Once a Core Node is selected: it becomes the temporary batch assembler, no other Core Node may stamp concurrently, and competing batch creation attempts are ignored. This prevents ledger branching and eliminates competing canonical histories. Because transactions are already finalized prior to stamping, parallel stamping provides no security advantage and is intentionally disallowed. The validated transaction pool remains globally preserved and unaffected during Core Node reselection.
Batch Assembly Process
The selected Core Node: pulls validated transactions from the global validated pool, sorts them deterministically, assembles them into a batch, computes the batch hash, appends the batch to the blockchain. The batch acts purely as a historical ordering container.
Failure Handling
If the selected Core Node: goes offline, fails to assemble a batch within the allowed window, broadcasts an invalid batch structure, the network automatically triggers a new random Core Node selection. Previously validated transactions remain valid and unaffected.
Consensus Philosophy of Core Nodes
Core Nodes are intentionally designed to function as: deterministic ledger organizers, not consensus authorities. Security derives from distributed validator agreement, not from block producers. This architecture removes: mining races, leader dominance, fork competition, probabilistic settlement, and replaces them with: validator-driven deterministic finality and randomized organizational stamping.
6.3 Parallelism Model
The Parallax Network supports safe parallel validation under one constraint: A single account cannot have multiple active consensus-eligible transactions simultaneously. However: different accounts may validate transactions concurrently, multiple validator groups may operate in parallel, multiple transaction batches may be processed simultaneously. This achieves high throughput without violating chronological account execution.
6.4 Transaction Expiration Rules
Transactions waiting for missing nonce predecessors: remain buffered only within the bounded wait window and expire automatically if sequence completion fails. This prevents: mempool inflation attacks, intentional sequence blocking, and propagation manipulation.
6.5 Security Properties
The Proof-of-Trust model guarantees:
- Deterministic account ordering: Every account executes transactions strictly sequentially.
- Adversarial resistance: Randomized trust-weighted validator grouping combined with signed majority voting provides probabilistic protection against coordinated malicious participation.
- Sybil resistance via trust graph density: Validator influence requires long-term network participation rather than instantaneous stake injection.
- Fast finality: Small group validation drastically reduces consensus latency.
- Horizontal scalability: Parallel independent validation groups allow throughput growth with validator expansion.
6.6 Promotion Mechanism for Core Nodes
A Validator Node becomes eligible for Core status when: its trust score exceeds the network limit, its historical validation reliability remains above the minimum, and a significant amount of PAX collateral is locked. Users can apply to become core nodes and operate as validator nodes until they meet the minimum conditions, the promotion is automatic and rule-based. Core Nodes that behave maliciously risk: collateral slashing, trust reset, automatic demotion.
6.7 Consensus Philosophy
The Parallax Consensus design is based on three principles: Trust accumulation replaces computational waste, local validation replaces global contention, deterministic sequencing replaces probabilistic ordering. This allows the network to achieve: low latency, high throughput, strong consistency, sustainable validator participation without mining or classical stake races.
7. Network Architecture & Incentives: The Tri-Layered Model
Traditional blockchains often trend toward centralization through massive validator pools or suffer from severe bottlenecks by forcing every node to validate every transaction. Parallax introduces a Tri-Layered Node Architecture to enforce decentralization by design, segmenting workloads and economic rewards based on trust and processing capacity.
The Three Tiers of the Parallax Network
The ecosystem is divided into three distinct functional layers, each playing a critical role in the consensus process and featuring its own distinct reward mechanism:
- Tier 1: Mobile Nodes (The Trust Layer)
These are the everyday users interacting via the mobile application. While they do not perform heavy computational hashing, they are the foundational layer of the network. Through their organic interactions, they generate the static data known as the Trust Score, actively building the localized Graph of Trust.
Reward Mechanism: Mobile Nodes earn PAX tokens proportionally to their active participation in mining cycles. In future protocol upgrades, the Savings Protocol will be integrated; meaning users who hold and store their tokens will receive a mathematical multiplier on their baseline interaction yields. - Tier 2: Validator Nodes (The Processing Layer)
Operated by users running the core software on standard desktop machines. Validator Nodes handle the bulk of localized, lightweight network traffic and data packet routing.
Reward Mechanism: Instead of traditional block rewards, Validator Nodes receive a dynamic multiplier (Mining Boost) applied to their base mining cycles. The magnitude of this boost is directly proportional to their verifiable network uptime and the aggregated Trust Score of their surrounding node branch. - Tier 3: Core Nodes (The Settlement Layer)
Advanced desktop nodes with higher processing capabilities. Core Nodes manage the heaviest computational tasks, acting as the final cryptographic authority for organizing and stamping state updates onto the global ledger.
Reward Mechanism: Core Nodes receive the highest tier of economic incentives. In addition to maximizing their Mining Boost, these nodes earn a direct percentage of the transaction fees generated by the network traffic they successfully process and settle.
Localized Consensus and Dynamic Promotion
Transactions within the Parallax Network are not broadcasted to the entire global ledger simultaneously. Instead, they are fragmented into smaller data packets validated by a specific subset of surrounding Validator Nodes.
Parallax is designed to scale organically. A Validator Node is not permanently restricted to Tier 2. If a Validator Node meets specific hardware processing requirements and accumulates a critical mass of Trust Score from its surrounding network, it automatically becomes eligible for promotion to a Core Node.
The Inverse Exponential Trust Curve
To prevent any single node or cluster from monopolizing network consensus, the accumulation of trust is mathematically capped. The Trust Score follows an inverse exponential growth curve. In practical terms: the more Trust Score a node possesses, the exponentially harder it becomes to acquire more.
This mathematical friction ensures that power cannot be endlessly centralized by a few early or massive nodes. Furthermore, when a specific region of the Trust Graph becomes too dense, the protocol automatically elects a highly trusted Validator Node in that sector to become a new Core Node, perpetually distributing validation power and rewards toward the edges of the network.
8. Economic Model: The Deflationary Epoch Engine
The Parallax economic engine is designed to ensure long-term scarcity and reward early network bootstrapping. The native utility token, PAX, has a hard-capped maximum supply of 10,000,000,000 (10 Billion) tokens. It is crucial to note that this maximum cap is a mathematical ceiling, not a target metric. The actual circulating supply is governed by strict deflationary mechanisms and user behavior.
Unlike time-based emission schedules, which are vulnerable to fluctuating network activity and can over-inflate supply during low-usage periods, Parallax utilizes a dynamic Emission Epoch Protocol triggered strictly by total network output.
The Halving Algorithm and Emission Formula
The base mining rate is algorithmically reduced by 10% for every 100,000,000 (100 Million) verified PAX emitted. The network emission rate follows a specific decay function:
Rn = R0 × (0.90)n
Where Rn is the new rate, R0 is the genesis rate, and n is the current Epoch (increments of 100M PAX). This ensures that as the network matures, token generation becomes mathematically harder, creating natural scarcity.
Yield Generation: The Mining Calculation
The individual user yield is not a static number. It is a composite calculation that rewards consistency and network expansion. A standard mining cycle lasts exactly 4 hours. The total PAX generated per cycle is calculated through the following components:
- Base Yield: The current active Epoch Rate (PAX/h) multiplied by 4.
- Daily Streak Multiplier: A compounding boost awarded for consecutive daily check-ins.
- Network Expansion Bonus: Additional yield based on the active participation of invited users.
- Node Infrastructure Boost: In future phases, users operating Desktop Validator Nodes will receive significant multipliers on top of their base cycles as compensation for their hardware output.
- The Savings Protocol Boost: Post-Mainnet, Parallax will introduce a frictionless alternative to traditional staking. Users who allocate their balance to the Savings Protocol will receive a proportional multiplier on their ongoing mining cycles, economically rewarding long-term holders without the complexity of smart-contract lockups.
Mainnet Migration and The Token Generation Event (TGE)
Not all tokens generated within the mobile application will enter the live blockchain immediately. To protect the network from instant hyper-inflation and dump mechanics, migrated tokens will be subject to a Trust-Weighted Vesting Schedule. During the Mainnet TGE, tokens are released linearly over a specified number of months based on a precise matrix comparing the user's Total Balance against their Graph of Trust (Trust Score):
- Low Balance + High Trust Score: Immediate or near-immediate unlock of the full balance.
- Low Balance + Low Trust Score: Intermediate vesting period.
- High Balance + High Trust Score: Intermediate vesting period, rewarding large holders while protecting market liquidity.
- High Balance + Low Trust Score: The maximum vesting duration. This severely restricts potential bad actors who accumulated large balances without organic, trusted network behavior.
Initial Circulating Supply Dynamics
The transition to Mainnet acts as a massive deflationary filter. A significant portion of the currently mined tokens will never reach the live blockchain due to natural user abandonment, lost accounts, or permanent bans resulting from Sybil attacks (multi-accounting and botting detected by the Fuzzy Biometric Hash).
Coupled with the Trust-Weighted Vesting Schedule, the initial liquidity pool will be highly restricted. Based on network projections, the circulating supply at Mainnet launch is estimated to be approximately 100,000,000 (100 Million) PAX. This low initial supply, paired with high utility demand, establishes a robust economic foundation for the Parallax ecosystem.
9. The Epoch Roadmap: Soft Halvings and Protocol Phases
Unlike traditional blockchain roadmaps, which depend on arbitrary calendar dates, the Parallax Network development cycle is mathematically tied to network adoption. For every 100,000,000 (100 million) verified PAX emitted, a Soft Halving (Epoch) is triggered, as described in Section 8. Protocol phases advance through their own thresholds, which expand as the engineering work contained within them becomes more substantial, culminating in Mainnet at the 2 billion PAX mark.
Each phase describes the production work carried out within it, not a guaranteed delivery. A component is launched when its production is complete, not when an emission threshold is crossed. Emission and engineering progress independently, and the roadmap is calibrated so that the former does not outpace the latter.
Phase 0: Genesis (0 to 100M PAX) (Completed)
Focus: Initial network seeding and Proof of Concept (PoC) validation.
Milestones: Launch of the Android App (Beta), deployment of the core Proof-of-Time mechanics, and the organic generation of the initial Graph of Trust through user invitations.
Phase 1: Ignition (100M to 200M PAX) (Completed)
Focus: Ecosystem accessibility, Sybil resistance, and network purification.
- Expansion to the iOS Ecosystem: Launch of the Parallax App within the Apple ecosystem.
- Fuzzy Biometric Hash Deployment: Activation of the Liveness Verification system to generate an irreversible cryptographic hash without storing images, proving the user's humanity.
- Bot Purge: With biometric anchoring active, automated scripts and multi-account farms are actively isolated, ensuring that the Graph of Trust remains strictly human.
Phase 2: Expansion (200M to 300M PAX) (Partial)
Focus: Hardware decentralization and Validator Tier integration.
Status: Partial. Desktop Validator Node development continues into Phase 3.
- Parallax Desktop App: Development of the primary desktop client for Windows, macOS, and Linux.
- Tier 2 Integration (Validator Node): Development of the linking mechanism through which eligible Mobile Nodes (users with high Trust Scores) connect their accounts to the Desktop App. This allows them to operate Validator Nodes using their computer hardware to process lightweight data packets, earning Mining Boosts while maintaining their mobile liveness verification.
Phase 3: Convergence (300M to 500M PAX) (Current Phase)
Focus: Production of the Validator Node layer.
- Desktop Validator Node: Production of the Tier 2 client for Windows, macOS, and Linux.
- Node Synchronization: Production of the cryptographic handshake between mobile Trust Scores (Tier 1) and desktop Validator routing (Tier 2).
Phase 4: Nexus (500M to 700M PAX)
Focus: Production of the internal Testnet.
- Internal Testnet: Production of a closed testing environment simulating the Proof-of-Trust consensus model, with no real liquidity.
Phase 5: Resonance (700M to 900M PAX)
Focus: Production of the public Testnet.
- Public Testnet: Production of an open testing environment extending the Proof-of-Trust model to external participants, with no real liquidity.
Phase 6: Vanguard (900M to 1.2B PAX)
Focus: Production of the Core Node layer.
- Core Nodes (Tier 3): Production and stress testing of the settlement layer, including election mechanics and ledger batch stamping.
Phase 7: Sovereignty (1.2B to 1.5B PAX)
Focus: Production of the developer ecosystem and cryptographic hardening.
- Security Audits: Rigorous audits of consensus cryptography.
- Post-Quantum Integration: Production of post-quantum signature candidates behind the scheme registry, with conjunctive hybrid validation enabled for new accounts (Section 12).
- Developer Tools: Production of SDKs and APIs for the future ecosystem.
Phase 8: Resilience (1.5B to 1.8B PAX)
Focus: Protocol hardening and scalability.
- Scalability: Production of throughput improvements through parallel validator groups.
- Final Hardening: Consolidation of consensus cryptography before Mainnet.
Phase 9: Horizon (1.8B to 2B PAX)
Focus: Mainnet production and economic realization.
- Savings Protocol: Production of lockup mechanics for increased yields, intended to encourage liquidity retention before migration.
- Mainnet and TGE: Production and official launch of the Parallax Blockchain.
- Token Migration: Conversion of verified mined balances based on the Trust-Weighted Vesting Schedule.
10. Token Allocation & The Community-Pegged Vesting Protocol
To ensure absolute alignment between the protocol creators and the network participants, Parallax Network employs a transparent, anti-dilutive token distribution model. The hard-capped maximum supply of 10,000,000,000 (10 Billion) PAX is rigidly partitioned to prioritize the users:
The 90/10 Macro Allocation
- 90% Community & Ecosystem (9,000,000,000 PAX): Dedicated entirely to the user base. This vast majority encompasses all mobile mining yields, Desktop Validator rewards bonus and network savings.
- 10% Foundation & Development (1,000,000,000 PAX): Allocated to the Parallax Foundation and the core development team. These funds are designated strictly for continuous protocol engineering, global marketing initiatives, promotional campaigns, liquidity and long-term operational maintenance.
The Community-Pegged Vesting Mechanism
A critical vulnerability in traditional Web3 projects is the reliance on time-based team vesting schedules. Time-based unlocks allow founders to access and liquidate tokens based on a calendar date, regardless of whether the network has actually achieved adoption or success.
Parallax eradicates this structural risk by implementing a dynamic release mechanism. The core team's liquidity is mathematically pegged directly to the community's mining progress.
The 10% Foundation allocation does not unlock over time. Instead, it unlocks strictly in proportion to the circulating supply generated by the community. For example: if the community successfully mines 10% of the total network supply (1 Billion PAX), the protocol authorizes the release of exactly 10% of the team's allocated vault (100 Million PAX).
Economic Alignment and Network Security
This architectural decision acts as a permanent security guarantee for the network. It mathematically ensures that the core development team cannot unfairly benefit from their allocated tokens prior to delivering real, tangible growth to the ecosystem. The team is only rewarded when the community expands. This mechanism eliminates internal dump risks, fortifies market stability, and binds the financial success of the founders absolutely to the success and prosperity of the everyday users.
11. The Savings Protocol: Frictionless Yield Generation
Traditional Web3 staking introduces unnecessary friction for the everyday user. Complex smart contract interactions, prolonged unbonding periods, and unpredictable annual yields deter mass adoption. To bridge this gap, Parallax introduces the Savings Protocol. Scheduled for architectural implementation during the Testnet phase and fully activated upon Mainnet launch, this system mirrors the familiar, intuitive mechanics of a traditional bank savings account, yet operates entirely on a decentralized framework.
Yield as a Mining Boost
Unlike conventional staking mechanisms that arbitrarily mint new tokens to pay interest, the Savings Protocol rewards users by amplifying their active participation. The "interest" generated by stored funds is applied directly as a Mining Boost. By allocating tokens to their Savings account, users receive a mathematical multiplier on their ongoing mining yields, aligning passive holding with active network consensus.
Absolute Liquidity and Micro-Locking
The Parallax ecosystem prioritizes user sovereignty. Consequently, the Savings Protocol features zero fixed, long-term lock-up periods. Users are free to unlock and withdraw their funds at any moment.
However, to guarantee network stability during consensus generation, the protocol enforces a Micro-Locking mechanism. If a user initiates a standard 4-hour mining cycle, the funds currently allocated to the Savings Protocol become strictly non-transferable for the exact duration of that cycle. Once the 4-hour cycle concludes, full liquidity and transferability are immediately restored.
The Proportional Boost Calculation
The magnitude of the Mining Boost is determined by the ratio between the user's locked balance and their historically validated (mined) balance. If a user migrates 100 PAX to the Mainnet and chooses to lock 50 PAX in the Savings Protocol, they receive a 50% multiplier on their base mining yield. This directly rewards users who preserve the tokens they organically generated.
The Maturation Phase (Anti-Rotation Safeguard)
To prevent circular liquidity attacks where a single pool of funds is rapidly transferred between multiple accounts to trigger simultaneous mining boosts the Savings Protocol implements a Time-Locked Eligibility mechanism.
While incoming PAX transfers are immediately liquid for standard peer-to-peer transactions or dApp interactions, they are subjected to a Maturation Freeze before they can be allocated to the Savings Protocol. Newly deposited tokens must age organically within the receiving wallet for a minimum designated period (72 hours) before they become eligible to generate a Mining Boost. This mathematical friction ensures that network yield is exclusively distributed to genuine, long-term ecosystem participants, completely neutralizing velocity-based rotational exploits.
The Exponential Decay Safeguard (Anti-Exploit Mechanism)
The protocol permits users to lock liquidity exceeding their originally mined amount. For example, a user who mined 100 PAX can acquire additional tokens on the open market and lock 110 PAX, temporarily achieving a 110% boost.
To protect the network's emission integrity, Parallax implements a strict algorithmic safeguard. The linear boost maxes out when the locked amount matches 100% of the user's natively mined balance. Any locked liquidity that exceeds this 100% threshold triggers an exponential decay curve on the resulting boost. This mathematical friction neutralizes economic exploits, specifically preventing wealthy external actors from purchasing massive token volumes and injecting them into low-activity accounts to drain the network's yield reserves.
12. Quantum Resistance and Cryptographic Agility
SCOPE OF THIS SECTION
This section describes a threat model, a set of design invariants, and a list of unresolved problems. It does not describe implemented functionality. Parallax deliberately does not commit to a specific post-quantum algorithm at this stage; instead, it commits to an architecture capable of adopting and retiring such algorithms. Final primitive selection will take place during the Testnet Era, prior to Mainnet.
12.1 Rationale
The current generation of public blockchains derives its security from elliptic-curve cryptography. That foundation carries a known expiration condition: a sufficiently large, fault-tolerant quantum computer running Shor's algorithm can derive a private key from its corresponding public key in polynomial time. This is not a gradual erosion of the scheme's security margin. It is a complete failure of the underlying assumption.
Parallax addresses this before Mainnet rather than after it for a structural reason. Replacing a signature scheme on a live network that already holds user balances, has an established address space, and carries a permanent transaction history is substantially more difficult than specifying cryptographic agility at genesis. Networks that were not designed for this are now facing migrations that require coordinated hard forks, emergency recovery mechanisms, and, in some proposals, the permanent freezing of balances whose public keys have already been exposed.
Distributed ledgers also represent the worst-case adversarial environment for this class of threat. To date, most post-quantum deployment across the industry has focused on key exchange, because confidentiality is vulnerable to retrospective decryption. In conventional systems, signatures only need to remain secure at the moment of verification. A public ledger reverses that completely: it derives little value from confidentiality, depends almost entirely on signatures, and publishes every public key permanently and irrevocably. The sector operating with the narrowest margin has, so far, received the least attention.
12.2 Threat Model
Two quantum algorithms are relevant to this architecture, and they impose asymmetric costs.
Shor's algorithm solves integer factorization and the discrete logarithm problem in polynomial time. Both RSA and elliptic-curve cryptography reduce to instances of the hidden subgroup problem over abelian groups, a class efficiently solved using the Quantum Fourier Transform. Any construction whose security depends on elliptic curves fails completely under this attack, including ECDSA, EdDSA, pairing-based aggregate signatures, and most practical Verifiable Random Functions (VRFs). Increasing key size is not a mitigation: doubling an elliptic-curve key approximately doubles the quantum resources required, which is a linear adjustment applied against a polynomial-time attack.
Grover's algorithm provides only a quadratic speedup against unstructured search, reducing the effective security of an n-bit hash to n/2 bits. A 256-bit hash therefore retains approximately 128 bits of security under quantum attack, which remains beyond practical reach. Hash functions and symmetric primitives are not broken; they simply require larger output sizes.
The resulting distinction governs every decision in this section: signature and key-agreement schemes face an existential threat, while hash-based constructions face only a parameter adjustment.
It is worth clarifying what a quantum computer is not. It is not a general-purpose accelerator, it does not provide an advantage for ordinary computation, and it will not outperform classical hardware on the workloads a network actually executes. Its advantage is limited to a narrow class of problems with exploitable mathematical structure. One of those problems happens to be exactly the structure underlying contemporary public-key cryptography.
Retrospective exposure. Because a public ledger publishes every public key permanently, an adversary can archive network data today and derive the corresponding private keys once capable hardware exists. Any key exposed on-chain during the Testnet Era remains exposed indefinitely. Under this model, the operative deadline is not the arrival of quantum hardware, but the point at which the network stops issuing vulnerable keys.
Timeline. No reliable estimate fixes a specific date. Current devices operate in the noisy intermediate-scale quantum (NISQ) regime and lack both the logical-qubit count and circuit depth required for Shor's algorithm against 256-bit curves; published resource estimates place the requirement in the range of thousands of logical qubits sustaining on the order of 109 to 1011 sequential logical operations, against physical error rates that remain many orders of magnitude too high without error correction. Two observations, however, govern planning. Below-threshold error-correction demonstrations, in which increasing the size of the correction code decreases rather than increases the logical error rate, have established that the path to scale is an engineering and capital problem rather than an open question in physics. Separately, published resource estimates have fallen substantially across successive revisions through algorithmic improvements alone, independent of hardware progress. Parallax therefore treats institutional deprecation timelines, rather than hardware forecasts, as its planning anchor: NIST will deprecate ECDSA and RSA in 2030 and disallow them in 2035.
12.3 Vulnerability Surface of the Parallax Architecture
The following assessment applies to the architecture as specified in this document and is mapped to the sections that introduce each component. This is stated explicitly because a protocol that cannot identify its own exposure cannot credibly claim to be addressing it.
| Component | Specified in | Primitive | Exposure |
|---|---|---|---|
| Sovereign Wallet key pair | 5.1 | ECDSA | Critical (Shor) |
| Validator committee votes | 6, Stage 4 | Digital signature | Critical (Shor) |
| Core Node selection | 6.1.2 | Verifiable Random Function (VRF) | Critical (Shor) |
| Public-key exposure on first spend | 5.1 | Address derivation | Critical (retrospective) |
| Distributed entropy (commit-reveal) | 6.1.1 | Hash | Low (Grover) |
| Fuzzy Biometric Hash | 3 | Hash | Low (Grover) |
| Batch hash and ledger stamp | 6.2 | Hash | Low (Grover) |
| Auditable Trust Score mask | 4, 6 | Undetermined | Depends on construction |
Two entries warrant further explanation.
Validator committee votes. Section 6 derives consensus security from randomized assignment weighted by Trust Score, combined with cryptographic signing of votes and public verification through a 47-member committee. Against an adversary capable of forging validator signatures, that security argument does not degrade gracefully. The attacker does not need to compromise, recruit, or coordinate a malicious majority because the majority can simply be fabricated. This converts an assumption about the distribution of adversarial trust into an assumption about signature unforgeability, and the latter does not survive Shor's algorithm. The consequence is a consensus failure rather than the isolated compromise of a single account.
Core Node selection. The mechanism specified in 6.1.2 guarantees unpredictability and manipulation resistance under the assumption that a node's VRF private key cannot be derived from public data. Recovering that key would allow an adversary to predict and bias batch-assembly authority, defeating the guarantees enumerated in 6.1.4. By contrast, the commit-reveal entropy process specified in 6.1.1 is hash-based and is not materially affected by this class of threat.
12.4 Design Principles
Parallax does not commit to a specific post-quantum algorithm in this version of the specification. Premature commitment to a single algorithm is the very decision that creates the migration problem in the first place. Instead, the protocol commits to the following invariants.
- Cryptographic agility as a protocol invariant. The signature scheme is a versioned protocol parameter, not a fixed property of genesis state. Accounts carry an explicit scheme identifier, signature verification is dispatched according to that identifier, and an on-chain registry governs the lifecycle of each scheme: active, deprecated, sunset, and prohibited. Schemes can therefore be introduced and retired without invalidating established history. This is the architecture already used by Sui and Aptos, which encode a scheme flag directly into address derivation, and Parallax inherits the same Move account model described in Section 1.
- Conjunctive hybrid validation. During the transition, an account may register signatures under multiple schemes. Where multiple schemes are registered, validity requires all registered signatures to verify successfully. Disjunctive validation, in which any single valid signature is sufficient, reduces account security to that of its weakest registered scheme and is explicitly excluded from the protocol.
- Deferred public-key exposure. Address derivation binds a hash of the scheme identifier and public key rather than the public key itself, so a key is disclosed only when an account authorizes a transaction for the first time. This is not a substitute for a post-quantum signature scheme. It only limits the retrospective exposure window and protects accounts that have received value but have not yet spent it.
- No pairing dependency for aggregation. Signature aggregation across validator committees, if introduced to reduce the bandwidth cost described in 12.5, will not be built on elliptic-curve pairings. Pairing-based aggregation is the specific dependency that currently constrains post-quantum migration in established proof-of-stake consensus layers. Parallax will not acquire that dependency while its consensus layer remains unimplemented.
- Migration without reputation loss. The Identity Decoupling property described in Section 3 separates the Identity Layer from the Custody Layer: Trust Score and migration eligibility are bound to the Parallax Account, while signing authority resides in the linked wallet. The mechanism specified there for relinking a compromised Seed Phrase is structurally identical to the mechanism required for cryptographic-scheme migration. Parallax can therefore require rotation to a post-quantum scheme without users losing accumulated Trust Score, a migration path structurally unavailable to architectures in which the key pair itself is the identity.
- Pre-committed recovery material. Accounts may optionally register the hash of a post-quantum public key while classical signatures remain secure. The commitment is hash-based and therefore quantum-resistant, and the committed key itself is never published to the ledger. In a compromise scenario, control is demonstrated by revealing the preimage, which an adversary possessing only a derived classical private key cannot produce.
12.5 Candidate Primitives and Allocation
NIST standardization provides ML-DSA (FIPS 204, lattice-based) as the general-purpose signature standard, SLH-DSA (FIPS 205, hash-based) as a conservative alternative relying on no assumption beyond the security of the hash function, and FN-DSA (Falcon) as a compact lattice construction. Lattice-based constructions resist Shor's algorithm because their security does not reduce to periodicity over an abelian group, leaving no exploitable structure for the Quantum Fourier Transform. Hash-based constructions resist it because they introduce no algebraic assumption.
These schemes differ substantially in signature size, and in an architecture that collects 47 signatures per transaction, that difference becomes the governing constraint.
| Scheme | Signature | Public key | Basis |
|---|---|---|---|
| ECDSA (current) | 64 B | 32 B | Elliptic curve (vulnerable) |
| FN-DSA / Falcon-512 | ~666 B | ~897 B | Lattice |
| ML-DSA-44 / Dilithium | ~2.4 KB | ~1.3 KB | Lattice |
| SLH-DSA / SPHINCS+ 128s | ~7.8 KB | 32 B | Hash only |
The limiting cost is bandwidth and persistent storage, not computation. Parallax imposes no proof-of-work competition for processor time, so the signing cost of hash-based schemes, while significant in absolute terms, is not a limiting factor for this architecture. Signature size multiplied by committee cardinality is limiting. The provisional allocation follows directly from that multiplier.
| Operation | Specified in | Multiplier | Provisional candidate |
|---|---|---|---|
| Validator committee votes | 6, Stage 4 | 47 per transaction | Compact lattice (Falcon class) |
| Standard account transactions | 5.1 | 1 per transaction | ML-DSA or Falcon |
| Core Node batch stamp | 6.2 | 1 per batch | SLH-DSA (hash-based) |
| Mainnet balance migration | 5.2 | 1 per account, once | SLH-DSA (hash-based) |
| Core Node promotion | 6.6 | Rare | SLH-DSA (hash-based) |
The reasoning is uniform. Operations executed once per ledger batch or once over the lifetime of an account can absorb a multi-kilobyte hash-based signature with no measurable effect on the network and, in return, receive the most conservative security assumption available, one that introduces no mathematical assumption beyond the security of the hash function itself. Operations multiplied across a 47-member committee cannot absorb that cost and require the most compact construction available. The batch stamp is a deliberate rather than incidental assignment: it establishes canonical ordering and permanent history, making it the highest-value signature in the protocol, and it occurs with a multiplier of one.
Whether validator committee votes are persisted in the canonical ledger or retained only until finality is reached materially affects this calculation, since the former converts a recurring bandwidth cost into an unbounded storage cost. This is not currently specified and will be determined during the Testnet Era.
12.6 Precedents
Post-quantum protection in distributed ledgers is not without precedent, and Parallax does not treat the problem as one requiring an original cryptographic construction.
- Sui and Aptos: multi-scheme signature dispatch through an explicit scheme flag in address derivation. These networks share the Move lineage described in Section 1, making their account structure directly applicable to Parallax rather than merely analogous.
- Algorand: Falcon deployed in production for state proofs. The sequencing is instructive: network history was protected before account signatures, on the rationale that history is permanent and retrospectively exposed, while account keys can be rotated.
- QRL: hash-based signatures in production since 2018, solving the state-management problem inherent in stateful schemes by tracking consumed key indices on-chain rather than in client software.
- IOTA: adopted hash-based one-time signatures and later abandoned them in favor of elliptic-curve signatures for usability reasons.
The IOTA case is the most instructive for a network with the design goals stated in this document. One-time and stateful signature schemes make address reuse catastrophic, and users do reuse addresses. That friction proved incompatible with a usability-oriented product, and the network ultimately gave up quantum resistance to resolve it. Parallax, which states in Section 2 that blockchain mechanics should become entirely invisible to the end user, is exactly the design profile exposed to that failure mode. Stateful signature schemes are therefore excluded from the user-facing layer. SLH-DSA is stateless by construction and does not carry this failure mode, which is the primary reason it is preferred over stateful hash-based alternatives despite its larger signatures.
Reference implementations of the standardized schemes exist in audited open-source libraries. Parallax will not implement these primitives independently. Verification will be exposed through native functions in the Move virtual machine, following the pattern already used for classical signature verification in the Aptos and Sui frameworks, rather than being implemented in Move bytecode.
12.7 Open Problems
The following problems remain unresolved. They are stated here rather than omitted, because a specification that presents only the tractable portion of a problem is not a specification.
- Post-quantum signature aggregation. No mature post-quantum scheme provides aggregation efficiency comparable to pairing-based constructions. This is an industry-wide open problem rather than one specific to Parallax, and it directly constrains the bandwidth cost of committee validation. Candidate directions involve hash-based signatures aggregated through transparent succinct proofs, which remain in the research stage. Parallax may therefore operate without aggregation at a higher bandwidth cost, and that decision will be guided by Testnet measurements rather than assumed in advance.
- Post-quantum Verifiable Random Functions (VRFs). Practical VRF constructions are predominantly elliptic-curve based. Post-quantum alternatives exist in the literature, but they do not have a comparable deployment history. Increasing reliance on the hash-based commit-reveal entropy process specified in 6.1.1, which is already resistant to quantum attacks, provides a partial mitigation but does not by itself replace the per-node verifiability property described in 6.1.2.
- Bandwidth in a mobile-first topology. Post-quantum signatures are one to three orders of magnitude larger than ECDSA. The resulting effect on Validator Node bandwidth requirements, and therefore on the accessibility of Tier 2 participation described in Section 7, requires empirical measurement rather than estimation.
- Maturity of the primitives themselves. Post-quantum cryptography has undergone substantially less cryptanalysis than the schemes it is intended to replace. SIKE, a fourth-round NIST candidate, was broken classically in approximately one hour of computation on a single machine. Lattice constructions have withstood continued scrutiny, but the defensible conclusion is that no single scheme justifies exclusive dependency. This is the reasoning behind cryptographic agility as the primary commitment: the protocol is designed to survive the failure of any specific algorithm, including the post-quantum algorithms it eventually adopts.
12.8 Roadmap Integration
Consistent with the issuance-linked model described in Section 9, this work is mapped to protocol phases rather than calendar dates.
| Phase | Objective |
|---|---|
| Phase 3 (Convergence) | Scheme identifier and registry implemented in the account model. |
| Phases 4 to 6 (Testnet Era) | Internal and public Testnet validate multi-scheme dispatch using classical signatures only. Empirical measurement of bandwidth, storage, and latency costs across the 47-member committee model. Aggregation strategy determined. |
| Phase 7 (Sovereignty) | Post-quantum candidates integrated behind the registry. Conjunctive hybrid validation enabled for new accounts. |
| Phase 8 (Resilience) | Hybrid validation extended to all accounts. ECDSA marked as deprecated: valid for existing accounts, unavailable for new registrations. Consensus-cryptography audits extended to post-quantum primitives. |
| Phase 9 (Horizon) | Mainnet genesis with post-quantum schemes active. Balance migration authorized under hash-based signatures. ECDSA enters sunset: verification of established history preserved, new authorizations disabled. |
The objective of this schedule is for the network to stop issuing quantum-vulnerable keys before capable hardware exists, not after. Given the retrospective-exposure property described in 12.2, a migration completed after the threat materializes does not protect keys that have already been published.
13. Conclusion
Parallax Network is not merely a ledger; it is a fundamental redesign of how humans interact with decentralized systems. By stripping away cryptographic friction, implementing mathematically sound tokenomics, and preserving absolute privacy, Parallax is building the infrastructure for the next billion users.
We invite you to participate in this paradigm shift. Not as a spectator. Not merely as an investor. But as a foundational node in a truly usable decentralized world.
Welcome to Parallax Network.