BASIS
Documentation

Reference · Network data

Network data

Basis publishes aggregate metrics for the inference network on a single page, /data, and as JSON at /api/data. Both describe what the network has served — jobs, tokens, payments, receipts, workers, and Base settlement — as aggregates only. No prompts, no wallets, no API keys, no private user data.

What it shows

  • Network — total jobs (completed / failed), total server-counted tokens, workers online, distinct active models, and the runtime status.
  • Users & API — API-key and active-user counts. These are not tracked without durable persistence and are reported as such, never invented.
  • Credits & payments — credits spent (derived from receipts), BASIS routed by sell token (ETH / WETH / USDC) as aggregate volume, and quotes created vs. executed.
  • Pricing — the active pricing epoch: its id, the BASIS-per-credit rate (basis_per_credit_raw), the honest price_source and overall pricing status, the credit USD target, and any warnings. Pre-launch this reads as the placeholder epoch — a concrete rate, never a fabricated live market price. The rate is dynamic and versioned; a new epoch applies prospectively and never reprices settled jobs.
  • Workers & rewards — pending and settled $BASIS rewards (raw base units), settlement batches, and failed batches.
  • Token & launch status — what is configured vs. pending, derived from environment configuration, plus the payment-router status.
  • Treasury — fee-stream statuses with WETH-side and $BASIS-side amounts accounted separately, plus a draft allocation and a proposed (not implemented) burn. Amounts are nullable raws — pending, never fabricated. Detailed below.
  • Recent activity — the last receipts and settlement batches by hash, model, status, and counts only.

Treasury metricsdraft / pending

The treasury block reports how value would accrue to the network once $BASIS launches — fee streams, a draft allocation, and a proposed burn. None of it is live. Every fee/treasury/burn amount is pending until the token launches, addresses are configured, and reads are verified on Base. The page renders this at /treasury.

  • Streams — each fee stream (inference network margin, Bankr creator fee WETH-side, Bankr creator fee $BASIS-side, payment-router, settlement) carries a side (weth or basis) and an amount_raw that is null until configured and verified. WETH-side and $BASIS-side are never blended into one figure.
  • Worker / network & $BASIS-side splits — the per-job split (v0.1 reference proposal 70% worker / 30% network margin, configurable) and the $BASIS-side fee-generation split (50% burn / 50% staker rewards). The treasury is shown as assets vs obligations — there is no fixed allocation matrix.
  • Bankr creator fees — the Bankr/Doppler protocol keeps its protocol share (a source-tagged assumption from the Bankr docs). Basis receives only its beneficiary share, which is read from the launch output / fee API once $BASIS is live — never guessed. WETH-side and $BASIS-side claimable/claimed are tracked separately and null until verified.
  • Burn & staking — the 50% burn and 50% staker-reward shares of $BASIS-side fee generation. Both carry status: not_implemented with a to-date of "0", tracked separately from treasury balances. No burn or staker reward occurs until the contracts exist and are verified on-chain. WETH-side fees stay separate (operations, liquidity, security) with no burn/staker split.

Honest by construction

Fee, treasury, and burn figures are pending or draft until launch and on-chain verification. The API never coerces a pending amount to zero and never blends WETH-side with $BASIS-side. The burn policy is a draft proposal that is not implemented.

Privacy model

The endpoint is aggregates-only by construction. No prompt text exists anywhere in the store, so none can be surfaced. Recent activity exposes a receiptHash or batchHash with a model, a status, and token or entity counts — never a user wallet, a payer, or an API key. There is no endpoint that returns a raw list of wallets or keys.

Guarantee

Aggregates only. No prompts. No private keys. No private user data.

Durability & honest gapsnon-durable

The store backing these metrics is process-local and non-durable: it resets on a cold start and is not shared across serverless instances. Before launch, every figure reads honestly as zero or pending rather than a fabricated history.

As a result, durable time-series — the per-day token series (tokens_per_day) and average throughput (avg_tokens_per_second) — require a persistent store and are pending. The API returns an empty array and null respectively rather than guessing values. Likewise, aggregate user counts and wallet-keyed deposit totals are not derivable in a privacy-safe way from the non-durable store and are reported as not tracked / zero.

The API

/api/data and /api/network/data return the same payload from a single shared builder, so the two can never drift. Both are dynamic (never cached) so the numbers reflect the current process.

shell
curl -s https://basis.watch/api/data
# alias — identical payload:
curl -s https://basis.watch/api/network/data

See the rendered page at /data and the JSON at /api/data.