MaxWeightLimitSet

Event Re-added v101 → v219, v233 → v265, v273 → v277, v290 → current #10

Emitted when maximum weight limit is changed.

View events on chain
Useful for: validatorssubnet ownersdevelopersanalytics

The Big Picture

While MinAllowedWeight ensures validators evaluate enough miners, MaxWeightLimit caps how many they can evaluate in one transaction. This has practical purposes: it limits transaction size, processing time, and storage. For large subnets with hundreds of miners, validators can't weight everyone in one transaction - they must prioritize. The limit forces validators to be selective, which can actually improve consensus quality (validators focus on miners they've actually evaluated well).

Why This Matters

If you're validating a subnet with 500 miners but MaxWeightLimit is 256, you can only weight 256 miners per transaction. You need to decide which miners to prioritize. Changes to this limit affect your validator strategy and code.

Example Scenario

Subnet 15 has 400 miners. MaxWeightLimit was 400 (weight everyone). To reduce transaction overhead, the owner reduces it to 200. MaxWeightLimitSet fires. Validators who were weighting all 400 miners must now be selective - their transactions with 400 weights will fail. They need to prioritize the 200 most important miners to evaluate.

Common Questions

What happens if I try to set more weights than MaxWeightLimit?
Your transaction will fail. You must ensure your set_weights call includes at most MaxWeightLimit miners. Check the limit before building your weight vector.
How do I choose which miners to weight when I can't weight everyone?
Common strategies: weight the miners you've actually queried, focus on top performers from previous rounds, or rotate through miners across multiple weight-setting cycles. The best approach depends on your subnet's validation requirements.
Is MaxWeightLimit always higher than MinAllowedWeight?
It should be - you can't require validators to set more weights than they're allowed to. If min > max, weight-setting becomes impossible. This is a configuration error the subnet owner must fix.

Use Cases

  • Understand validator capacity constraints
  • Monitor weight limits affecting validator strategy
  • Alert validators when max limits change
  • Optimize validator evaluation strategies within limits

How to Use This Event

  • → Check max weight limit before building validator strategies
  • → Monitor changes that affect how many miners you can evaluate
  • → Track limits across subnets for capacity planning

From Chain Metadata

the max weight limit has been set for a subnetwork.

Triggers

Preconditions

  • Caller has admin/sudo privileges
  • New limit is within valid range

Effects

Postconditions

  • MaxWeightsLimit updated for subnet
  • Weight submissions exceeding limit are truncated or rejected

Side Effects

  • Limits how many UIDs a validator can weight per submission
  • May require validators to be more selective in evaluations

Event Data

#NameTypeDescription
0
arg0
u16 Event field #0 (u16)
1
arg1
u16 Event field #1 (u16)

Code Examples

import { ApiPromise, WsProvider } from "@polkadot/api";
import { stringCamelCase } from "@polkadot/util";

const provider = new WsProvider("wss://entrypoint-finney.opentensor.ai:443");
const api = await ApiPromise.create({ provider });

// Subscribe to MaxWeightLimitSet events
api.query.system.events((events) => {
  events
    .filter(({ event }) =>
      event.section === stringCamelCase("SubtensorModule") &&
      event.method === "MaxWeightLimitSet"
    )
    .forEach(({ event }) => {
      console.log("MaxWeightLimitSet:", event.data.toHuman());
    });
});

Version History

v101 block 1 2 args
v233 block 4,920,350 2 args
v273 block 5,659,032 2 args
v290 block 5,947,548 2 args Current

Runtime Info

View Source
Pallet Index
7
Event Index
10
First Version
v101
Current Version
v393
Back to SubtensorModule Events