protocol

Documentation

How the pool, the nodes, and TOK fit together — and how to build on the network.

Overview

t0k is a decentralized compute network for AI inference. Inference has a real marginal cost (GPU time, VRAM, bandwidth, orchestration), and conventional platforms recover it from the user through subscriptions and per-call API billing. t0k pushes that cost onto token markets instead.

Every token launched on t0k is a node. The token deploys on a pump.fun bonding curve and its creator-fee stream is assigned to the protocol, which sweeps those fees into a single compute reserve on a fixed interval. The reserve is an on-chain wallet; its balance is the network's spendable compute, accounted in TOK.

Inference requests are priced in TOK, executed against model providers, and settled by transferring the request's SOL value out of the reserve. Users run frontier image, video, language, and audio models without provisioning GPUs, holding provider keys, or paying a subscription. The reserve pays, and node fees refill it.

Architecture

Four subsystems, isolated by responsibility:

  • Token layer: nodes deploy on the pump.fun bonding curve. Creator fees originate here and are claimable by the fee recipient.
  • Reserve:a keypair-controlled wallet. Its lamport balance is the network's liquid compute budget, surfaced as TOK.
  • Inference layer: a server route that resolves a model, dispatches the job to a provider, and meters TOK per call.
  • Settlement layer:on each paid call, a SystemProgram transfer moves the request's SOL-denominated cost from the reserve to a payout wallet.

State is derived, not asserted: reserve depth is the wallet balance, node market data is read live from Birdeye, and inference counts come from the run ledger.

Nodes

A node is a token deployed through t0k. On launch the create instruction mints the token on a pump.fun bonding curve, attaches IPFS metadata, and assigns the creator-fee recipient. The node is then indexed into the tokens registry that backs the Nodes and Leaderboard surfaces.

Creator fees accrue at the protocol fee account as the token trades. Fee accrual scales with volume, and volume tracks market cap, so the leaderboard ranks nodes by market cap: the directly observable variable that determines how much each node contributes to the reserve.

Per-node market data (price, market cap, 24h change, liquidity, logo) is fetched from the Birdeye token-overview endpoint at render time and is never cached into the database.

TOK

TOKis the network's accounting unit for GPU time. Each model carries a fixed TOKprice per run, independent of the provider's underlying rate card. This normalizes heterogeneous provider pricing into one unit and decouples the caller from provider-side cost changes.

TOK is backed by the reserve. As node creator fees are swept in, reserve depth increases, and with it the volume of TOK the network can spend before the next refill. There is no separately minted balance to deplete; capacity is the reserve.

Launching a node

A launch requires a connected wallet, a name, a ticker, and a logo; description and socials are optional. Social inputs accept a bare handle, an @handle, or a full URL and are normalized before pinning. Two paths assign the creator-fee recipient differently:

  • Contribute to pool (Lightning). The protocol wallet is the creator. The create transaction is built and signed server-side via the PumpPortal Lightning API; creator fees accrue to the protocol and are swept into the reserve. The user does not custody anything.
  • Keep rewards (Local).The connected wallet is the creator. The unsigned transaction is built via the PumpPortal Local API, partially signed by the freshly generated mint keypair, then signed by the user's wallet and broadcast. Creator fees accrue to the user, not the reserve.

In both paths the logo and a metadata JSON are pinned to IPFS first, and the resulting metadata URI is passed into the create instruction. The mint is a per-launch ephemeral keypair.

Metadata & IPFS

Token assets are content-addressed. The logo is pinned to IPFS, then a metadata JSON object referencing that image plus the token's name, symbol, description, and socials is pinned as a second object. The metadata URI supplied to the bonding-curve program is the pinned JSON.

Pinning runs server-side so the Pinata credential is never exposed to the client. The Lightning launch route validates that any metadata URI it accepts is an IPFS URL it produced, which prevents arbitrary off-network metadata from being attached to a node.

Fee flow

Creator fees reach the reserve through three wallets:

  • Launch wallet: the creator for Lightning launches. pump.fun settles creator fees per creator, so a single launch wallet can claim fees for every node it created in one call.
  • Compute wallet (reserve): the sweep collects accrued fees into the launch wallet, then forwards the balance here. This wallet's SOL balance is reserve depth.
  • Payout wallet: settlement target. On each inference, the request's cost is transferred reserve → payout, sized in lamports from the live SOL price.

Pool depth shown across the app is the compute wallet's lamport balance converted to USD at the current SOL/USD rate. Both addresses are on-chain and verifiable.

