SN20 is built on capabilities Bittensor already ships — multiple incentive mechanisms inside one subnet, native crowdloans, and leased subnet registration. This page shows how those pieces fit together, and is honest about the trade-offs.
This page describes current design intent, verified against Bittensor's chain code. Final parameters are being confirmed on testnet before launch — where a number would change a claim, we describe the structure rather than commit to a figure.
SN20 runs in two distinct phases. A team incubates inside SN20 — then graduates out into a subnet of its own. The mechanics of each phase are deliberately different.
Bittensor lets a single subnet run multiple independent incentive mechanisms — formerly called sub-subnets. SN20 uses this to host eight incubation teams at once, each on its own mechanism.
When a team is ready, a native Bittensor crowdloan funds the registration of its own full subnet — and the leased-subnet mechanics give backers a real, on-chain share of it.
Inside SN20, eight incentive mechanisms run side by side — each one a team's incubation slot. SN20's validators evaluate all eight at once.
SN20 doesn't need new protocol features. Every layer below is a capability that exists in the Bittensor chain today.
A Bittensor subnet can run several independent incentive mechanisms — each its own scoring model under Yuma Consensus. SN20 uses eight, one per incubation team. The protocol supports up to sixteen.
Miners and validators hold a single UID but can participate across every mechanism. Rizzo's validators score all eight incubation mechanisms at once — one validation operation, eight teams covered.
At graduation, a native Bittensor crowdloan pools TAO from backers to fund a new subnet registration. The dispatched call and target are locked at creation — backers can see exactly what they're funding.
Registering the new subnet via the leased-subnet path mints pro-rata emission shares to every crowdloan contributor — a real, on-chain claim on the graduate's owner emissions, paid continuously.
Every architecture has constraints. Here are SN20's, stated openly, with why each one is acceptable.
Mechanisms inside a subnet share one UID pool, so each incubation slot is compact. That's by design — a team incubating needs a focused proving ground, not scale. Scale comes after graduation, on its own subnet.
While incubating, a team funds itself by mining its own slot — not by an on-chain lease. The crowdloan and emission split happen at graduation, on the team's own subnet, where they belong.
SN20 introduces no custom chain code. It composes features Bittensor already ships and maintains. Nothing here depends on a protocol change landing — it's buildable today.
An incubator only works if the validation underneath it is real and always-on. SN20 runs on Team Rizzo's infrastructure — a team operating across all 128 subnets, on its own bare-metal hardware, maintained 24/7.
That's why the eight-mechanism model is feasible: running every incubation mechanism in parallel is demanding, and it sits on infrastructure already built to carry it.
The architecture is the structure. The flywheel is the economics that runs on top of it — and shows exactly who gains, and how.