The Numbers

The formulas that run the system, the property they are built to guarantee, and a worked example with every assumption labelled. Everything here is reproducible from the open stats endpoint described in Verify It Yourself.

Notation#

The controller#

There is no static backing target. The target ratchets up with the system:

b*(t) = max( $250 per 10M ; 1.25 * HW90(b) )
HW90  = high-water mark of b over the trailing 90 days
g     = min(b / b*, 1)

The gap g steers two levers, both published:

alpha(g) = 0.25 * g^2                drip rate: 0% to 25% of inflows
rho(g)   = 0.85 + 0.13 * g           redemption ratio: 0.85 to 0.98

Underfunding automatically throttles the drip and raises the redemption haircut. When b exceeds the target, the target ratchets upward; the system is never "done". In v0 the drip and haircut are executed weekly against this published formula and every execution is recomputable from /api/stats; the documented hardening path moves the computation on-chain.

An earlier version of this design had a third lever: the reserve's share of fees varied between 70% and 90% with the gap. That lever no longer exists. The split moved into an immutable contract at a fixed 2/3, which is a deliberate trade: the reserve share can never be raised in a shortfall, and in exchange it can be proven, by anyone, that two thirds of fee income can only ever go to the reserve. Provability was bought at the price of adjustability. The team share consequently no longer shrinks automatically when backing is below target; the controller works with two levers instead of three.

The epoch law#

Per epoch, with beta = b / 10^7 (backing per token):

change in (R - O) =  (1 - alpha(g)) * I        inflows minus drip      >= 0
                  -  rho(g) * beta * X         burn credits, new liability
                  +  m * U                     margin on consumed credits >= 0
                  +  Exp                       expired drip             >= 0

change in S       = -X

where X is tokens burned in the epoch, U is credits consumed in USD, and Exp is expired drip. Note the burn term is negative: a burn leaves R unchanged and raises O by the credited amount, so the absolute net reserve can shrink through redemptions. That is planned, capped, and happens only against real claims.

Why backing per token cannot fall from protocol operations#

The proof is per operation, not "every term is positive" (which would be false):

• Drip: R += I, O += alpha * I, so (R - O) rises by (1 - alpha) * I >= 0 with S unchanged. b rises.
• Consumption: O -= U, R -= (1 - m) * U, so (R - O) rises by m * U >= 0 with S unchanged. b rises.
• Drip expiry: O falls, S unchanged. b rises.
• Burn: (R - O) falls by rho * beta * x, but S falls by x, and the supply reduction dominates:

b' = b * (S - rho * x) / (S - x)  >=  b     for every rho <= 1

At rho = 1 a burn is exactly backing-neutral; at rho < 1 it is accretive: whoever exits by burning donates the haircut to everyone who stays. The classic run mechanic (last one out gets nothing) is inverted. Every protocol operation is non-decreasing for b, so any composition of them is too.

What this theorem does not cover, stated as loudly as the theorem: b can fall through losses on reserve assets or operational failure, and the market price of the token is entirely outside it.

The redemption value is also the ceiling#

For an actor who can use machine work at market value, a token is worth at least rho * beta (buy, burn, work), throttled by the redemption caps. That is a usage value, not a price floor, and we do not call it one. If trading volume dies, the market price converges toward the backing from above: the backing becomes the terminal valuation, not a floor under a premium. Everything above b is premium, and premium is speculation on future usage. If demand for machine work itself goes to zero, the economic value is zero with a full reserve, because nobody wants the only thing the reserve pays out. This is the sharpest honest statement of the design's limits and it is repeated in Risks.

Worked example: six months, base scenario#

This example was recomputed on 2026-09-08 for the current fee model; the previous published version assumed a 0.7% fee share and is superseded. What changed and why is summarized after the table.

All inputs are ASSUMPTIONS, chosen and defended in the mechanism design document. Average trading volume $50,000 per day post-subsidy (the chain's gas subsidy ends 2026-09-29 and we launch after it; the subsidized volumes before that date are not planning inputs). One caution on that assumption: it was originally chosen under a 1% fee model. At 3.35% per trade, a round trip costs 6.7%, and the same volume assumption is more aggressive than it was; the bear case below is the honest companion, not a footnote. Reserve inflow is 2.00% of volume, $30,000 per month; the team treasury receives a further 1.00%, $15,000 per month, which never enters the reserve and never appears in any backing figure. Yield is zero by policy. Direct credit purchases from month 4: $2,000 per month at a 7% deposit fee, $140 per month. Burns deliberately assumed low at 0.3M tokens per month, anchored to the verified near-zero redemption of the only comparable project. Consumption margin neglected (early volumes are tiny). Monthly steps of the weekly controller.

Reading the table:

• A holder of 10M tokens (about 1% of supply) holds, after six months of this scenario, a redemption claim of rho * $1,565, roughly $1,490 of Workbench work. The product displays that primarily in Runtime Minutes with its model range; the dollar figure is the labelled utility basis.
• Bear case: at $10,000 per day of volume instead of $50,000, reserve fees are $6,000 per month and b after six months is roughly $333 per 10M (the drip throttles itself harder at low coverage, so the fee lines do not scale perfectly linearly). Smaller, same direction. The team treasury receives $3,000 per month in this case.
• Sensitivity to burns: raising the burn assumption tenfold, to 20M tokens over six months, moves b after six months by about 1%, and upward: with rho < 1 every burn is slightly accretive for the holders who remain. Early on, the backing trajectory is almost entirely inflow-driven, and the mechanism that links price and compute is economically dormant until substantial burn volumes exist. Both halves of that sentence matter; the second one is a risk and is listed as one.
• The deposit fee column is the honest one. It is the only inflow in the table that does not come from trading our own token, and it is about 0.5% of total inflows. The other 99.5% is reflexive. The higher fee rate made this ratio worse, not better: fee inflows grew 3.6x while external inflows stayed the same. This is the central vulnerability of the design and the first thing Risks covers.

What changed against the previously published example. The old model earned 0.7% of volume and routed 70% to 90% of it to the reserve (effectively about 0.56% of volume); the current model earns 3.00% and routes a fixed two thirds (2.00% of volume) to the reserve, roughly 3.6x the reserve inflow at identical volume. Six-month base backing moved from about $464 to about $1,565 per 10M tokens, and the drip pool grew in proportion. Two things became worse and are stated as plainly: the trader now pays 3.35% instead of 1%, a permanent rate that may itself suppress the volume the model assumes, and the externally-sourced share of inflows fell from about 1% to about 0.5% because the reflexive part grew and the external part did not. The team treasury line ($15,000 per month at base volume) is new; the old model had no funded operations at all.

Steady state, precisely#

The absolute net reserve grows exactly when

(1 - alpha) * I + m * U + Exp  >  rho * beta * X

At high burn volume the absolute net reserve can shrink while b still rises, because every individual operation is non-decreasing for b. A critic will find the case "reserve shrinks, backing per token rises" and present it as a hidden leak. It is not hidden and it is not a leak; it is what serving redemptions means, and both curves are published side by side so the two cannot be conflated. The growth rate of b, honestly, hangs on volume.