commit_reveal_weights_enabled

commit_reveal_weights_enabled decides how weights reach the chain. When on (the default for new subnets), validators must commit a hidden form of their weights first and the actual values only become public an epoch or more later — so weight-copying validators cannot free-ride on others' scoring work by mirroring their submissions in the same epoch.

How it works

The flag flips the accepted submission path. With it on, the plain set_weights extrinsic is rejected outright with CommitRevealEnabled (pallets/subtensor/src/macros/dispatches.rs); validators must instead commit — either a salted hash (revealed later by a matching reveal_weights call) or a timelock-encrypted payload that the chain auto-decrypts at a drand round, no reveal transaction needed. With it off, commits are rejected with CommitRevealDisabled and plain set_weights is the only path.

The reveal delay is governed by commit_reveal_period, and the weights_rate_limit cooldown applies at commit time rather than set time. Revealed weights pass through the full set_weights validation (length, cap, version key) when they land.

Validators do not need to branch on this flag themselves: btcli tx set-weights (the set_weights intent) reads it and automatically dispatches to plaintext set_weights or a timelocked commit, so the same command works in either regime.

Reading and setting

btcli sudo get --netuid N --name commit_reveal_weights_enabled

Owner-settable; the value is a flag (true/false or 1/0):

btcli sudo set --netuid N --name commit_reveal_weights_enabled --value true

Related

• commit_reveal_period — how long weights stay hidden
• weights_rate_limit — cooldown applied at commit time
• weights_version — version gate on revealed weights
• min_allowed_weights — floor on submission size in either mode