CommitRevealPeriodsSet

Event Re-added v261 → v265, v273 → v277, v290 → v315, v320 → v326, v334 → v367, v372 → v377, v385 → current #98

Emitted when the commit-reveal period length is changed.

Useful for: validatorssubnet ownersdevelopersanalytics

The Big Picture

The commit-reveal period determines how long validators must wait between commit and reveal, and how long they have to reveal before their commit expires. Shorter periods mean faster consensus cycles but tighter timing requirements. Longer periods give more breathing room but slow things down. This event signals timing policy changes.

Why This Matters

Commit-reveal timing is critical for validators. Too slow to reveal and your commit expires. Reveal too early and it might be rejected. Changes to the period affect when you can reveal and how quickly you must act. Adjust your automation accordingly.

Example Scenario

Subnet 3 had a 2-epoch reveal period but validators want faster consensus. The period is reduced to 1 epoch. CommitRevealPeriodsSet fires with netuid 3 and the new period. Validators must now reveal within 1 epoch of committing instead of 2. Tighter automation required.

Common Questions

Does this affect my existing commits?: Usually no - existing commits use the period from when they were created. New commits use the new period. Check implementation for edge cases during transition.
What happens if the period is too short for my automation?: Your commits will expire before you reveal, wasting your effort. Improve your automation's responsiveness or advocate for longer periods on subnets you validate.
Is there a minimum/maximum period?: Likely yes, to ensure meaningful commit-reveal security while remaining practical. Check the valid range for RevealPeriodEpochs on your runtime.

Use Cases

Track commit-reveal timing requirements
Adjust validator timing for new periods
Monitor subnet consensus timing policies
Build timing-aware validator automation

How to Use This Event

→ Monitor for timing changes on your subnets
→ Build adaptive timing logic in validator software
→ Track period trends across subnets

From Chain Metadata

Commit-Reveal periods has been successfully set. **netuid**: The network identifier. **periods**: The number of epochs before the reveal.

Triggers

Preconditions

Caller has admin/sudo privileges
Valid period value

Effects

Postconditions

RevealPeriodEpochs updated

Side Effects

Affects timing for future commits

Event Data

#	Name	Type	Description
0	arg0	u16	Event field #0 (u16)
1	arg1	u64	Event field #1 (u64)

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 CommitRevealPeriodsSet events
api.query.system.events((events) => {
  events
    .filter(({ event }) =>
      event.section === stringCamelCase("SubtensorModule") &&
      event.method === "CommitRevealPeriodsSet"
    )
    .forEach(({ event }) => {
      console.log("CommitRevealPeriodsSet:", event.data.toHuman());
    });
});

Version History

Version:

v261 block 5,328,895 2 args

v273 block 5,659,032 2 args

v290 block 5,947,548 2 args

v320 block 6,523,566 2 args

v334 block 6,811,690 2 args

v372 block 7,430,358 2 args

v385 block 7,782,670 2 args Current

Runtime Info

View Source

Pallet Index: 7
Event Index: 98
First Version: v261
Current Version: v393

Back to SubtensorModule Events