Plaτform
SN100Collaborative AI research through parallel challenges where you compete and cooperate to advance AI
A subnet built as a platform, not a single product. Plaτform runs many isolated challenges under one master validator, with Docker-sandboxed evaluation and PBFT consensus deciding what counts as good work.
// Many challenges, one orchestration layer
Plaτform is a multi-challenge subnet on Bittensor. Instead of doing one task, it lets independent AI challenges run side by side under a shared orchestration layer that collects results from each one and submits a single set of weights to the chain.
The simple version: It is like a tournament platform. Each challenge is its own contest with its own rules and scoring. Plaτform is the venue that hosts them, tallies the results, and pays the winners.
Centralized equivalent: Closest parallel is Kaggle hosting competitions, except every contest runs in a sandboxed container and scoring is decided by a quorum of independent operators rather than a single platform owner.
How it works:
- Miners pick a challenge, package a solution as code, and submit it to the challenge through Plaτform's public proxy.
- Validators pull the challenge's Docker image, run identical evaluation containers on every submission, share scores, and reach agreement through PBFT consensus before pushing final weights to Bittensor.
- The problem it solves: Bittensor subnets usually do one thing. That makes adding new ideas slow, because each idea needs its own subnet slot. Plaτform turns that into a hosting problem: new challenges plug in without registering a new subnet.
- The opportunity: A working orchestration layer would let small teams ship an experiment to a real validator set without owning the full subnet stack.
- The Bittensor advantage: Sandboxed Docker evaluation plus PBFT means no single validator decides who wins a challenge, and no challenge author can directly mark their own miners.
- Traction signals: The repo pushed code yesterday and ships a working Helm chart, production policy, and Kubernetes validation flow. The Data Fabrication Challenge was announced for launch earlier this year. On-chain
active_minersreads 0 today, which is worth flagging.
Category: Inference and Compute | Centralized Competitor: Kaggle, Hugging Face Evaluate
Plaτform sits in an unusual position on Bittensor. Most subnets pick a vertical and optimize a single mining task. Plaτform's bet is that the harder problem is the platform itself: registry, sandboxing, weight normalization, and consensus between validators that do not trust each other. Each individual challenge becomes a tenant on top of that layer.
Mechanism:
A master process tracks which challenges are active and what emission share each one gets. Validators sync the registry, pull the configured Docker images for every active challenge, and run them locally. When a miner submits a solution to the Plaτform proxy, every validator runs the same evaluation container against that submission, scores it, and shares the result. The challenge's scoring logic stays inside its own container, so it can be anything from a coding benchmark to a data fabrication task.
Scores are then aggregated with stake-weighted averaging and a 2-sigma outlier filter, normalized across challenges, and mapped from miner hotkeys to UIDs. The master submits the final weights to Bittensor at each epoch boundary, roughly every 72 minutes. The about page describes a 2f+1 PBFT threshold and a 1,000 TAO minimum stake for validators participating in consensus.
The architecture explicitly separates concerns. The master runs PostgreSQL and the central registry. Each challenge keeps its own state (often SQLite). Production Helm values require external Postgres, semver-pinned images with sha256 digests, TLS verification on remote GPU targets, and an explicit deployment policy that rejects latest tags and insecure target lists. The codebase reflects an operator-first mindset: validation flows for Helm templates, kubeconform checks, and kind-based dry runs are all documented.
On-chain, the subnet trades at 0.01249 TAO with a market cap near 20,900 TAO and a 1.25% emission share (1.70% on the smoothed EMA). The pool holds 3,735 TAO of root liquidity, root_prop is 0.37, and the 7-day net flow is positive at roughly 338 TAO. Gini on the top 100 reads 0.72. The on-chain active_miners counter is 0 at the time of writing, even though neurons are registered against the subnet, which suggests miners are not currently responding to validator queries or the network is between challenge windows. Chain buys sit around 1.07% of emissions.
GitHub activity is high and concentrated. The PlatformNetwork/platform repo pushed code on 2026-05-21, has 41 commits attributed to a single contributor (echobt), and shows 160 stars and 15 forks. The recent commit log is dense with deployment-policy work: Helm hardening, Kubernetes broker routing, Docker orchestrator cleanup, CI validation gates, and security documentation updates. That pattern is consistent with infrastructure prep rather than a feature push.
- Single-contributor codebase: Public GitHub history attributes all 41 commits to one contributor. Internal contributors may exist who do not show up here, but the public bus factor is one.
- Zero active miners on-chain: TaoSwap reports
active_miners: 0while neurons are registered. This is a factual datapoint, not a verdict. It could reflect a transition between challenge windows, a registration phase, or low miner engagement. Worth watching. - Concentration: Gini coefficient of 0.72 on the top 100 suggests concentrated ownership or stake distribution. Large positions could move the pool significantly.
- Execution complexity: Multi-challenge orchestration with PBFT consensus, Docker sandboxing, and per-challenge state is more moving parts than a single-task subnet. The Multi-Mechanism Support feature is listed under future work in the official about page.
- Liquidity: Root pool depth of 3,735 TAO and 1-day total volume around 1,657 TAO mean any sizable position will face slippage on entry or exit.
Into the next one.
