max_weights_limit

max_weights_limit caps how much of a validator's normalized weight can land on one miner, forcing weight to spread across the pool. It is stored as a u16 fraction: 65535 means 1.0 — no cap — and, say, 6553 means no miner may hold more than ~10% of a submission's total weight.

How it works

The check is on the normalized distribution, not the raw values. On submission the chain first max-upscales the u16 values so the largest equals 65535 (vec_u16_max_upscale_to_u16), then max_weight_limited (pallets/subtensor/src/subnets/weights.rs) sum-normalizes them and rejects the whole submission with MaxWeightExceeded if the largest share exceeds max_weights_limit / 65535 (check_vec_max_limited in epoch/math.rs). A single self-weight is exempt.

In the current runtime the enforced limit is pinned: get_max_weight_limit (pallets/subtensor/src/utils/misc.rs) is a constant returning u16::MAX, so the on-chain check always passes and there is no extrinsic to change it. The MaxWeightsLimit storage map still exists and is what queries return; the SDK reads it and btcli tx set-weights (the set_weights intent) proactively clips and renormalizes your weights to fit the stored value — redistributing the excess mass rather than discarding it — and warns when clipping occurs.

Reading and setting

btcli sudo get --netuid N --name max_weights_limit

Root/governance-only — not settable by the subnet owner. Where a value is taken, it is a fraction: either the human 0..1 form with a decimal point (e.g. 0.1) or the raw integer 0..65535.

Related

• min_allowed_weights — the floor on submission size
• weights_rate_limit — how often submissions are accepted
• commit_reveal_weights_enabled — whether weights go through commit-reveal
• kappa — consensus clipping applied later, at epoch time