Skip to main content

// Chapter 01 · Concepts

First Principles

The shape of the network, before the mechanics.

10 min4 sectionsConcepts

// 1.0 · three named failures

CENTRALISATION

Hyperscale providers price compute by market position, not the marginal cost of the hardware. The premium compounds every procurement cycle.

IDLE CAPACITY

Workstations, research clusters, and enterprise hardware sit idle for most of their duty cycle. That is a routing problem, not a hardware shortage.

DEMAND PRESSURE

AI, inference, blockchain compute, scientific simulation, and rendering all pull on the same pool. Pool growth lags demand growth, every quarter.

The parallel-first principle

// 1.1 · the unit of work is the request

The unit of work is the request, not the machine.

Centralised cloud and most DePIN compute projects treat the rented instance as the unit: one job lands on one box. ParalleliX inverts that. The live demand is ParalleliX AI, and each inference request is dispatched whole to a capable node, with many requests running in parallel across the pool.

Each request runs on a machine the user never sees. Throughput scales with the number of online nodes, not with the size of any single rented instance. Capacity becomes a property of the network rather than of the strongest available node. Genuinely parallelizable workloads can also be segmented into sub-tasks across machines.

// single-machine
node-01

Task complete @ T=8s

// parallel-dispatch
node-07
node-09
node-11
node-13

Task complete @ T=2s

What request-first changes downstream

// 1.1.1 · six effects

//01

Scheduling

Routes per request. Capability match and best-fit allocation operate on whole inference requests; many route across the pool at once.

//02

Validation

Verifies per request. Proof-of-Execution binds a result to a specific request and the node that served it.

//03

Payment

Settles off-chain. ParalleliX AI credits are metered per request with no on-chain gas; operators earn reward weight from uptime.

//04

Pricing

Scales with the request served, weighted by the node's hardware tier and uptime, not the wall-clock of one rented machine.

//05

Telemetry

Surfaces per-node, per-request state. The node and the requests it serves, not a task ID, are the primary observability unit.

//06

Failure recovery

Redispatches per request. A failing node loses that request and its uptime credit; the coordinator re-routes to a healthy node.

Two layers. Two jobs.

// 1.2 · compute + settlement

// LAYER 1

Compute network

Where work happens. ParalleliX AI posts inference requests; the coordination layer routes each whole to a capable node; many run in parallel and return signed results plus proofs. Parallelizable workloads are segmented into sub-tasks.

// off-chain · request granularity

// LAYER 2

Token + settlement

Where value moves. $PRLX has two utilities: stake on-chain to run a node and earn uptime rewards, and fund ParalleliX AI credits. Settlement is on-chain; computation is not.

// ERC-20 · 0x93ff39…f893

Note·The two seams

The two layers connect at exactly two points: node stake and rewards (an operator locks $PRLX in NodeRegistryLocker to register a node and claims uptime rewards) and ParalleliX AI credits (a user deposits $PRLX once on-chain, then spends it off-chain per request). Every other interaction is off-chain.

The field, side by side

// 1.3 · five projects · eight axes

Read the ‘Unit of work’ row. Every other project in the table starts from the rented machine. That is the differentiator.

Five projects · eight axes · source: documentation.md §1.2

// The field

  • // 01

    Filecoin

    machine

  • // 02

    Render

    machine

  • // 03

    Akash

    machine

  • // 04

    IO.net

    machine

// ParalleliX

// 00

Inference requests

fan out to ↓

  • node · 1whole request
  • node · 2whole request
  • node · 3whole request
  • node · 4whole request
  • node · 5whole request
  • node · 6whole request
  • node · 7whole request
  • node · 8whole request
  • node · 9whole request

// 7 other axes · where ParalleliX diverges from the default

  • Routing modelfield:Single-node assignment (3 of 4) · single-provider deal (Filecoin)prlx:Request fan-out across many nodes
  • Validationfield:Per-job verification (hash · storage proofs · reputation)prlx:PoE hash commitment + sampled re-dispatch
  • Primary workloadfield:Workload-specific (storage · render · containers · GPU)prlx:Workload-agnostic · any parallelizable compute
  • Operator collateralfield:Stake required to participate (varies)prlx:Min 50,000 $PRLX per node · no slashing
  • On-chain honestyfield:Mature / production with limited disclosureprlx:Documented single point of failure (coordination layer)
  • Settlement chainfield:Chain varies (Filecoin L1 · Solana · Cosmos)prlx:Ethereum L1
  • Token rolefield:Pay + stake + earnprlx:· same · Pay + stake + earn

Note

The goal is to turn a procurement problem into a routing problem: instead of renting a bigger machine, submit the work and let the network route it across many nodes. The shared procurement pattern with Filecoin and Render is real; the divergence on the execution unit is what sets the network apart.