Reference

Architecture

Reaver GPU splits responsibilities across three planes: a node fleet that runs compute, an off-chain scheduler that matches supply to demand, and a Solana settlement layer that holds escrow and enforces stake.

System overview

The design keeps the hot path fast and the trust path on-chain. Matching and metering happen off-chain at low latency; money and stake move only through audited Solana programs. Nothing about a payout depends on a central operator staying honest.

  renter ──submit──▶  scheduler  ──assign──▶  node
    ▲                    │                     │
    │                    │ match by class,     │ run sandbox,
    │                    │ region, reputation  │ stream receipts
    │                    ▼                     ▼
    └────────────  Solana settlement program  ◀──┘
                 (escrow · receipts · stake)

Nodes

A node is any machine running the agent. It advertises a benchmarked GPU class, a region, and a price floor, then waits for assignments. When a job lands, the agent pulls the image, launches it in an isolated sandbox, meters GPU-seconds, and emits signed receipts. Nodes are stateless between jobs — scratch storage is wiped on exit so no renter data persists.

Scheduler

The scheduler is the matching engine. It maintains a live view of available nodes and pending jobs, then assigns work to optimize for price, locality, and reliability. It is deliberately off-chain so matches resolve in milliseconds, but it has no custody of funds — it can only propose an assignment that both parties' on-chain accounts authorize.

• Class & region filter — only nodes meeting the spec are considered.
• Reputation weighting — reliable nodes are preferred and win ties.
• Price discovery — the clearing rate is the lowest floor that satisfies the request.
• Failover — if a node drops, the job is rescheduled and the fault is recorded for slashing.

L1 settlement

Settlement lives in a set of Solana programs. When a renter submits, funds move into an escrow PDA. As the job runs, the node accumulates signed usage receipts. At completion the settlement instruction verifies the receipt chain, releases payment to the operator, refunds unused escrow to the renter, and routes the protocol fee to the treasury — atomically, in one transaction.

Usage receipts

A receipt is a signed, monotonically-numbered record of metered GPU-seconds for a job. The node signs each interval and the renter's session counter-acknowledges, producing a chain neither side can forge alone. Settlement only pays for the highest mutually-acknowledged receipt, so a node cannot overbill and a renter cannot underpay for work it consumed.

Encryption & isolation

Workloads run inside hardware-isolated sandboxes on the node, with the scratch volume encrypted at rest using an ephemeral key generated per job and destroyed at teardown. Inputs and outputs travel over TLS to the renter's own storage. Control-plane traffic between agent, scheduler, and settlement is mutually authenticated, and job specs containing secrets are encrypted to the assigned node's key so the scheduler never sees them in plaintext.

End-to-end job flow

1. Renter submits a spec and escrows estimated cost on-chain.
2. Scheduler assigns an eligible, bonded node.
3. Node pulls the image, starts the sandbox, begins metering.
4. Signed receipts stream as the workload runs.
5. On exit, settlement verifies receipts, pays the node, refunds the renter, takes the fee.
6. Faults (if any) are recorded; the staking program applies slashing.

Ready to integrate? The API Reference documents every endpoint and CLI command.