Skip to main content

// Section 2.1 · Concepts

The Four Actors

1 min2.1Concepts
// 1 of 4 · network anatomy

Four actors. Every operation.

// 2.1 · the participants and their relationships

// 1Demand SideParalleliX AI at launch
// 2Coordination LayerSchedules · dispatches · validates · settles
// 3Node OperatorsExecute and return
commits PoE
On-Chain AnchorTamper-resistant PoE records

Each actor in detail

// responsibilities · constraints · build status

// 1 · Demand Side

ParalleliX AI at launch. Open submitters are planned.

At launch the demand side is ParalleliX AI: users fund $PRLX credits and each inference request becomes a unit of work on the network, dispatched whole to one capable node. A permissionless marketplace where third parties submit and price arbitrary compute directly is a planned later addition. Either way the unit of interaction is the request, never a specific operator or machine image.

// 2 · Coordination Layer

Single coordinator at launch. A quorum is planned.

Schedules requests, dispatches each whole to one node, acts as the launch validator, settles payment. It also segments genuinely parallelizable workloads into sub-tasks, the general compute path. Implementation specifics (centralised coordinator vs decentralised quorum, on-chain vs off-chain logic) are deployment-time decisions. Validator decentralisation is a planned later addition.

// 4 Services

  • Intake API
  • Segmenter
  • Scheduler
  • Validator

// Launch Caveat

Documented single point of failure. Decentralised validator quorums are a planned later addition.

// 3 · Node Operators

Independent participants running the operator client.

Operate their own GPU/CPU hardware. Register capabilities (tier, region, workload classes), accept dispatched work, return signed results plus PoE, earn $PRLX uptime rewards. Registration is permissionless from launch: anyone stakes the 50,000 $PRLX minimum on NodeRegistryLocker and runs the client. No allowlist, no curation, no off-site outreach.

// Must

  • Run the node client
  • Hold a node key pair
  • Stake to register a node
  • Return PoE per unit of work

// Cannot

  • See cross-task data
  • Replay another node's result
  • Modify the segmentation logic
// 4 · On-Chain Anchor

The blockchain layer for tamper resistance.

Proof-of-Execution records are committed here for auditability. The on-chain anchor is Ethereum mainnet today; L1 + L2 cross-chain settlement is a planned later addition. Compute itself is off-chain; the anchor records the receipt, not the work.

Coordinator scope

// must · may · cannot · the audit-visible boundary

// Must

  • Route every request to a qualified node
  • Segment parallelizable workloads into sub-tasks
  • Validate Proof-of-Execution commitments
  • Settle payment to operators

// May

  • Decide topology (one process or many)
  • Re-dispatch a sampled fraction for redundant validation
  • Evolve from single coordinator to quorum (planned)

// Cannot

  • See plaintext request payloads (encrypted to node pubkey)
  • Alter results returned by nodes without detection
  • Seize staked principal (no slashing exists)

Caveat·Honest trade-off at launch

The coordinator is a documented single point of failure at launch. The design goal is to ship a working network with one moving part rather than a partial multi-validator system. Decentralised validator quorums are a planned later addition.