Under Bittensor, all mining occurs through subnets and their custom protocols. To mine HashTensor, a user must register a hotkey for SN16 (paying a TAO fee) and run a mining node. In practice, this involves running a Kaspa full node plus a Stratum mining adapter: the adapter turns the Kaspa node into a Stratum-compatible pool so that standard miners can connect. Once set up, miners solve Kaspa’s PoW puzzles via HashTensor’s system. Their performance is then evaluated by the subnet’s validators in each epoch – similar to other subnets – and emissions (TAO) are distributed accordingly. In effect, HashTensor’s “mining task” is Kaspa hashing, but rewards are paid out on Bittensor. The exact reward algorithm (how many TAO/alpha per hash or per block) has not been published. In general Bittensor terms:

Register and bind: Miners register a hotkey and obtain a SN16 UID, as per Bittensor’s registration flow. (The subnet has a limited number of slots; registrations use dynamic TAO burn logic.)

Mine Kaspa: Using HashTensor’s Kaspa-Stratum interface, miners contribute Kaspa hashpower. They run a Kaspa daemon and connect it to HashTensor’s mining adapter (likely on GitHub) so mining rigs can connect.
Serve and score: HashTensor’s validators use Bittensor’s scoring (weights) to rate miner contributions each epoch. High-performing miners earn a larger share of the subnet’s emission (in TAO and SN16 tokens).

Emission: Like other subnets, SN16 emits a fixed TAO rate per block (0.6% of total TAO supply initially), which is split among miners based on these scores. The exact “alpha” token mechanics (SN16’s native token) are not publicly detailed but presumably act as the miner reward currency inside the subnet.

Technical Architecture

The specific implementation of HashTensor is not fully documented, but it likely includes the following components and systems:

• Kaspa Full Node: A running Kaspa blockchain node (kaspad) that connects to the Kaspa network. HashTensor miners contribute work to this node’s mining jobs.
• Kaspa-Stratum Adapter: A custom service (presumably provided by HashTensor) that translates between Kaspa’s mining API and the Stratum mining protocol. This allows miners’ software to submit proofs of work to the Kaspa node as if it were a traditional mining pool.
• Bittensor Subtensor Client (Subnet 16): A modified Bittensor node (based on Subtensor) configured for netuid 16. This node implements the SN16 hyperparameters (difficulty, tempo, burn rates, etc.) and participates in Bittensor’s consensus (Yuma) to evaluate miner scores and issue rewards.
• Token Mechanics: HashTensor may have a native “alpha” token on SN16. This is likely implemented either on-chain (as an extra column of the ledger, as with SN14’s token) or via a burn mechanism. (SN14’s design issued SN14 tokens to miners; HashTensor presumably does the same with SN16/alpha, though details are unpublished.)
• Protocols: Uses Kaspa’s GHOSTDAG PoW for mining and Bittensor’s substrate chain for consensus. Kaspa mining uses the KHeavyHash algorithm; Bittensor consensus uses validators’ signed weight blocks. The Kaspa-Stratum adapter ties these together.
• Web and API: A HashTensor website and mining tutorial were launched in mid-2025, and a GitHub repo opened around that time, suggesting there is an accompanying front-end or documentation site (though content was not available to us).
• On-chain State: All relevant hyperparameters (min burn, difficulty, emissions, etc.) are stored on the Bittensor chain for netuid 16. (For example, SN16’s initial emission rate is 0.6% of TAO per block, as seen on explorers.)