BASIS
Documentation

Network · Token

The $BASIS token

soonPending

$BASIS is the planned, Base-native token at the center of the Basis inference economy. It is the asset inference is paid in, the worker-reward token, and the settlement token — one unit of account across payment, credits, API usage, worker rewards, and on-chain settlement. Credits are the accounting and reservation unit; the charge settles in $BASIS. ETH, WETH, and USDC on Base route into $BASIS at payment time, so callers don't have to hold it in advance. This page describes what it is for — and is honest about what is configured versus pending.

Token identity

Name
Basis
Symbol
BASIS
Chain
Base · chainId 8453
Launch platform
Bankr
Decimals
18
Token address
pending deployment

The address renders as pending deployment until a real contract address is supplied through configuration. No address is invented in source.

What $BASIS is for

Inference payment asset

$BASIS is the asset inference is paid in. Credits are the accounting and reservation unit; the charge itself settles in $BASIS base units. A user's available credits reserve and meter inference and API calls, locked to a rate at reservation.

API usage

Every call to the OpenAI-compatible API is priced deterministically in $BASIS base units (integer base units, no floating point) so a request and its receipt agree to the last unit.

Worker rewards

Contributor GPU workers that serve jobs accrue a reward in $BASIS base units — the worker share of each completed, quality-checked job, set by a configurable worker/network split. A worker needs a valid EVM reward address to accrue anything; failed and rejected jobs accrue zero.

Settlement accounting

Reward ledger entries and Base settlement batches are denominated in $BASIS, so the on-chain settlement record matches the off-chain accounting.

Routable funding

ETH, WETH, or USDC on Base can route into $BASIS at payment time to fund credits. Basis prepares the swap; the user or agent wallet signs and submits it — Basis never signs or custodies. Holding $BASIS is not required to start: you can convert at the moment you pay.

Network usage coordination

$BASIS is the shared unit that lets the credit, receipt, reward, and settlement layers reference the same accounting across the network.

Routing in, rewards out

Two directions, one token. In: a payer holding ETH, WETH, or USDC routes it into $BASIS at payment time to fund credits — the user/agent wallet signs the swap, and Basis never signs or takes custody. Out: contributor workers earn $BASIS only — the worker share of each completed job under a configurable worker/network split, settled on Base. The mechanics live in Credits and the API reference.

Credits & dynamic pricing

Usage is metered in credits — Basis's usage-accounting unit. Credits are deterministic inside a quote, reservation, pricing epoch, and receipt, but the network does not promise that one credit maps to the same amount of $BASIS forever. The credit ↔ $BASIS conversion is set by a versioned pricing epoch and locked at reservation into a hashed snapshot the receipt preserves.

A new pricing epoch applies prospectively to new quotes and reservations only. There is no retroactive repricing: accepted jobs are never silently repriced, existing receipts are never rewritten, and a worker's reward is drawn from the same locked snapshot recorded on the receipt. Epoch-to-epoch moves in BASIS-per-credit are capped, and pre-launch the rate runs in an honest placeholder epoch. The mechanics and the machine-readable epoch are in Credits and GET /api/pricing.

Fee streams & treasury

$BASIS is the payment, reward, and settlement asset — not a financial product. The network has, at most, the fee streams below, and WETH-side and $BASIS-side amounts are accounted separately, never blended. None is live: each reads pending until $BASIS is deployed and verified on-chain. The full model is in the repository at docs/tokenomics.md, docs/treasury-policy.md, and docs/bankr-fees.md.

Fee streams — accounted separately by side

  • Inference network margin

    $BASIS

    The network's share of each completed job — the gross $BASIS charge minus the worker reward. A configurable split; the v0.1 reference proposal is 70% worker / 30% network margin, pending operator approval. Collects nothing until $BASIS is live.

  • Bankr creator trading fees

    WETH + $BASIS

    Accrue on both sides of the Uniswap V4 pool from the swap fee. The two sides are tracked separately and never blended: WETH funds operations; $BASIS is native inventory. The exact Basis beneficiary share is read from the launch output, never assumed.

  • Payment-router fee

    none

    None today beyond market slippage. The router prepares user-signed swaps and takes no protocol rake in v0.1.

  • Settlement fee

    none

    None today. Settlement is keeper-driven and charges no separate fee in v0.1.

The network margin plus token fee streams feed treasury accounting. $BASIS-side fee generation — the inference network margin and the $BASIS side of the Bankr creator fees — is designed to split 50% burn / 50% staker rewards once the supporting contracts exist. That split is on the $BASIS side only. The WETH side stays separate: it is a liquid external reserve for operations, the inference backend, liquidity, security, and a treasury reserve, and is never routed into burn or staker rewards. There is no fixed allocation matrix of the 100B supply, and no per-bucket split is asserted. The policy is in docs/treasury-policy.md.

Burn & staking — designed, NOT IMPLEMENTED

The $BASIS side of fee generation is designed to split 50% burn / 50% staker rewards, but neither is built. Burn would remove $BASIS from supply; staker rewards would distribute the other half to stakers. Both are not implemented: each requires a token launch, contract support, accounting support, operator approval, and legal review before it could ever be turned on.

Until those contracts exist and a production read verifies them on-chain, there is no burn, no staking, and no staker rewards — and none is claimed here. Burned amounts and staker-reward amounts would be tracked separately from treasury balances and surfaced only once verifiable. The full analysis lives in docs/treasury-policy.md.

Planned, not live

Status

$BASIS is planned for network usage and settlement accounting. It is not live until a token address and launch URL are configured.

Until then, the network runs its accounting honestly: credit balances may be internal and pending, worker rewards accrue in a dry-run ledger, and the documented token address reads as pending deployment. The table below is derived from configuration, never asserted.

What $BASIS is not

  • —Not an investment. These docs do not describe a financial product, and nothing here is an offer.
  • —No yield. Holding $BASIS does not produce yield, interest, or returns.
  • —No passive income. There is no mechanism that pays holders for holding.
  • —No guaranteed worker earnings. Rewards depend on jobs actually served and quality, uptime, and latency factors; failed and rejected jobs reward zero.
  • —No custody. Basis never holds a user's or worker's funds or keys.

Live vs pending

Every row reflects real configuration. Nothing reads as live unless the corresponding value is actually set.

Live vs pending — derived from configuration