The Miner Template
The miner template is what you publish for participants to run. It defines the interface miners must implement — the specific synapse types your subnet uses (request and response schemas), the port and axon configuration, and any baseline logic for handling queries. Miners customize this template to optimize their own performance, but they must conform to the interface you define.
A well-designed miner template is opinionated about interface and unopinionated about implementation. You specify exactly what the input and output formats must be, and you provide a reference implementation that demonstrates correct behavior — but you leave the internal model choice, hardware configuration, and optimization strategy entirely up to the miner. Over-specifying implementation details discourages innovation and reduces competitive diversity on your subnet.
The template should also include documentation on how miners are scored. Transparent scoring criteria let miners optimize in the right direction and reduce the likelihood that they game superficial metrics. The best miner templates are accompanied by a leaderboard or benchmark suite that lets miners evaluate their own performance before committing to mainnet registration.
The Validator Template
The validator template implements your scoring function and weight-setting logic. It is the most critical code you will write as a subnet owner, because it is the direct translation of your incentive design into on-chain behavior. Bugs in the miner template affect individual miners; bugs in the validator template affect every emission decision your subnet makes.
The core validator loop works as follows: query a sample of active miners each epoch, score their responses using your scoring function, normalize the scores into a weight vector (values between 0 and 1 that sum to 1 or less), and submit those weights to the chain via the Bittensor SDK. The Yuma Consensus algorithm then combines weight vectors from all validators to produce each miner’s final emission share.
Validator templates should be designed to be run by third parties without modification. The goal is a competitive validation market where multiple independent operators run your template and produce consistent, honest scores. A validator template that only works well when run by you — because it relies on private data, custom infrastructure, or undocumented assumptions — will struggle to attract the independent validators your subnet needs to reach consensus robustly.
Protocol Design
The protocol layer defines how validators and miners communicate. In Bittensor, this is built on top of synapses — typed request/response objects that are serialized over the network. You define the synapse types your subnet uses by subclassing the Bittensor SDK’s base synapse class and specifying the fields your task requires.
Protocol design decisions have downstream implications for performance, security, and composability. Larger synapse payloads increase bandwidth requirements and response latency. Poorly typed fields create ambiguity that miners may interpret inconsistently. Synchronous request/response works well for most tasks, but tasks that involve long-running computation may benefit from a streaming or asynchronous protocol.
Versioning your protocol from the start is one of the most important design decisions you can make. When you need to change request or response formats — and you will — a versioned protocol lets you migrate miners incrementally rather than forcing a hard cutover that disrupts active participants. Include a version field in every synapse type and handle version negotiation in both the miner and validator templates.
Use the official Bittensor SDK documentation for current interfaces and the migration reference when adapting a template built for an earlier SDK.
API and Integration Points
Many subnet owners want external consumers to be able to access their subnet’s outputs without running a validator. This is typically done by exposing an API gateway — a service that acts as a proxy between external clients and the subnet’s miners, handling the Bittensor protocol details transparently.
An API gateway gives you a commercialization path for your subnet: you can charge external consumers (via rate limits, API keys, or payment channels) while continuing to earn emissions from the on-chain side. It also provides a feedback loop — real external usage generates demand signals that help you calibrate your scoring function against actual use cases rather than synthetic benchmarks.
Building the gateway is optional but strategically important for subnets targeting production AI workloads. The gateway should expose a standard API format (REST or OpenAI-compatible for inference subnets) to minimize integration friction for external developers, and it should implement basic quality filtering to ensure only miners above a performance threshold serve external traffic.