Loading...
Loading
Overview
Registration Activity
Neuron registration trends
This Interval
0
— burn · — PoW
Target / Interval
Loading
Neuron registration trends
Training time-series foundation models requires large volumes of high-quality synthetic data, but generating effective priors is expensive and the signal from any single dataset is noisy. The quality of synthetic training data—not model architecture—determines forecasting performance, yet there is no mechanism to systematize and reward its improvement. Cascade makes data quality itself the competition by holding the model, training process, and evaluation constant while miners compete on their generators' output. Each round, a deterministic generator is scored by training a fixed Toto2-4M forecaster from the same initialization on its corpus and measuring the resulting model's performance (CRPS and MASE) on a private, rotating held-out eval set. The generator whose data trains the best forecaster wins the throne and receives subnet incentives. Cascade runs on Bittensor subnet 91 with 12-hour rounds. Miners submit generators either privately (code stays in the operator's vault, published only if crowned) or publicly (pushed to Hippius Hub). Each submission is funded by the miner's own Lium API key, which pays for the training pod. Validators independently verify the trainer's signed manifest, score the king and challenger on identical windows, run a deterministic paired-bootstrap verdict, and set weights. Because seeds derive from block hashes, corpus digests are deterministic, and the contract is pinned on-chain, every round is fully auditable—any second trainer can re-run the corpus, re-train the model, and verify the checkpoint byte-for-byte.
Use cases were auto-generated from the GitHub repository and may not reflect the latest changes.
Cascade is a Bittensor subnet where miners compete on synthetic time-series data quality. Miners submit deterministic generators that produce training data; the operator trains a fixed Toto2-4M forecaster on each generator's data and scores the resulting model against the reigning king on private, rotating held-out windows using CRPS and MASE metrics. The generator whose data trains the best forecaster wins the throne and shares weights.
Validators independently score the trained models, verify signatures and digests, run the king-of-the-hill verdict via paired bootstrap, and set weights. Everything is auditable: seeds derive from block hashes, corpus digests are deterministic, and the contract is pinned on-chain.
Cascade splits into three roles: (1) Miners write DataGenerator subclasses (code-only, no shipped weights) that yield synthetic time-series. They submit via cascade submit (private vault) or cascade deploy + cascade fund (public Hub repo), funded by their own Lium API key. (2) Trainer (owner-operated) reads on-chain commitments, resolves the king and challenger field, derives seeds from the epoch-boundary block hash, and trains a fixed Toto2-4M backbone from random init (or cascade warm-start) on each generator's streamed data within a fixed token budget (~3h under 5h wall). One RoundSeeds instance seeds all runs (king, heat, finalists, all sizes) so only the generator varies.
Checkpoints are pushed to Hippius Hub OCI registry and signed into a TrainingManifest on S3. (3) Validators read the manifest, verify signatures and contract digests (controlled-experiment gate), score king and challengers on identical private eval windows using CRPS+MASE, run a paired-bootstrap king-of-the-hill verdict, and set weights. The manifest, checkpoints, and signatures are all content-addressed or digest-pinned; seeds and verdicts are deterministic from block hash and recorded scores, making every round auditable. Cascade promotion: when a king holds 5 rounds, up to 3 best duel checkpoints (by public benchmark geomean, within 5% diversity window) become the next generation's warm-start init, announced in a trainer-signed PromotionRecord.
This information was auto-extracted from the GitHub repository and may be incomplete or out of date. Always refer to the subnet's GitHub repository for the latest instructions.
All training is from-scratch at generation 0; once promotions fire, later generations warm-start from a shared lineage init. GPU pods are rented on miner-supplied Lium keys per round, or locally if no pods are available. Validators can offload eval to SSH GPU pods via --eval-hosts but don't need GPU for the core verdict.
The whole system is designed to make data quality the sole competitive variable while keeping the controlled experiment airtight: identical model, identical init, identical training contract, identical seeds—only the corpus differs.
Each round: (1) Field: revealed commitments seat in reveal order up to a cap, all funded by the miner's own Lium key. (2) Training: king and every challenger train the full budget (~5h, enforced as fixed token count) on the same GPU type, from the same shared init (random at generation 0; cascade warm-start once promotions fire), with identical seeds. Only the generator differs. (3) Manifest: trainer signs checkpoints and digests to S3. (4) Verdict: validators score king and challengers on identical private windows (geomean of CRPS and MASE over 64/256/720-step horizons), pool scores across sizes, and decide via paired-bootstrap LCB. The margin is 1% against a fresh king, decaying to 0.5% over 8 tenure rounds. (5) Bench: each checkpoint benchmarked on GIFT-Eval / BOOM / TIME for public telemetry and cascade promotion.
Cascade: when a king holds 5 consecutive rounds, up to 3 best checkpoints (within 5% of the reign's best, decorrelated by error) become the next generation's shared init; no downgrade guard ensures promotion never ratchets backward. Weights follow geometric decay across the lineage.
The sections above were auto-generated from the GitHub repository and may not reflect the latest changes. View repository
SOTA Time Series Foundation Models
FAQs were auto-generated from the GitHub repository and may not reflect the latest changes.
Holder & total-staked metrics as of 1h ago (hourly snapshot)
Miners only write Python code; GPU training is done by the operator. Miners pay for their own training leg via Lium API key. Keep ~6 hours of GPU cost on the Lium account (~5h training + ~1h benchmarking).
CPU is sufficient for validator operation. GPU is optional and only needed for optional benchmark evaluation or gift-gate enforcement via --eval-hosts for SSH GPU pods.
Clone the cascade repository
git clone https://github.com/TensorLink-AI/cascade && cd cascade
Install cascade with hippius (storage/registry) and chain (bittensor) extras. Uses bittensor==10.5.0 exactly.
pip install -e '.[hippius,chain]'
Verify your generator passes all checks: determinism, imports, dependencies, output shape, bounds
cascade verify ./my-generator
Register wallet and hotkey for your submission
btcli wallet new-coldkey --wallet-name my-miner && btcli wallet new-hotkey --wallet-name my-miner --wallet-hotkey gen1
Register the hotkey on subnet netuid 91 (mainnet)
btcli subnets register --netuid 91 --network finney --wallet-name my-miner --wallet-hotkey gen1
Submit your generator privately (recommended) or use 'cascade deploy' + 'cascade fund' for public submission. LIUM_API_KEY environment variable only, never as argument.
export LIUM_API_KEY=sk-... && cascade submit ./my-generator https://submissions.cascadesub.net --wallet-name my-miner --wallet-hotkey gen1 --label my-gen-v1
Monitor your submission in the queue; rounds run every 12 hours at ~08:30 and 20:30 UTC(optional)
cascade queue --intake https://submissions.cascadesub.net --hotkey <your-ss58>
Check round countdown, dethrone bar, and settled verdict with scores(optional)
cascade round && cascade duel
Clone the cascade repository
git clone https://github.com/TensorLink-AI/cascade && cd cascade
Install cascade with hippius (storage/registry) and chain (bittensor) extras. Uses bittensor==10.5.0 exactly.
pip install -e '.[hippius,chain]'
Set environment variables for manifest bucket (S3) and Hippius Hub registry access. Credentials-only, never in files.
export HIPPIUS_S3_ACCESS_KEY=... HIPPIUS_S3_SECRET_KEY=... HIPPIUS_HUB_USERNAME=... HIPPIUS_HUB_PASSWORD=... (or HIPPIUS_HUB_TOKEN=...)
Create validator wallet and hotkey
btcli wallet new-coldkey --wallet-name my-validator && btcli wallet new-hotkey --wallet-name my-validator --wallet-hotkey default
Register on subnet 91 (mainnet). Need stake above threshold for weight-setting.
btcli subnets register --netuid 91 --network finney --wallet-name my-validator --wallet-hotkey default
Smoke test with zero chain/GPU I/O to validate configuration(optional)
cascade-validator --offline --chain-toml chain.toml
Run the validator loop. Keep under a process manager (systemd/tmux). It resumes cleanly from persisted state.
cascade-validator --chain-toml chain.toml --network finney --wallet-name my-validator --wallet-hotkey default
Verify your rounds with offline audit (Tier 0), corpus verification (Tier 1), or full retrain (Tier 2, experimental)(optional)
cascade-audit latest --tier 1 --json
