Zeus — subnet 18

Zeus pays for weather forecasts, and its own published code shows two separate, purpose-built defenses against copying — one aimed at whoever submits a forecast, one aimed at whoever judges it.

What it does

Zeus scores forecasts of real weather. The subnet uses ERA5 reanalysis data — the European Union's Copernicus programme's record of hourly measurements going back to 1940 — as its source of truth, and issues global forecasting challenges for four surface variables that matter to energy trading: 2-metre temperature, the two components of 100-metre wind, and solar radiation reaching the surface. Miners compete to produce the best forecast on the full Earth grid; validators score each reveal against what ERA5 actually recorded, keep a rolling rank history, and set subnet weights from that verified performance. [source]

The pitch is a cheaper substitute for traditional physics-based weather simulation, which is accurate but slow and computationally expensive. Zeus bets that data-driven forecasting models can eventually match that accuracy at a fraction of the cost, and structures the contest so miners can take on harder problems as the subnet matures. [source]

How the incentive mechanism works

Challenges run on two separate clocks: a short-term window covering the next two days and a long-term window covering the next fifteen. Validators sample one challenge per weather variable and time window on every pass, using per-window sampling limits defined in zeus/validator/constants.py; weight aggregation runs on separate rolling windows for the two horizons, configured via zeus/utils/config.py. [source]

The actual weight-setting logic lives in a dedicated background thread rather than running inline with every scoring pass: it refreshes burn data near the end of each epoch, waits for a configured block window, respects the chain's rate limit on how often weights can be resubmitted, and loads one shared rank snapshot from local storage before computing anything. [source] [source]

Weights themselves come from rolling average ranks, not raw scores: for each available challenge, the best-ranked eligible miner gets most of that challenge's weight share, and the rest is spread out logarithmically among everyone else. Per-challenge shares are then combined using fixed variable- and horizon-specific weights set in zeus/validator/constants.py. Challenge metadata, on-chain prediction hashes, and per-challenge rank history all live in local SQLite databases the validator maintains itself (challenges_v2.db, rank_history.db). [source] [source]

On top of ranked scoring, zeus/validator/collusion.py runs a direct similarity check between every pair of scored miners: if two miners' prediction errors are close enough to count as the same submission, the more recently registered of the two has its score wiped and is excluded from that round's weights, while the earlier-registered one is kept untouched. [source] [source]

What miners are actually optimising

The stated goal is the best global weather forecast. What actually gets paid is narrower: performance on exactly four named variables, at two fixed time horizons, with "geographic scalars" that can boost the score attached to specific regions such as Europe and Germany. A miner that specialises in those scored variables, horizons, and regions earns more than one that builds a genuinely general forecasting model and spreads its effort evenly across the planet — the contest rewards matching the scoring surface, not maximising real-world forecast quality everywhere. [source]

Because most of each challenge's weight goes to whichever single miner ranks best for that variable and window, being narrowly the best on a given axis matters far more than being broadly competent across all of them — a design that rewards specialisation over general-purpose accuracy. [source]

Unverified the collusion check only penalises the more recently registered of two similar miners, never the older one. That asymmetry is stated plainly in the code's own log message, but whether it has ever been used adversarially — one operator submitting a forecast close enough to an established rival's to trigger a penalty against the rival — is not something this course's evidence can confirm either way.

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 instead of paid out, divided by the same figure summed across every subnet on the network. [source] [source] [source] Nowhere in that formula does the quality of a subnet's own scoring code appear — a mechanism can only raise what it earns by first raising demand for its own token, which is a claim about buyers' beliefs, not a measurement of the code. So what follows is not, and cannot be, an argument that Zeus's earnings prove its mechanism works. It is a description of what the published code actually does and how checkable that is.

By that narrower standard, Zeus ships two independent, purpose-built defenses that a purely honest design would not need: on-chain commit-reveal for miners, so a forecast can't be copied after the fact because the hash is posted before the real numbers are revealed, and a "dynamic burn" that reassigns a changing share of emissions to a burn UID every epoch specifically to make a copied weight vector go stale the moment the burn amount changes. Both are described in the subnet's own published feature list as answers to real, named exploits — relay mining and weight-copying validators — rather than generic security boilerplate. [source]

Stake evidence

At the snapshot block, Zeus carries 2680 @ 8871732 token holders, placing it at holder rank 31 @ 8871732 against emission rank 18 @ 8871732, with 98.4% @ 8871732 of emission captured by subnets ranked at or above it. Those two ranks sit close enough together that the snapshot does not raise a rank disagreement for Zeus: false @ 8871732. Its position by who holds the token and its position by how much it currently earns tell roughly the same story, which is not true of every subnet in this course.

Separately, 14.9% @ 8871732 of Zeus's own judging power comes from money staked into the root network rather than staked directly into Zeus's own alpha — a root proportion that describes who decides *within* this subnet, independent of anything about price.

Price evidence

Zeus alpha traded at 0.00505515 @ 8871732 TAO at the snapshot block, up 0.80805579036854 @ 8871732 percent over the trailing week but down -26.56316665918519 @ 8871732 percent over the trailing month, against a market capitalisation of 26453078814198 @ 8871732 and 578368243561 @ 8871732 rao of trading volume in the prior day. Its emission share of 0.7% @ 8871732 tracks a slow-moving average of that price, not the latest tick — new information takes weeks to fully reach emission, by design. [source]

Unverified the mechanism evidence above shows real, working anti-copying code, and the price evidence shows a token that fell over the month while holding up over the week. This course's evidence cannot say whether that price move reflects growing or shrinking confidence in the mechanism specifically, as opposed to the same broad market conditions moving every subnet's alpha at once — the formula above guarantees the two are connected only through price, never directly.

Failure modes and attack surface

The dynamic burn that deters weight-copying depends on an external "performance API" for its per-epoch burn amount; if that call fails, the validator falls back to a fixed default burn percentage instead. That fallback is honestly documented, but it means the anti-copying property is not self-contained inside the subnet's own on-chain logic — it depends on a service whose own source is not part of this pinned repository. [source]

The collusion check is pairwise similarity on prediction error, and it always penalises the newer registration when two miners look alike. Any legitimate reason two independent forecasting models might converge on similar numbers — a genuinely easy prediction window, for instance — would fall the same way as deliberate copying, and only ever costs the newer entrant. [source]

What to copy, what to avoid

Copy the dynamic burn idea: changing what a copier would need to copy on every single epoch is a stronger defense than a one-time secret, because it removes the "steady state" a copier could otherwise settle into. Copy the commit-reveal pairing with an open verification path — Zeus publishes prediction hashes specifically so outside parties can check a forecast against what was actually committed, not just so the subnet can trust itself. [source]

Avoid quietly routing a security-critical number — like a burn amount meant to defeat copying — through an external API with a static fallback; an attacker who can reason about the fallback value can reason about the copying opportunity it reopens. And avoid an asymmetric anti-collusion rule that always blames the newer party: it is simple to implement, but it is also simple to describe as a way to attack a newer competitor rather than an actual collusion pair. [source] [source]