Tensorprox’s mission is to provide a decentralized defense against DDoS attacks and other high-impact cyber threats. It serves as an “ultimate scrubbing center for cyber defense” within the Bittensor network. In traditional terms, a scrubbing center is a system that cleanses incoming traffic to remove malicious packets before they reach a protected server. Tensorprox implements this concept in a decentralized way: instead of a single entity or data center filtering traffic, a network of community-run nodes (miners) competes and collaborates to scrub traffic. This offers several advantages:

Robust DDoS Mitigation: Tensorprox leverages competitive and collaborative efforts of miners to develop highly selective filtering protocols, yielding scalable and resilient protection against malicious traffic. The system is designed to handle evolving attack vectors by continuously improving through competition.

Decentralized Excellence: By harnessing a distributed network of independent nodes, Tensorprox eliminates single points of failure in DDoS defense. No single firewall or server is solely responsible; many nodes worldwide can share the load and back each other up. This decentralization increases resilience: even if some nodes fail or are overwhelmed, others can continue defending, and the system as a whole adapts to new threats.

AI-Driven Precision: Tensorprox integrates machine learning for anomaly detection. Each mining node can run advanced detection algorithms to identify attacks versus normal traffic. The AI models (or rule-based heuristics) used by miners continuously evolve based on feedback and competition, ensuring state-of-the-art detection capabilities tuned to real-world attack patterns.

Incentive Alignment via Bittensor: The value of Tensorprox within Bittensor is that it transforms DDoS mitigation into a tokenized, incentivized service. Bittensor’s protocol emits TAO rewards to participants (miners and validators) proportional to the value they contribute. In Tensorprox, this means miners who are most effective at blocking attacks and allowing legitimate traffic will earn more TAO. The subnet essentially creates a marketplace for DDoS defense – encouraging innovation as miners strive to build better defenses to earn rewards. This competitive model drives rapid improvement in cyber defense strategies, guided by real performance metrics rather than just theoretical promise.

Use Cases: Initially, Tensorprox operates as a research and development subnet to prove that decentralized DDoS protection is feasible and effective. The immediate “customers” of the service are the Bittensor validators (who act as testers, as we will see) and the Bittensor ecosystem itself (gaining security know-how). However, the long-term vision is to offer plug-and-play DDoS protection for any internet service or even other Bittensor subnets that need to secure their nodes. By developing in the Bittensor environment first, Tensorprox can mature its technology with a built-in community and economic model. Eventually, businesses or individual server owners could use Tensorprox to protect their public IPs from DDoS attacks, essentially becoming clients of this decentralized scrubbing network.

Overall, the purpose of Tensorprox is to push the boundaries of cybersecurity through decentralization. It demonstrates a novel use case for Bittensor (securing network infrastructure) beyond the more common AI-model serving tasks. If successful, Tensorprox could significantly enhance the security of decentralized networks by providing community-powered DDoS defense and set a precedent for other security-focused subnets. As the team puts it, “Tensorprox is building the future of decentralized cybersecurity”– a future where anyone can deploy powerful protection in seconds, backed by a global network of incentivized defenders.

Design and Operation: How Tensorprox Works

Tensorprox introduces an innovative design for DDoS protection by using Bittensor’s miner/validator framework to continuously simulate attacks and test defenses. The subnet operates with two main participant roles familiar in Bittensor: miners and validators – but here their roles are tailored to cybersecurity:

• Miners (Defense Nodes): In Tensorprox, miners are the DDoS protection service providers. Each miner runs a specialized firewall application (nicknamed the “Moat”) that inspects and filters network traffic in real-time. During testing rounds, a miner’s Moat will receive a mix of legitimate and attack traffic and must quickly decide which packets to allow or block. The miner essentially behaves like an edge firewall guarding a target server (referred to as the “King”, discussed below). This is done by sniffing live packets (using tools like libpcap or even kernel-bypass techniques like AF_PACKET/nfqueue) and applying an ML-based or rule-based detection model to each packet stream. The miner’s software makes instant allow/deny decisions for each connection or packet, dropping suspected malicious traffic and forwarding benign traffic to the destination. Miners are encouraged to run intelligent filtering models – potentially leveraging machine learning for anomaly detection – to maximize accuracy. Notably, the default miner implementation provided by Shugo includes a basic Moat filter using high-performance packet processing (AF_XDP) for speed, but miners are free to improve on this with their own strategies. In summary, miners provide DDoS mitigation by acting as distributed scrubbing nodes.
• Validators (Attack Simulators & Judges): Validators in Tensorprox serve a dual purpose: they generate realistic traffic (including attacks) to challenge the miners, and they evaluate the miners’ performance. In each testing round (analogous to a Bittensor block interval), validators will orchestrate a simulated scenario for each miner. This involves spinning up traffic generators that send a blend of normal (benign) traffic and malicious traffic (DDoS patterns) towards the miner’s firewall. The validators control the proportion and intensity of attack traffic, alternating between normal behavior and intense DDoS bursts to mimic real-world conditions. Each validator then measures how well the miner’s Moat handled the challenge: Did it allow legitimate traffic through to the protected server? Did it block the attacks effectively? How quickly did it respond? All these factors are recorded. Essentially, the validator behaves like an “adversary” (launching the attack) and an auditor (scoring the outcome) at the same time. After the round, the validator will assign a performance score or weight to the miner, which feeds into Bittensor’s incentive mechanism.

