CommitRevealEnabled

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

Emitted when commit-reveal mode is toggled for a subnet .

Useful for: validatorssubnet ownersdevelopersanalytics

The Big Picture

Commit-reveal is a security mechanism against weight copying attacks. When enabled, validators can't just publish weights directly - they must commit a hash first, then reveal later. This prevents validators from seeing others' weights before submitting their own. Subnets toggle this based on their security needs. This event signals the policy change.

Why This Matters

If commit-reveal is enabled on a subnet you validate, your direct set_weights calls will fail. You must switch to the commit-reveal flow. Conversely, if disabled, commit-reveal is unnecessary (though may still work). This event tells you when to change your validation approach.

Example Scenario

Subnet 7 was using direct weights but has gaming problems. The owner enables commit-reveal. CommitRevealEnabled fires with netuid 7 and enabled=true. Your validator on subnet 7 must now use commit→wait→reveal instead of direct set_weights. Update your validator software accordingly.

Common Questions

Do I lose my weights if the mode changes while I have pending commits?: Mode changes typically don't invalidate pending commits. But check the implementation - you might need to reveal existing commits before switching modes.
Why would a subnet disable commit-reveal?: Complexity reduction, faster weight updates, or if the security benefit isn't needed. Some subnets have inherent protections that make commit-reveal unnecessary.
Is commit-reveal required on all subnets?: No, each subnet chooses. Some high-value subnets mandate it, others don't. Check the subnet's CommitRevealWeightsEnabled setting.

Use Cases

Track when subnets require commit-reveal validation
Update validator software for new subnet requirements
Monitor subnet security policy changes
Build adaptive validator tools

How to Use This Event

→ Monitor subnets you validate on for policy changes
→ Build adaptive validator systems that respond to mode changes
→ Track commit-reveal adoption across the network

From Chain Metadata

Commit-Reveal has been successfully toggled. **netuid**: The network identifier. **Enabled**: Is Commit-Reveal enabled.

Triggers

Preconditions

Caller has admin/sudo privileges for subnet

Effects

Postconditions

CommitRevealWeightsEnabled storage updated

Side Effects

If enabled, validators must use commit-reveal
If disabled, direct set_weights allowed

Event Data

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

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 CommitRevealEnabled events
api.query.system.events((events) => {
  events
    .filter(({ event }) =>
      event.section === stringCamelCase("SubtensorModule") &&
      event.method === "CommitRevealEnabled"
    )
    .forEach(({ event }) => {
      console.log("CommitRevealEnabled:", 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: 99
First Version: v261
Current Version: v393

Back to SubtensorModule Events