Subnet 114: SOMA
SOMA is Bittensor Subnet 114, a subnet for decentralized AI tooling infrastructure. Its on-chain description is “AI solutions delivered through MCP infrastructure,” and the project site is thesoma.ai. The subnet’s goal is to make Model Context Protocol (MCP) servers a reliable, competitive service inside Bittensor, so that AI models can reach external tools, data sources, and execution environments through a standard interface. The codebase for the subnet is the DendriteHQ/SOMA repository, and the SOMA README source describes the subnet as a competitive environment for production-ready MCP services.
What SOMA Rewards
MCP is a standard way for an AI model to call out to external tools and data instead of relying only on what it already knows. SOMA turns the job of providing those tools into a rewarded competition: miners are paid for delivering MCP services that are highly available, fast, and high quality.
Rather than running one fixed task forever, SOMA defines a competition target that miners work to solve, and that target rotates over time. Any problem that can be meaningfully solved with an MCP server, and that measurably improves how well an AI agent performs, can become the active target. At the time of writing the current competition focuses on compressing an agent’s chain-of-thought context, with the aim of lowering inference cost and speeding up responses while preserving the reasoning quality. The subnet rewards the submissions that solve the active task most effectively.
MCP Service Context
SOMA’s public materials treat MCP servers as a service layer for AI agents. The point is not simply to publish a tool catalogue; it is to make external capabilities available through interfaces that agents can use reliably while they reason, retrieve data, call APIs, or coordinate execution. In that setting, service quality is part of the product. An MCP service that is theoretically useful but slow, unavailable, or inconsistent is less valuable to an agent workflow than one that responds predictably under real use.
Availability, latency, and quality are reward-relevant because they determine whether an MCP service can be trusted inside an agent workflow. SOMA turns useful agent tooling into a competitive subnet market: miners improve the active MCP task, validators measure the submitted work, and the platform provides the coordination layer around registration, orchestration, and evaluation. The result is closer to a market for dependable agent infrastructure than to a static library of integrations.
Competition Pipeline Context
The active task can change, but SOMA’s competition structure gives the subnet a recurring pattern. Miners submit solutions for the current target, screening filters out unstable or technically incorrect submissions, and qualified solutions are evaluated under the live competition criteria. This keeps the reward signal tied to the current task while still giving miners a predictable way to iterate.
For readers, the important distinction is that SOMA rewards the usefulness of a submitted MCP solution in context, not just the existence of code. A context-compression solution, for example, is valuable only if it helps an agent preserve useful reasoning while reducing cost or response time. That is why the subnet’s platform and validator roles focus on task-specific evaluation rather than generic service registration alone.
Miner and Validator Roles
Miners design and implement a model or algorithm that solves the active MCP task as well as possible, then upload it to the subnet’s platform under a hotkey registered on netuid 114. The platform handles orchestration, so a miner’s main job is the quality of the solution itself rather than running the surrounding infrastructure.
Validators score those submissions. They retrieve the execution results for each miner’s solution from the platform, judge how well it meets the active competition criteria, and report those scores back so that network weights can be set. That weighting is how reward flows through Yuma Consensus. At the article level the split is straightforward: miners supply the solutions, while validators decide how good each one is and weight it accordingly.
Competitions run on a recurring cycle with a window for miners to submit their work, a screening stage that checks submissions for correctness and baseline quality, and a live phase where qualified solutions are evaluated and ranked. The recurring structure is designed to reward sustained performance and continuous improvement rather than a one-time result.
Source and Live Data
The public project site is thesoma.ai, and the codebase is maintained in the DendriteHQ/SOMA repository. Live SN114 subnet data is available on TaoStats. The mechanism context in this article is tied to the project site and public README rather than to live identity fields alone.
Relationship to Yuma Consensus
Subnet 114 uses Yuma Consensus to convert the MCP-solution quality weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The Yuma Consensus documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In SOMA’s context, validators retrieve execution results for each miner’s MCP solution from the platform, score those results against the active competition criteria, and translate those quality assessments into weight vectors for the subnet. 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 SOMA (SN114), that sequence changes how readers should interpret MCP service competition examples and task-based scoring outcomes.
In localnet, SOMA-compatible miners and validators can be developed and tested in an isolated environment. Localnet MCP service evaluation results and emission outcomes do not represent production subnet performance.
On testnet, SOMA-compatible MCP solution submission workflows can be exercised in a shared, non-production network. Testnet competition scores and validator weights are separate from mainnet subnet state.
On mainnet, SOMA (SN114) is the live production subnet where miners submit MCP solutions for the active competition task and validators score their quality to determine real Bittensor emissions. The SOMA repository describes the mechanism that applies on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. An MCP service evaluation result or emission outcome from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 114 SOMA should not be read as a static MCP integration catalogue or as proof that publishing any tool wrapper earns weight. The SOMA README describes a competitive environment for production-ready MCP services where miners solve an active task and validators score submitted execution results.
Rotating Competition Targets, Not a Fixed MCP Catalogue
The same README explains that the competition target rotates over time and that any problem solvable through an MCP server can become the active target. Readers should not treat one historical task, such as chain-of-thought context compression, as the permanent definition of what SN114 rewards.
Screened Execution Results, Not Registered Code Alone
The README’s competition pipeline includes screening for unstable or incorrect submissions before qualified solutions are evaluated under live criteria. A registered MCP repository or hotkey alone does not substitute for platform execution results that validators score against the current task.
Validator weights still flow through Yuma Consensus to determine emissions each tempo (Yuma Consensus, Emission).