Hone — subnet 5

Hone pays for solved reasoning puzzles, and its own scoring code shows most of every payout being deliberately thrown away before it ever reaches whoever earned it.

What it does

Hone benchmarks solvers against ARC-AGI-2, a public set of abstract visual reasoning puzzles designed to be hard for today's models but solvable by a competent general reasoner. Miners point at a solution repository; a validator fetches that pointer, submits the job to a separate GPU execution service, and that service clones the repository, builds it, runs it in isolation, and reports back how many puzzles it solved exactly right. [source]

How the incentive mechanism works

The measured metric is exact_match_rate — the share of ARC problems a miner's solver gets exactly right — and a miner has to clear a fixed floor, 20% accuracy, before it is even eligible for a reward. Only the top five miners above that floor are paid, and among those five, reward is split by exponential decay: each rank down from first gets a share multiplied by 0.8 relative to the rank above it, then normalised so the paid ranks sum to whatever slice of the round is available. If nobody clears the floor at all, the entire round is burned. [source]

The actual weight-setting code, validator/scoring.py, then applies a second layer on top of that leaderboard: by default, 95% of every round's available reward is sent to a dedicated burn UID regardless of how many miners qualified, and only the remaining 5% is split among the qualifying top five by that same exponential-decay rule. If nobody qualifies at all, the full 100% is burned. [source] [source] [source]

Isolation is enforced at the infrastructure level, not just the scoring level: the sandbox runner builds a miner's submitted repository with internet access, for installing dependencies, but then runs the actual inference step with no network access at all — a submission cannot phone home or fetch answers during the scored run. Submissions are cached by exact repository, branch, and commit, so resubmitting the same code does not trigger a redundant evaluation. [source] [source]

What miners are actually optimising

The floor-plus-top-five-plus-exponential-decay design means a miner is optimising for a narrow target: clear 20% accuracy, then be first or second specifically, since the decay curve means each additional rank down is worth meaningfully less than the one above it. Ninth place and no place pay the same: nothing. [source]

Because 95% of every round is burned by default regardless of how many miners qualify, the mechanism is not actually optimising for maximum participation or a broad, healthy leaderboard — it is optimising to identify a small number of genuinely strong solvers and pay them a small, fixed pool, with almost all of the round's emission withheld on every single round, win or not. [source]

Why it earns

Mechanism evidence

Every subnet's cross-network emission share is set by one chain-wide formula — a subnet's own moving-average alpha price, adjusted for how much of the last period's miner incentive was redirected back to the subnet owner, divided by that same figure summed across every subnet on the network. [source] [source] That penalty term is directly relevant here: Hone's own scoring code sends 95% of every round's reward to a burn UID by default, whether or not any miner qualified. [source] Whether that specific burn UID counts as "redirected to the subnet owner" for the purposes of the network's own formula is not something this course's pinned evidence can confirm — the repository sets the UID from an environment variable rather than naming who controls it — but if it does, a 95% default burn is large enough to explain a measured emission share far below what 241 @ 8871732 active miners and real, running competitions would otherwise suggest. This dossier states that as a plausible reading of the formula, not a confirmed fact. [source]

What can be checked directly is that the leaderboard logic is real, running code in this pinned repository, not an external claim: floor, ranking, decay, and burn are all implemented in validator/scoring.py itself, with the isolation and caching rules enforced by a separate but also-described sandbox service. [source] [source]

Stake evidence

Hone carries 2875 @ 8871732 token holders at holder rank 24 @ 8871732, against an emission rank of 30 @ 8871732 — the snapshot does not raise a rank disagreement for Hone: false @ 8871732. 14.8% @ 8871732 of Hone's own judging power comes from root network stake rather than stake placed directly in Hone's own alpha — a root proportion that describes who decides within this subnet, separate from anything about price or the 95% burn described above.

Price evidence

Hone alpha traded at 0.013155863 @ 8871732 TAO at the snapshot block, down -3.40405141842084 @ 8871732 percent over the trailing week and down -8.19509652315663 @ 8871732 percent over the trailing month, against a market capitalisation of 53813695302989 @ 8871732 rao and 2371653681574 @ 8871732 rao of trading volume in the prior day. Its measured emission share at this block is 0.0% @ 8871732 — a genuinely measured figure, not a missing one, and consistent with both a low moving-average price and a mechanism that burns most of its own round-level reward before it ever reaches the cross-subnet formula. [source]

Failure modes and attack surface

The sandbox's build phase has internet access before the network-isolated inference phase begins — a real, documented boundary, but one whose safety depends entirely on nothing being fetched during the build step that could influence the isolated run, something this dossier cannot verify beyond what the architecture doc claims. [source]

The 95% default burn is a genuine design choice, not a bug, but it does mean that from a miner's perspective, the honest, fully-documented mechanism and a mechanism that quietly starves participants look identical from the outside — both produce a small paid pool and a large burned one. Distinguishing "intentionally scarce reward, functioning as designed" from "reward that never reaches miners regardless of quality" requires reading the code, which is exactly what most participants and outside observers will not do. [source]

What to copy, what to avoid

Copy the network-isolated inference step: separating "install dependencies" (networked) from "run and score" (isolated) closes off an entire class of exploit where a submission fetches results instead of computing them. [source]

Copy publishing the exact decay factor and burn percentage as named, readable constants in the scoring code itself, rather than leaving them as unstated internal policy — a miner deciding whether to compete at all can actually do the math. [source] [source]

Avoid a large default burn percentage without also publishing, alongside it, who or what actually receives the burned share — a burn UID set from an environment variable, with no public statement of who controls it, is exactly the kind of detail that turns a defensible design decision into an unverifiable one. [source]