batch_reveal_weights

Call v205 → current #98

Reveals committed weights on multiple subnets in a single transaction.

View calls on chain

Click items to navigate. Pan and zoom to explore.

Used by: validatorsdevelopers

The Big Picture

The companion to batch_commit_weights. Once your commits are in and reveal windows open, batch_reveal_weights completes the cycle for multiple subnets atomically. Critical for timing - if reveal windows are similar, batching ensures all your weights update together without the risk of missing individual windows.

Why This Matters

Missing a reveal window means your weights don't count for that epoch. Batching reduces the chance of partial reveals (where some subnets update and others don't). One transaction, all reveals, consistent validator behavior across your subnet portfolio.

Example Scenario

You committed weights to subnets 1, 3, 7, 18. Reveal windows all open at block 1,000,000. Call batch_reveal_weights(netuids=[1,3,7,18], uids_list=[[...],[...],[...],[...]], weights_list=[[...],[...],[...],[...]], salts=['salt1','salt2','salt3','salt4']). All four reveals execute atomically. Weights applied, commits cleared.

Common Questions

What if reveal windows don't align perfectly?
You can only batch subnets whose windows are currently open. If subnet 1's window is blocks 1000-1100 and subnet 3's is 1050-1150, batch during the overlap (1050-1100).
What if I reveal with wrong weights/salt?
The hash won't match, and that subnet's reveal fails. Depending on batch semantics, this might fail the entire batch. Double-check all parameters.
Can I mix batch_commit with individual reveals?
Yes - commits and reveals are independent. Batch commit then reveal individually, or individual commits with batch reveal. Use whatever fits your timing needs.

Use Cases

  • Complete multi-subnet commit-reveal cycle in one transaction
  • Synchronized weight updates across subnet portfolio
  • Gas-efficient reveals for large validator operations
  • Ensure all weights land in same block for consistency

From Chain Metadata

- The implementation for batch revealing committed weights.

Input Parameters

#NameTypeDescription
0
netuid
u16 Subnet/network identifier (0-65535)
1
uids_list
Vec<Vec<u16>> Vecuids_list (Vec<Vec<u16>>)
2
values_list
Vec<Vec<u16>> Vecvalues_list (Vec<Vec<u16>>)
3
salts_list
Vec<Vec<u16>> Vecsalts_list (Vec<Vec<u16>>)
4
version_keys
Vec<u64> Vecversion_keys (Vec<u64>)

Permissions

Origin
Signed
Required Role
Any

Permission data inferred from metadata. May be incomplete.

Requirements

  • Commits exist for all target subnets
  • Reveals match their commitments
  • Within reveal windows for all subnets

Effects

Postconditions

  • Weights applied on all subnets
  • Commits cleared
  • Weight versions incremented

Side Effects

  • Efficient multi-subnet weight reveal
  • Affects next epoch's consensus on all subnets

Possible Errors

NotEnoughStakeToSetWeightsWeightVecNotEqualSizeNotSettingEnoughWeightsWeightVecLengthIsLowMaxWeightExceededSettingWeightsTooFastIncorrectWeightVersionKeyCanNotSetRootNetworkWeightsNoWeightsCommitFoundWeightsCommitNotAllowedExpiredWeightCommitCommittingWeightsTooFastAdminActionProhibitedDuringWeightsWindow

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 });

// Build batch_reveal_weights call
const netuid = 1;
const uids_list = 0;
const values_list = 0;
const salts_list = 0;
const version_keys = 0;

const call = api.tx[stringCamelCase("SubtensorModule")][stringCamelCase("batch_reveal_weights")](
  netuid,
  uids_list,
  values_list,
  salts_list,
  version_keys
);

Runtime Info

View Source
Pallet Index
7
Call Index
98
First Version
v205
Current Version
v393
Back to SubtensorModule Calls