Reading a subnet's code: where the mechanism actually lives
This lesson does what the last few could only describe: it opens up one real, currently running contest and shows exactly where its rules actually live in code — and where they don't.
Apex is subnet 1 on Bittensor's main network, one of the oldest contests still running. It hosts open competitions where anyone can submit an algorithm or model to solve a hard problem; every entry is scored automatically and the best ones are paid out. Its own documentation describes it as "Kaggle for decentralized intelligence" — Kaggle captures predictions, this captures the actual models and algorithms producing them. [source] [source]
The file that actually talks to the chain, validator.py, spends most of its code on plumbing that has nothing to do with judging: connecting a wallet, syncing the shared on-chain record of who's registered, restarting itself if something crashes. When it's time to report scores, it doesn't compute anything itself — it makes a signed request to a separate service its own code calls the orchestrator, asking for global_miner_scores. The actual judging doesn't live in this repository at all. [source] [source]
Unverified Searching this course's full pinned snapshot of the Apex repository for anything mentioning "orchestrator" turns up nothing beyond the client code that calls one — the service that actually computes scores does not appear to be part of the public codebase pinned here. This is an absence, not a documented claim, so take it as this author's search result rather than a stated fact: the orchestrator's own source could simply live in a different, unpinned repository this course doesn't have.
When that orchestrator can't be reached, the validator doesn't go silent — it falls back to copying. It reads whatever numbers are already sitting on the chain from other judges, averages them by how much money backs each one who submitted them, and reports that average as its own. That is, functionally, the exact same shortcut the previous lesson described as a way to cheat: here it is built in on purpose, as a safety net for when the real scoring service is down, but the underlying arithmetic is identical. [source] [source]
What Apex does publish in full is the definition of each competition itself: what a submission has to do, and the baseline code a newcomer starts from. One of its competitions scores every attempt with a simple, published formula — one minus the share of an allotted time budget used, clamped so a run that hits or exceeds the ceiling scores zero and a near-instant one scores close to one — and the final result for that round is just the median across five separately-seeded evaluation runs. [source] [source] [source]
The numbers that do finally reach the chain go through the same normalization an earlier lesson on judging described: the code hands its scores to the SDK's own process_weights_for_netuid function before submitting them, rather than reimplementing that math itself. [source]
How it actually works
In the weight loop, the decision reads almost exactly like this: check the orchestrator's health; if it's healthy, call ValidatorAPIClient.get_global_miner_scores(hotkey=self.wallet.hotkey); if that call raises an exception or simply times out, the surrounding except block calls self.set_weights(weights=self.copy_weights_from_chain()) instead. copy_weights_from_chain is itself short: pull the validator-permitted rows out of a freshly synced metagraph, normalize their stake, and take the dot product against the weights they've already set. [source] [source] [source]
Every call to the orchestrator is signed before it goes out: the client builds a message body, generates a header from the caller's own hotkey keypair, and only then opens the HTTP request — so the orchestrator can verify which registered hotkey is actually asking, even though it sits entirely outside any route the chain itself defines. [source] [source]
The public repository does go deeper than the final formula for some competitions. Its Tron reinforcement-learning environment (shared/competition/src/competition/tron/train/env.py) hands out a reward on every single step during training — +0.01 for surviving a step, +1.0 for a win, -1.0 for a loss — and its Battleship environment does the same with per-hit and per-sunk-ship rewards, both far finer-grained than the single number a finished submission ultimately earns in competition. [source] [source]