With the amount of new subnets being added it can be hard to get up to date information across all subnets, so data may be slightly out of date from time to time
Tensor Private Network (TPN) is a decentralized VPN-like network aimed at providing secure, private, and globally diverse internet access within the Bittensor ecosystem. In essence, TPN coordinates a distributed network of nodes around the world (effectively community-run VPN servers) to offer censorship-resistant connectivity. Its primary purpose is to serve as an anonymous, decentralized VPN service that can be used by both machines and people, leveraging Bittensor’s blockchain incentives to reward those who contribute connectivity.
By operating as a Bittensor subnet, TPN extends the ecosystem beyond AI model sharing into the realm of privacy and networking, creating a new digital commodity (private internet access) within the Bittensor marketplace. Community members have described TPN as “a decentralised anon VPN product” expected to offer both residential and business VPN services, underlining its goal of catering to everyday internet users as well as organizations.
Tensor Private Network (TPN) is a decentralized VPN-like network aimed at providing secure, private, and globally diverse internet access within the Bittensor ecosystem. In essence, TPN coordinates a distributed network of nodes around the world (effectively community-run VPN servers) to offer censorship-resistant connectivity. Its primary purpose is to serve as an anonymous, decentralized VPN service that can be used by both machines and people, leveraging Bittensor’s blockchain incentives to reward those who contribute connectivity.
By operating as a Bittensor subnet, TPN extends the ecosystem beyond AI model sharing into the realm of privacy and networking, creating a new digital commodity (private internet access) within the Bittensor marketplace. Community members have described TPN as “a decentralised anon VPN product” expected to offer both residential and business VPN services, underlining its goal of catering to everyday internet users as well as organizations.
TPN’s design mirrors the typical Bittensor subnet structure with two types of nodes: miners and validators. The miners in Subnet 65 run the infrastructure that actually provides VPN connections or performs web requests, and they are rewarded in the network’s token for delivering reliable service. The validators act as the coordinators and gatekeepers – they interface with end-users or requesting agents, distribute tasks to miners, and verify that miners perform those tasks correctly. In other words, validators send work (e.g. data fetch requests or connection challenges) to the miners, then evaluate the responses to decide how to allocate rewards (via weight assignments) to the miners.
Privacy and Data Routing
The core idea is to route user traffic or data requests through this decentralized network of miners (similar to how a VPN or proxy works) with encryption and anonymity. In future iterations, a user or application will ask a TPN validator for a connection or for content; the validator then selects an appropriate miner node (e.g. based on location or performance) and facilitates an encrypted tunnel or request through that miner. Because each miner is independently operated and geographically distributed, TPN can offer a wide range of IP endpoints across different countries and networks. This makes it hard for any content host or government to censor or blacklist the service as a whole. Unlike traditional VPNs which often use known data-center IP ranges, TPN’s nodes are incentivized to run on diverse connection types – including residential networks – to blend in with normal internet traffic. This diversity means content providers cannot easily identify and block TPN nodes, preserving access to region-locked or censorship-prone content.
Challenge-Response Mechanism
In its current implementation, TPN emphasizes a proof-of-location and responsiveness scheme to bootstrap the network. Validators continually issue random challenge requests to miners to ensure they are operational and located in unique network zones. For example, a validator might instruct a miner to fetch a small file from a test URL (the “challenge”) that contains a secret key. The miner must open that URL and return the secret within it back to the validator. By doing this, the validator can verify two things: (1) the miner is actually online at a certain IP address (since the request comes from that IP), and (2) the miner’s network location (IP geo-location and type) and response speed. Miners that respond with the correct secret quickly and from unique locations (e.g. under-represented countries or residential IPs not already covered by others) will score higher. This challenge/response approach ensures the subnet self-organizes into a globally distributed network rather than a cluster of nodes all in one region. It prevents miners from concentrating in a single cheap cloud provider, which would undermine TPN’s purpose of diverse endpoints. Validators use these tests to continually rank miners and adjust their stake “weights” accordingly, so that well-performing, uniquely positioned miners earn more rewards. All communication for challenges and responses happens over encrypted channels, and miners are expected to run secure connection software (like VPN daemons or proxy servers) as part of their node stack.
Data Requests and VPN Tunneling
TPN’s functionality will expand in stages. In upcoming phases, validators will expose an API for users to request arbitrary URLs or data through the network. For example, a user (which could be an AI agent or a regular user via an application) might ask a TPN validator to fetch a web page. The validator will forward this request to one of the miners (or a set of miners), which will then retrieve the content and return it. Validators will cross-verify responses (e.g. by random spot-checks or comparing across miners) to ensure miners aren’t tampering with or failing to fetch the data.
Later, the network plans to support advanced web interactions – not just simple HTTP GET requests, but complex page interactions. Under this model, a user could specify a script of actions (like clicking buttons, waiting for dynamic content to load, filling forms) and the miner would execute it in a headless browser environment. This is crucial for scraping or accessing modern web content that requires JavaScript execution or login steps. The miner essentially acts as a remote browser. All such interactions remain privacy-preserving for the end-user, since the requests originate from the miner’s machine/IP, not the user’s, and any sensitive data can be transmitted securely over the encrypted channel between the user and validator/miner.
Finally, in the fully realized VPN stage, TPN will enable users to establish actual VPN tunnels through the miners. In this scenario, a user’s device might request a VPN connection to, say, country X. The validator will identify a miner in the requested region, perform a quick challenge to ensure that miner is up and has the desired characteristics, and then obtain a VPN configuration file or credentials from that miner. The user can then use that config to open an encrypted VPN tunnel directly to the miner node, effectively routing all of the user’s internet traffic through that node (just like a standard VPN service). TPN’s design even envisions allowing sophisticated usage like rotating between multiple miners: for instance, a user could specify they want their exit IP to change every 5 minutes or cycle through a set of countries. This would be handled by the validators/miners coordinating to hand off connections or issue new config files periodically. Throughout these operations, strong encryption (likely using well-established VPN protocols) would protect the data in transit, such that neither eavesdroppers nor the miners themselves can see or alter the content of the user’s traffic. The end result is a highly flexible, decentralized private network that users (and applications) can tailor to their needs for privacy, web scraping, avoiding geo-blocks, etc.
TPN’s design mirrors the typical Bittensor subnet structure with two types of nodes: miners and validators. The miners in Subnet 65 run the infrastructure that actually provides VPN connections or performs web requests, and they are rewarded in the network’s token for delivering reliable service. The validators act as the coordinators and gatekeepers – they interface with end-users or requesting agents, distribute tasks to miners, and verify that miners perform those tasks correctly. In other words, validators send work (e.g. data fetch requests or connection challenges) to the miners, then evaluate the responses to decide how to allocate rewards (via weight assignments) to the miners.
Privacy and Data Routing
The core idea is to route user traffic or data requests through this decentralized network of miners (similar to how a VPN or proxy works) with encryption and anonymity. In future iterations, a user or application will ask a TPN validator for a connection or for content; the validator then selects an appropriate miner node (e.g. based on location or performance) and facilitates an encrypted tunnel or request through that miner. Because each miner is independently operated and geographically distributed, TPN can offer a wide range of IP endpoints across different countries and networks. This makes it hard for any content host or government to censor or blacklist the service as a whole. Unlike traditional VPNs which often use known data-center IP ranges, TPN’s nodes are incentivized to run on diverse connection types – including residential networks – to blend in with normal internet traffic. This diversity means content providers cannot easily identify and block TPN nodes, preserving access to region-locked or censorship-prone content.
Challenge-Response Mechanism
In its current implementation, TPN emphasizes a proof-of-location and responsiveness scheme to bootstrap the network. Validators continually issue random challenge requests to miners to ensure they are operational and located in unique network zones. For example, a validator might instruct a miner to fetch a small file from a test URL (the “challenge”) that contains a secret key. The miner must open that URL and return the secret within it back to the validator. By doing this, the validator can verify two things: (1) the miner is actually online at a certain IP address (since the request comes from that IP), and (2) the miner’s network location (IP geo-location and type) and response speed. Miners that respond with the correct secret quickly and from unique locations (e.g. under-represented countries or residential IPs not already covered by others) will score higher. This challenge/response approach ensures the subnet self-organizes into a globally distributed network rather than a cluster of nodes all in one region. It prevents miners from concentrating in a single cheap cloud provider, which would undermine TPN’s purpose of diverse endpoints. Validators use these tests to continually rank miners and adjust their stake “weights” accordingly, so that well-performing, uniquely positioned miners earn more rewards. All communication for challenges and responses happens over encrypted channels, and miners are expected to run secure connection software (like VPN daemons or proxy servers) as part of their node stack.
Data Requests and VPN Tunneling
TPN’s functionality will expand in stages. In upcoming phases, validators will expose an API for users to request arbitrary URLs or data through the network. For example, a user (which could be an AI agent or a regular user via an application) might ask a TPN validator to fetch a web page. The validator will forward this request to one of the miners (or a set of miners), which will then retrieve the content and return it. Validators will cross-verify responses (e.g. by random spot-checks or comparing across miners) to ensure miners aren’t tampering with or failing to fetch the data.
Later, the network plans to support advanced web interactions – not just simple HTTP GET requests, but complex page interactions. Under this model, a user could specify a script of actions (like clicking buttons, waiting for dynamic content to load, filling forms) and the miner would execute it in a headless browser environment. This is crucial for scraping or accessing modern web content that requires JavaScript execution or login steps. The miner essentially acts as a remote browser. All such interactions remain privacy-preserving for the end-user, since the requests originate from the miner’s machine/IP, not the user’s, and any sensitive data can be transmitted securely over the encrypted channel between the user and validator/miner.
Finally, in the fully realized VPN stage, TPN will enable users to establish actual VPN tunnels through the miners. In this scenario, a user’s device might request a VPN connection to, say, country X. The validator will identify a miner in the requested region, perform a quick challenge to ensure that miner is up and has the desired characteristics, and then obtain a VPN configuration file or credentials from that miner. The user can then use that config to open an encrypted VPN tunnel directly to the miner node, effectively routing all of the user’s internet traffic through that node (just like a standard VPN service). TPN’s design even envisions allowing sophisticated usage like rotating between multiple miners: for instance, a user could specify they want their exit IP to change every 5 minutes or cycle through a set of countries. This would be handled by the validators/miners coordinating to hand off connections or issue new config files periodically. Throughout these operations, strong encryption (likely using well-established VPN protocols) would protect the data in transit, such that neither eavesdroppers nor the miners themselves can see or alter the content of the user’s traffic. The end result is a highly flexible, decentralized private network that users (and applications) can tailor to their needs for privacy, web scraping, avoiding geo-blocks, etc.
TPN is spearheaded by the same team that created the Taofu protocol. Taofu is a Bittensor-focused project aimed at helping subnet developers raise capital and decentralize ownership via “Subnet Seeds” (a kind of crowdfunding and governance token system) – in other words, the TPN team is deeply involved in the broader Bittensor ecosystem and its growth initiatives. The development of TPN falls under the banner of Beyond Stake, which is the organization behind Taofu. The team brings together expertise from both blockchain and privacy-tech domains:
Just – an experienced blockchain engineer (formerly at Parity Technologies) who has contributed to the Polkadot/Substrate codebase, including core components like the XCM (cross-chain messaging) system. This indicates that TPN’s smart contract and chain integration are in capable hands, with deep knowledge of decentralized network infrastructure.
Mentor – a Web2/Web3 engineer with a long background in the VPN industry. Mentor previously founded and ran two VPN companies (selling one and operating the second as a non-profit for 8 years), and notably created OnionDAO, a project that incentivized people to run Tor exit nodes. His involvement brings a wealth of knowledge in building privacy networks and dealing with the challenges of running exit nodes (like handling abuse, maintaining stability and anonymity). The influence of OnionDAO’s philosophy can be seen in TPN’s design (incentivizing individuals to contribute to a privacy network).
Additionally, the broader Beyond Stake/Taofu leadership includes founders Mitch and Mikel, who have backgrounds in entrepreneurship, growth marketing, and blockchain innovation. Mitch, for example, has founded companies in both traditional tech and crypto, and helped launch Taofu to support Bittensor subnet teams. Mikel comes from a science and innovation academic background and has been involved in blockchain education ventures (according to team info shared on their Notion pages). Together, this team combines business acumen with technical prowess, which bodes well for TPN’s development and adoption.
The affiliations and support network for TPN also extend to the Bittensor community and investors. Taofu (and by extension TPN) has been backed by entities such as GLC Capital and Yuma Capital to help bootstrap subnets in Bittensor. While not an official Bittensor core project, TPN is very much aligned with Bittensor’s vision of decentralized AI and services. The team frequently engages with the community on Discord and X (Twitter) to provide updates. For instance, when Subnet 65 launched, Bittensor enthusiasts on social media quickly noted TPN’s unique value proposition (privacy-as-a-service on Bittensor). The TPN developers have open-sourced their code and even a litepaper in the project repository, reflecting a transparent, community-driven approach to building this subnet.
TPN is spearheaded by the same team that created the Taofu protocol. Taofu is a Bittensor-focused project aimed at helping subnet developers raise capital and decentralize ownership via “Subnet Seeds” (a kind of crowdfunding and governance token system) – in other words, the TPN team is deeply involved in the broader Bittensor ecosystem and its growth initiatives. The development of TPN falls under the banner of Beyond Stake, which is the organization behind Taofu. The team brings together expertise from both blockchain and privacy-tech domains:
Just – an experienced blockchain engineer (formerly at Parity Technologies) who has contributed to the Polkadot/Substrate codebase, including core components like the XCM (cross-chain messaging) system. This indicates that TPN’s smart contract and chain integration are in capable hands, with deep knowledge of decentralized network infrastructure.
Mentor – a Web2/Web3 engineer with a long background in the VPN industry. Mentor previously founded and ran two VPN companies (selling one and operating the second as a non-profit for 8 years), and notably created OnionDAO, a project that incentivized people to run Tor exit nodes. His involvement brings a wealth of knowledge in building privacy networks and dealing with the challenges of running exit nodes (like handling abuse, maintaining stability and anonymity). The influence of OnionDAO’s philosophy can be seen in TPN’s design (incentivizing individuals to contribute to a privacy network).
Additionally, the broader Beyond Stake/Taofu leadership includes founders Mitch and Mikel, who have backgrounds in entrepreneurship, growth marketing, and blockchain innovation. Mitch, for example, has founded companies in both traditional tech and crypto, and helped launch Taofu to support Bittensor subnet teams. Mikel comes from a science and innovation academic background and has been involved in blockchain education ventures (according to team info shared on their Notion pages). Together, this team combines business acumen with technical prowess, which bodes well for TPN’s development and adoption.
The affiliations and support network for TPN also extend to the Bittensor community and investors. Taofu (and by extension TPN) has been backed by entities such as GLC Capital and Yuma Capital to help bootstrap subnets in Bittensor. While not an official Bittensor core project, TPN is very much aligned with Bittensor’s vision of decentralized AI and services. The team frequently engages with the community on Discord and X (Twitter) to provide updates. For instance, when Subnet 65 launched, Bittensor enthusiasts on social media quickly noted TPN’s unique value proposition (privacy-as-a-service on Bittensor). The TPN developers have open-sourced their code and even a litepaper in the project repository, reflecting a transparent, community-driven approach to building this subnet.
The Tensor Private Network has a clear development roadmap outlined in its litepaper. The roadmap is divided into progressive phases (V0 through V4), each adding new capabilities on top of the previous:
V0: Network Bootstrapping
In this initial phase, the goal is to deploy a globally distributed network of miner nodes and ensure they behave correctly. As described earlier, validators issue challenge/response tests and reward miners for good behavior (uptime, correct responses, unique geo-locations). No end-user traffic is served yet – it’s essentially a testing and hardening phase. This phase started in Q1 2025 with Subnet-65’s launch. Status: TPN is currently in bootstrap mode, meaning users cannot yet use it as a VPN, but miners are actively setting up infrastructure and getting incentivized for preparation. This phase also helps gather data on miner performance and fine-tune the scoring algorithms.
V1: Static Querying
Once the network has sufficient coverage and stability, TPN will introduce a feature for static web queries. Validators will expose an interface where a user (likely an application or script at first) can request a specific URL’s content via TPN. For example, one could ask a validator “fetch the HTML of example.com through the TPN network.” The validator will then assign a miner to retrieve that content. The response from the miner (the HTML or data) is returned to the user via the validator. During this stage, validators will add an extra layer of validation: they might randomly verify some requests themselves or compare multiple miners’ outputs to ensure miners aren’t spoofing data. If a miner returns invalid or incorrect content, the validator will down-rank that miner’s weight (reducing its rewards). Notably, the challenge/response mechanism from V0 will remain in use as a baseline health check during V1. In summary: V1 enables basic web scraping and data access through the TPN network, turning it into a decentralized HTTP proxy for static content.
V2: Advanced (Dynamic) Querying
In this phase, TPN tackles the complexity of modern web content. Websites today often require interacting with dynamic elements – e.g. clicking “load more” to reveal comments, accepting cookie notices, or logging in. V2 plans to let users specify a script or set of actions to be performed in a headless browser environment on the miner side. Essentially, instead of just fetching a URL, a user could send a JSON recipe describing how to fully render a page (e.g. “go to this URL, wait for network idle, then click this button, then extract the text of a certain element”). The miner will run a headless browser (like Chromium) to execute those steps, and then return the final page content or result. This allows even rich, gated, or interactive content to be retrieved through the decentralized network. V2 transforms TPN into a full web automation platform powered by miners. The use cases here might include AI agents that need to gather information from various forums or social media which require login or button clicks. Successful execution would greatly broaden the range of data that Bittensor’s AI models (or other users) can access in a decentralized manner.
V3: Full VPN Networking
This is the milestone where TPN truly becomes a VPN service in the traditional sense. At V3, users will be able to request an actual VPN connection through the TPN network. The validator node will serve as the entry point: a user’s VPN client can connect to a validator, which will then broker the connection to a miner that serves as the exit node. Upon request, the chosen miner will provide a VPN configuration (for example, a WireGuard config file or OpenVPN profile) to the validator, which passes it to the user. The user can then directly connect to that miner using the config, establishing an encrypted tunnel. All of the user’s traffic will flow out to the internet from that miner’s IP address, effectively masking the user’s true location. V3 also contemplates creative VPN use-cases that centralized providers struggle with, such as rapidly rotating exit nodes or chaining multiple hops. Because TPN has many miners, a user could schedule rotations (e.g. change exit IP every few minutes) to enhance privacy. The validator would automate this by handing the user a new config for a different miner periodically. This level of flexibility—having a pool of global nodes to route through on-demand—demonstrates the power of a decentralized VPN. It would be very difficult for a traditional VPN company to offer hundreds of rotating residential exits, but TPN can collectively provide that. Technically, reaching V3 means significant development in coordinating secure tunnels and possibly dealing with networking challenges (NAT traversal, bandwidth considerations, etc.), but it is a core part of TPN’s vision.
V4: Consumer-Level Integrations
The final phase on the roadmap emphasizes user-friendly integration of TPN into mainstream applications and for non-technical users. At V4, the subnet should be robust and feature-complete enough to offer simple apps or interfaces for people to use it as they would a normal VPN or web service. This could mean browser extensions, mobile apps, or integration with IoT devices that route traffic through TPN. The team notes that given the diverse and versatile nature of the TPN (referred to as “the sybil subnet” in their docs), it will be suitable not only for automated agents and power users, but also for everyday consumers looking for private internet access. We can expect efforts in this phase to reduce complexity — for example, abstracting the validator/miner selection from the user entirely, so that using TPN might be as easy as clicking “Connect” in a VPN app. V4 might also involve partnerships or plugins (perhaps enabling other decentralized applications to use TPN under the hood for network calls). Essentially, this stage is about moving from a niche tech solution to a broadly accessible privacy service.
The Tensor Private Network has a clear development roadmap outlined in its litepaper. The roadmap is divided into progressive phases (V0 through V4), each adding new capabilities on top of the previous:
V0: Network Bootstrapping
In this initial phase, the goal is to deploy a globally distributed network of miner nodes and ensure they behave correctly. As described earlier, validators issue challenge/response tests and reward miners for good behavior (uptime, correct responses, unique geo-locations). No end-user traffic is served yet – it’s essentially a testing and hardening phase. This phase started in Q1 2025 with Subnet-65’s launch. Status: TPN is currently in bootstrap mode, meaning users cannot yet use it as a VPN, but miners are actively setting up infrastructure and getting incentivized for preparation. This phase also helps gather data on miner performance and fine-tune the scoring algorithms.
V1: Static Querying
Once the network has sufficient coverage and stability, TPN will introduce a feature for static web queries. Validators will expose an interface where a user (likely an application or script at first) can request a specific URL’s content via TPN. For example, one could ask a validator “fetch the HTML of example.com through the TPN network.” The validator will then assign a miner to retrieve that content. The response from the miner (the HTML or data) is returned to the user via the validator. During this stage, validators will add an extra layer of validation: they might randomly verify some requests themselves or compare multiple miners’ outputs to ensure miners aren’t spoofing data. If a miner returns invalid or incorrect content, the validator will down-rank that miner’s weight (reducing its rewards). Notably, the challenge/response mechanism from V0 will remain in use as a baseline health check during V1. In summary: V1 enables basic web scraping and data access through the TPN network, turning it into a decentralized HTTP proxy for static content.
V2: Advanced (Dynamic) Querying
In this phase, TPN tackles the complexity of modern web content. Websites today often require interacting with dynamic elements – e.g. clicking “load more” to reveal comments, accepting cookie notices, or logging in. V2 plans to let users specify a script or set of actions to be performed in a headless browser environment on the miner side. Essentially, instead of just fetching a URL, a user could send a JSON recipe describing how to fully render a page (e.g. “go to this URL, wait for network idle, then click this button, then extract the text of a certain element”). The miner will run a headless browser (like Chromium) to execute those steps, and then return the final page content or result. This allows even rich, gated, or interactive content to be retrieved through the decentralized network. V2 transforms TPN into a full web automation platform powered by miners. The use cases here might include AI agents that need to gather information from various forums or social media which require login or button clicks. Successful execution would greatly broaden the range of data that Bittensor’s AI models (or other users) can access in a decentralized manner.
V3: Full VPN Networking
This is the milestone where TPN truly becomes a VPN service in the traditional sense. At V3, users will be able to request an actual VPN connection through the TPN network. The validator node will serve as the entry point: a user’s VPN client can connect to a validator, which will then broker the connection to a miner that serves as the exit node. Upon request, the chosen miner will provide a VPN configuration (for example, a WireGuard config file or OpenVPN profile) to the validator, which passes it to the user. The user can then directly connect to that miner using the config, establishing an encrypted tunnel. All of the user’s traffic will flow out to the internet from that miner’s IP address, effectively masking the user’s true location. V3 also contemplates creative VPN use-cases that centralized providers struggle with, such as rapidly rotating exit nodes or chaining multiple hops. Because TPN has many miners, a user could schedule rotations (e.g. change exit IP every few minutes) to enhance privacy. The validator would automate this by handing the user a new config for a different miner periodically. This level of flexibility—having a pool of global nodes to route through on-demand—demonstrates the power of a decentralized VPN. It would be very difficult for a traditional VPN company to offer hundreds of rotating residential exits, but TPN can collectively provide that. Technically, reaching V3 means significant development in coordinating secure tunnels and possibly dealing with networking challenges (NAT traversal, bandwidth considerations, etc.), but it is a core part of TPN’s vision.
V4: Consumer-Level Integrations
The final phase on the roadmap emphasizes user-friendly integration of TPN into mainstream applications and for non-technical users. At V4, the subnet should be robust and feature-complete enough to offer simple apps or interfaces for people to use it as they would a normal VPN or web service. This could mean browser extensions, mobile apps, or integration with IoT devices that route traffic through TPN. The team notes that given the diverse and versatile nature of the TPN (referred to as “the sybil subnet” in their docs), it will be suitable not only for automated agents and power users, but also for everyday consumers looking for private internet access. We can expect efforts in this phase to reduce complexity — for example, abstracting the validator/miner selection from the user entirely, so that using TPN might be as easy as clicking “Connect” in a VPN app. V4 might also involve partnerships or plugins (perhaps enabling other decentralized applications to use TPN under the hood for network calls). Essentially, this stage is about moving from a niche tech solution to a broadly accessible privacy service.
Keep ahead of the Bittensor exponential development curve…
Subnet Alpha is an informational platform for Bittensor Subnets.
This site is not affiliated with the Opentensor Foundation or TaoStats.
The content provided on this website is for informational purposes only. We make no guarantees regarding the accuracy or currency of the information at any given time.
Subnet Alpha is created and maintained by The Realistic Trader. If you have any suggestions or encounter any issues, please contact us at [email protected].
Copyright 2024