VPermit
VPermit is a Bittensor validation term for the subnets where a delegate is authorized to validate. The Glossary defines VPermit as a list of subnet IDs that indicate which subnets a delegate is authorized to validate on.
Delegate Context
A delegate can validate in more than one subnet. VPermit is the delegate-level view of that authorization, while a validator permit is the subnet-level permission flag for validation rights.
Relationship to Validator Permits
The glossary describes VPermits as aggregating individual validator permits across multiple subnets. At Taopedia level, the useful distinction is scope: a validator permit answers whether validation rights apply inside one subnet, while VPermit summarizes the subnets where those rights apply for a delegate.
Stake Weight Context
Individual validator permits are tied to stake-weight position inside each subnet. The Glossary: Validator Permit describes those permits as awarded to the top neurons by stake weight within a subnet. VPermit is the delegate-level summary of which subnets carry that authorization, so a delegate’s VPermit reflects where those stake-weight-based subnet permits apply across the subnets they validate on.
References: Glossary: VPermit, Glossary: Validator Permit, Glossary: Stake Weight
Relationship to Multiple Mechanisms
VPermit summarizes the subnets where a delegate is authorized to validate. The Glossary notes that validators must evaluate miners separately for each mechanism.
For readers, VPermit still names delegate-level subnet authorization. Validation rights on a subnet that runs more than one incentive mechanism still span separate evaluation contexts inside that netuid.
References: Multiple Incentive Mechanisms Within Subnets, Glossary: Multiple Incentive Mechanisms
Relationship to Child Hotkeys
VPermit and child hotkeys both concern which keys may validate, but they describe different things. VPermit is the list of subnet IDs a delegate is authorized to validate on, as the Glossary defines it. A child hotkey, by the Child Hotkeys documentation, is a separate key that a parent hotkey authorizes to validate on its behalf by re-delegating a portion of the parent’s stake to it, without transferring ownership of that stake.
For readers, VPermit answers which subnets a delegate is permitted to validate on, while a child hotkey answers which key carries out that validation for a parent. The two are not interchangeable: VPermit is a per-delegate summary of authorized subnets, whereas a child hotkey is a delegated key that performs validation using the parent’s re-delegated stake-weight. VPermit describes where a delegate may validate; a child hotkey is one way the validation itself can be carried out on a parent’s behalf.
References: Glossary: VPermit, Child Hotkeys
Relationship to Yuma Consensus
VPermit and Yuma Consensus describe related parts of Bittensor’s incentive system. Yuma Consensus is the on-chain process that aggregates validator weight signals within a subnet into miner incentives and validator dividends, applying consensus clipping, bonding, and emission calculation (Yuma Consensus).
For readers, vpermit names a specific part of that incentive picture, while Yuma Consensus names the consensus process that turns validator weights into the resulting incentives and dividends.
Reader Boundary
This article defines the term at a high level. It does not list live permissions, rank validators, describe staking or registration steps, or restate validator requirements. Readers should use official validator references for those details.
Relationship to Coinbase
VPermit and coinbase are related but different concepts that sit on different layers of Bittensor. VPermit is the delegate-level summary of which subnets a delegate is authorized to validate on. The Coinbase Implementation documentation describes coinbase as the per-block protocol mechanism that drives TAO emission, accumulates pending emissions, and triggers Yuma Consensus rounds at epoch boundaries, while the Glossary: VPermit describes the delegate-level permission summary.
The two answer different questions. VPermit is a permission-scope concept: it records, across subnets, where a delegate is authorized to validate. Coinbase is an emission concept: it is the recurring per-subnet process that produces and distributes emissions each epoch on the subnets where validation takes place. VPermit does not itself perform or allocate any emission, and coinbase is not a permission record; one summarizes authorization across subnets, while the other names the mechanism that generates each subnet’s emissions.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For VPermit, that sequence changes how readers should interpret evidence about delegate validation authorization.
In localnet, VPermit assignments can be tested in an isolated environment. Localnet validation authorization reflects local chain configuration and does not represent production delegate state.
On testnet, VPermit activity can be observed in a shared, non-production network. Testnet authorization lists are separate from mainnet delegate validation state.
On mainnet, VPermit is the live delegate-level summary of which subnets a delegate is authorized to validate on. The Glossary: VPermit describes the authorization scope that applies on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A VPermit example from one environment should not be read as representing delegate authorization or validation rights in another environment.
VPermit Lists Authorized netuid Values for a Delegate
The Glossary: VPermit defines VPermit as a list of subnet IDs showing which subnets a delegate is authorized to validate on. VPermit vocabulary therefore summarizes delegate-level authorization across netuids, not a single-subnet validator score or emission outcome.
Readers should name the delegate and attach the listed netuid context when citing VPermit. A subnet such as netuid 1 may appear in the list, but the term itself remains a permission summary rather than proof of validator performance on that subnet (Glossary: Validator Permit).