Until now, emission was a fixed amount distributed by rank. Validators score miners, weights sum to one, and the same quantity leaves every block whether the trainer could absorb the data or not.
We are replacing that with a price. There is a price per unit of admissible data, discovered by competition among miners, and whatever is not spent is burned.
The purpose is not to emit less. It is to stop paying for throughput we cannot consume, so that the same emission can buy several kinds of work at once instead of one kind in surplus.
The problem
Our trainer consumes at a bounded rate. A window lasts as long as the slowest of training, verification and collection, so once collection is saturated, additional miner throughput buys nothing. It is produced, discarded, and paid for anyway.
Miners have no reason to stop at that ceiling. Under rank-based emission, payout depends on relative share, so the rational strategy is to produce as much as you can afford. Everyone reasoning that way pushes aggregate production far past what we can consume, and the excess is real GPU spend buying nothing.
The amount we need is not a constant we could hard-code either. It moves with the in-zone rate as the policy trains: on an already post-trained model, the share of prompts landing in the useful reward-variance band sits somewhere between 5 and 15 percent, so the raw generations behind one usable group vary by nearly 3×. It also moves with our verification speed, our step time, and the task mix. Any number we fix today is wrong next month.
Why a classic burn does not fix it
The validator has always had a path for it: burn_weight = max(0, 1 − Σ weights),
so anything the weights leave unassigned goes to a burn UID where the
tokens are gone. In practice nothing went there. Rank-based weights sum to one
by construction, so the residue was zero except when a window failed outright.
Burning was an artefact of failure, not an instrument.
Turning it into an instrument by burning a fixed fraction would not fix much either, because a fixed fraction is a discount, not a price. We would still choose the number ex ante, from the same seat we chose the old one from. When the in-zone rate drops and a usable group costs three times more, a fixed fraction does not notice. When miners get twice as efficient and the same data could be bought for half as much, it does not notice either. And it still pays the same total whether the network needed ten miners or a hundred.
The path was already there. What was missing was a price against which the residue could be defined.
The mechanism
One sensor. Per window,
r = (collect_ready_round − open_round) / max(train_time, verify_time)
The numerator measures time to admissible data, not to its proof: slow
verification is our bottleneck, not something to pay miners for. The denominator
is our own ceiling, so supply faster than we can consume is invisible and r
caps at 1. The clock is drand rounds, so the controller makes no chain calls.
r measures tension. Scarcity is a separate event, the window failing to fill,
and only that raises the price.
One controller. r̄ is the median of r over 1000 rounds.
window did not fill → price × 1.20
r̄ < 0.80 → price × 0.99^(Δrounds/1000)
otherwise → hold
price = clamp(price, 0.05, 1.0)
The snap escalates from the current price, so a raise that does not suffice keeps rising instead of stalling the trainer. Only a filled window updates the reference price. The decay is expressed in rounds rather than windows, so it keeps its meaning when we change the pipeline.
One registry. A task is an entry in a single object: its generation contract
pinned by sha256, its pricing mechanism, and its cap. Launching a task is a
conditional write, with the check that caps sum below 1 inside the
compare-and-swap. Two launches cannot both pass.
One floor. A hotkey below 2 percent of the pool is not paid, and the freed mass burns rather than being rescaled onto the survivors, which would make the threshold a transfer from small miners to large ones.
What we expect it to change
The price settles at the marginal producer's cost. The controller decays while windows fill and stops when one does not, which happens when the price falls below the cost of the last miner whose capacity was needed. Miners below that margin keep the spread. The price is then a continuous public estimate of what a unit of admissible data costs to produce, which a constant-sum mechanism cannot produce because its payout is fixed independently of cost.
Miners optimise one ratio. Under rank-based emission, outspending others is a valid strategy. Under a clearing price, survival depends on
cost per accepted submission = cost per generation / acceptance rate
Below the price a miner accumulates; above it, they lose money on every unit. Budget size stops substituting for efficiency.
Hardware fit becomes a strategy that pays. This workload is many short generations, batch-parallel, bound by memory bandwidth rather than peak matmul throughput, so the accelerator that maximises FLOPs per dollar on a training run is probably not the one that maximises accepted submissions per dollar here. A miner who finds the better fit earns the spread until the price decays toward their cost, and competitors on the wrong hardware end up above the line and exit. Under rank-based emission the same discovery would have been a transfer between miners, and we would never have learned which hardware was right.
In-zone prediction becomes the main lever. Rejected groups are generation cost with zero revenue, so the acceptance rate sits in the denominator above. At a 10 percent base rate, a miner who predicts well enough to reach 20 percent has halved their cost per accepted submission, which no hardware swap delivers as cheaply. Prediction quality therefore dominates the marginal cost curve, and the price tracks that curve. This is the intended target: prediction is what separates this from centralised dynamic sampling, which generates and discards at more than double the cost for the same usable batch.
Emission falls as miners improve. An efficiency gain earns a spread until entry and decay erode it, then the price drops and the difference is not redistributed. It burns. The decay constant sets how long a gain stays profitable before the price catches up, and it is the one parameter here that is a choice rather than a measurement.
Under-supply becomes visible. A window that does not fill raises the price rather than quietly degrading the data reaching the trainer, so a shortfall appears in the price series immediately instead of days later in the learning curves.
The point is not to spend less
This change removes waste, but removing waste is the precondition, not the objective.
Under rank-based emission, the entire budget was committed to a single task whether or not that task could absorb it. Adding a second task meant taking emission away from the first and deciding by hand how much, so in practice we ran one task and paid for surplus we discarded.
Pricing removes that negotiation. What a task does not consume burns rather than passing to another task, so the only condition on running several at once is that declared caps sum below 1, and that is checked inside the compare-and-swap when a task is registered. Adding a task is a conditional write, not a governance decision.
What gets freed by all this is not tokens. It is room to ask miners for more work.
- More environments in parallel. Each with its own generation contract, price and cap, discovered independently.
- New categories of work. Anything a validator can verify and a trainer can consume becomes a task, including work whose value we cannot currently estimate well enough to hard-code a budget for. Competition among miners estimates it instead.
- Miner capacity redeployed. Capacity currently spent producing surplus that is generated, verified in part and thrown away goes to work we actually consume.
The measure that matters is not emission spent. It is value extracted per token emitted, and that ratio rises both ways: less paid for throughput we cannot consume, and more distinct work bought with what remains.
What we will measure
- Whether the price converges away from both clamp bounds.
- Whether cost per unit of admissible data falls over weeks of stable operation.
- How many tasks run concurrently, and what each clears at.
We will publish the price series.