20Lesson

Hone: how the mechanism works

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

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

At this course's snapshot, Hone's measured emission share is 0.0% @ 8878789 — the same as Targon, elsewhere in this batch — while 243 @ 8878789 miners are active, the highest count of any subnet this course tracks. 2858 @ 8878789 wallets hold its alpha token, judged by a committee of 9 @ 8878789 validators.

How the mechanism works

The measured metric is exact_match_rate, the share of ARC problems a solver gets exactly right. A miner must clear a floor — 20% by default — before it is eligible for anything, and only the top five above that floor are paid at all; each rank down from first is worth 0.8 times the rank above it, normalised so the paid ranks sum to whatever slice of the round is available. [source] [source] [source] [source] [source]

A second layer sits on top of that leaderboard: by default, 95% of every round's available reward goes 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 decay rule. If nobody qualifies at all, the whole round burns. [source] [source] [source]

Isolation is enforced at the infrastructure level, not just the scoring level: a submitted repository is built with internet access, for installing dependencies, but the actual inference step runs with network_mode: none — no network at all — so a submission cannot phone home or fetch answers during the scored run. [source] [source]

Why they built it this way

The subnet's own security notes state the reasoning for the isolation split directly: wallet files are mounted read-only, the inference phase runs with networking disabled, several Linux capabilities are dropped, and the validation dataset with expected outputs is never exposed to a miner. [source] That is a stated reason for *why the run is sealed the way it is*. This lesson did not find a stated reason, anywhere in this pinned source, for the specific choice of a 95% default burn over any other figure — the code documents *what* the split is, not *why* that particular number, so this lesson says that plainly rather than inventing a rationale for it.

What a miner is actually optimising

The floor-plus-top-five-plus-decay design means a miner is optimising for a narrow target: clear 20% accuracy, then land first or second specifically, since 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 burns by default regardless of how many miners qualify, the mechanism is not optimising for a broad, healthy leaderboard at all — it is optimising to find a small number of genuinely strong solvers and pay them a small, fixed pool, with almost all of the round's emission withheld every single round, win or not. [source]

Do validators do anything besides validate?

Not in the sense of running a second, paid line of business — nothing in this source shows a validator serving external customers, holding funds beyond its own stake, or billing anyone. But grading here is genuinely expensive to run: a validator needs its own NVIDIA GPU to operate the sandbox that clones, builds, and executes a miner's repository, and that sandbox endpoint is a plain configuration value a validator operator points at its own infrastructure, not a single address baked into the code. [source] [source] [source] That is a real difference from the other two subnets in this batch published by the same organisation: Hone's own LICENSE reads "Copyright (c) 2025 Manifold," and its own setup instructions clone from github.com/manifold-inc/hone — the same account that publishes Targon, github.com/manifold-inc/targon. [source] [source] [source] Both subnets burn heavily by default, but not the same way: Targon burns only whatever an auction leaves unmatched, a figure that shrinks as more real demand shows up. [source] Hone burns a flat 95% of every round regardless of how many miners qualified. [source]

Why it earns

Cross-subnet emission share runs on one formula, identical for every subnet: each one's share is its own moving-average alpha price, discounted by a miner-burn penalty, against every other subnet's. [source] [source] Hone's own 95% default burn is directly relevant to that penalty term, but this lesson cannot confirm from its pinned source whether Hone's specific burn UID counts as "redirected to the subnet owner" for that formula's purposes — the repository sets it from an environment variable rather than naming who controls it. [source] What is measured directly is Hone's 0.0% @ 8878789 share, against 243 @ 8878789 active miners and a market capitalisation of 53975628135505 @ 8878789 rao — a real, running contest, by miner count the busiest subnet this course tracks, earning nothing measurable at this snapshot. 0.013170032 @ 8878789 TAO is the current alpha price, down -8.14408468522896 @ 8878789% over the trailing month.

What to copy, what to avoid

Copying: 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] Publishing the decay factor, the floor, and the burn percentage as named, readable constants in the scoring code itself — rather than leaving them as unstated policy — lets a miner actually do the math before competing. [source] [source]

Avoiding: a large default burn percentage without also publishing who or what actually receives it. A burn UID set from an environment variable, with no public statement of who controls it, turns a defensible design decision into an unverifiable one. [source]

How it actually works

validator/config.py sets the floor, the paid-rank count, and the lookback window as environment-overridable defaults: [source]

max_submissions_per_day: int = int(os.getenv("MAX_SUBMISSIONS_PER_DAY", "1"))
min_accuracy_floor: float = float(os.getenv("MIN_ACCURACY_FLOOR", "0.20"))
top_miners_count: int = int(os.getenv("TOP_MINERS_COUNT", "5"))

[source] Eligibility looks back over a rolling window sized off the query cycle itself — score_window_blocks is four cycles — and requires at least one successful response inside it, min_responses. [source] [source]

validator/scoring.py computes the leaderboard, then converts it to on-chain weights in two passes. [source] First, exponential decay across the top ranks:

decay_factor = 0.8
exponential_weights = [math.exp(-decay_factor * rank) for rank in range(len(top_miners))]
normalized_weights = [w / sum(exponential_weights) for w in exponential_weights]

[source] [source] [source] Then set_weights applies the burn split on top of that:

BURN_UID = int(os.getenv("BURN_UID", "251"))
BURN_PERCENTAGE = float(os.getenv("BURN_PERCENTAGE", "0.95"))
...
if not has_qualifying_miners:
    all_weights[BURN_UID] = 1.0
else:
    all_weights[BURN_UID] = BURN_PERCENTAGE
    for uid, weight in scores.items():
        all_weights[uid] = (weight / miner_weight_sum) * (1.0 - BURN_PERCENTAGE)

[source] [source] [source] [source] [source]

Execution itself runs through a separate SandboxRunnerClient, which submit_jobs a repo_url, repo_branch, and repo_commit to a configurable SANDBOX_RUNNER_ENDPOINT, then polls a job through phases logged as pending, cloning, building, prep, inference, completed. [source] A validator operator needs an NVIDIA GPU to run this locally, and the example configuration in this repository points that endpoint at localhost — it is infrastructure a validator provisions itself, not a single shared address. [source] [source] Identical repo_url + repo_branch + repo_commit combinations are cached rather than re-evaluated, and a miner is limited to one new submission per day by default. [source]