Question 1

What exactly do miners submit to Cascade?

Accepted Answer

Miners submit a deterministic generator—a Python class implementing the DataGenerator interface that yields synthetic time-series arrays. The generator is code-only (no shipped weights or data); it reads a seed and produces series by pure computation (parametric trends, seasonality, noise, or learned priors like GPs trained on-the-fly). The operator's trainer calls generate() to stream series during training, and the quality of that corpus determines how well the fixed Toto2-4M model learns. Submissions can be private (submitted directly to the operator's vault and kept private unless crowned) or public (pushed to a Hub repo).

Question 2

How is the winner of each round determined?

Accepted Answer

Every round, the trainer fits a fixed Toto2-4M forecaster from the same initialization on the king's and each challenger's generator data, within a fixed token budget (~3 hours). Validators then independently score both trained models on identical held-out real-world time-series windows, computing CRPS and MASE. A paired-bootstrap test (resampling windows) determines whether the challenger's geomean improvement over the king clears the round's margin (1% for a fresh king, decaying to 0.5% after 8 rounds of tenure). If yes, the challenger is crowned; if not, the king holds. This verdicts are deterministic: the eval windows are seeded by the block hash, the scores are recorded, and any validator can replay the bootstrap from the receipt.

Question 3

Why can't miners see the eval pool or memorize it?

Accepted Answer

The eval pool is private and rotates every round. Validators fetch a snapshot of real-world time-series selected by the epoch-boundary block hash, and a different slice is chosen for each round. Miners never see the windows or the scores, only their final win/loss verdict. The pool is stored in an owner-controlled bucket and mirrored to Cloudflare R2; only the eval-pool reference (a digest pin) is published in the signed manifest. Even if a miner somehow obtained a portion of the pool, the corpus they submit is frozen (its digest is pinned on-chain before training), so distribution-matching cannot occur—the generator's output is deterministic and immutable.

Question 4

Do validators need a GPU to participate?

Accepted Answer

No. Validators score trained checkpoints on CPU in under a minute per round using the recorded scores and running a paired-bootstrap verdict. If they want to run optional benchmarks (GIFT-Eval, BOOM, TIME) to feed the warm-start promotion pool, they can offload eval to an SSH GPU pod via --eval-hosts, but the core king-of-the-hill verdict and weight-setting happen on CPU. The manifest, signatures, and scores are the only dependencies—all publicly signed and content-addressed.

Question 5

What stops a miner from submitting the same generator twice or copying the king?

Accepted Answer

Generators are content-addressed by their OCI digest (repo@digest on Hippius Hub, or vault/direct@sha256:hash for private submissions). The earliest reveal of a digest owns it; a byte-identical copy by another hotkey is dropped before training. Copying the public king is legal but ineffective: the king's generator is published only after it wins, and by then the field has already moved on—submitting the same generator will not generate new, unseen data for the next round, and whatever advantage it had (if any) is likely spent. The competitive pressure is to beat the visible best, not to match it.

Question 6

How does warm-start promotion work, and why does it matter?

Accepted Answer

When a king holds the throne for 5 consecutive rounds, the trainer publishes a PromotionRecord naming up to 3 best duel checkpoints (picked by public benchmark score and error diversity) from that reign. These checkpoints become the next generation's shared warm-start init—every subsequent round's king and challenger both train from one of these three (rotated per round) instead of random init. This ratchets the floor: later data is selected to improve a lineage that already encodes prior winning data, so you win by finding regimes the lineage is weak on, not by re-teaching what it knows. After a promotion, the king persists (warm-start is not an advantage) and the throne only changes via a real dethrone verdict.

Question 7

What is the cost of submitting a generator?

Accepted Answer

Miners pay for their own training leg via a Lium API key. Each submission costs roughly 5 hours of GPU time (the training budget) plus ~1 hour of benching your checkpoint afterward. The exact cost depends on the GPU SKU chosen that round (most-available of RTX4090, RTX3090, L40S, L40, A6000). Miners should keep ~6 hours of GPU price on their Lium account (~$40–200 depending on SKU and provider). The reveal/commitment (on-chain) is free; only the training leg is metered.

Question 8

Can I submit multivariate (multi-channel) time series?

Accepted Answer

Yes, since block 9068400. Generators can yield (C, L) arrays with up to 32 coupled channels instead of univariate (L,) arrays. The budget is still per time-step (a C-channel series costs L points), so wider series train more tokens from the same budget. The wall (5 hours) remains fixed, so a very wide series that the round's GPU cannot train through in 5 hours will stop early under budget. Channels should be truly coupled (real cross-predictiveness), not independent stacked series. From block 9068400, eval windows are scored jointly (one C-channel window = one series, not C univariate scores).

cascade

cascade

Hardware Requirements

Hardware Requirements

Miner Setup

Validator Setup

Participate

Participate

Hardware Requirements

Hardware Requirements

Miner Setup

Validator Setup