The sweep

The sweep is a scheduled job run on a fixed interval. It issues a collectCreatorFeecall against the PumpPortal Lightning API , which claims all accrued pump.fun creator fees for the launch wallet in one transaction, then forwards the launch wallet's balance, minus a lamport buffer reserved for fees and rent exemption, to the compute reserve.

The endpoint is gated by a shared secret so only the scheduler can invoke it, and it is idempotent in effect: collecting zero fees or forwarding a zero balance is a clean no-op.

Running inference

A model declares its own input schema, a prompt, an optional negative prompt, an optional reference image. Reference images are uploaded as data URIs and passed directly to the provider. On submit, the server resolves the model's latest provider version, dispatches the job, and awaits the result.

Provider output, a URL, an array of URLs, a file object, or streamed text, is normalized into a single response shape keyed by output type and rendered in-app as image, video, audio, or text. Each completed run is written to the runs ledger, which drives the inference counter and activity series.

Rate limits

Inference and launches are rate-limited with a Redis-backed fixed-window counter, atomic via INCR + EXPIRE. Because the counter is centralized, limits hold across server instances and survive reloads or tab rotation. If Redis is briefly unreachable the limiter falls back to an in-process window so throttling never fully disengages.

  • Inference: 5 requests per minute per client IP.
  • Launches: 3 per minute per client IP, plus a global ceiling of 20 per minute that protects the creation wallet from cross-client flooding.

A throttled request returns 429 with a Retry-After hint; the client surfaces it as a notification rather than failing silently.

Pricing & settlement

Each model has a notional USD cost. At settlement the cost is converted to lamports as round(priceUsd / solUsd * LAMPORTS_PER_SOL) and transferred from the reserve to the payout wallet. If the payout account is not yet rent-exempt, the first transfer is topped up to the rent-exempt minimum so the account is created.

The SOL/USD rate is sourced from CoinGecko and cached in Redis with a 60-second TTL, so request volume does not hammer the oracle while transfers still track the market. Settlement is a real on-chain transfer , the cost of inference leaves the reserve, so reserve depth reflects genuine spend and is externally verifiable.

Model catalog

The catalog spans image, video, language, and audio. Each entry declares a provider model identifier, output modality, expected latency band, and TOKcost per run. Models are addressed by a stable id, so a direct link resolves to a dedicated run surface that renders that model's declared inputs and live specs.

At run time the server resolves the provider model's latest version and invokes it pinned to that version, so a bare model slug never 404s on dispatch.

Data model

Two tables back the network's observable state:

  • tokens: one row per node: mint, name, ticker, description, image and metadata URIs, socials, creator, launch signature, created_at. Source for Nodes and Leaderboard.
  • runs: one row per inference: model id, USD cost, settlement signature, coarse client id, created_at. Source for the inference counter and the activity chart.

Row-level security exposes reads publicly; writes go through trusted server routes. Both tables are published to Supabase Realtime so the live feed streams new launches and runs without polling.

Reliability

The system degrades cleanly under partial failure. If the price oracle is unreachable, cached pricing is used; if the cache is cold, settlement is skipped rather than blocking the result. If persistence fails after a successful launch or run, the on-chain action still stands, the database mirrors truth, it is not the source of it.

Local launches broadcast through a configured RPC and confirm against a fresh blockhash, surfacing on-chain errors instead of failing silently. The sweep and settlement transfers are retry-safe.

Security & custody

Local launches are non-custodial end to end: the user signs in their own wallet and the network never holds their keys. Lightning launches and the reserve are operated by server-held keypairs whose secrets live only in server configuration and are never sent to the client.

Wallet interactions favor single-signer flows, separate signing from submission, and broadcast through a configured RPC rather than the throttled public endpoint, which avoids both opaque-transaction warnings and dropped sends.

FAQ

Do I need SOL to run a model? No. Inference is settled from the reserve. A wallet is only required to launch a node.

Where do the fees come from? pump.fun creator fees on nodes launched in contribute-to-pool mode, claimed and swept into the reserve on a schedule.

Is reserve depth real? Yes, it is the on-chain lamport balance of the compute wallet, shown in USD at the live SOL price.

What backs TOK? The reserve. Each run draws a fixed TOK amount, and settlement is denominated in SOL out of the reserve.

What happens if a request fails? The provider error is returned and no settlement occurs. Throttled requests are rejected before any provider call.