DemandPROPOSED
The Demand Reserve index. Empty today.
The Demand Reserve follows the subnets customers actually pay to use. The index would be built from paid receipts, never from raw request count. Charging is OFF, so no request carries a charge, no route has a demand score, and the index allocates nothing. The methodology below is published so it can be read before it can be gamed.
LIVE ROUTER
VERIFIEDRuns today: a request is routed, answered and recorded. Free while charging is off.
PROPOSED ECONOMICS
PROPOSEDWritten down and modelled. Charging is off, revenue is $0, no fee is collected and no TAO has been bought.
NOT-DEPLOYED TOKEN
NOT DEPLOYEDTAON has no contract, no address and no market. 0 of 8 token gates are met.
The index today
No paid demand yet
No reserve allocation while not operating · charging OFF · paid requests 0 · routes scored 0
Historical windows: None yet. The first window opens with the first paid, settled request. Every route reads zero, and a route with no paid, settled requests has no score, not a small one. Nothing here is a sample.
A static treasury holds assets whatever customers do. Here every allocation would originate from paid route evidence: no paid demand, no allocation.
The methodology, the caps and the empty indexWhat a reserve would hold, by accounting class
The score, term by term
One route and capability pair is the unit; subnets are a roll-up for display and policy. The denomination is gross margin in US dollars: the money TAONIC keeps from a route, which is what could later fund TAO. Anyone who wants to inflate a score has to pay at least one dollar of margin per dollar of score.
S(route) = Q × B × R² · index(route) = S / Σ S over ELIGIBLE routes
- Q
- Capped value: decayed gross margin in USD (charge minus refund minus provider cost, floored at zero per request), after the per-identity cap.
- B
- Breadth: Neff / (Neff + 4), where Neff is the effective number of paying identities. One identity reads 0.20; twenty read 0.83.
- R
- Reliability: (answered + 1) / (attempts + 2), squared. Only provider-called attempts count; a refunded answer is not good.
- decay
- Half-life of seven days from the window’s end; the window is 28 days, recomputed daily.
- lat
- Latency factor: one up to the capability’s target, falling to one half at the route’s hard timeout, zero beyond.
| Cap | Rule |
|---|---|
| Per identity | No identity supplies more than one third of a route’s capped value. Fewer than three paying identities give zero. |
| Per route | No route above 35% of the index weight; the excess is redistributed or held. |
| Minimum sample | ELIGIBLE needs 30 paid answers, 5 identities and 7 active days in the window; otherwise the route is PROVISIONAL, shown and given no weight. |
| Attempts | Each identity adds at most 25 decayed attempts to a route’s reliability, so one account cannot grief it. |
| Exclusions | Provider-affiliated identities, operator and helper accounts, and accounts with a payment dispute are excluded for the window. |
Parameter sheet, all proposed and to be fixed in the published policy: window 28 days, half-life 7 days, identity cap one third, breadth constant 4, reliability exponent 2, per-identity attempt cap 25, minimum 30 answers, 5 identities and 7 days, route cap 35%, notice 14 days.
Manipulation protections
Tested against one user spamming cheap requests, one expensive enterprise customer, a route with high revenue and frequent failures, a cheap route with many successful customers, a new route with little history, a route temporarily offline, a provider subsidizing its own usage, Sybil accounts, wash usage and sudden demand changes: 15 of 17 checks pass, 2 are residual, 0 fail. Modelled on synthetic customers at proposed prices.
- Raw request count is never an input
- Modelled: one account sending 84,000 cheap requests took 94.6% of a count-based index. Margin, breadth and reliability replace it.
- Score costs margin
- Anyone who wants $1 of score has to pay TAONIC at least $1 of margin, even a provider buying its own route.
- Conservation bound
- In any later allocating version, cumulative allocation to a subnet is at most half the cumulative margin attributed to its routes: at most $0.50 of reserve moved per $1 paid.
- Publish before allocate
- Version one publishes the index, every term and a dataset hash daily. No contract, keeper, script or key reads it to move any asset.
- Notice and review
- Any formula change is published 14 days ahead and never applied to a past window. A later allocating version needs a frozen snapshot, an independent recomputation, a 14-day notice and reserve custodians who may only halt or reduce, never enlarge.
Known residual weakness
Sybil accounts that each hold a distinct payment instrument look like real customers; no formula can tell them apart. In the harness, twenty such accounts moved one route from 19% to 94.5% of the uncapped index, while the per-route cap still bounded its weight. The bound is economic: they pay at least $1 of margin per $1 of score and could move at most $0.18 to $0.19 of reserve per $1 spent under the allocation bounds. Pay-then-refund lowers a route’s reliability a little at the price of processing fees. All harness figures are modelled on synthetic customers; no real paid request exists to calibrate against.
What the index may and may not do
PROPOSED ECONOMICS · NOT OPERATING · TOKEN NOT DEPLOYED
Version one publishes only. The index per route and per subnet, every term, the formula version, the parameter sheet and a dataset hash would be published daily; no contract, keeper, script or key would read it to move, stake, buy or sell any asset. A later allocating version would need all eight token gates, a published policy change with 30 days of notice, at least 90 days of eligible history and the owner’s written yes; then only protocol-owned reserve assets, never reward-vault assets, could follow the index, under a 35% subnet cap, a 5-point monthly step, a 20% unstaked or root buffer, a per-epoch depth limit of 0.5% of a subnet pool’s TAO, and a reviewed, timelocked proposal whose custodians may only halt or reduce, never enlarge.
Bittensor splits emissions by each subnet’s alpha price, not by demand or revenue. The index would be an independent, customer-paid signal. It does not feed Bittensor and does not claim to.
Not recorded yet
The score needs fields the ledger does not hold today. Until they exist the formula cannot run, and the reliability term would over-state a first-choice route that fails over.
- A payment-instrument fingerprint per checkout (a keyed hash, never the raw value)
- The fallback trail: which first-choice route failed before another served the request
- A per-step provider cost for multi-step requests
- An affiliation register and an operator or helper flag on accounts
- A daily snapshot table so every published index can be recomputed
Token (proposed)ReserveStatus: the evidence matrix and the gatesDocs: the mechanism and its sources