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:
| file | change |
|---|
config.json | augment.pad_prefix 0.05 → 0.25 |
generator.py:1812 | cut band size//8 .. 3*size//4 → 0.70*size .. 0.94*size |
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.
| setting | observed vs the king | LCB |
|---|
| 1h budget, parent B, seeds 1–2 | +1.37% | +0.29% |
| 1h budget, parent B, seeds 3–4 | +0.69% | −0.03% |
| 1h budget, parent A, 2 seeds | +1.27% | −0.10% |
| 1h budget, parent C, 2 seeds | +0.59% | −0.48% |
| 3h budget (dose 0.15 variant) | +1.20% | +0.09% |
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:
- 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.
- 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.
1python -m cascade.miner.cli verify submission # re-run the gate
2python -m cascade.miner.cli deploy submission \
3 --hub-repo <namespace>/<name> \
4 --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.