Challenge-Response Cycle: The interaction between validators and miners is the heart of Tensorprox’s operation. For a given round, a validator (or a set of validators) will connect to the miner’s testing environment via a secure channel (SSH, as configured – more on this in architecture). The validator deploys one or more Traffic Generator (TGen) processes on machines that the miner provides access to, and designates a King server (the target to protect) in that miner’s environment. The traffic generators then begin sending traffic to the King server through the miner’s Moat. This traffic is dynamically configured each round: one moment it might be mostly normal traffic (to see if the miner allows good traffic through), the next moment it might spike with a flood of simulated attack packets (to test the miner’s blocking under pressure). The miner’s Moat has to continuously adapt, letting benign traffic reach the King while diverting or dropping the malicious packets.

During this process, validators collect detailed telemetry:

• How many benign packets reached the King vs how many were sent (this indicates how much legitimate traffic got through, called Benign Delivery Rate (BDR) in their metrics).
• How many attack packets got through to the King vs how many were sent (i.e. how much malicious traffic slipped past the defenses; from this they compute Attack Mitigation Accuracy (AMA) – the fraction of attacks blocked).
• The total volume of traffic handled by the miner and the relative volume compared to other miners (gauging throughput capacity).
• The latency or response time introduced by the miner’s filtering (measured via round-trip time to the King).
• The “purity” of the traffic that reaches the King – meaning what percentage of it was benign (they call this Selective Processing Score, favoring miners that pass mostly clean traffic).

At the end of the round, the validator uses these measurements to compute an overall score for the miner. Tensorprox’s incentive model is explicitly defined as a weighted combination of Accuracy, Efficiency, Throughput, and Latency components (each 25%). In simplified terms, miners earn the highest rewards if they consistently allow most or all benign traffic (high BDR), block nearly all attack traffic (high AMA), handle large volumes of packets (high throughput), and do so with minimal delay (low latency). This comprehensive scoring mechanism ensures that miners can’t “game” the system by focusing on one metric alone – they need to balance all aspects of performance (for example, a miner that blocks everything including good traffic would have great attack mitigation but terrible benign delivery, resulting in a poor score). The validators’ scores are then submitted on-chain, and the Bittensor protocol allocates the newly emitted TAO accordingly: miners with better scores get a larger share of the reward for that round.

From a user perspective, at this stage of development, Tensorprox is mostly an infrastructure and developer-focused product. It doesn’t yet offer a plug-and-play interface for a website owner to protect their site. However, everything needed to participate in and benefit from Tensorprox is publicly available:

• Open-Source Code: The entire Tensorprox subnet codebase is open on GitHub, allowing developers to review how it works or even run their own instances. The repository provides separate instructions to run a Validator node (to test others) or a Miner node (to provide DDoS protection service).
• Setup and Interfaces: To join as a miner, one must have a suitable server setup (Ubuntu 22.04, Python 3.10, plus certain packages). The miner needs to run the Tensorprox software and also provision at least two auxiliary machines for traffic generation and one “King” server in their environment. These can be modest virtual machines or even containers – the system is designed to scale the load according to what the miner provides, so even a small setup can participate with lighter traffic. The key interface the miner must expose is SSH access to those machines for the validators (with strict security controls, discussed later). There isn’t a traditional API or web interface that external users call on the miner; instead, the interaction is orchestrated by the validator via scripts and SSH commands under the hood.
• Monitoring and Dashboard: The team has provided a “mining dashboard” web interface (at dashprox.com) for monitoring performance, which suggests that miners and the community can observe real-time metrics of the subnet. (This dashboard is likely still in development or early stages; the idea is to visualize stats like current miners, their throughput, scores, etc., to foster transparency.)
• Community and Support: Tensorprox’s creators actively maintain a community Discord channel, where miners and validators can get support, discuss strategies, and stay updated. They also post updates and guides on social media (e.g., Twitter/X and LinkedIn) to help onboard participants. For instance, at launch they shared step-by-step setup instructions and encouraged users to “join us and be your very own (profitable) CEO in cybersecurity” by running a Tensorprox miner.

