Subnet 100: Plaτform
Plaτform is Bittensor Subnet 100. Its on-chain identity registers the subnet as an auto-research network where miners compete against a synthetic benchmark.
What Plaτform Provides
The registered identity describes Plaτform as “an auto-research subnet where miners compete in multiple challenges to achieve top scores against a synthetic benchmark, driving continuous performance optimization.” The registered project website is platform.network and the codebase is the PlatformNetwork/platform repository, which defines the challenges in more detail than the on-chain identity alone.
Multi-Challenge Context
The Plaτform README describes the project as a multi-challenge Bittensor subnet platform. Instead of treating the subnet as one fixed task, Plaτform is built so independent challenges can run under a shared validator network. That makes the subnet closer to a challenge orchestration layer than to a single benchmark with one permanent scoring rule.
This structure changes what miners are competing on. A miner’s work is associated with whichever challenge is active or relevant, while the shared platform handles the surrounding routing, normalization, and weight publication. The public Plaτform website describes the same idea as a decentralized benchmark platform for multi-challenge miner benchmarks.
For readers, the useful distinction is that Plaτform separates the challenge from the subnet infrastructure. A challenge can define its own submissions, scoring data, and benchmark logic, while the Platform stack provides the shared control layer that lets validators collect challenge results and produce a subnet-level output.
Challenge Boundary Context
The challenge documentation describes each challenge as owning its own logic, public routes, submissions, scoring data, database schema, and local files. That makes a challenge the unit where task-specific competition happens. Plaτform’s role is to host and route those challenge-specific systems inside the larger subnet.
The architecture documentation describes separate control, worker, challenge-service, and weight-output responsibilities. The important point is that Plaτform divides control-plane work from evaluation work. Validators can use the platform to coordinate multiple challenge outputs rather than hand-building a separate subnet stack for each benchmark.
That division also explains why Plaτform’s identity emphasizes “multiple challenges” and a “synthetic benchmark.” The subnet is designed to keep adding or running challenge tasks while preserving a common path from miner submissions to validator scoring and published weights.
Weight Aggregation Context
The README and public website describe Plaτform’s weight path as the step that turns separate challenge results into one subnet output. Each challenge can score its own miner submissions and produce challenge-local hotkey weights. Plaτform then collects those weights, applies the configured emissions, maps miner hotkeys to Bittensor UIDs, and exposes the final vector that validators submit on chain.
This is the practical meaning of the subnet’s multi-challenge design. Challenge owners can define their own submissions, scoring data, state, and public miner experience, while the shared platform provides the registry, proxy, and weight orchestration around them. The final validator-submitted weights are therefore a normalized platform output, not a direct copy of any one challenge’s raw results.
For readers, this keeps the architecture simple to compare: challenges own the task-specific competition, and Plaτform owns the common path from challenge weights to Bittensor weights.
References: Plaτform README, Plaτform website
Miner and Validator Roles
Subnet 100 operates under the standard Bittensor two-role structure. Miners supply a capability — here research results scored against the benchmark — and validators evaluate those contributions and set weights. Reward distribution follows Yuma Consensus.
On-Chain Identity
The live Finney identity for netuid 100 registers the subnet name as Plaτform. The registered project website is platform.network, the GitHub repository is PlatformNetwork/platform, and a Discord server is recorded in the identity. Live subnet data is available on TaoStats.
Relationship to Yuma Consensus
Subnet 100 uses Yuma Consensus to convert the multi-challenge score weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The linked documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In Plaτform’s context, validators collect per-challenge miner scores, apply the configured emissions weighting, map challenge-local hotkey weights to Bittensor UIDs, and submit the aggregated weight vector on chain. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Plaτform (SN100), that sequence changes how readers should interpret multi-challenge auto-research competition examples and synthetic benchmark scoring outcomes.
In localnet, Plaτform-compatible miners and validators can be developed and tested in an isolated environment. Localnet challenge results and emission outcomes do not represent production subnet performance.
On testnet, Plaτform-compatible multi-challenge research workflows can be exercised in a shared, non-production network. Testnet benchmark results and validator weights are separate from mainnet subnet state.
On mainnet, Plaτform (SN100) is the live production subnet where miners compete across multiple challenges against a synthetic benchmark and validators aggregate challenge weights to determine real Bittensor emissions. The Plaτform repository describes the mechanism that applies on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A challenge result or emission outcome from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 100 Plaτform should not be read as generic Bittensor subnet documentation, a single fixed benchmark leaderboard, or proof that one challenge score maps one-to-one to subnet emissions. The Plaτform README describes a multi-challenge platform where independent challenges run under shared validator infrastructure.
Challenge Owners Define Task-Specific Competition
The challenge documentation states that each challenge owns its own logic, submissions, scoring data, and local state. Miner performance should be read within the active challenge context rather than assuming every challenge shares the same scoring rules or submission format.
Platform Weights Normalize Across Challenges
The platform materials describe collecting challenge-local hotkey weights, applying configured emissions, mapping hotkeys to Bittensor UIDs, and publishing a final vector validators submit on chain. Subnet weights are therefore a normalized platform output, not a direct copy of any single challenge’s raw leaderboard.
Validator weights still flow through Yuma Consensus to determine emissions each tempo (Yuma Consensus, Emission).