Loom Compute

Overview

Loom is designed as a two-sided compute market. Buyers fund deterministic inference, rendering, and verification jobs. Operators opt in to short sessions, accept compatible work, and submit measurable outputs. A verification service evaluates those outputs before a settlement coordinator includes rewards in a claim epoch.

The system deliberately separates useful computation from financial settlement. GPU execution happens off-chain because that is where commodity hardware is available. Robinhood Chain is the planned public record for NVDA custody, epoch commitments, and completed claims.

Design principles

Useful work before rewards

Customer-funded execution is the intended economic base. Benchmarks can test hardware and bootstrap operators, but they cannot create sustainable reward value by themselves.

Verification before settlement

A client-reported score is not proof. Accepted work must be bound to a server-issued lease, a specific input commitment, a deadline, and checks that a modified browser cannot predict in advance.

Liabilities before distribution

An epoch cannot authorize more raw token units than the treasury can cover after accounting for every earlier unclaimed reward. Display prices never substitute for raw-unit solvency.

Explicit trust boundaries

Loom does not describe an off-chain verifier as trustless. Operator eligibility, job assignment, result acceptance, and root construction remain coordinated services until a stronger proof system replaces them.

Product loop

1. Fund: a buyer creates a bounded job and deposits its execution budget.
2. Lease: the coordinator issues a signed, short-lived lease to a compatible operator.
3. Execute: the browser worker downloads committed inputs and performs the requested GPU work.
4. Submit: the worker returns outputs, timing evidence, adapter capability, and the lease identifier.
5. Verify: the verifier checks commitments, ceilings, hidden challenges, and selected independent replays.
6. Account: an accepted result becomes a reward ledger entry under a published allocation policy.
7. Commit: the settlement service builds an epoch Merkle tree and publishes its root to the Robinhood Chain claim contract.
8. Claim: the operator submits a Merkle proof; the contract transfers covered raw token units and records the claim.

System architecture

Minimum contract state

• ProtocolConfig: authorities, fee limits, verifier policy, and paused state.
• RewardReserve: NVDA contract, cumulative deposits, liabilities, and paid units.
• Epoch: sequence, Merkle root, NVDA total, close time, and accounting hash.
• Claimed: epoch and wallet record preventing a second claim.

Verification model

Loom uses layered defenses rather than treating one benchmark result as proof. The target is economically meaningful confidence, not a claim that arbitrary GPU work is perfectly verifiable.

• Signed leases bind a wallet, workload, nonce, input hash, deadline, and maximum reward.
• Hidden challenges introduce unpredictable inputs that cannot be precomputed from public client code.
• Deterministic workloads are preferred where an output can be reproduced within an accepted numerical tolerance.
• Independent replay re-runs a sample of work on verifier-controlled infrastructure.
• Ceilings and anomaly detection limit impossible throughput, duplicate output, and coordinated abuse.
• Reputation influences assignment limits but never replaces validation of the current result.

Robinhood Chain settlement

Accepted work is accumulated off-chain during a six-hour epoch. Before closure, the settler converts every entitlement into NVDA's raw integer units, verifies reserve coverage, and builds a deterministic Merkle tree. The root and total NVDA liability are committed to an epoch in the claim contract.

A claim call verifies the leaf, confirms that the epoch is active, checks that the wallet has not claimed, transfers NVDA from the reserve, and records the claim atomically. This makes duplicate claims fail without depending on an off-chain database.

Root reproducibility

Each closed epoch should publish a downloadable manifest containing sorted leaves, allocation policy version, source revenue, conversion records, raw-unit totals, and the resulting root. An independent tool must reproduce the root byte for byte.

One covered reward reserve

Loom maps every eligible verifier-accepted run to NVDA on Robinhood Chain, regardless of the GPU vendor reported by the browser. The fixed NVDA ERC-20 address remains bound into every settlement leaf so claims cannot be redirected to another asset.