The operation of Tensorprox today involves validators simulating attacks and scoring miners, and miners running firewall nodes to earn rewards by protecting a dummy target. The product is currently the network itself – a proving ground for decentralized DDoS defense techniques. As it matures, this will evolve into a more user-facing service (where real clients could route their traffic through Tensorprox nodes for protection). Even in its current form, Tensorprox provides immediate value to the Bittensor ecosystem: it’s a live, constantly-improving cybersecurity experiment that not only secures the subnet’s own infrastructure but also generates knowledge and tooling that could secure other parts of the network.

Technical Architecture and Components

The Tensorprox subnet employs a clever distributed architecture to simulate realistic network attacks and test defenses in a safe yet rigorous environment. The design is centered around a few key components and concepts:

• The “King” (Protected Server): The King represents the target server that needs protection. In practice, this is a machine or process provided by the miner which will act as the destination for all traffic during a validation round. It could be a simple server application that responds to pings or HTTP requests – its main role is to be the endpoint that should receive benign traffic and be shielded from malicious traffic. The King allows the system to measure what actually got through the defenses.
• Traffic Generators (TGen): These are machines or processes that generate network traffic directed at the King. Validators use TGen instances to create both normal traffic (e.g. legitimate web requests, pings, etc.) and malicious traffic (e.g. SYN floods, UDP floods, HTTP request floods, etc.). Each miner typically needs to supply at least two TGen machines (tgen-0, tgen-1, etc.) which validators can use. By using multiple sources of traffic, the simulation can mimic a distributed attack coming from different IP addresses. Per-round configuration: In each round, the validator can dynamically adjust the behavior of the TGen instances – for example, increase the packet rate to simulate a burst, or switch the attack vector (one round might simulate a volumetric UDP flood, the next an HTTP flood, etc.). This dynamic setup ensures miners face a broad range of scenarios over time.
• The “Moat” (Miner’s Firewall): The Moat is the nickname for the miner’s DDoS defense mechanism that stands between the incoming traffic and the King. Physically, the Moat is software running on the miner’s node which has network interfaces connecting to each TGen and to the King. It operates like a router or proxy: all packets from TGen sources must pass through the Moat before reaching the King. The Moat applies filtering rules or an ML model to decide which packets to forward to the King and which to drop. For high throughput, the Moat implementation uses Linux’s AF_XDP (a high-performance packet processing framework in the kernel). This allows it to handle millions of packets per second if needed, by bypassing some of the kernel’s networking overhead. The Moat can be thought of as an embedded intrusion prevention system that the miner controls. Each TGen has a dedicated GRE tunnel (see below) or interface to send traffic to the Moat, so the miner can isolate and inspect traffic streams from each source.

Network Topology: To create a realistic yet controlled testbed, Tensorprox uses an overlay network built with GRE (Generic Routing Encapsulation) and IP-in-IP tunnels. All the involved nodes (TGen machines, Moat/miner machine, and King) are networked together in this overlay:

• The miner configures GRE tunnels from each TGen node to the Moat. For example, TGen-0 might have a GRE tunnel endpoint with the Moat on a private subnet (say 192.168.110.0/30). Similarly TGen-1 has another GRE tunnel endpoint with the Moat on a different subnet (192.168.114.0/30 in the example). These GRE tunnels allow arbitrary IP traffic to be sent between TGen and Moat, even carrying “spoofed” source IPs or unusual protocols, because the GRE encapsulation abstracts away the underlying physical network’s restrictions.
• On top of GRE, an IP-in-IP tunnel is used for the actual attack traffic. The overlay is configured such that TGen sends packets addressed to the King’s overlay IP (e.g., an address in 10.200.77.0/32 range). These packets get encapsulated and delivered to the Moat, which then decapsulates and sees traffic ostensibly coming from various forged IPs headed toward the King. The Moat then applies its filtering logic. If a packet is allowed, the Moat forwards it to the King (probably via another tunnel or directly if King is reachable). If it’s blocked, the Moat drops it.
• The 10.0.0.0/24 physical network mentioned in the architecture is likely the underlying network where all these machines reside or can reach each other (for instance, a VPN or cloud virtual network). The overlay (GRE/IPIP) is layered on top of this to create an isolated “sandbox” network environment.

