# Gamification & More ## Delegate Staking Flywheel A flywheel inside a flywheel. ### More Nodes, More Stake As previously learned earlier in the documentation (see [Understanding Subnets](/understanding-subnets.md#minimum-delegate-stake-balance)), each subnet must maintain a minimum delegate stake balance at all times, which increases with inflation and the subnet's size; otherwise, it will be removed.
### Asset-Price Inflation As the inflation increases in each epoch, so does the **base minimum delegate stake balance** for all subnets, including new ones. The subnets' total delegate stake balance MUST increase with the economy's inflation; otherwise, it will be removed. #### Inflation This ensures the price of becoming a subnet is relative to the economic growth. ## Red Queen Hypothesis This is the idea that participants in a system must constantly improve just to maintain their current position. **In Hypertensor**, this applies to all subnets because the **base minimum delegate stake increases over time**, due to both inflation and subnet size. As a result, subnets must **continuously attract more stakeholders and stay performant** to remain active and competitive. Stagnation leads to being outpaced and eventually removed from the network. This creates a flywheel; the more nodes, the higher the delegate stake is required, the higher the delegate stake, the more nodes are incentivized to join a subnet. This is a built-in incentive for ongoing competition and improvement. *** ## Let's exploit a centralized subnet ### Incentivized Decentralization Before reading further, learn more about [Overwatch Nodes](/overwatch-nodes/introduction.md) and how centralized subnets are not possible in the Hypertensor network, and how nodes graduate [subnet node classifications](/network/subnet-node.md#classification). We built every feature in Hypertensor around ensuring decentralized AI. Subnets that are built as a centralized and permissioned network are at risk of having a 66% takeover. The consensus mechanism is built specifically to incentivize decentralization and put centralized subnets at high risk of being taken over in a 66% takeover attack. Centralized subnets are unlikely to have a way to deterministically know if a node is doing its job and may rely on "if you're staked and registered, you're a subnet node". With this system, nodes will graduate through classifications without knowing if they are doing the job of the node. In Hypertensor, just because you're a staked participant and registered on-chain doesn't automatically determine if you're a subnet node. In most proof-of-stake systems, such as Base, Ethereum, Optimism, Solana, Kaspa, etc., peer discovery and routing are two essential aspects of P2P networking. In a P2P network, each node must be able to discover and communicate with other nodes without the need for a central server The consensus mechanism imitates routing tables. Each node must be able to communicate with each node, and each node must be able to deterministically generate a score on each node. If a subnet is centralized, this is a concept that would take more work to accomplish than if it were just decentralized in the first place. The main way to accomplish a centralized subnet would be to have it fully permissioned. Keep in mind, Overwatch Nodes will not allow this. *** ## Weight Copying Mitigation **Weight copying** — where a node mimics or mirrors another node's scores or behavior — is a common attack in decentralized reputation or consensus systems. In Hypertensor, this is mitigated through several systemic safeguards: ### **Staking Does Not Equal Participation (nodes must be nodes)** Unlike traditional blockchain designs, **staking and registering on-chain doesn't automatically make an entity a recognized node in the subnet**. Like traditional blockchains, **other nodes must recognize you,** and **you must perform tasks** to be a node in the subnet. * Nodes must go through a **handshake process** with existing peers in the subnet (See [node classifications](/network/subnet-node.md#classifications)). * For a node to be available to submit consensus data or attest, that node must have previously graduated through the node classifications to be able to do so. This is only possible if they are recognized by other nodes by having weights submitted to them. * They must be **present in the routing tables of neighbor peers**, **visible in DHT Records**, and **node tasks verified by other nodes** to participate in consensus (e.g., validating or attesting). * This ensures only connected, live, and authenticated nodes can influence scoring or be scored. > 🛡️ **Security by separation**: On-chain registration is necessary but not sufficient. Actual participation happens in the P2P mesh. ### Why You Can't Weight Copy * **Nodes are nodes** * Other nodes must recognize you and submit weights on you (see [classifications](/network/subnet-node/classifications.md)). * Nodes cannot simply validate or attest because they are simply staked on-chain — they must **join the subnet**, **prove stake**, **be verifiably online**, and **connect to the subnet's P2P network.** * Think about this like a blockchain; the subnet uses the same logic that allows nodes to connect in a decentralized network and communicate with each other. * **Subnets are decentralized (and required to be)** * Subnets are **decentralized** networks themselves * Consensus design is up to the subnet (see [Scoring design](/build-a-subnet/consensus/scoring.md#design-against-weight-copyers)). * If chosen as the validator, **what will you submit?** * If you're not in the subnet, you will not be able to score the nodes or submit dated data, which is unlikely to be attested by the subnet. * For the most part, AI is not deterministic, and scores are likely to differ epoch to epoch. Subnets should always utilize commit-reveal schemes to ensure nodes are doing their tasks (see [Scoring design](/build-a-subnet/consensus/scoring.md#design-against-weight-copyers)). * What if a node were a legitimate node and turned off the logic to idle by? * A subnet designed correctly (see [Scoring design](/build-a-subnet/consensus/scoring.md#design-against-weight-copyers)) should have no weight copying. * For example, each subnet should have ways to both qualify and quantify each node's work. * [**Overwatch Nodes**](/overwatch-nodes/introduction.md) * Subnets that are fake or purposely designed to be full of 100% weight copying nodes will be watched by Overwatch Nodes. * They will ensure nodes are decentralized, utilize proof of stake, ensure consensus is accurate to the subnet's connected nodes, and benchmark the subnet. **In conclusion**, weight copying is only possible if a subnet codes it in such a way that a node can get away with it. Even if a subnet were run by one person or a coalition of nodes that all agree on faking scores, the Overwatch Nodes will not be able to verify them and make them economically unviable. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.hypertensor.org/gamification-and-more.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.