Queried by: validatorsdevelopersanalytics
The Big Picture
Active validators update weights regularly to reflect current network state. This timestamp shows when each neuron last updated. Stale weights (many blocks old) suggest inactive or poorly maintained validators - important for delegation decisions.
Why This Matters
Is this validator actively maintaining their weights, or set-and-forget? Recent LastUpdate means active participation. Old LastUpdate is a red flag.
Example Scenario
Current block is 7,000,000. Query LastUpdate(netuid=1, uid=5) returns 6,999,950. Validator updated 50 blocks ago - very active. If it returned 6,900,000, that's 100,000 blocks stale - concerning.
Common Questions
- How fresh should weights be?
- Depends on the subnet's tempo. Generally, weights should update at least once per epoch. Check subnet parameters for specific expectations.
- What's the rate limit?
- Check WeightsSetRateLimit for the subnet. You typically can't update more than once per N blocks.
Use Cases
- Check if validator is actively updating weights
- Determine when weights can be updated again (rate limiting)
- Identify stale or inactive validators
- Build validator activity monitoring dashboards
From Chain Metadata
MAP ( netuid ) --> last_update
Purpose & Usage
Purpose
Track weight freshness and rate limiting.
Common Query Patterns
- Check if weights are stale
- Verify rate limit compliance
Query Keys
| # | Name | Type | Description |
|---|---|---|---|
| 1 | netuid | u16 | Subnet ID. Same NetUidStorageIndex remap caveat as Weights. |
Stored Value
Relationships
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 LastUpdate storage
const netuid = 1;
const result = await api.query.SubtensorModule.LastUpdate.getValue(netuid);
console.log("LastUpdate:", result);On-Chain Activity
Write Frequency
●●●●●● Ultra-High >10M est. writes
>10M estimated writes
#2 most written storage item
Write Source Calls + Hooks
Modified by both user extrinsics and runtime hooks
As of block 7,429,232
Version History
v101 block 1 Added
v120 block 315,568 Internal re-bind
v123 block 720,235 Internal re-bind
v128–v132 · runtime versions skipped on chain (never deployed)
v133 block 1,404,224 Internal re-bind
v136 block 1,756,781 Internal re-bind
v138 block 1,907,363 Internal re-bind
v140 block 1,929,216 Internal re-bind
v146 block 2,848,978 Internal re-bind
v149 block 3,014,339 Internal re-bind
v151 block 3,157,274 Internal re-bind
v154 block 3,308,611 Internal re-bind
v166–v194 · runtime versions skipped on chain (never deployed)
v195 block 3,791,350 Internal re-bind
v202 block 3,848,823 Internal re-bind
v207–v209 · runtime versions skipped on chain (never deployed)
v210 block 4,345,556 Internal re-bind
v213–v215 · runtime versions skipped on chain (never deployed)
v216 block 4,510,996 Internal re-bind
v235–v237 · runtime versions skipped on chain (never deployed)
v238 block 4,936,550 Internal re-bind
v278–v289 · runtime versions skipped on chain (never deployed)
v290 block 5,947,548 Internal re-bind
v307–v314 · runtime versions skipped on chain (never deployed)
v315 block 6,414,634 Internal re-bind
v316–v319 · runtime versions skipped on chain (never deployed)
v320 block 6,523,566 Internal re-bind
v327–v333 · runtime versions skipped on chain (never deployed)
v334 block 6,811,690 Internal re-bind
v353–v360 · runtime versions skipped on chain (never deployed)
v361 block 7,063,679 Internal re-bind
v394–v400 · runtime versions skipped on chain (never deployed)
v401 block 8,036,576 Internal re-bind Current
Runtime Info
View Source- Pallet
- SubtensorModule
- Storage Kind
- Map
- First Version
- v101
- Current Version
- v411