The configured reward contract is 0xd0601ce157db5bdc3162bbac2a2c8af5320d9eec. Claims use 18-decimal raw-unit accounting and remain disabled until the Robinhood Chain reserve and audited claim contract are deployed and funded.

• Only the configured NVDA contract is eligible for the reward reserve.
• Only realized and reconciled revenue can fund acquisition.
• Existing liabilities are reserved before a new epoch closes.
• Price displays are informational; claim solvency is measured in raw units.
• Emergency pause prevents new claims while preserving the public accounting trail.

Loom token

The planned Loom coordination asset has a fixed display configuration of 1,000,000,000 units on Robinhood Chain with 18 decimals. The contract remains TBA and the intended public launch venue is pons. Runner payouts use the separate NVDA contract on the same chain.

Its proposed role is access, not payout. A 24-hour mining pass reads the wallet's $LOOM value when issued: holder at $30 or more receives x1.0, operator at $300 or more receives x1.25, and foundry at $3,000 or more receives x1.5. A later balance change applies only when the next pass is issued.

$LOOM does not make an unverified browser score valid, replace treasury solvency, or guarantee a reward. The disclosed protocol treasury allocation is approximately 10% of supply. Its purpose is to support covered runner rewards, network incentives, and protocol continuity while buyer-funded compute demand develops. The allocation is controlled, not locked, until multisig custody and a public movement policy are active.

Economic model

Revenue should come from compute buyers, verification services, and clearly disclosed platform fees. A finite launch subsidy may accelerate testing, but it must be budgeted separately and cannot be described as workload revenue.

Proposed reward formula

The nominal policy is ($0.10 base + $0.0009 × verified VCU) × treasury governor × pass tier. During the initial browser rollout, one participation VCU is assigned per server-verified second. Browser-reported dispatches and local Loom units are diagnostic only and cannot increase the reward. Instrument-specific useful-work pricing remains a later verifier version.

At each six-hour settlement, the governor compares nominal 24-hour liabilities with treasury value and scales the epoch toward a maximum distribution target of 3% of the vault per day. Rate movement is bounded to 2× per settlement with a proposed floor of 0.1. The program can pay only assets already deposited in allowlisted vaults.

Illustrative revenue waterfall

1. Buyer payment clears payment and infrastructure costs.
2. Operator compensation funds accepted execution.
3. Verifier compensation funds replay and integrity checks.
4. A protocol fee supports coordination, development, and risk reserves.
5. The reward reserve allocation acquires NVDA for future covered epochs.

All percentages remain configuration proposals until real workload costs, fraud rates, asset access, and legal constraints are measured.

Threat model

• Fabricated work: modified clients submit invented timing or results.
• Replay: a valid output is reused across leases or wallets.
• Sybil operation: one operator presents many identities to bypass limits.
• Verifier compromise: a coordinator accepts invalid work or censors valid work.
• Insolvent root: settlement commits liabilities beyond vault coverage.
• Key compromise: a hot signer publishes a malicious root or changes configuration.
• Privacy leakage: GPU metadata or model inputs expose user or buyer information.

Production readiness requires independent program review, multisig controls, least-privilege service keys, reproducible epoch tooling, incident procedures, monitoring, and a public disclosure of every remaining centralized decision.

Staged roadmap

Phase 0: local prototype

Browser capability checks, interface validation, workload schema, and deterministic test vectors. No token rewards.

Phase 1: closed compute pilot

Approved operators, customer-funded test jobs, server-side replay, fiat or stablecoin accounting, and measured fraud rates.

Phase 2: test settlement

Reserve contracts, epoch roots, claim records, root reproduction tools, multisig procedures, and adversarial testing.

Phase 3: limited mainnet

Capped NVDA liabilities, audited contracts, restricted workload classes, monitored claims, and conservative acquisition limits.

Phase 4: open market

Broader operator access only after useful demand, verification costs, compliance, solvency, and unit economics are demonstrated.