BASIS
Documentation

Overview

What is Basis?

Basis is a Base-native inference network for agents and applications. It exposes an OpenAI-compatible API, coordinates contributor GPU workers, records inference receipts, and prepares $BASIS-denominated credits and Base-settled rewards.

Definition

One sentence: Basis is a Base-native inference network. Developers and agents query language models through an OpenAI-compatible API; contributor GPUs register as workers and serve those jobs; every settled job produces a verifiable inference receipt; and accounting is denominated in planned $BASIS credits, with worker rewards planned to settle in batches on Base.

Token posture

$BASIS is the planned network token for inference credits, API usage, and worker rewards. It is planned, not live: no contract is deployed until an address is configured, and nothing here is an offer, price, or investment. Surfaces render pending until configuration is real. soon

Who it is for

App developers

Teams that want chat-completion inference behind a familiar, OpenAI-compatible interface — no new SDK to learn, just a base URL change.

Agent builders

Autonomous agents that call inference over HTTP and need deterministic, auditable per-job accounting they can reconcile in code.

GPU workers

Operators with idle GPU capacity who want a structured way to register a worker, serve jobs, and earn Base-settled rewards for measured work.

Token & launch participants

People following the planned $BASIS launch on Base — credits, rewards, and settlement accounting, with honest pending states.

Operators

Self-hosters running the orchestrator, the settlement keeper, and a backend — configuring env vars and watching what is live versus pending.

What it does

  • Serves OpenAI-compatible inference

    Point any OpenAI client at the Basis base URL. /api/v1/chat/completions streams tokens; /api/v1/models lists what the network can serve.

  • Coordinates contributor GPUs

    Workers register with an EVM reward address, heartbeat, and serve jobs the orchestrator routes to them. The server counts output tokens — worker-reported counts are advisory.

  • Accounts deterministically

    Charges, the protocol fee, and worker rewards are computed in $BASIS base units with integer math — no floating point anywhere in the money path.

  • Writes a receipt for every job

    Each settled job produces a SHA-256 receipt over canonical JSON. Anyone can re-derive the hash; duplicate jobs and receipts are rejected.

  • Settles rewards on Base

    Worker rewards accrue to a reward ledger and are batched by a keeper for idempotent settlement on Base — a batch settles once, failures stay recoverable.

What is live now

These pieces exist and run today. They do not depend on a deployed token or a hosted backend.

  • live

    OpenAI-compatible API contract

    The /api/v1/chat/completions and /api/v1/models routes are real; clients get a structured runtime_pending (503) until a backend is configured.

  • live

    Deterministic accounting

    The credit, receipt, and reward formulas are implemented and unit-tested with bigint math.

  • live

    Worker registration

    Contributor GPUs can register a worker_id, an EVM reward wallet, a runtime, and the models they serve.

  • live

    Inference receipts

    Settled jobs produce canonical-JSON, SHA-256-hashed receipts that anyone can re-derive.

  • dry-run

    Settlement keeper (dry-run)

    The keeper can batch the reward ledger and compute a batch hash without writing on-chain until the distributor is configured.

What is pending

These pieces are designed and documented but not yet live. Each renders its real configuration state.

  • pending

    Live token, contracts & Bankr launch

    The $BASIS contract, the credit vault, the reward distributor, and the Bankr launch are all pending. Addresses render pending until env vars are set.

  • pending

    Hosted orchestrator

    The long-lived Socket.io orchestrator and contributor workers run locally or self-hosted today; a hosted deployment is pending.

  • process-local

    Durable persistence

    The store is process-local and non-durable — it resets on a cold start — until a durable store is configured.

  • pending

    Inference runtime backend

    No upstream backend is configured; requests return a structured runtime_pending response.

Live vs pending

The panel below is derived from real configuration — not a roadmap. A fresh deployment with no addresses set reads honestly as pending.

Live vs pending — derived from configuration