>Per-Step Detail

A request enters the coordinator. On the live path it is a ParalleliX AI inference request carrying a prompt, a model reference, and $PRLX credits deposited once on-chain and metered off-chain. The general parallelizable-workload path (rendering, scientific sweeps, smart-contract bytecode, simulation parameters) reuses the same intake with task parameters (workload class, hardware tier, priority, deadline) and a $PRLX payment matching the quoted task_price (§8.7).

The coordinator's intake API checks the credit balance or payment, allocates a unique request_id, and enqueues the request for scheduling.

{
  "workload_class": "ai.inference",
  "model": "oss-chat-v1",
  "hardware_tier": 3,
  "priority": "standard",
  "deadline_seconds": 60,
  "credit_account": "0xe3...",
  "client_pubkey": "0x..."
}

General-path only. A ParalleliX AI inference request skips this step: an autoregressive generation cannot be split across nodes, so it is dispatched whole to one capable node. For genuinely parallelizable workloads (rendering, scientific sweeps, big-data map-reduce), the segmenter inspects the task and splits it into independent sub-tasks. The split obeys the task's dependency graph; sub-tasks with no data dependency can run in parallel, sub-tasks with dependencies are sequenced.

Tasks that genuinely cannot be parallelised dispatch as a single unit. The network does not pretend a sequential workload is parallel. It routes it honestly. A permissionless third-party submitter marketplace that feeds this path is a planned direction, not the live ParalleliX AI flow.

The unit of work, a whole inference request or a single sub-task on the general path, is matched to a node using four signals in priority order (full detail in §IV): capability match, capacity-aware queue position, best-fit allocation, reputation weighting (a planned signal; constant 1.0 today). For AI inference, parallelism is request-level: many requests route across the pool concurrently and throughput scales with the number of online nodes.

The whole inference request, or a single sub-task on the general path, is encrypted to the assigned node's RSA public key before transmission. Only that node can decrypt. The network treats in-transit confidentiality as a default, not an option.

The node decrypts the payload and runs it on local hardware. An inference request runs whole: the node generates the full autoregressive output. Execution time is bounded by the node's declared capacity and the deadline.

If the node fails to return within the deadline the work is re-dispatched to a fresh node and the original returns are discarded.

The node computes a commitment over the result. The formula is bytecode-stable and audit-anchored.

PoE = SHA-256(task_id || result || node_id)

def proof_of_execution(task_id: bytes, result: bytes, node_id: bytes) -> bytes:
    return sha256(task_id + result + node_id).digest()

# Node returns:
#   { "request_id": ..., "result": ..., "poe": ..., "sig": rsa_sign(...) }

The coordination layer reconstructs the commitment from the returned result and compares to what the node submitted. Two checks run before settlement.

Recovery without slashing: a bad PoE result is dropped and the node flagged, and the sub-task is re-dispatched to another node. Repeated bad results lower the node's standing and can remove it from the active pool. Staked principal is never seized; it is returned in full on unstake (§8.5).

An inference request has a single result and skips aggregation: its output returns whole to ParalleliX AI through the same encrypted channel. On the general path, validated sub-task results are aggregated by the coordinator into the task's final output, honouring the original dependency graph, and returned to the submitter through the same secure channel.

Operators are paid for node uptime, not per request. Served work keeps verified uptime high, and uptime drives the daily reward stream, weighted by stake x tier. Rewards are pay-for-uptime, never APY or yield.