Subnet 65: TAO Private Network
TAO Private Network (TPN) is Bittensor Subnet 65, a decentralized VPN. The subnet coordinates operators who offer VPN connections from a wide range of geographic locations, turning that connectivity into a service that end users can reach through the network. The incentive-mechanism code is maintained in the taofu-labs/tpn-subnet repository.
What the Subnet Provides
The subnet’s product is VPN connectivity with geographic breadth. A VPN’s usefulness depends heavily on having endpoints in many countries, so TPN’s incentive design rewards covering more locations, not just running more capacity in one place. End users connect through the network and reach the internet via an operator’s connection in their chosen location.
Roles and How Rewards Work
TPN is organized into three roles, which is what makes it unusual. Workers are simple machines that actually provide the VPN connections; they require no Bittensor neuron and are the role most participants run. Mining pools (the miners) aggregate the connections their workers provide, receive the subnet’s emissions, and decide how to pay out to the workers in their pool. Validators check the miners’ work and serve as the interface to end users.
According to the repository, a miner’s emissions scale linearly with the size of its worker pool and the geographic uniqueness of those workers, with a penalty for slowness — so coverage in under-served locations and a larger, responsive pool both matter more than raw concentration. Because there is no benefit to registering many miners, the design steers participants toward contributing workers. Validator scoring of pools turns into the weights that feed into Yuma Consensus, which converts them into the incentive split across miners and validators.
Worker Pool Context
The TPN README describes a three-role network: workers, miners, and validators. Workers provide the VPN connections and do not need a Bittensor neuron. Miners operate the mining pools that aggregate worker connections, receive subnet emissions, and decide how to distribute rewards to the workers in their pool. Validators validate miner work and act as the interface to end users.
That split is important because TPN does not treat every VPN endpoint as its own miner. A worker can contribute connectivity without registering directly on Bittensor, while a mining pool is the Bittensor-facing aggregation point. The design therefore separates endpoint operation from the on-chain miner role, which lets a pool represent many worker-provided VPN connections.
For readers, this is the main reason pool size and geographic uniqueness matter together. A large pool with many workers can increase coverage, but the README also emphasizes geographic uniqueness and reasonable response speed. Concentrating workers in the same kind of location is less useful than providing connections that widen the network’s geographic reach.
Reference: TPN README source
Validation and Sampling Context
The TPN litepaper describes the integrity model as challenge/response tests combined with randomized sampling. In the bootstrapping phase, validators host challenge endpoints, miners supply challenge responses, and the resulting score considers geolocation uniqueness, connection type, and response speed.
The public scoring code shows the same pool-oriented model in implementation terms. It reads worker-broadcast metadata for a mining pool, retrieves live workers, calculates a sample size, and selects workers for scoring. That supports the article’s interpretation that validator scoring is about sampled pool behavior, not just a miner’s static registration.
This also keeps the reward discussion grounded. TPN’s current README says miner emissions depend on worker pool size, geographic uniqueness, and a slowness penalty. The litepaper adds why those signals matter: validators need to encourage useful locations and connection types rather than letting every participant cluster in the same easy-to-host environment.
References: TPN litepaper, TPN scoring code
On-Chain Identity
Live SN65 data, including metagraph state and alpha token pool information, is available on TaoStats. The source-backed role and reward details in this article come from the public taofu-labs/tpn-subnet repository rather than from live index pages.
Relationship to Yuma Consensus
Subnet 65 uses Yuma Consensus to convert the pool-performance weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The Yuma Consensus documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In TPN’s context, validators score mining pools by sampling workers and evaluating geolocation uniqueness, connection type, and response speed through challenge/response tests. A miner’s emissions scale linearly with worker pool size and geographic uniqueness, with a penalty for slowness. Validators submit weight vectors reflecting those pool-performance scores. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Miner and Validator Roles
Subnet 65 operates under the standard Bittensor two-role structure. Miners supply the subnet’s capability and validators evaluate those contributions and set weights. Reward distribution follows Yuma Consensus.
Reader Boundary
Subnet 65 TAO Private Network should not be read as generic Bittensor subnet documentation, a single central VPN provider, or a claim that each VPN endpoint is an on-chain miner. The TPN materials describe a three-role system where workers provide VPN connections without running a neuron, mining pools aggregate many workers and receive emissions, and validators both score pools and interface with end users (TPN README source).
Rewards therefore follow sampled pool behavior and geographic uniqueness rather than raw endpoint count alone. Validator weights still flow through Yuma Consensus to determine emissions each tempo (Yuma Consensus, Emission).
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Subnet 65, that sequence applies to the standard Bittensor lifecycle: localnet for isolated development, testnet for shared non-production testing, and mainnet for live operation with real emissions.
On mainnet, Subnet 65 is registered as the live production subnet at netuid 65. The Bittensor Networks reference separates mainnet, testnet, and localnet. Participation examples or emission outcomes from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 65 TAO Private Network should not be read as generic Bittensor subnet documentation, a consumer VPN subscription, or a guarantee of anonymity, uptime, or jurisdiction. It names one subnet’s decentralized VPN market — operators provide geographically diverse connections in exchange for emissions — on netuid 65 (TPN repository, Understanding Subnets, Glossary: Netuid).
The subnet coordinates and rewards operator-supplied connectivity, so the article describes the incentive layer rather than a service-level or privacy commitment for any individual connection (Subnet 65 on TaoStats).