Zeus SN18 has changed what repeated failure means for a miner’s share of an affected forecasting challenge.
Release v2.1.4 says a miner registered for more than four weeks receives no weight on a challenge after eight consecutive penalties. Newer miners keep a grace period. The rule is designed to stop established hotkeys from retaining emission while repeatedly missing or failing the work Zeus scores.
The release language calls these miners inactive. The code covers a wider group. A missed response counts, but so do shape errors, hash mismatches, collusion flags and other conditions that Zeus records as penalties. Tao Outsider therefore does not label every excluded miner inactive, abusive or fraudulent.
The important change is narrower. Eight consecutive penalty records can now remove a hotkey from one challenge’s weight calculation.
Before v2.1.4, a poor record could still have a weight path
Zeus maintains rank history for several weather-forecasting tasks. Validators use recent challenge ranks to calculate weights, with different rolling windows for short- and long-horizon work.
A miner that failed a challenge could receive the worst rank. A miner that did not answer could also be written into history with a penalty rank. That lowered the miner’s standing. A long run of penalties still lacked a separate eligibility stop.
As long as the hotkey remained in the set passed to the averaging function, it could still be part of the ranking and weight process. Zeus describes the result as non-participating miners receiving some emission.
Version 2.1.4 adds a second question before the rank is averaged: has this hotkey accumulated at least eight penalty rows in a row for this challenge?
An established hotkey that meets the penalty threshold is skipped. The four-week registration grace period prevents the same exclusion for a newer hotkey.
The cutoff is challenge-specific
The implementation stores penalty history under a state_key. In Zeus, that key identifies a particular variable and forecast horizon.
The validator builds an exclusion set for each key. A miner can therefore lose its weight path on one challenge without the code automatically declaring it ineligible everywhere.
That detail prevents an easy but wrong headline. Zeus did not add a subnet-wide ban after eight bad events. It added a challenge-level eligibility rule to the weight setter.
The change also distinguishes a penalty from a low but valid rank. The database now carries a got_penalty field alongside rank and participation. Future rows can record whether a poor result came from a penalty condition rather than treating every last-place forecast as the same event.
Zeus lists missed challenges, malformed output, missing responses, hash mismatches and collusion among the paths that can produce a penalty. Their causes and severity vary. Once the consecutive count reaches the threshold, the weight consequence is the same.
Four weeks of grace protect a new registration
The release exempts miners registered within the past four weeks.
The code estimates registration age from the current block and the hotkey’s registration block, using a 12-second block interval. Hotkeys inside the grace window are removed from the exclusion set even if their recent rows meet the penalty condition.
The grace period gives a new operator time to configure the forecasting pipeline, learn the challenge schedule and repair early failures. It also creates a deliberate difference between an onboarding problem and a persistent pattern from an established miner.
That policy has tradeoffs.
A four-week exemption can keep emission eligibility open for a new hotkey that is not yet producing useful work. A strict cutoff without grace could make entry too expensive and reward only operators who already know the stack. Zeus has chosen a fixed period rather than trying to infer intent.
The four-week estimate also depends on block-time assumptions. It is an implementation rule, not a guarantee that every miner receives exactly 28 calendar days under every chain condition.
Historical rows need a migration
Existing validator databases were created before the new got_penalty column existed. Version 2.1.4 adds the column and backfills older records.
Absences are marked as penalties. For older participating rows, the migration also marks records whose rank matches the maximum rank assigned to absent miners in the same challenge and time window.
This is a practical reconstruction from the data already stored. It is not the same as having preserved the original reason for every historical rank.
The new eligibility decision depends on the last eight flags. Validators upgrading from an older database may be applying a backfilled interpretation to history, while a fresh database records the penalty bit directly.
The repository includes tests for the new path, but Tao Outsider did not run a production validator database through the migration or compare the resulting exclusion sets across operators.
Who gains and who loses
The likely winners are miners that keep answering challenges with valid output. Removing an established hotkey after a long penalty streak reduces the set sharing that challenge’s weight allocation.
The likely losers are hotkeys that remained registered and retained a weak weight path despite repeatedly receiving penalties. The consequence arrives after eight consecutive records, not after one failure.
The rule also changes the value of simply staying registered. A hotkey cannot rely on poor rolling ranks alone to preserve eligibility forever if every new row is a penalty.
That is an incentive improvement, not proof of better forecasts. Excluding repeated failures can make the competition cleaner while leaving model quality, benchmark design and customer demand unchanged.
It can also create new edge cases. A miner may challenge whether a shape error was caused by its own output, a validator bug or a transient data problem. A false penalty now has more economic weight because eight consecutive flags can close the path entirely.
The quality of the exclusion rule therefore depends on the quality and consistency of penalty classification.
What is live, and what is not verified
Zeus published v2.1.4 as a numbered GitHub release on September 7. The tag points to the commit that adds the new database field, exclusion logic, grace period and documentation.
That proves the software package exists. It does not prove every production validator upgraded immediately, that all validators reconstructed history identically or that live weights already reflect the new rule.
At TaoSwap block 9,015,736, Zeus SN18 had 34 active miners and a nonzero emission_value of 0.000279579. That snapshot confirms active subnet context only. It does not reveal which validator version produced a particular weight vector or which miners met the eight-penalty condition.
The next useful evidence is operational. Zeus should show the rule in a public challenge history, identify how excluded hotkeys can inspect or dispute penalty rows and demonstrate that validators converge on the same eligibility set after migration.
For now, v2.1.4 makes the intended direction clear. Registration is not participation, and a long sequence of penalty records is no longer supposed to keep an established miner inside the affected challenge’s emission calculation.
Sources
Zeus v2.1.4 implementation commit
Zeus mining documentation at v2.1.4
Was this article useful?
One tap feedback helps us improve each post.
