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 daemon reads it live from the on-chain contract (ChampionRegistry.quorumBps(), via ProtocolConfig) — there is no CHAMPION_QUORUM_BPS env var to set. Inspect the current value with cast call $CHAMPION_REGISTRY 'quorumBps()(uint256)' --rpc-url https://lite.chain.opentensor.ai (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 — read live from ChampionRegistry.quorumBps() on-chain (no env var to set)
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 1300).
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. Leadership is not stake-assigned: during the early-network period the leader is locked to the subnet team’s hotkey via LOCKED_LEADER_HOTKEY (with LOCKED_LEADER_EVM_ADDRESS pinning the signer), so a newly onboarded validator participates as a follower/signer and does not take the leader role by stake. Stake-based election applies only once the team clears the lock (announced ahead of time).

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.