Queried by: minersvalidatorsdevelopersanalytics
The Big Picture
Difficulty adjusts based on demand but won't exceed MaxDifficulty. This ensures POW registration remains feasible even during extreme demand. Without a cap, difficulty could become computationally impossible.
Why This Matters
How hard can POW get? MaxDifficulty. Beyond this, the system stops increasing difficulty regardless of demand.
Example Scenario
Query MaxDifficulty(netuid=1) returns the difficulty ceiling. Even during sustained high demand, POW won't require more computation than this.
Common Questions
- What happens at max difficulty?
- Difficulty stays at the cap. If demand remains high, consider burn registration instead - it might be more practical.
- How does this relate to burn?
- Difficulty and burn both adjust to demand. At maxes, one might be better than the other depending on your resources (compute vs TAO).
Use Cases
- Understand worst-case POW requirements
- Plan hardware for registration
- Research registration economics
- Design subnet difficulty parameters
- Build difficulty displays with bounds
From Chain Metadata
MAP ( netuid ) --> MaxDifficulty
Purpose & Usage
Purpose
Cap on difficulty - prevents computationally impossible registration.
Common Query Patterns
- Query by netuid
- Plan POW registration strategy
- Understand difficulty ceiling
Query Keys
| # | Name | Type | Description |
|---|---|---|---|
| 1 | netuid | u16 | netuid (u16, hashed key component) |
Stored Value
Relationships
Modified By
Related Events
Code Examples
import { createClient, Binary } from "polkadot-api";
import { getWsProvider } from "polkadot-api/ws";
import { sub } from "@polkadot-api/descriptors"; // generated by: npx papi add sub -w wss://entrypoint-finney.opentensor.ai:443
const client = createClient(getWsProvider("wss://entrypoint-finney.opentensor.ai:443"));
const api = client.getTypedApi(sub);
// Query MaxDifficulty storage
const netuid = 1;
const result = await api.query.SubtensorModule.MaxDifficulty.getValue(netuid);
console.log("MaxDifficulty:", result);Version History
v101 block 1 Added
v123 block 720,235 Internal re-bind
v149 block 3,014,339 Internal re-bind
v166–v194 · runtime versions skipped on chain (never deployed)
v195 block 3,791,350 Internal re-bind
v278–v289 · runtime versions skipped on chain (never deployed)
v290 block 5,947,548 Internal re-bind Current
Runtime Info
View Source- Pallet
- SubtensorModule
- Storage Kind
- Map
- First Version
- v101
- Current Version
- v411