Skip to main content

// Section 2.4 · Concepts

The On-Chain Anchor

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

What survives a hostile coordinator or node.

// 2.4 · on-chain anchor · three categories · each anchored for a different reason

The blockchain layer holds the data that has to survive a hostile coordinator or a hostile node. Three categories anchor there, each for a different reason.

Three anchor categories

// 2.4.1 · 2.4.2 · 2.4.3

// 2.4.1 · execution records

A previous_hash-linked chain

ExecutionRecord entries form a previous_hash-linked chain. Each record commits a unit of work's request_id, unit_id, node_id, result_root (Merkle root of result chunks), and poe_v1 (the SHA-256 commitment). For AI inference the unit is the whole request; for a parallelizable workload it is one sub-task. Any modification to a past record breaks the chain at that point. A reader walking backwards can detect tampering without trusting any single party.

ExecutionRecord shape: request_id, unit_id, node_id, result_root, poe_v1, previous_hash, signature
Anchoring cadence: records anchor in batches (a Merkle commitment of N records per L1 block), not individually. The cadence trades L1 gas cost against verification freshness. At launch: one commitment per 10 minutes. Planned: one per 2 minutes as on-chain throughput economics improve.
// 2.4.2 · $prlx contract

Standard ERC-20, fee-on-transfer extension

Standard ERC-20 on Ethereum mainnet, with the fee-on-transfer extension (§8.3). The contract holds no execution state beyond what every ERC-20 holds: balances, allowances, the FoT classifier allowlist, the tax-destination wallets, and the owner key. No task data, no operator data, no result data; those live in the execution records, not in the token contract.

0x93ff39f65cc1d21067939961993adf3f36bbf893
// 2.4.3 · operator contractsAt launch

Two live contracts, separate from $PRLX, permissionless

NodeRegistryLocker (0x7068…82b6) is the stake vault. Anyone calls registerNode(stakeAmount, hardwareTier, nodeKeyHash) at or above the 50,000 $PRLX floor; each call mints one independent nodeId (one stake equals one node), and a wallet may hold unlimited nodes. requestUnstake(nodeId) starts a 7-day cooldown, cancelUnstake aborts it, and withdrawStake(nodeId) returns the full principal after it elapses. No slashing, no slasher role.

OperatorStakeRewardsV2 (0x2669…84e3) is the streaming reward distributor. While a node is online its earned(nodeId) balance grows every block, weighted by stake × tier; the operator pulls it with claim(nodeId) to wei precision. Stake and rewards live in separate contracts, so the reward path never touches principal.

Gas economics

// 2.4.4 · l1 cost is real · batched commitment is the bridge

Note·L1 gas cost is visible, not hidden

The coordinator batches commitments to amortise the per-record cost across many units of work. At the planned target throughput (1,000+ units of work per second network-wide), per-record on-chain commitment would saturate L1 by itself. The batched-Merkle commitment pattern is the workaround. Planned L2 settlement for execution records is the structural fix; the batched commitment pattern is the bridge.
AT LAUNCH1 commitment / 10 min

Batched Merkle. Tight L1 gas budget.

PLANNED1 commitment / 2 min

On-chain throughput economics improve. Tighter freshness target.

LATERL2 settlement

Execution records move to L2. L1 anchors a periodic L2 state root.