BASIS
Documentation

The $BASIS token

liveDeployed

$BASIS is the 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

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/burn 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.

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/burn 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 until a live price source is configured 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 yet: each reads pending until a verified production read of the live pool. The full model lives in Tokenomics, Treasury, and Bankr fees.

Fee streams — accounted separately by side
  • Per-job burn

    $BASIS

    The protocol's per-job share of each completed job — the gross $BASIS charge minus the worker reward. A configurable split; the v0.1 reference proposal is 90% worker / 10% burn, pending operator approval. Earmarked for burn (draft / not implemented; burned-to-date 0), a separate flow from the Bankr $BASIS-side split. Collects nothing until settlement 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 protocol's per-job share is earmarked for burn (draft / not implemented; burned-to-date 0) — a separate flow. Bankr creator fees feed treasury accounting. $BASIS-side fee generation — the $BASIS side of the Bankr creator fees — is designed to split 50% burn / 50% staker rewards. The staker-reward side is funded on-chain and streams into the redeemable value of staked $BASIS; the burn share waits on its contract. That split is on the $BASIS side only and is separate from the per-job burn. 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 Treasury.

The $BASIS side of fee generation is designed to split 50% burn / 50% staker rewards. The staker-reward tranche is funded on-chain and streams into the redeemable value of staked $BASIS through the staking vault on Base. Burn would remove $BASIS from supply, and it is not implemented: it requires contract support, accounting support, operator approval, and legal review before it could ever be turned on. Rewards are not guaranteed.

Every staker-reward figure is read live from Base, and burned amounts — tracked separately from treasury balances — appear only once verified on-chain (no burn is claimed here). The full analysis lives in Treasury.

Live on Base

$BASIS is LIVE on Base — the asset inference is paid in and the worker-reward + settlement token. The staker-reward tranche is funded on-chain and streams into the redeemable value of staked $BASIS. Deployed is not live for the other money paths it enables: paid deposits and on-chain worker payouts are not yet active, and each activates independently.

So the network runs its accounting honestly: credit balances may be internal and pending, worker rewards accrue in a dry-run ledger, and on an unconfigured deploy 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

This page is the overview. The full economic model is split across three deeper pages: