The Minotaur validator is the backbone of Bittensor Subnet 112 — a distributed intent execution platform. Validators run the Solving Engine, simulate execution plans on Ethereum-/Base-/BT-EVM-forks via Anvil, score results through a dual-scoring system, and reach consensus before relaying approved transactions on-chain.

↳ NEXT · 01 Quickstart Six-step setup for a production third-party validator. ↳ REF · 02 Configuration Full CLI + environment variable reference. ↳ HELP · 03 Troubleshooting Common issues and solutions.

What Validators Do

Validators perform six core functions:

1. Run the Solving Engine

   Execute the champion miner’s solver code to generate execution plans for user orders in the Intent OrderBook.

2. Simulate on Anvil forks

   Plans are executed on local Anvil forks of each supported chain (Ethereum mainnet, Base, BT EVM), using snapshot/revert isolation so no real state is modified.

3. Dual scoring

   Every plan is scored twice. The JavaScript score (from the app’s JS scoring module, range 0.0–1.0) and the on-chain score (from contract simulation on the Anvil fork) must both exceed the configured threshold.

4. N-of-M consensus

   The leader validator proposes plans; follower validators independently re-simulate, re-score, and sign EIP-712 approvals. Exact score match is not required — followers sign if both scores pass their threshold. Default quorum is 6666 bps (2-of-3 BFT) read from on-chain ValidatorRegistry.

5. Weight emission

   Champion-takes-all model. The miner who submitted the currently active solver receives 100% of emissions via set_weights(). At Alpha launch only 5% of miner emissions are enabled, ramping as the network proves out.

6. Champion-consensus signing (api service)

   On the optional api side, validators re-benchmark the leader’s champion candidate inside a sandboxed Docker container and sign the certification if scores hold up.

Architecture

Leader / Follower Model

Validators operate in a leader/follower topology:

• Leader: The validator with the highest TAO stake on subnet 112. Ties broken by hotkey (lexicographic ascending). The leader runs the BlockLoop, processes all orders, and broadcasts proposals to followers.
• Followers: All other registered validators. They receive proposals from the leader, independently re-simulate and re-score each plan, and sign EIP-712 approvals if both scores pass threshold.
• Leader failover: When the leader changes (e.g., stake rebalancing), the Relayer drops all in-flight work. The new leader reprocesses everything from scratch.

+

Tip

Every validator must be leader-capable. Leadership rotates whenever stakes shift on chain. A validator that cannot immediately accept the leader role on stake change is a free-rider — it collects the same emissions as a fully-provisioned validator while only signing follower attestations.

BlockLoop Pipeline

The BlockLoop is the core runtime for validators, executing once per tick (default: every 12 seconds, matching Ethereum block time).

Each tick:

1. Expire stale orders

   Drop any orders past their deadline.

2. Snapshot open orders

   Pull all OPEN orders from the Intent OrderBook.

3. Process each order

   • Generate an execution plan (via the Solving Engine / miner solver)
   • Simulate the plan on an Anvil fork (captures on-chain score and token transfer events)
   • Run JS scoring (score(plan, state, context))
   • Both scores must exceed threshold (default: 0.5)
   • Broadcast proposal to follower validators for consensus
   • Collect N-of-M EIP-712 signatures
   • Submit the approved plan via the Relayer

4. Cross-chain orders

   Two-phase lifecycle — source leg execution, then BRIDGING status while the bridge transfer completes, then destination leg execution. (Cross-chain ships in Phase 5.)

Dual Scoring

Every execution plan is scored at two layers:

Layer	Where it runs	What it checks
JavaScript	Validator Node.js sandbox	App-defined scoring logic via score(plan, state, context). Reads simulation data including token transfers, gas usage, and state changes. Score range: 0.0–1.0.
Solidity	Anvil fork (simulated on-chain)	Contract-enforced invariants, user signature verification, validator quorum checks. Executed via ephemeral proxy (CREATE2) for state isolation.

+

Tip

Both scores must independently exceed the threshold. This prevents any single layer from being bypassed.

Intent OrderBook

The Intent OrderBook is the universal entry point for all intent execution:

