Question 1

How does a miner submit a new solver to compete on Subnet 112?

Accepted Answer

Miners fork the canonical solver repository (`subnet112/minotaur-solver`), edit `solver.py` with their custom `IntentSolver` implementation, push to a branch, and open a PR. The `minotaur_subnet.miner.main submit` command takes the PR number and head SHA, signs it with the miner's registered hotkey, and submits it to the validator API. The validator then runs three screening stages (static checks, Docker build, smoke test) and benchmarks the solver against the current champion using real orders.

Question 2

What does it mean for a solver to be 'net better on breadth'?

Accepted Answer

Solvers are compared to the current champion order by order on Anvil forks at identical snapshots. A challenger is adopted if `(wins + blind_spot_covers) − regressions ≥ 1`, where a win is delivering strictly more output than the champion, a blind-spot cover is delivering output when the champion delivered nothing, and a regression is delivering less. Each tolerated regression must stay within a 1% per-order floor—cutting any order by more than 1% is a hard veto regardless of wins.

Question 3

How are plans scored before they are submitted on-chain?

Accepted Answer

Every plan is scored twice: (1) a JavaScript module defined by the App Intent runs `score(plan, state, context)` and returns a 0.0–1.0 validity score plus the real per-order result (e.g., raw delivered output in wei for swaps); (2) the plan is simulated on an Anvil fork of the destination chain, executing the on-chain `scoreIntent` gate to verify invariants and quorum checks. Both scores must exceed the app's threshold (default 0.5) for the plan to proceed to consensus.

Question 4

Can a validator run follower-only (without being the leader)?

Accepted Answer

Yes. During the early network operating period, leadership is locked to the subnet team's hotkey via a hardcoded constant. Third-party validators register their EVM signing address in the on-chain `ValidatorRegistry`, start their validator daemon, and automatically join as followers. Followers receive proposals from the leader, independently re-simulate and re-score plans on their own Anvil forks, and sign EIP-712 consensus messages if both scores pass threshold. Followers earn weight emissions; they do not run the BlockLoop or process orders.

Question 5

What happens if a miner's submission loses the benchmark comparison?

Accepted Answer

If the challenger does not beat the champion on the adopted ladder (output net-better on breadth, or on a fully-matched tie, cheaper on gas/factorization/deadwood), the submission is scored and ranked but not adopted. The miner receives a detailed per-order breakdown showing where they won, lost, and where the champion is blind. The miner can then optimize their solver, rebase their fork onto the current main (which always holds the champion's code), and resubmit.

Question 6

How does the network prevent a miner from seeing and copying another miner's solver before they earn from it?

Accepted Answer

Miners can use the private-repo submission path: they host their solver in a private GitHub repository, create a fine-grained PAT scoped to that repo (with Contents:Read and Pull requests:Read+Write), and submit with `--private-repo`. The validator clones the private code, benchmarks it, and posts the benchmark report to the private PR. If the submission wins, the validator publishes the solver to the canonical public main—leak-only-on-champion—so the miner has already earned before the code becomes public.

for sale

for sale

Hardware Requirements

Hardware Requirements

Miner Setup

Validator Setup

Participate

Participate

Hardware Requirements

Hardware Requirements

Miner Setup

Validator Setup