Skip to content
Minotaur
Open app
+ 04 · Operator

Network Reference

Single source of truth for Subnet 112 operator-facing addresses, endpoints, and cluster expectations.

Single source of truth for operator-facing addresses and endpoints. Use this when configuring a new validator or miner against the live network.

Versioning: this page tracks the current mainnet state. When contracts get redeployed (e.g. the ValidatorRegistry-quorum migration), addresses change. Each entry below carries a “valid since” line so you can spot stale references.

Bittensor

ItemValue
Netuid112
Networkfinney
Subtensor endpointwss://entrypoint-finney.opentensor.ai:443
Public BT EVM RPChttps://lite.chain.opentensor.ai (chain 964)

Register a hotkey:

Terminal window
btcli subnet register --netuid 112 --subtensor.network finney \
  --wallet.name <YOUR_WALLET> --wallet.hotkey <YOUR_HOTKEY>

Production API

ItemValue
API endpointhttps://api.minotaursubnet.com
Frontend<PRODUCTION_FRONTEND_URL>

Miners pointing the agent loop at production use --validator-url https://api.minotaursubnet.com instead of http://localhost:8080.

Mainnet contract addresses

Addresses below reflect the post-quorum-refactor stack landed on 2026-05-21. ValidatorRegistry now holds the canonical quorumBps (single source of truth — AppIntentBase reads it at verification time, off-chain code reads it through ProtocolConfig.from_validator_registry). AppRegistry (introduced 2026-05-19) gates which AppIntentBase-derived contracts are accepted by validators and the relayer. All AppIntentBase-derived contracts were redeployed at the same time because their constructor signature changed. Verify any address against on-chain state before relying on it — cast call $VALIDATOR_REGISTRY 'quorumBps()(uint256)' should return a non-zero value on a current contract.

Base (chain 8453)

ContractAddressValid since
ValidatorRegistry0x88a08d1105393EACE9B6f5ff678DbE508B8639aC2026-05-21
AppRegistry0x0B5fE44e90515571761D86C28c4855F325EDE0982026-05-19 (state preserved across the 2026-05-21 refactor)
DexAggregatorApp0x0AeA6Ab70B384ADC6493d40e927ce53A7cefE0352026-05-21

BT EVM (chain 964)

ContractAddressValid since
ValidatorRegistry0x0B5fE44e90515571761D86C28c4855F325EDE0982026-05-21
ChampionRegistry0x33105027d03e76bf1F3679C0CB9b2688da383fb32026-05-21
AppRegistry0x80758D3Bf11715c82dB9964C634d5Fd8a0C58aBF2026-05-19

The string 0x0B5fE44e9... appears on both chains (Base AppRegistry, BT EVM ValidatorRegistry). They are independent contracts on independent chains — the deployer’s nonce happened to align across the two deploys. Different code at each address; the collision is purely cosmetic.

ChampionRegistry holds its own independent quorumBps for champion-certification consensus. The validator-side env var CHAMPION_QUORUM_BPS should mirror whatever cast call $CHAMPION_REGISTRY 'quorumBps()(uint256)' --rpc-url https://lite.chain.opentensor.ai returns (currently 6666).

Each chain’s AppRegistry address is now published on GET /v1/chains as app_registry_address (PR #553), so app deployers and frontends can read the gate without hardcoding it. The app-deployment, fee, and moderation env flags (ENABLE_PUBLIC_DEPLOYMENT, DEPLOY_FEE_*, APP_ADMIN_SIGNERS, REQUIRE_APP_ACTION_SIGNATURE, AUTO_REGISTER_APPS) are documented in the App-Management API reference.

Ethereum mainnet (chain 1)

The platform supports Ethereum mainnet execution, but the canonical DexAggregator deployment currently lives on Base. ValidatorRegistry on Ethereum mainnet TBD — operators running only Base do not need it; operators planning to support ETH-mainnet flows should ask before assuming an address.

Cluster expectations

MetricCurrent target
Active validator count3 (post-refactor migration may grow this)
Quorum threshold (quorumBps on ValidatorRegistry)6666 (2-of-3 BFT). Read live with cast call $VALIDATOR_REGISTRY 'quorumBps()(uint256)' --rpc-url $BASE_RPC.
Champion quorum (quorumBps on ChampionRegistry)6666 — mirror the on-chain value with CHAMPION_QUORUM_BPS
Tick interval12s (matches Ethereum block time)
Weight emission cadenceTempo-aligned by default (TEMPO_ALIGNED_EMIT=1, PR #524): one commit-reveal per tempo epoch, fired ~TEMPO_EMIT_LEAD_BLOCKS (20) blocks before the epoch step. The chain keeps only one pending commit per validator per tempo, so this replaces tuning --epoch-seconds for cadence. Set TEMPO_ALIGNED_EMIT=0 to fall back to the legacy wall-clock cadence (--epoch-seconds 1200).
ProtocolConfig refresh cadence60s — how often the daemon re-reads quorumBps and the validator set from ValidatorRegistry. Independent of weight emission.
Stake requirement for emissions(TBD — set by Bittensor subnet rules; check current metagraph output)

Onboarding handshake

New validators need their EVM signing address added to the on-chain ValidatorRegistry on every chain they operate on. See the validator quickstart Step 4 for the required information you send to the registry owner and the cast commands the owner runs to add you.

After the on-chain handshake, your daemon’s signatures count toward order-consensus quorum and your hotkey can be assigned to the leader role when stake rotation puts you on top.

Operational runbooks

Changing this page

This page is the authoritative network reference. When you redeploy a contract or update a production endpoint, update this page in the same PR. Don’t let it drift.