Apex — subnet 1

Apex is the oldest, most thoroughly documented contest this course pinned — and its own code shows that the final step of judging happens somewhere this course cannot read.

What it does

Apex is subnet 1, one of the oldest contests still running on the network. Its own documentation calls it "Kaggle for decentralized intelligence": Kaggle captures predictions, Apex captures the actual models and algorithms that produce them. Anyone can submit an algorithm or model to one of its open competitions; every entry is scored automatically, and the best ones are paid — no gatekeeper, no application process. [source]

Registering a hotkey on Apex is a one-time buy-in: the chain command reports the cost before anything is confirmed, and once it succeeds, that hotkey can submit to any of Apex's running competitions. [source] [source]

How the incentive mechanism works

Apex runs several competitions side by side, each with its own fully specified scoring rule. In its IOTA Simulator competition, a submission's score is one minus the share of an allotted time budget it used, clamped to between zero and one so a run that hits or exceeds the ceiling scores zero and a near-instant one scores close to one; the final result for a round is the median across five separately-seeded evaluation runs. [source] [source] [source] Its Tron reinforcement-learning environment scores every single training step — a small reward for surviving, a larger one for a win, a penalty for a loss — and its Battleship environment does the same with a reward for every hit and every sunk ship. [source] [source]

None of that final per-competition score is what reaches the chain directly, though. The file that actually talks to the chain, validator.py, does not compute scores itself. When it's time to report, it makes a signed request to a separate service its own code calls the orchestrator, asking for global_miner_scores. [source] [source]

Unverified searching this course's full pinned snapshot of the Apex repository — 1,908 chunks — for the word "orchestrator" turns up thirty-six chunks, and this dossier read all of them: every one is client code that calls the orchestrator, or a use of the same word inside a simulated competition (see below), never a server that implements it. That is an absence this dossier's own search found, not a documented claim Apex itself makes, so it is offered as this course's search result rather than a stated fact — the service that actually computes the numbers a validator reports may simply live in a different, unpinned repository. [source] [source]

When the orchestrator can't be reached, the validator does not go silent. It reads whatever numbers are already sitting on chain from other judges, weights them by how much stake backs each one, and reports that stake-weighted average as its own — the exact arithmetic this course's lesson on gaming describes as a way to cheat, here built into production code on purpose, as a safety net rather than an exploit. [source] [source] [source]

Whatever numbers do reach the chain — whether from the orchestrator or from copying — pass through the SDK's own process_weights_for_netuid before submission, rather than through anything Apex reimplements itself. [source]

What miners are actually optimising

Inside any one competition, miners are optimising exactly what that competition's published formula rewards — the time-budget formula for the IOTA Simulator, per-step survival and victory for Tron, per-hit accuracy for Battleship. One of Apex's competitions, built with an outside partner, goes further: it pays for steering a language model toward a target concept with the *smallest* intervention that still works, and a separate, unsteered pass of the same model judges every completion for coherence first — a submission that "wins" by degenerating the model into repeating the target concept scores zero regardless of how strongly a naive detector would say it hit the mark. [source] [source]

