BASIS

Run a GPU worker, earn $BASIS

Workers contribute GPU capacity to the Basis inference network. Connect a wallet, register a model set, send heartbeats, serve jobs — and earn $BASIS for completed, verified work, settled on Base.

Agent skill · basis-worker

Add the Basis Worker Skill to your agent

Hand the basis-worker skill to Claude Code or any agent and it sets up the worker for you: connect a public reward wallet, register a model set, generate a local config, and start serving. Registering is the action — your worker comes online and stays eligible as the contributor mesh comes online.

Open the worker skill →

connect → register → heartbeat → serve → earn

  1. 01
    Connect a walletConnect

    Bring a valid EVM address on Base. That address is where your $BASIS rewards are paid — a worker with no valid reward address cannot earn.

  2. 02
    Register the workerRegister

    Run the worker from runtime/worker on a machine with a supported GPU runtime. It registers a stable worker id, your reward address, and the model set it can serve.

  3. 03
    Send heartbeatsHeartbeat

    A connected worker stays eligible for dispatch; heartbeats keep it marked active and signal liveness so a worker that stops beating is treated as offline.

  4. 04
    Serve jobsServe

    An orchestrator assigns worker-routed jobs matching your models. You stream tokens back through the gateway, which counts output tokens as it relays them.

  5. 05
    Earn $BASISEarn

    A completed, verified worker-routed job pays a $BASIS reward, designed to be scaled by quality, uptime, and latency; failed jobs pay zero. The on-chain 10% burn / 90% worker reward route has been proven by a controlled mainnet transaction. Public worker routing is ready but off: a job routes to your GPU only when worker routing is enabled and a verified worker is online, so registering is not by itself a live earn path yet. Rewards batch and settle on Base.

Supported runtimes

  • Ollama — native local model servinglive
  • WebGPU — in-browser workerresearch

Register a worker

Register with a stable worker_id, a valid EVM worker_wallet, a runtime, and the list of models the worker can serve. The wallet is your reward destination, so it is validated as a well-formed EVM address 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"]
  }'

Once registered, keep the worker eligible for dispatch by sending periodic heartbeats. A worker that has not beaten recently is treated as offline and is not routed new jobs.

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

How rewards are computed

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

Completed, verified work earns. A job whose status is anything other than completed is not payable, and a worker without a valid EVM reward address cannot receive a reward even for completed work. Rewards depend on the work you serve — they are not promised or guaranteed.

Quality

A factor designed to scale the reward toward output that passes verification and away from junk or padding.

Uptime

Consistent heartbeats keep you marked active; uptime is a factor designed to weight the reward.

Latency

A factor designed so faster token delivery on assigned jobs improves the reward.

Rewards follow verified work

Rewards are gated on verified output, not self-reported tokens. 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.

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.

Network workers

1 registered
Worker idRuntimeModelsJobsOnline
basis-m4max-01ollamabasis-default0online

Run a worker

Connect a wallet, register your GPU, and start serving jobs. The worker guide walks through the runtime setup, registration, and heartbeats end to end.

For how jobs are routed and metered, see /inference. Rewards depend on completed, verified work — failed jobs earn nothing, and nothing here is a promise of earnings.