cascade-test

cascade submission — cascade-pad25

cascade verify → OK: generator would be accepted by the trainer. corpus_digest (seed=0): 5655bfce3fde13ab… [deterministic]

What it is

A fork of the reigning generator (uid 81, jen12-xp) with one intervention. The entire diff against the incumbent is two lines:

Why

cascade/validator/windows.py:130 slices ctx = min(4096, L-64) and the trainer left-pads to 4096 with h[0]. Measured on a hash-verified retired eval snapshot:

• 91% of real eval windows arrive with a constant prefix ≥64 (median pad 84% of the context)
• the base generator emits only ~28% such rows
• its stock 12.5–75% cut band never reaches the >87%-pad regime that half the eval lives in

This is a train/eval input-geometry mismatch, not a claim about prior realism. That distinction matters: six separate attempts to make the corpus statistically resemble the pool were measured flat to −11.3%, including a full from-scratch generator that matched the pool better on every statistic and lost.

Measured performance

All on hash-verified retired eval snapshots, real paired cluster bootstrap, equal token budgets (wall lifted so every arm consumes identical tokens), warm-started from live promoted checkpoints.

Best arm on every seed measured. Realistic central estimate: +0.9–1.0% observed, LCB around 0.000 ± 0.004.

⚠️ Honest assessment before you spend the hotkey

HEAT (gate 1) — strong. In a rebuilt 8-way heat against real entrants from round 8809200 on that round's own pool snapshot, this ranked 1st on both seeds, beating the entrant that actually won that heat by 6.0–8.1%.

DUEL (gate 2) — short. The gate needs LCB ≥ 0.0200. This measures ~0.000. Across 27 historical duels, conversion efficiency (LCB ÷ observed) for generators that actually dethroned ran 0.52–0.70; ours runs ~0.08, because the gain sits in the low-leverage part of the pool.

The bootstrap resamples clusters, and cluster sizes are wildly unequal: 773 of 852 clusters hold ONE window — 40% of the data but 91% of the vote (leverage 2.28×) — while the 45 largest feeds are half the data and 5% of the vote. On singletons this generator beats the king on 60%; uid 81 beat uid 124 on 72% when it took the throne.

So: this is very likely to win the heat and very unlikely to win the duel. Submitting spends the hotkey's one lifetime entry ([round] one_submission_per_hotkey = true).

If you submit anyway

Two free choices materially change the odds:

1. Pick the parent. The same generator measured +1.37% against one rotation member and +0.59% against another. The manifest publishes warm_start_ckpt every round, and heat_status now publishes next_scheduled_init for the following round — so the parent is a lookup, not a guess.
2. Watch the field. Heat entrant counts have ranged 2–30 and winner-to- runner-up gaps 0.02%–4.48%. A thin field is a cheaper heat.

python -m cascade.miner.cli verify submission          # re-run the gate
python -m cascade.miner.cli deploy submission \
    --hub-repo <namespace>/<name> \
    --wallet-name <wallet> --wallet-hotkey <hotkey>

deploy re-verifies locally, pushes to the Hippius Hub, and commits the on-chain pointer with a timed reveal targeting just before the epoch boundary.