thirty spkesDOCS
HomeDashboardGet an API key

Economic Model

What the subnet pays, what a miner spends, how cost enters the score, and — stated openly — what is not designed.

Scope. Emissions, the reign, the miner-key funding rail and the priced score are implemented, specified and measured. Value capture is not designed: there is no gateway, no pricing and no revenue path. Token and staking mechanics are Bittensor's.

Emissions: the reign

position share
reigning king 0.850
ex-king, 1 back 0.050
ex-king, 2 back 0.040
ex-king, 3 back 0.030
ex-king, 4 back 0.020
ex-king, 5 back 0.010

Winner-take-all was the first rule and had a real cost: a miner who expects to be dethroned within a window has little reason to enter, and a dethroned king every reason to grief the new one. The pension is deliberately shallow — at 0.05 a former king earns about a seventeenth of the crown — so defending is worth vastly more than having once won, but losing is a soft landing rather than a cliff.

Rules that close the ways the schedule could be gamed: ordering is by recency of coronation; the reigning king holds no pension slot; a hotkey crowned more than once holds one slot, at its most recent position; unfilled slots burn and are never redistributed to the king; shares are paid by hotkey resolved against the live metagraph, and an unresolvable slot burns.

King₀ and the vacant throne

Nobody is crowned by default. The baseline every challenger must beat is King₀ — the best fixed routing policy, which needs no miner, no training and no arena. If a trained conductor cannot beat one, the subnet would be paying for something the owner could deploy for free. So until a challenger clears the verdict against King₀, the king's 0.85 burns, and it burns again whenever the crown reverts because a king left the metagraph.

A burn is not free of consequence. Under Bittensor's accounting, emission that a subnet sends to the burn address reduces the subnet's own share of network emission in proportion — so a vacant throne is a cost the owner carries, on purpose, rather than a subsidy paid to whoever showed up first. The first coronation is when the subnet starts paying for routing.

Cost is in the score

final_b = quality_b − λ_b · (spend_b / C_b)        per benchmark
final   = mean over admitted benchmarks of final_b

λ_b is the slope of the benchmark's own cost/quality tradeoff between always-calling-the-cheapest-model and the best fixed policy, measured from the fixed-policy sweep; C_b is that pair's mean spend. Spending more is neither rewarded nor punished in itself — only relative to what it buys. A benchmark where the best fixed policy buys nothing over the cheapest model is dominated and excluded from scoring. On the launch corpus, fitted over three replicated draws: λ = 0.09 on LiveCodeBench and 0.08 on HLE, with the dominator flag firing in 0% of bootstrap resamples.

Who pays for a window

Each miner pays on their own OpenRouter key (D18). The key is registered sealed to the owner's mailbox key and signed by the miner's hotkey, kept beside the submission, and opened only by the owner's validator, which runs the miner's arm on it through the owner's gateway — the same pinned request every other arm sends — and meters each call's real cost against the miner's own per-window cap, bounded by what the key reports it can still spend. Every debit is against a signed receipt; the reveal says per arm whether it ran on the miner's key, which endpoints served it, and which of those the owner's own arms were never served by. Exhaustion zeroes the remaining tasks and is published as budget_exhausted, distinct from a stalled model and from a validator that ran out of clock, because a verdict decided by funding must be visible as such. A key the provider refuses, or an account with nothing left, defers the entry with its shot intact. The owner may also credit a hotkey by hand; that is a grant on top of the rail.

Every arm in a window draws from one shared outcome table: the first arm to ask for a given (task, model, attempt) buys it live on its own key, and every later arm is handed the same row at the same price without the provider being asked again. An arm's spend_b is what it was charged — every delegate, hit or miss — while only its misses cost anyone cash, so the score prices the routing a policy chose rather than the order the arms happened to run in. Both numbers are published per arm.

The owner's account pays the two reference arms every window and King₀'s arm while the throne is vacant; the validator refuses to start on an empty owner account, because that failure would otherwise publish a window blaming the corpus for the owner's wallet.

What a window costs

Measured, not estimated. The first live window on real benchmarks — LiveCodeBench and HLE, 60 tasks per reference arm, an 80-task king's arm and one 80-task challenger — cost $1.74 in worker calls, of which the challenger's arm was $0.91 over 516 metered calls. Per-episode spend over 30 episodes per fixed policy on a frontier-free pool: $0.001 always-cheapest, $0.062 the cascade, $0.067 always-strongest. Against the design target of ~250 tasks per arm, a window is roughly $0.25 to $17 per arm depending on how expensive the routing is — a floor, since the catalog carries rungs a hundred times dearer.

What entering costs a miner

  • the registration burn, at whatever the network charges when they register;
  • the worker calls their arm makes, on their own OpenRouter key, up to the cap they set — the only cost the subnet can size, above;
  • their training compute, bought wherever they like — never measured here and not estimated;
  • the upload of ~70 GB. Storage is the owner's: the reigning king and the five pensioners are kept indefinitely, losing submissions for a published grace window; the manifest digest and history entry are permanent regardless.

The subnet charges nothing beyond what a miner's own arm spends on their own key. The training set — every window's decision traces for the arms the owner ran — is published free, so entering does not require first buying one.

Capital, recorded

Because caps are miner-set and unequal, the leaderboard measures routing skill and capital together. That is a recorded owner decision (D5). The mitigation is transparency, not a cap: where an arm ran out of money is in the reveal.