Pareton — subnet 10
What it does
Pareton pays people for finding ways to make a shared piece of software run faster, and pays out only after checking, itself, that the faster version still works.
Pareton runs what it calls inference-optimisation campaigns. A campaign starts from a pinned, known-good version of vLLM, a widely used piece of software for serving large language models; miners write and submit a code patch against that exact starting point, and Pareton itself builds the patched version in a reproducible container and benchmarks its real performance. A patch that passes and measurably improves on the starting point becomes the new floor the next campaign is judged against. [source]
Pareton is in the top tier of this tracked set, tier A: its emission share is 4.0% @ 8871732, rank 5 @ 8871732 of the tracked set. 2718 @ 8871732 wallets hold its alpha token, but only 1 @ 8871732 active miner is currently earning against its full judging committee — the exact size of that committee is in the technical section below. 256 @ 8871732 of its 256 @ 8871732 registered slots are filled.
How the incentive mechanism works
The repository's own account of the pipeline runs in five steps: a campaign is opened with a frozen manifest — baseline commit, base image, and which files a patch is even allowed to touch; a miner writes a patch, uploads it, and commits its hash and the campaign id on-chain; a watcher process scans the chain for new commitments and a worker process runs validation gates on them; a passing patch is rebuilt from scratch inside the pinned base image so nothing the miner assembled locally can sneak into the result; and only then is it benchmarked for correctness, performance, and service-level checks. [source]
That fifth step is where the repository's own documentation stops short: it states plainly that turning a benchmark result into an on-chain score is "still design-only." [source] Everything upstream of that — the campaign manifest, the on-chain commitment, the hermetic rebuild, the benchmark harness — is real, working code this dossier could read. The step that would actually connect a benchmark result to a paid weight is not.
Submitting a patch is itself an on-chain act with a real cost: the miner's own submission script uploads the patch, transfers a submission fee from the miner's wallet when one is configured, and only then commits the patch's hash and campaign id to the chain, capped at three short data fields because Bittensor's own commitment storage cannot hold more. [source] [source] [source]
What miners are actually optimising
Stated plainly, the goal is: write the patch that most improves real, measured performance over the pinned baseline. [source] But with the step that turns a benchmark result into a paid weight still undocumented as working code, this dossier cannot say that improving the benchmark is what actually earns a miner money on lium.io's chain today. [source] What a miner can verifiably do, right now, is commit a well-formed, correctly-fee-paid patch that clears the validation gates and gets rebuilt successfully — that much is real, checkable, on-chain behaviour, whatever happens to it afterward. [source]
With only 1 @ 8871732 active miner against 2718 @ 8871732 holders of the token, whatever this subnet currently rewards is being captured by essentially one participant, not contested across a field of competing patches the way the campaign structure describes.
Why it earns
Mechanism evidence
Cross-subnet emission is set by one formula, identical for every subnet: a subnet's share is its own moving-average alpha price, discounted by a miner-burn penalty, against every other subnet's. [source] [source] Mechanism quality has no other route into that number — it can only matter by first moving demand for the token. For Pareton specifically, this dossier has an extra reason not to credit the mechanism: the repository's own documentation says the step that would turn a benchmark result into a paid score is still design-only, not shipped code. [source] A design that has not been shown to run cannot be the explanation for a rank-5 @ 8871732 share of the network's emission.
Stake evidence
14.4% @ 8871732 of the judging power behind Pareton's committee traces to the root network rather than stake placed directly in its own alpha token. [source] A validator permit itself is awarded purely by stake weight — the top accounts by money behind them, recalculated every epoch, with no separate check on whether that account is scoring anything real. [source] The technical section below gives the exact committee size; what matters here is that permits are handed out by money, not merit, regardless of the count.
Price evidence
Pareton's alpha trades at 0.007148645 @ 8871732 TAO, up 10.82551981594826 @ 8871732% over the trailing week and 19.45538406420465 @ 8871732% over the trailing month — and because the cross-subnet emission formula runs on exactly this number, that movement mechanically pulls a larger share of new emission toward Pareton regardless of whether a single working patch has ever been scored on-chain. [source] [source] With the scoring step itself undocumented as shipped, price is not merely the dominant explanation available here — it is close to the only one this dossier's evidence can point to at all.
Failure modes and attack surface
The most basic risk to a benchmark-and-pay design is a benchmark that can be gamed rather than beaten honestly — submitting a patch that special-cases the exact workload trace being measured instead of genuinely improving general performance. Nothing in what this dossier could read describes a defence against that beyond the hermetic, content-addressed rebuild, which stops a miner from shipping different bytes than what was benchmarked but does not stop a patch narrowly tuned to the known trace. [source] [source]
More basically: with the scoring-to-weight step still design-only by the repository's own account, this subnet currently has no documented, checkable link between a benchmark result and a payout at all. [source] Whatever the chain's ordinary consensus safeguards do here — clipping toward whatever a majority of active stake already supports, unable to distinguish independent judgment from coordinated agreement — they are only as meaningful as the scoring process feeding them, and this one is not shown working yet. [source]
What to copy, what to avoid
What to copy: a hermetic, content-addressed rebuild pipeline is a genuinely strong defence against a miner submitting one thing and shipping another. Rebuilding a patch from scratch inside a pinned base image, rather than trusting whatever a miner uploads pre-built, closes off an entire class of cheating before scoring even starts. [source]
What to avoid: shipping the submission pipeline before the scoring pipeline. Pareton's own documentation is honest that turning a benchmark result into a paid score is still design-only — but honesty about the gap does not close it. A subnet that can accept, fee-charge, and rebuild a miner's patch, yet cannot yet say how that patch becomes a weight, is collecting real emission for a mechanism that is not finished. [source]
How it actually works
Pareton's committee held 12 @ 8871732 validator permits at block 8871732, against 2718 @ 8871732 wallets holding the token and just 1 @ 8871732 active miner — the small-committee, near-single-miner point made in plain terms above.
The submission script sizes its on-chain payload defensively before spending anything: Bittensor's own commitment storage caps a plaintext commitment at three 128-byte fields, so the script raises a clear error and refuses to submit rather than let a chain-level failure burn a fee for nothing. [source] It also supports a timelock-sealed commitment mode as an alternative to plaintext, sealing the payload until a public drand round is reached — though the script's own comment notes that on the finney network this reveal path had produced no entries in roughly 52 days at the time it was written, which is itself a sign of how early-stage this campaign format still is. [source] [source]
What miners are actually optimising
The layout the repository documents assigns each concern its own directory — gate/ for patch validation, builder/ for the hermetic rebuild, bench/ for the correctness and performance harness, chain/ for reading commitments and watching the chain — which is a reasonable shape for a scoring pipeline to eventually finish in. [source] What a miner is optimising for today is getting a patch through the parts of that shape that exist: the gates, the build, and the fee payment — not yet a finished score.