Contributor compute

Run a GPU worker, earn planned $BASIS rewards

Workers contribute GPU capacity to the Basis inference network. They register a model set and an EVM reward address, send heartbeats, serve jobs, and accrue planned $BASIS rewards proportional to verified, quality-checked work.

Rewards planned · distributor not live

$BASIS worker rewards are planned, not live. The reward distributor contract is pending; settlement runs in dry-run until it is configured. Nothing here is an offer, an investment, or a promise of earnings — failed jobs earn nothing and rewards depend on served, verified work.

Run a worker

The worker process runs from runtime/worker, self-hosted on a machine with a supported GPU runtime. It connects to the orchestrator, advertises the models it can serve, and streams tokens back for jobs it is assigned.

An EVM wallet is required. The worker is identified by a stable worker id and bound to a valid EVM address — that address is where any planned $BASIS reward would be paid. A worker with no valid reward address cannot be rewarded.

Supported runtimes

Ollama — native local model servinglive
WebGPU — in-browser workerplanned

Worker registration

Register with a stable worker_id, a valid EVM worker_wallet, a runtime, and the list of models the worker can serve. The wallet must be a well-formed EVM address — it is the reward destination, so it is validated on registration.

shell

curl https://basis.watch/api/workers/register \
  -H "Content-Type: application/json" \
  -d '{
    "worker_id": "gpu-7a1c",
    "worker_wallet": "0xYourEvmRewardAddress",
    "runtime": "ollama",
    "models": ["basis-default", "basis-small"]
  }'

Heartbeats

A registered worker stays eligible for dispatch by sending periodic heartbeats. A worker that has not beaten recently is treated as offline and is not routed new jobs; uptime is one of the factors that scales rewards.

shell

curl https://basis.watch/api/workers/heartbeat \
  -H "Content-Type: application/json" \
  -d '{ "worker_id": "gpu-7a1c" }'

Reward formula

For a served job, the protocol fee is taken first; the remaining post-fee pool is scaled by the worker's quality × uptime × latency factors — each expressed in basis points — and any penalties are subtracted. All of this is integer bigint math with floor division, so the accounting is deterministic to the last base unit.

Failed jobs earn nothing. A job whose status is anything other than completed is never payable, and a worker without a valid EVM reward address cannot receive a reward even for completed work.

Anti-cheat

Rewards are gated on verified work, not self-reported output. The network applies:

Canary probes — known-answer prompts mixed into the job stream to detect workers returning junk.
Coherence checks — output is screened for being a plausible response rather than padding.
Throughput checks — token rates that are implausibly fast or slow are flagged.

Jobs that fail these checks are rejected on quality or worker grounds and earn nothing.

Settlement schedule

Accrued rewards are batched and settled on Base by a keeper. Each batch is idempotent — a batch hash settles once, with no double-pay — and pays the workers named in its receipts.

Settlement is in dry-run until the distributor is configured. Reward settlement is currently disabled (dry-run); the distributor contract is pending. See settlement batches.

Claim rewards

Claiming accrued rewards is pending the distributor. Until the reward distributor is configured on Base, there is no live claim path and no token to claim — settlement output is recorded in dry-run for verification only.

Registered workers

0 on this instance

No workers registered on this instance yet. The network is pre-launch and this registry is process-local — registered workers appear here once the network is serving jobs.

For how jobs are routed and metered, see /inference. $BASIS is planned, not live; rewards depend on verified work and are never guaranteed.