Rolling coldkey-deduped meaningful-failure pool (S5.6 fix) - #102
Open
karpabot wants to merge 1 commit into
Open
Conversation
- The 10% meaningful-failure pool was split among only the CURRENT epochs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rolling meaningful-failure reward pool (§5.6 fix)
The 10% meaningful-failure ("informative dead-end") pool was split among only the CURRENT epoch's failures. With weight-set rate-limiting (~1 set / 20 min) a contributor earned for one brief window, then every quiet epoch re-asserted king=100% and dropped it — no sustained incentive (observed live: goodlucklucky dropped to king-only after one deferred set).
Fix
validator/mf_pool.py— a persisted rolling window (chain/meaningful_pool.json,RALPH_MF_WINDOW_BLOCKSdefault 7200 ~1 day, capped 128). Recent meaningful failures keep sharing the 10% until they age out.Sybil-resistant: the split is deduped by coldkey (one share per operator, most-recent hotkey wins). A single operator running many hotkeys (e.g. the star-dust9023 6-hotkey fleet just found on sn40) gets ONE share, not one-per-hotkey — it cannot farm the pool by spamming failures across hotkeys. Deregistered hotkeys are filtered out.
Wired into
run_epochbefore_apply_pool_split;RALPH_MF_ROLLING_OFF=1reverts to the old per-epoch split. Validator-only (unmeasured) -> plain resync, no measurement cutover.7/7 unit tests (rolling persistence across quiet epochs, ageing-out, coldkey sybil-dedup, deregistered filter, window cap). Verified live: a quiet epoch now keeps weighting a recent meaningful failure at 0.100 instead of dropping it.
Generated with Claude Code.