The use of GRE/IP tunnels is crucial. It enables simulation of complex attack scenarios (including IP spoofing) in a controlled way. For example, a common DDoS tactic is to use fake source IP addresses. In a normal cloud environment, you often can’t send packets with arbitrary source IPs (ISPs will drop them). But within this GRE/IPIP sandbox, the validators can generate traffic that appears to come from random or globally distributed IP addresses, testing whether the miner’s defense can handle such conditions. All of this malicious traffic remains contained in the overlay and does not impact the public internet – making it a safe arena for stress-testing. The architecture essentially provides a “virtual battleground” where attacks and defenses can play out realistically without collateral damage.

Performance Scaling and Fairness: Tensorprox’s architecture accounts for both scalability and fairness in several ways:

Scalable Traffic for Miners: Miners are allowed to increase the number of traffic generator nodes they provide over time to handle more load. If a miner proves capable of filtering a high volume of traffic accurately, they are incentivized to add another TGen machine to push even more traffic through their Moat (thus potentially earning more if they can handle it). However, this is regulated by the reward function – simply adding more traffic without maintaining filtering quality won’t yield rewards. The reward mechanism, by incorporating throughput and accuracy, ensures that only miners who can both scale up and keep a high mitigation rate benefit from deploying many TGens. This creates a natural balance: miners start with perhaps a modest setup and as they optimize their system, they can scale out, but always need to keep performance high.

Validator Coordination: In a decentralized setting with multiple validators, Tensorprox enforces that validators operate in a synchronized and non-overlapping fashion. All validators coordinate their challenge rounds using a universal timestamp trigger, so that each testing round starts at the same time for everyone. This prevents timing advantages or a validator running extra rounds unfairly. Moreover, the design guarantees mutual exclusivity, meaning no two validators will try to validate the same miner at the same time (and conversely, each validator works on a distinct subset of miners each round). This ensures every miner is tested and scored uniformly and avoids duplicated work.

Security and Access Control: A very important aspect of the architecture is that miners must grant controlled SSH access to their machines so validators can deploy scripts and run traffic generators. To make this secure, Tensorprox implements a Whitelist-Agent on the miner side. This is a custom security daemon that intercepts any command a validator tries to execute over the SSH session and checks it against an approved list of actions. Validators are only allowed to run the predefined traffic generation and monitoring scripts needed for the challenge; anything outside that (e.g., trying to access miner’s filesystem or run arbitrary commands) would be blocked. Additionally, all scripts are verified by checksum (SHA-256) before execution to ensure they haven’t been tampered with. This protects the miner from malicious validators and also ensures validators can’t cheat by modifying test scripts on the fly. In essence, even though validators get access to miner-provided machines, that access is sandboxed and tightly controlled.

Protocol Integration: On the blockchain side, Tensorprox uses Bittensor’s subtensor mechanism to register miners and validators (each identified by wallet hotkeys) and to log scores. The netuid 91 identifies this subnet on-chain, and participants register to that netuid to join. The substrate chain stores the stake, ranks, and incentive weights for Tensorprox miners as with any subnet. Thus, the fundamental consensus mechanism of Bittensor (where validators’ scores translate into adjusting miners’ stake weight for token emission) underpins Tensorprox’s economics. The TAO tokenomics are inherited from Bittensor – Tensorprox did not need to create a new token, which lowers the barrier for participation and ties the subnet’s success to the broader TAO economy. Community members can also stake/delegate TAO to Tensorprox validators if they believe in the subnet, further rooting it in the ecosystem.

To visualize the above, imagine each miner as a mini fortress: It has a King inside (the asset to protect), a Moat around it (the filtering barrier), and the validators act like sporadic “stress testers” who send volleys of good and bad “traffic” at the fortress to see how well the moat holds. The entire fortress and attack simulation is built on a virtual land (the GRE tunnel network) that mimics the internet. This architecture is both complex and cutting-edge: it blends network engineering (tunneling, traffic generation), cybersecurity (intrusion detection systems), and blockchain-based incentive alignment. Tensorprox’s technical design allows it to evolve quickly – the team can introduce new attack patterns, new scoring rules, or allow miners to integrate new defense algorithms, all within this flexible sandbox. As attacks become more sophisticated, the decentralized defense can also adapt in a competitive Darwinian fashion.