Skip to content
Minotaur
Open app
+ 00 · Getting Started

Introduction

Minotaur is a distributed intent execution platform on Bittensor Subnet 112 — App Intents, the OrderBook, the Solving Engine, dual scoring, and consensus.

Minotaur is a distributed intent execution platform on Bittensor (NETUID 112). Developers define App Intents — a Solidity contract paired with a JavaScript scoring module — and deploy them permissionlessly. Users submit orders to the Intent OrderBook, and the network’s Solving Engine generates optimal execution plans. Validators simulate plans on Anvil forks, apply dual scoring (JS + on-chain), reach off-chain consensus, and the Relayer submits approved plans on-chain.

Core Concepts

App Intents

An App Intent is a smart contract (inheriting AppIntentBase) paired with a JavaScript scoring module. The Solidity contract is immutable and enforces on-chain safety — invariants, user signature verification, and validator quorum checks. The JS module is hot-upgradeable and handles off-chain scoring via score(plan, state, context).

Each App declares its own intent functions. There is no global intent type taxonomy.

For swap execution, the canonical built-in app is DexAggregatorApp. The older SwapApp contract remains only as an example/legacy artifact and is not the active runtime path.

Intent OrderBook

The universal entry point for all intent execution. Users submit signed orders — either one-shot (execute once) or perpetual (execute every tick when score exceeds threshold). The highest-stake validator serves as OrderBook leader.

Solving Engine

A single Solving Engine handles all Apps across the entire network. Miners compete to write the best engine. Validators run the winning engine in sandboxed Docker containers to generate execution plans for pending orders.

Dual Scoring

Every plan must pass two independent scoring layers:

LayerLocationPurpose
JavaScriptValidator (off-chain)score(plan, state, context) validates the plan and emits the real per-order result (for swaps, the raw delivered output in wei)
SolidityOn-chain (AppIntentBase)Enforces invariants, gates execution via scoreIntent

Both layers must pass. Champions are then chosen by relative, per-order scoring — a challenger is compared to the current champion order by order (more delivered = better), not against an absolute number. Adoption resolves a fixed ladder: output (net better on breadth, regressions bounded to a 1% floor), then, on a fully-matched tie, gas → factorization → deadwood tie-breaks. See the miner champion/challenger model.

Consensus

The leader validator proposes a plan. Follower validators independently re-simulate and re-score. If both scores pass, followers sign with EIP-712. The leader collects N-of-M signatures. The Relayer submits the co-signed transaction on-chain.

Wallets

Users can connect their own wallet (MetaMask, any EIP-712 signer) or use a managed wallet (Lit Protocol MPC, 2-of-2 custody). No pre-deposit is required either way.

Fees

Platform fees are charged in the chain’s wrapped native token — WETH on Ethereum/Base, wTAO on Bittensor EVM (per AppIntentBase.wrappedNativeToken). Each App declares a [minPlatformFeeWei, maxPlatformFeeWei] band that clamps the per-execution fee. Users pay zero EVM gas — the Relayer fronts all gas costs.

How It Works

User submits signed order to OrderBook
        |
        v
Leader validator's Solving Engine generates plan
        |
        v
Plan simulated on Anvil fork (captures on-chain score + transfer events)
        |
        v
JS scoring engine evaluates plan (0.0 - 1.0)
        |
        v
BOTH scores must exceed threshold
        |
        v
Leader broadcasts proposal to follower validators
        |
        v
Followers independently re-simulate + re-score
        |
        v
Followers sign with EIP-712 if both scores pass
        |
        v
Leader collects N-of-M quorum
        |
        v
Relayer submits co-signed transaction on-chain
        |
        v
AppIntentBase.executeIntent() verifies quorum + user sig + executes via proxy

Documentation

Getting Started

Miner

Validator

API

  • App-Management API — Create, validate, deploy, and manage App Intents; wallet-signature auth model

Operator

Solver

Getting Started

The fastest way to explore Minotaur is with the local testnet, which starts the full stack (Anvil forks, subtensor, API, validator, relayer) in Docker. The miner agent runs on host via make miner-agent:

Terminal window
git clone https://github.com/subnet112/minotaur_subnet.git
cd minotaur_subnet
make testnet-up

Services available after startup:

ServicePortURL
API8080http://localhost:8080
Relayer8091http://localhost:8091
Anvil (ETH fork)8545http://localhost:8545
Anvil (Base fork)8546http://localhost:8546
Subtensor9944ws://localhost:9944

Stop with make testnet-down.

To run smoke tests against the live local testnet stack:

Terminal window
make test-testnet

This recreates a clean Docker Compose testnet, then validates service health, creates and deploys a fresh DexAggregatorApp through the real API path, checks faucet and balance helpers, and exercises live prepare and quote against that freshly deployed flagship app.

Testing

Use the Makefile targets as the canonical entrypoints:

Terminal window
# Quick confidence: unit + app tests
make test


# Full local regression sweep
make test-all


# Live Docker testnet smoke path
make test-testnet


# Mainnet-fork-only E2E path
make test-fork

Contributor note: DexAggregator-focused E2E tests should reuse tests/e2e/dex_test_helpers.py for token funding and approval, the current 9-field intent payload encoding, deployment recording, and the orderbook “submit then sign real order id” flow. That keeps the tests aligned with the current DexAggregatorApp ABI and execution path.

Current Status

Minotaur is in Alpha on Bittensor Subnet 112 (NETUID 112) with real mainnet execution. The flagship DexAggregatorApp is live on Base; Bittensor EVM and Ethereum follow within Phase 4. The permissionless deployment path — wallet-signature auth (no shared admin key), a once-per-app WTAO deploy fee, and permissionless-deploy / admin-gated-activation moderation — has landed and is gated behind go-live flags (ENABLE_PUBLIC_DEPLOYMENT); cross-chain settlement opens in Phase 5 (Jun 9, 2026). The champion miner’s submitter receives 100% of miner emissions (champion-takes-all); before a real miner-backed champion exists, emissions burn to the subnet owner. A challenger is adopted by relative, per-order scoring resolved on a ladder: net-better delivered output (regressions bounded to a 1% floor), then, on a fully-matched tie, gas / factorization / deadwood tie-breaks — not an absolute score. See ROADMAP.md for the phase-by-phase plan.

Getting Help

  • Check the troubleshooting guides for common issues
  • See the Solver Guide for writing custom solvers
  • Review CLAUDE.md in the repo root for the full architecture overview