• One-shot orders: Execute once and complete.
• Perpetual orders: Re-execute every tick when score exceeds threshold. No explicit trigger gate — validators try every tick.
• Orders are signed by users (EIP-712) and submitted to the OrderBook.
• The leader validator’s BlockLoop drains the OrderBook each tick.

HTTP API Endpoints

The canonical third-party validator stack exposes HTTP on two ports. Both must be reachable from the public internet so the current leader can deliver proposals.

Validator daemon — port 9100

Method	Path	Description
GET	/health	Service health, loaded intents, uptime
GET	/identity	Self-attested EIP-712 binding (evm_address, hotkey, axon_url) for peer discovery
GET	/intents/available	Active intents available for miners
GET	/intents/{app_id}/details	Detailed info for a specific app
GET	/intents/{app_id}/scores	Score history for a specific app
POST	/intents/{app_id}/submit	Accept a miner plan submission
GET	/weights	Current champion and weight mapping
GET	/weights/history	Historical weight emissions
GET	/blockloop/status	Block loop tick statistics
POST	/orders/submit	Submit an order to the OrderBook
GET	/orders	List orders in the OrderBook
POST	/apps/{app_id}/quote	Get a dry-run quote for an intent
POST	/consensus/proposal	Receive an order-consensus proposal from the leader (followers)
GET	/consensus/info	Order-consensus configuration and discovered peer info
GET	/leader	Leader status and metagraph info
POST	/reload	Reload app definitions from store

API service — port 8080

Method	Path	Description
GET	/health	Service health + champion-consensus state
GET	/identity	Same EIP-712 binding as :9100 (api-side peer discovery)
GET	/v1/apps/	List App Intents (read endpoint, no auth)
POST	/v1/apps/	Create an App Intent (gated by X-Admin-Key header when ADMIN_API_KEY is set)
POST	/v1/apps/{app_id}/deploy	Deploy an App Intent on-chain (admin-gated)
POST	/v1/submissions	Git/Docker miner submission (signature required)
POST	/v1/submissions/source	Inline source submission (queues straight to benchmarking)
POST	/v1/solver/round/consensus/proposal	Receive a champion-consensus proposal from the leader (followers)
POST	/v1/solver/round/certify	Submit a certified champion (leader-only)

!

Caution

Git/source solver submissions are served by the api service on :8080, not by the validator daemon on :9100. Miners must point --validator-url at the api port.

Entry Points

There are three ways to run a validator:

1. Canonical validator stack RECOMMENDED

Docker Compose with the daemon, the api service, and the three Anvil forks pre-configured. This is what a third-party validator runs in production:

terminal SH COPY

cd platform/validator
cp .env.example .env  # fill in every YOUR_* placeholder
docker compose --profile autoupdate up -d   # with Watchtower auto-update
# ── or ──
docker compose up -d                          # without

See the Quickstart for the full end-to-end setup including on-chain ValidatorRegistry onboarding.

2. Standalone validator daemon

Direct Python process, you bring your own Anvil + Subtensor connections. Useful for advanced operators who want systemd supervision instead of Docker:

terminal SH COPY

python -m minotaur_subnet.validator.main \
--port 9100 --epoch-seconds 1200

3. Local testnet DEVELOPMENT ONLY

Full Docker Compose stack including subtensor, Anvil forks, API, validator, miner, relayer, and frontend. For local development of the protocol itself, not for connecting to mainnet:

terminal SH COPY

make testnet-up

Requirements

• Python 3.12 with project dependencies installed
• Node.js 20.x for the JS scoring engine
• Foundry (anvil, forge, cast) for simulation and contract interaction
• Bittensor wallet with a registered hotkey on subnet 112
• Upstream RPC URLs for Ethereum (Alchemy/Infura), Base (Alchemy/Infura), and BT EVM (https://lite.chain.opentensor.ai)
• EVM private key for EIP-712 consensus signing (a fresh key — does not hold funds)
• On-chain ValidatorRegistry membership on every chain you operate on (manual handshake with the registry owner — see Quickstart Step 4)
• Sufficient TAO stake to participate in leader election

See the Quickstart for step-by-step setup and the Network Reference for current mainnet contract addresses.