// Chapter 15 · FAQ
Hard Questions
The questions a skeptical reader of the specification would ask.
The questions a skeptical reader would ask.
// 15.0 · honest answers · fifteen of them
// Honesty
Fifteen questions a sophisticated reader would push on. Twelve common misconceptions corrected.
Index
// 15.1 · jump to a question
Fifteen questions
// 15.2 · q&a
// q.1 Is Proof-of-Execution a real zero-knowledge proof?
No. PoE v1 is a SHA-256 hash commitment over the result and the task / node identifiers. It proves a result was produced and bound to its task. It does not, on its own, prove the result is correct. Validity is enforced through redundant re-dispatch on a sample of sub-tasks.
Real zero-knowledge proofs are a research direction; they are not marketed as live until they are.
// q.2 What stops a node from faking results?
Three layers at launch. (1) Every dispatched sub-task is signed and the receiving node is authenticated; unattributable returns are dropped. (2) A configurable share of sub-tasks is re-dispatched to a second node and the commitments are compared; mismatches eliminate the offending result and flag the node. (3) Every operator has staked $PRLX to register the node, so a node that consistently returns bad results is dropped from the active set and stops earning while its capital stays locked through the 7-day cooldown. There is no slashing: the deterrent is forfeited earnings and wasted stake-weight, not seizure. A reputation system on top of the same sampling mechanism is planned, not yet built.
// q.3 What happens if the coordination layer fails?
At launch, dispatch and validation run through a centralised coordination layer. If it stops, in-flight tasks pause until it recovers. This is a deliberate trade-off: ship a working network with one moving part rather than a partial multi-validator system on day one. Decentralised validator quorums are a planned later addition; until then, the coordinator is the single point of failure and the docs say so explicitly.
// q.4 Where do operator rewards come from in steady state?
At launch, operators are paid from the 25% Operator Rewards bucket (25,000,000 $PRLX reserved at deployment, streamed via Sablier over 24 months). Once ParalleliX AI usage is sustainable, rewards transition to a share of ParalleliX AI usage payments. The exact split between operators, treasury, and platform is locked before the transition. The bucket hard-exhausts at month 24, so AI demand has to carry the rewards before then. The 4% transfer tax does not enter this pool; it funds development, operations, and marketing.
// q.5 Does $PRLX have governance?
No. $PRLX has exactly two utilities: stake to run a node (and earn $PRLX for keeping it online) and spend as ParalleliX AI credits. There are no proposals, no voting weight, no DAO. Governance is not added later by surprise; if it becomes part of the project scope, it ships with a versioned token-spec change and a migration window.
// q.6 Why isn't contract ownership renounced at launch?
Because the $PRLX contract is a fee-on-transfer token, and its FoT classification depends on a router-and-pair allowlist that has to stay updatable: new DEXes list over time, NodeRegistryLocker (already live) and the ParalleliX AI credit-deposit address need tax exemption, and protocol-internal flows (reward-pool transfers, settlement) come online later. Renouncing ownership freezes the allowlist and breaks every one of those flows.
Ownership is retained until those integrations are stable and the protocol stops requiring new admin surface area. The owner cannot mint, cannot change the tax above the audited maximum, and cannot move tokens from wallets they don't own. See §8.8 for the full ownership scope, the audit-enforced boundaries, and the renouncement trigger conditions.
// q.7 Is the token live? Where is the contract?
Live. The $PRLX token is at 0x93FF39f65cC1D21067939961993ADF3f36BBF893, deployed and verified on Etherscan. The operator contracts are also live and verified: NodeRegistryLocker (stake vault) at 0x706851273c3f5892e2d68ff48dd80bea02a382b6 and OperatorStakeRewardsV2 (rewards distributor) at 0x266939a8baa29344c7687ce2b5074af6dec984e3.
// q.8 Is quantum compute available on the network?
No. Hybrid classical / quantum pipelines are tracked as a research direction, not a capability. The network today targets parallel CPU and GPU workloads, and quantum integration is not listed under what runs now.
// q.9 What is the difference between staking and holding?
Holding is a wallet balance. Staking is an on-chain collateral lock by a registered operator running a node. The two are not interchangeable. There is no holder-staking product, no liquid staking, no staking derivative. The only way $PRLX is staked in the protocol is by an operator running a node, a role that requires hardware, an internet connection, and the node client.
// q.10 Can I run a node without doxxing my identity?
Yes. Registration is permissionless and on-chain: the wallet calls registerNode directly, no outreach, no application, no curator. The node client identifies itself to the coordinator by its node key (secp256k1) and the on-chain nodeId; neither requires a real name. Participation is pseudonymous at the protocol level; KYC, if any operator-side venue ever requires it, is the venue's concern, not the network's. Rewards accrue against the nodeId and are claimed to the staking wallet, which is whatever the operator controls.
// q.11 What happens to in-flight tasks if Ethereum mainnet forks?
Compute does not pause. The coordinator and the node client run off-chain and keep dispatching sub-tasks during the fork window. Settlement, which moves $PRLX on the mainnet, queues until the fork resolves and the network re-anchors to the canonical chain. If a contentious fork produces two surviving chains, the project follows the chain its ERC-20 contract is canonically on and publishes the decision in the docs. Operators do not lose their stake during the fork; NodeRegistryLocker is dormant during the queue, then resumes.
// q.12 Is there a referral or affiliate program for node operators?
No. Registration is permissionless from launch, and the sybil cost is the 50,000 $PRLX minimum stake per node, not a gate. A referral layer that paid for new registrations would just subsidise sybil stake-weight, so it is not in the launch scope. Whether a programmatic referral reward ships later is an open design question, and it will only ship if it can be built without weakening the sybil-resistance of §VII.
// q.13 Can a single task span multiple workload classes?
The live demand path is ParalleliX AI inference, where the unit of work is a single request served whole by one node, not a multi-class pipeline. Multi-class tasks belong to the broader parallelizable-workload path: in the planned open marketplace, a task declares one workload class at submission and the coordinator routes its sub-tasks against that class. A pipeline that genuinely needs more than one class (for example AI inference followed by post-processing render frames) is best decomposed into multiple sequential tasks by the submitter. Workload-class optimisation that treats multi-class tasks as a first-class type is planned, not live; until then, the cleaner mental model is one class per task.
// q.14 What is the smallest task I can submit?
Today the demand surface is ParalleliX AI, where the unit is a single inference request priced in $PRLX credits, so there is no task-segmentation floor to worry about. For the broader parallelizable-workload path in the planned open marketplace, there is no hard floor in the protocol, but the pricing formula has a practical one: at a baseline near 1 $PRLX per CPU-core-hour, a task that wants less than a few minutes of compute is overhead-dominated by intake, segmentation, and settlement. The marketplace quote endpoint returns the actual task_price; if the figure looks disproportionate to the work, the task is below the useful minimum.
// q.15 What stops two submitters from front-running each other?
This applies to the broader parallelizable-workload path in the planned open marketplace, not to ParalleliX AI, where each inference request is metered off-chain in $PRLX credits and routed whole to one node. In the marketplace, submission is not an auction. Each task gets a quote, the quote is valid for 30 seconds, and the coordinator dispatches sub-tasks in the order they are paid for. Two submitters racing for the same operator do not collide; each gets a sub-task slot on a different operator from the eligible pool. The priority_mult parameter lets a submitter pay more to jump the queue legitimately; there is no out-of-band way to do the same.
Common misconceptions
// 15.3 · twelve corrections that come up most often
// Misconception register · 12 corrections
wrong:ParalleliX is a decentralised cloud provider.
right:A decentralised parallel-compute network. The live unit of work is the ParalleliX AI inference request, served whole by one node. Sub-task segmentation is the general parallelizable-workload path served through the future marketplace.
wrong:Holding $PRLX earns staking yield.
right:Holding does not stake. Only registered node operators stake; rewards are payment for node uptime, not yield. There is no slashing: principal is always returned in full on unstake.
wrong:Proof-of-Execution is a zero-knowledge proof.
right:It is a SHA-256 hash commitment. Real ZK is a research direction.
wrong:The network is fully decentralised at launch.
right:The network ships with a centralised coordinator; decentralised validator quorums are a planned later addition.
wrong:$PRLX has governance / voting / DAO.
right:It does not, and adding governance later requires a versioned token-spec change with public notice.
wrong:Operators are paid from the transfer tax.
right:The tax funds Development, Operations, and Marketing. Operators are paid from the 25% Operator Rewards bucket at launch and from a share of ParalleliX AI usage payments in steady state.
wrong:Renouncing ownership would make the contract trustless.
right:It would freeze the FoT classification allowlist, which would break new DEX listings and the NodeRegistryLocker / AI-credit-deposit exemptions. The renouncement criteria are pre-committed (§8.8).
wrong:ParalleliX competes with Ethereum / is its own L1.
right:$PRLX is an ERC-20 on Ethereum. ParalleliX uses Ethereum as the settlement chain; the compute network is off-chain.
wrong:Quantum, real ZK, and federated learning are live or imminent.
right:They are research directions, not yet built, and the document calls them so wherever they appear.
wrong:Staking $PRLX is a way to passively earn.
right:Staking alone earns nothing. Rewards are pay-for-uptime: you must run a real online node, and the stake only sets the reward weight and the sybil cost. Holding or staking without a live node earns zero.
wrong:Anyone can become a node operator right now.
right:True: registration is permissionless and on-chain from launch (registerNode, 50,000 $PRLX minimum stake). There is no allowlist and no curation.
wrong:The network can serve any workload.
right:It targets five workload classes: AI, scientific compute, big-data analytics, blockchain compute, media rendering. Workloads outside these classes may not segment cleanly into sub-tasks.
// Where to go next · reading path