But every one of those well-specified formulas only ever produces a *candidate* score. What a miner is actually paid on is whatever the orchestrator reports as global_miner_scores — a step this course cannot inspect — or, if that call fails, a stake-weighted copy of other validators' already-set numbers. A miner genuinely optimising Apex's own published rules and a miner merely convincing an unseen orchestrator (or the validators copying each other's output) are not guaranteed to be the same target, and this dossier cannot confirm from the pinned source that they are. [source] [source]

Why it earns

Mechanism evidence

Every subnet's cross-network emission share is set by one chain-wide formula: its 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] Nowhere in that formula does the quality of Apex's own competitions or scoring code appear directly — earnings cannot confirm the mechanism works, and Apex is the sharpest illustration of that in this whole course: its measured emission share at this snapshot is 0.0% @ 8871732, while it still runs real validators judging 4 @ 8871732 active miners among 3358 @ 8871732 token holders. A working mechanism can earn nothing if nobody is buying the token; the two facts are not in tension.

The orchestrator gap and the weight-copying fallback do not explain that zero either — they are a separate axis entirely. A subnet could run exactly this same opaque-scoring, copy-on-failure design and still capture a large emission share if its alpha price held up; what actually earns is checkable and specific — the individual competition formulas — while what actually reaches the chain, on the days the orchestrator is unavailable, is a number nobody in this repository computed from any of those formulas at all. [source] [source]

Stake evidence

Apex sits at holder rank 17 @ 8871732 and emission rank 26 @ 8871732 — a gap the snapshot does not flag as a rank disagreement: false @ 8871732. 14.5% @ 8871732 of Apex's own judging power comes from root network stake rather than stake placed directly in Apex's own alpha — a root proportion describing who decides within this subnet, independent of its price or its measured emission.

Price evidence

Apex alpha traded at 0.007867788 @ 8871732 TAO at the snapshot block, down -2.096702643074505 @ 8871732 percent over the trailing week and down -8.90614614103279 @ 8871732 percent over the trailing month, against a market capitalisation of 38427048863158 @ 8871732 rao — a real, actively traded market, not an abandoned one, with 361883044225 @ 8871732 rao changing hands in the prior day alone. Emission share tracks a slow moving average of that price rather than the latest tick. [source]

Unverified a nonzero, actively traded price alongside a measured emission share of essentially zero is the pattern the network's own formula predicts when almost all of a subnet's recent miner incentive was redirected to subnet owner hotkeys rather than paid out — that redirected share is exactly the penalty term the formula subtracts before comparing subnets. This course's pinned evidence does not include that specific figure for Apex, so this is offered as the most consistent reading of the formula against what is measured, not a confirmed cause.

Failure modes and attack surface

The clearest attack surface is the one this course cannot see into: whatever the orchestrator actually does to turn competition results into global_miner_scores is not part of the pinned repository, so nothing here can confirm it resists collusion, miner-side gaming, or simple bugs any better than the well-specified per-competition formulas it sits on top of. [source]

The fallback path is a second, distinct risk: copy_weights_from_chain is real, callable, production code, triggered automatically on a timeout or an empty response, not a hypothetical. It reproduces — deliberately, as a safety net — the exact stake-weighted-copying shortcut this course's own lesson on gaming names as something Yuma Consensus is supposed to make unrewarding for a validator to do on purpose. Whether Apex's own validators hit this path often enough for it to matter in practice is not something this dossier can measure from source code alone. [source] [source]

A third, narrower dependency sits inside one competition rather than the core validator loop: the Aurelius-partnered steering competition is scored by a separately maintained image, hosted by that outside partner, that Apex's own GPU fleet calls over the network for every submission — a second point, alongside the orchestrator, where the number a miner is actually paid on is computed outside this pinned repository. [source]

What to copy, what to avoid

Copy the individual competition designs: a published, numeric formula — a time-budget ratio, a median across seeded runs, a coherence gate that zeroes a degenerate "win" — gives a miner and an outside reader alike something concrete to check, and Apex's own repository shows several different, genuinely well-specified versions of this. [source] [source]

Avoid routing every one of those well-specified scores through a single opaque aggregation step before they reach the chain. Publishing a rigorous per-competition formula and then handing the actual payout decision to an unpinned external service undoes much of the point of publishing the formula in the first place — a reader can verify the rule but not the number that actually determines pay. [source]

Avoid a silent, automatic fallback to stake-weighted copying without a highly visible flag when it triggers. A safety net that behaves identically to a known exploit is reasonable engineering under real operational constraints, but it should be loud, not a quiet except branch, precisely because it is indistinguishable from the thing this course's own lesson on gaming warns validators not to do on purpose. [source]