What you trust, and what you can verify

Robinhood Chain is the settlement and trust layer, not the compute layer. Nothing that would be expensive, private or high-frequency goes onchain.

The coordinator's verifier key signs an EIP-712 Completion after a job passes verification. It is an attestation key: it holds no funds and sends no transactions. Anyone (the host, the customer, a keeper) submits the signed completion to the escrow.

Completion(bytes32 jobKey, address provider, bytes32 farmId, uint256 amount,
           uint64 computeSeconds, uint64 startedAt, uint64 completedAt,
           bytes32 workloadType, bytes32 resultHash, uint64 sigDeadline)

Refund(bytes32 jobKey, uint64 sigDeadline)

Before signing, the coordinator runs these checks on the uploaded result:

• Re-hashes the output bundle from storage and compares it with the host-reported resultHash and the host-signed receipt (personal_sign by the daemon's host key).
• Checks execution telemetry from the assigned GPU UUIDs during the run: utilization, memory and temperature samples. A run that claims success with no utilization on its GPUs is flagged.
• For workloads with a registered deterministic verifier, recomputes the expected output independently and compares it — the only path to RESULT VERIFIED.
• Computes billable GPU-seconds as the shorter of host-reported and server-observed runtime, capped at the job's max runtime.

The backend can never simply declare “job completed” and take the escrow. Money moves only through these paths, each enforced by ComputeEscrow:

The amount in a completion is the customer's charge — compute plus the platform fee added on top — and can never exceed what the customer escrowed. On release the escrow splits it so the fee recipient gets exactly the fee and the provider side gets the full compute charge (any rounding unit stays with the host). Anything the job didn't use goes back to the customer. Exact formula

• During the challenge window the customer calls openDispute (job result problem, missing output, host terminated early, invalid output). The escrow freezes: nothing can be released.
• The arbiter reviews the job spec, logs, GPU telemetry, the result and server hashes and the host-signed receipt — all of which GPUFarm keeps for the job.
• The arbiter calls resolveDispute(jobKey, providerAmount). It can only choose how much of the completed charge is paid out (≤ amount) — that award is split into fee, farm commission and host share exactly like a normal release — and everything else returns to the customer. It cannot send funds to any other address, including itself.
• The arbiter address is snapshotted into each job when it's funded; replacing the arbiter later never affects existing jobs.
• If a dispute is not resolved within 30 days, anyone can call resolveExpiredDispute and the customer is refunded in full.

Every completed job gets exactly one label. GPUFarm never labels everything “verified”.

• Host disappears before running: the job is re-offered to another compatible machine. The customer pays nothing for the lost attempt.
• Host fails or disconnects mid-run: the assignment is abandoned and the job re-queued (up to its attempt limit), else marked FAILED.
• A FAILED or canceled funded job gets a verifier-signed Refund; anyone can submit it and the full escrow is credited back to the customer.
• If GPUFarm's servers vanished entirely, the customer can still call refund after the job's deadline (max runtime + 24 h queue allowance + 1 h, at most 30 days). No server cooperation needed.
• Duplicate settlement is impossible: each transition requires an exact current status, so a job settles or refunds once.
• Payouts are pull-based: a payee who can't receive funds can't block anyone else's settlement.