Epic(data): subnet revenue vs emissions — the coverage ratio, with provenance

[JSONbored]

Nobody publishes a subnet revenue number you can re-derive. This epic makes metagraphed the place that does.

Why this exists

The question "how much does this subnet actually earn, versus what it emits" is the most-asked unanswered question in the ecosystem, and the existing answers are all closed:

Source	What it is	Why it is not enough
TAO Institute	The dataset everyone resells. Tags entries TI Verified / Self-reported / Public.	Human-curated, login-walled, no published method, no API.
SubnetRadar	Resells the TAO Institute set every few hours.	Downstream. No independent observation.
taorevenue.com	"Revenue, emissions & profitability in real time."	Closed methodology.
Pine Analytics	Produced the quoted "$52M emissions vs $2.4M revenue" and 22–40:1 for Chutes.	A March 2026 essay, not a live feed.

Every one is human-curated and self-reported. Nobody derives revenue from live public endpoints on a schedule, cross-checks it against the chain, or publishes provenance per number. That is the gap, and it is the discipline this repo already runs on everywhere else.

Why it is cheap here specifically

1. The denominator is already exact. get_emission_pipeline returns per-subnet tao_total measured from SubnetTaoInEmission + SubnetExcessTao, with four identity checks that must pass. No competitor is close.
2. The fiat leg landed this week. usd_at_tx / price_at_tx / /network/tao-usd staleness (feat(api): usd_at_tx — the fiat companion, resolved at each event's own instant #10431–feat(ui): render the fiat leg beside price_at_tx, and say it is the less precise one #10433). Revenue-in-USD vs emissions-in-USD needs exactly per-instant fiat resolution.
3. The chain transfer index is live, and the feed reconciles against it exactly. spike(revenue): reconcile the Chutes payment feed against the chain #10448 matched 32/32 Chutes payments for 2026-08-08 to on-chain Balances.Transfer events, delta 0.000000000 TAO. (An earlier draft of this epic claimed the trail ran to a Chutes "collector wallet" — that address is SN64's protocol TAO pool, and the claim was withdrawn. See spike(revenue): reconcile the Chutes payment feed against the chain #10448.)

The metric is already computable — worked live, 2026-08-10

SN64 (Chutes), entirely from public sources:

emissions  tao_total 0.063615264 TAO/block × 7200 = 458.0 TAO/day
           × $204.03/TAO (/network/tao-usd)        = $93,452/day = $34.1M/yr
revenue    api.chutes.ai/daily_revenue_summary, 4-day mean
                                                   = $11,668/day = $4.26M/yr
SUBSIDY MULTIPLE  8.0 : 1        COVERAGE RATIO  12.5 %

The ecosystem is still quoting Pine's 22–40:1 from March. A live, re-runnable 8:1 is the launch story.

Definitions (the contract)

Denominator emission_value_usd, default basis tao_total — TAO the network directs into the subnet. Fully measured. Alternates published, never silently substituted: alpha_out_emission × alpha_price, and owner_take (18%).

Numerator external_revenue_usd — money from outside Bittensor paid for a service. Explicitly not emissions, alpha appreciation, miner payouts, or validator yield.

• coverage_ratio = revenue / emissions ("12.5% covered")
• subsidy_multiple = emissions / revenue ("8:1")

Windows: daily / 7d / 30d / 90d over a common block range.

The provenance ladder

Tier	Value	Counts toward headline?
A	chain-verified — payments observed in our transfer index against an attributed address	yes
B	probe-derived — public endpoint polled on schedule, hashed + timestamped	yes
C	operator-attested — citable URL, or endpoint exists but auth-gated	no — shown beside
D	third-party-reported — Pine / TAO Institute / press, cited	no — shown beside
E	proxy-only — usage figures, no money	no
F	none — searched, absent, dated	no

Tier A is a spot-check, not a substitute. Measured on SN64 for 2026-08-08, the on-chain TAO channel is $1,036.50 against $9,776.06 total revenue — 10.6%. The other ~89% is card/pay-as-you-go, off-chain and unverifiable by construction. chain-verified corroborates an operator's honesty on the slice it can see; the headline still rests on probe-derived.

Two hard rules, mirroring probe-derived-only for health:

1. The headline ratio uses A + B only. No estimation, no modelling, no gap-filling.
2. Absent revenue is null, never 0; coverage_ratio is null whenever revenue is null. A subnet with no data must not render as a 0% subnet.

What the completed sweep actually found

Updated 2026-08-10. Phases 1–3 are done: all 129 subnets classified, every OpenAPI fetched and path-scanned, every website and docs page fetched and scanned for pricing signals. The original tiering below was a keyword sweep of the registry; this is the result of actually looking.

Two subnets out of 129 publish a revenue figure anyone can read. SN64 Chutes and SN51 Lium. That is the headline, and it is much sharper than the "73% dark" estimate this epic opened with.

state	count	what it means
publishes a readable figure	2	SN64, SN51 — the only inputs a coverage ratio can be computed from today
declared but unreadable	3	SN75, SN93, SN110 — revenue endpoints in their own schemas, all 401/403
commerce visible, no figure	33+	pricing/billing on their own site or docs; they sell things and do not publish what they earn
usage counts only	21	requests, tokens, jobs, proofs — no money anywhere
no commerce signal found	~60	searched and dated; nothing observable

"No observable external revenue" is not "no revenue", and the 33 are the proof. Any wording in the API, the UI or the docs that lets those two be confused is a bug — that population is a quarter of the network and it visibly sells things.

Money that points the wrong way

The sweep's most consistent finding is that a money figure is not a revenue figure. Recorded explicitly as miner-payout or not-revenue so each is retired rather than re-investigated:

• SN4 Targon payout — emission to miners. The most-quoted number on that subnet, and it is the denominator.
• SN11 TrajectoryRL totalCostUsd — what the subnet spends. An expense.
• SN46 Zipcode dailyPrizePoolUsd, SN60 Bitsec daily_prize_pool — money paid out to competitors.
• SN74 Gittensor totalPayouts — contributor rewards flowing out.
• SN15 ORO top-miner-payout, SN93/SN110 *-earnings / revenue-by-miner — payout, not platform revenue.
• SN49, SN75 /pricing, /latest-tao-price/ — exchange-rate feeds under money-shaped paths.
• SN35 OxMarkets apy_tiers — advertised yield config, not an amount earned.

Also found

• SN37 Aurelius: all nine registered surfaces answer Application not found — the host is gone. Filed as registry(sn37): nine surfaces on a Railway host that no longer exists, invisible because probe.enabled is false #10548, because probe.enabled: false made an entire dead origin invisible to health.
• SN18 Zeus, SN43 Graphite: real POST-only checkout/webhook plumbing. Evidence of paying customers, no readable amount.

The seven traps## The seven traps (found by probing, not theorising)

1. Miner payout ≠ revenue. Targon's stats.targon.com/api/miners exposes payout — that is emission payout. Counting it puts the denominator in the numerator. Same class: SN43 returns total_alpha_stake, SN96 returns miner health. A "stats" endpoint is guilty until proven revenue.
2. Unit ambiguity. api.chutes.ai/payments/summary/tao reads {today: 1072, this_month: 15052, total: 2321800} — path says TAO, values reconcile as USD.
3. Channel double-count. Chutes exposes /payments (TAO channel, ~$1k/day) and daily_revenue_summary (all channels, ~$11k/day). The first is a subset. Summing inflates ~10%.
4. Gross ≠ external. sponsored_inference is subnet-funded. pending_instance_revenue is unrecognised. Both excluded from headline, shown separately.
5. Attribution is evidence, not inference. A high-volume collector is consistent with a payment address; it is not ownership proof.
6. Surfaces rot. SN103 djinn.gg/api/genius/earnings is already a 301.
7. Circular revenue. Paid in the subnet's own alpha, or funded by the team selling emissions, is not external. Explicit circularity flag, default unknown.

Architecture

Split along the existing seam:

• Declaration → registry/subnets/<slug>.json, annotating existing surfaces with a revenue block. One file per subnet (house rule 2).
• Observation → probe worker → store → generated artifact. Never hand-edited, exactly as health/uptime/latency.

Sibling

Epic B is the other half of the same question — A asks whether money comes in, B asks where the emitted money goes. They share the fiat leg, the provenance ladder, and the claim-vs-chain pattern.

Sequencing

Critical path: #10441 → #10442 → #10443 → #10444/#10445 → #10446 → #10447, with #10448 run early — if the Chutes feed and the chain disagree, the Tier-A/Tier-B split needs rethinking before the 12 subnet issues are worked. Phase 2 parallelises fully once #10441/#10442 land; Phase 3 can start after #10441.

Children

Phase 0 · foundation (blocks everything)

• schema(revenue): a revenue block on subnet surfaces #10441 — schema(revenue): a revenue block on subnet surfaces
• schema(revenue): payment-collector accounts, on the existing entity layer #10442 — schema(revenue): payment-collector accounts, on the existing entity layer
• validate(revenue): revenue figures are probe-derived only #10443 — validate(revenue): revenue figures are probe-derived only
• worker(revenue): the revenue probe lane #10444 — worker(revenue): the revenue probe lane
• chain(revenue): inflow aggregation for attributed payment accounts #10445 — chain(revenue): inflow aggregation for attributed payment accounts
• compute(revenue): coverage_ratio and subsidy_multiple #10446 — compute(revenue): coverage_ratio and subsidy_multiple
• api(revenue): GET /subnets/{netuid}/revenue and /chain/revenue-coverage #10447 — api(revenue): GET /subnets/{netuid}/revenue and /chain/revenue-coverage
• spike(revenue): reconcile the Chutes payment feed against the chain #10448 — spike(revenue): reconcile the Chutes payment feed against the chain
• validate(entities): protocol-derived accounts must never carry a revenue or treasury role #10516 — validate(entities): protocol-derived accounts must never carry a revenue or treasury role

Phase 1 · proof on the two working subnets

• data(sn64): Chutes revenue provenance #10449 — data(sn64): Chutes revenue provenance
• data(sn51): Lium revenue provenance #10450 — data(sn51): Lium revenue provenance

Phase 2 · candidate subnets, one each

• data(sn15): revenue provenance for ORO #10451 — data(sn15): revenue provenance for ORO
• data(sn19): revenue provenance for blockmachine #10452 — data(sn19): revenue provenance for blockmachine
• data(sn43): revenue provenance for Graphite #10453 — data(sn43): revenue provenance for Graphite
• data(sn46): revenue provenance for Zipcode #10454 — data(sn46): revenue provenance for Zipcode
• data(sn49): revenue provenance for Nepher Robotics #10455 — data(sn49): revenue provenance for Nepher Robotics
• data(sn50): revenue provenance for Synth #10456 — data(sn50): revenue provenance for Synth
• data(sn62): revenue provenance for Ridges #10457 — data(sn62): revenue provenance for Ridges
• data(sn75): revenue provenance for Hippius #10458 — data(sn75): revenue provenance for Hippius
• data(sn93): revenue provenance for Bitcast #10459 — data(sn93): revenue provenance for Bitcast
• data(sn100): revenue provenance for Plaτform #10460 — data(sn100): revenue provenance for Plaτform
• data(sn103): revenue provenance for Djinn #10461 — data(sn103): revenue provenance for Djinn
• data(sn110): revenue provenance for Green Compute #10462 — data(sn110): revenue provenance for Green Compute

Phase 3 · sweeps

• data(sweep 1/3): usage-proxy subnets — promote or confirm proxy-only #10463 — data(sweep 1/3): usage-proxy subnets — promote or confirm proxy-only
• data(sweep 2/3): usage-proxy subnets — promote or confirm proxy-only #10464 — data(sweep 2/3): usage-proxy subnets — promote or confirm proxy-only
• data(sweep 3/3): usage-proxy subnets — promote or confirm proxy-only #10465 — data(sweep 3/3): usage-proxy subnets — promote or confirm proxy-only
• data(sweep 1/9): dark subnets — searched-and-absent, with a date #10466 — data(sweep 1/9): dark subnets — searched-and-absent, with a date
• data(sweep 2/9): dark subnets — searched-and-absent, with a date #10467 — data(sweep 2/9): dark subnets — searched-and-absent, with a date
• data(sweep 3/9): dark subnets — searched-and-absent, with a date #10468 — data(sweep 3/9): dark subnets — searched-and-absent, with a date
• data(sweep 4/9): dark subnets — searched-and-absent, with a date #10469 — data(sweep 4/9): dark subnets — searched-and-absent, with a date
• data(sweep 5/9): dark subnets — searched-and-absent, with a date #10470 — data(sweep 5/9): dark subnets — searched-and-absent, with a date
• data(sweep 6/9): dark subnets — searched-and-absent, with a date #10471 — data(sweep 6/9): dark subnets — searched-and-absent, with a date
• data(sweep 7/9): dark subnets — searched-and-absent, with a date #10472 — data(sweep 7/9): dark subnets — searched-and-absent, with a date
• data(sweep 8/9): dark subnets — searched-and-absent, with a date #10473 — data(sweep 8/9): dark subnets — searched-and-absent, with a date
• data(sweep 9/9): dark subnets — searched-and-absent, with a date #10474 — data(sweep 9/9): dark subnets — searched-and-absent, with a date

Phase 4 · surfacing

• mcp(revenue): get_subnet_revenue and list_revenue_coverage #10475 — mcp(revenue): get_subnet_revenue and list_revenue_coverage
• graphql(revenue): coverage fields on the SDL #10476 — graphql(revenue): coverage fields on the SDL
• ui(revenue): revenue vs emissions on the subnet page #10477 — ui(revenue): revenue vs emissions on the subnet page
• ui(revenue): the network-wide coverage leaderboard #10478 — ui(revenue): the network-wide coverage leaderboard
• docs(revenue): the methodology page #10479 — docs(revenue): the methodology page
• feed(revenue): coverage-change and provenance-upgrade events #10480 — feed(revenue): coverage-change and provenance-upgrade events

[linear-code]

JSO-7897