WeightsBatchRevealed

Event v205 → v212, v216 → v247, v252 → v265, v273 → v277, v290 → v315, v320 → v326, v334 → v367, v372 → v377, v385 → v402, v411 → current Changed in v411 #86

Emitted when multiple weight commits are revealed in a batch.

View events on chain
Useful for: validatorssubnet ownersanalyticsdevelopers

The Big Picture

Validators operating on multiple subnets can batch their weight reveals into a single transaction instead of revealing on each subnet separately. This saves transaction fees and simplifies operations. The event confirms all included reveals succeeded as a batch - either all apply or none do (atomic).

Why This Matters

If you validate on multiple subnets using commit-reveal, batch revealing saves significant fees and operational complexity. Instead of N transactions for N subnets, you do one. This event confirms your batch reveal worked across all included subnets.

Example Scenario

You validate on subnets 1, 3, and 7, all using commit-reveal. You committed weights on all three. Instead of three separate reveals, you batch them. WeightsBatchRevealed fires once, confirming all three subnets received their weight updates in a single transaction.

Common Questions

What if one reveal in the batch fails?
Batch operations are typically atomic - if one fails, none apply. Check for BatchCompletedWithErrors events that indicate partial failures.
Can I mix different subnets in one batch reveal?
Yes, that's the point. Batch any pending reveals into one transaction regardless of subnet.
How do I batch my reveals?
Use the batch_reveal_weights extrinsic (or similar) instead of individual reveal_weights calls. Check documentation for exact function signatures.

Use Cases

  • Batch reveal weights across multiple subnets efficiently
  • Track multi-subnet validator activity
  • Monitor batch reveal patterns
  • Optimize validator transaction costs

How to Use This Event

  • → Monitor your batch reveals for success confirmation
  • → Track validator efficiency in multi-subnet operations
  • → Build batch optimization tools for validators

From Chain Metadata

Weights have been successfully batch revealed. **who**: The account ID of the user revealing the weights. **netuid**: The network identifier. **revealed_hashes**: A vector of hashes representing each revealed weight set.

Triggers

Preconditions

  • Validator has multiple pending commits
  • All reveal hashes match their commits
  • Within reveal time window

Effects

Postconditions

  • Multiple weight sets applied
  • All revealed commits cleared

Side Effects

  • More efficient than individual reveals

Event Data

#NameTypeDescription
0
arg0
→ account
AccountId Account address (32 bytes, SS58-encoded) (hex -> SS58)
1
arg1
→ netuid
u16 NetUidSubnet ID (u16, 0-65535)
2
arg2
→ list_of_h256
Vec<H256> Vec list of 32-byte hash (Ethereum-compatible)

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

// Subscribe to WeightsBatchRevealed events
client.finalizedBlock$.subscribe(async (block) => {
  const events = await api.event.SubtensorModule.WeightsBatchRevealed.get(block.hash);
  for (const evt of events) {
    console.log("WeightsBatchRevealed:", evt.payload);
  }
});

Version History

v205 block 4,209,446 3 args
v216 block 4,510,996 3 args
v252 block 5,163,656 3 args
v273 block 5,659,032 3 args
v290 block 5,947,548 3 args
v320 block 6,523,566 3 args
v334 block 6,811,690 3 args
v372 block 7,430,358 3 args
v385 block 7,782,670 3 args
v411 block 8,283,784 3 args Current

Runtime Info

View Source
Pallet Index
7
Event Index
86
First Version
v205
Current Version
v411
Back to SubtensorModule Events