Subnet 112: Minotaur
Minotaur is Bittensor Subnet 112. Its on-chain description is “Distributed DEX aggregator and swap intent solver engine,” and the project site is minotaursubnet.com. The subnet’s purpose is to take a swap request expressed as an intent — a desired outcome such as “exchange one token for another on the best available terms” — and have the network compete to find and carry out the best way to fill it. The codebase for the subnet is subnet112/minotaur_subnet, and the Minotaur README source describes the subnet as a distributed intent-execution platform.
What Minotaur Rewards
An intent describes what a user wants to happen rather than the exact steps to get there. Minotaur rewards miners for building the solving logic that turns those intents into good executions: finding the best route for a swap, matching orders directly when buyers and sellers line up, and pulling on outside liquidity sources to fill the rest.
Rewards are aligned around the quality of the outcome for the user. The main thing that wins is a better effective price on the swap while respecting the limits the user set, with correctness and efficient execution treated as secondary considerations. Because solvers compete continuously, the network keeps converging on better execution over time rather than settling on a fixed strategy.
Intent Execution Context
Minotaur separates the user’s desired result from the route used to achieve it. A user or agent can express an intent, and the solver market searches for an execution plan that satisfies the outcome constraints. This is different from a fixed swap interface where the user chooses a route in advance: the subnet’s competitive work is deciding how the intent should be filled.
At a high level, the supported solver work is route optimization. A solver can search across available liquidity sources, compare possible paths, and produce a plan that aims to satisfy the user’s constraints on better terms. The miner’s product is optimization logic for the intent, not liquidity ownership by itself.
App Intent Context
The README describes Minotaur around app intents: requests that combine a desired outcome with the rules used to score whether that outcome was satisfied. The public website presents the same idea in user-facing terms, saying a user declares an intent and Minotaur searches for the best route across chains, decentralized exchanges, and protocols. Read together, the sources frame an intent as more than a swap form. It is the object that tells the subnet what result should be optimized.
This matters because the subnet’s competitive work happens before execution is finalized. Miners are not rewarded for merely listing a possible route. They compete to produce the solving engine that can turn the app intent into a better execution plan, while validators check whether the proposed plan actually satisfies the intent’s scoring rules and constraints. The useful output is therefore a verified execution plan, not just a quote.
The README also explains why Minotaur can cover more than one swap path. It describes direct matching, routing through outside liquidity sources, and arbitrage legs when those legs improve the user’s outcome. That gives the subnet a broader role than a single decentralized exchange frontend: it is trying to select among execution strategies while keeping the intent’s requested result at the center of the scoring process.
The README’s “champion” language also helps explain the miner role. Miners are competing over the best current solving engine, not over isolated route suggestions that disappear after one request. When a better engine outperforms the current one, the network can favor that engine for future intent solving. Validators still provide the shared checking process, so claimed route quality does not become the reward signal unless the plan passes validation.
For readers, the important distinction is that Minotaur separates the desired financial outcome from the mechanics used to reach it. A user-facing app can express the outcome, but the subnet competition is over the solver logic that makes the outcome better, valid, and reproducible. That is why the article treats Minotaur as an intent-execution subnet rather than simply another liquidity venue.
References: Minotaur README, Minotaur website
Verification Context
Minotaur’s validator side exists because an intent solver has to be checked before its plan can be trusted. A plan is useful only if it satisfies the user’s constraints, produces a valid execution result, and passes the subnet’s validation process. Validators simulate plans, score results, and reach agreement before treating the result as valid.
This keeps the reward loop tied to execution quality instead of to a miner’s claimed route quality. Miners compete to improve the plan generated for an intent, while validators make sure the proposed route can actually satisfy the task’s constraints. The reward signal is therefore tied to verified execution quality and constraint satisfaction.
Miner and Validator Roles
Miners write and continuously improve the solving software that decides how each intent should be filled. They compete on how good their solutions are, and the strongest-performing solver becomes the one the network actively uses, so a miner earns by writing the engine that produces the best results. A registered hotkey on netuid 112 is what ties a miner’s work back to them.
Validators provide the execution and checking environment. They take the pending intents, run the leading solver to produce an execution plan, and simulate that plan in a controlled setting to confirm it is valid and meets the required standard before anything is finalized. Validators reach agreement on the result, score miners on how well their solver performed, and set weights on the network, which is how reward flows through Yuma Consensus. At the article level the split is straightforward: miners supply the solving logic, while validators run, verify, and weight it.
Source and Live Data
The public project site is minotaursubnet.com, and the codebase is maintained in the subnet112/minotaur_subnet repository. Live SN112 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 112 uses Yuma Consensus to convert the solver-performance 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 Minotaur’s context, validators simulate swap intent execution plans, score miners on how well their solver engines satisfy intent constraints, and translate those results 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 Minotaur (SN112), that sequence changes how readers should interpret swap intent-solving competition examples and validator-simulated scoring outcomes.
In localnet, Minotaur-compatible miners and validators can be developed and tested in an isolated environment. Localnet intent execution results and emission outcomes do not represent production subnet performance.
On testnet, Minotaur-compatible solver and DEX aggregation workflows can be exercised in a shared, non-production network. Testnet simulation results and validator weights are separate from mainnet subnet state.
On mainnet, Minotaur (SN112) is the live production subnet where miners develop swap intent-solving engines and validators simulate and score execution plans to determine real Bittensor emissions. The Minotaur repository describes the mechanism that applies on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. An intent execution result or emission outcome from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 112 Minotaur should not be read as a single decentralized exchange frontend or as proof that an unaudited route quote earns weight. The Minotaur README describes a distributed intent-execution platform where miners compete over solving engines and validators verify plans before they become reward evidence.
Quotes Are Not Verified Execution Plans
The same README frames app intents as outcomes plus scoring rules, with validators simulating proposed plans to confirm they satisfy constraints. A displayed swap quote or route suggestion does not substitute for a validated execution plan that passed the subnet’s checking process.
Champion Solvers, Not One-Off Routes
The README’s champion language describes miners competing over the best current solving engine rather than isolated route suggestions that disappear after one request. Validator weights follow simulated, constraint-satisfying execution quality rather than miner-claimed route quality alone.
Validator weights still flow through Yuma Consensus to determine emissions each tempo (Yuma Consensus, Emission).