Commit Reveal
Commit Reveal is a Bittensor mechanism that delays when validator weight signals become visible. Fresh weights are concealed before they can be reused by observers (Commit Reveal, Glossary: Commit Reveal, Weight Copying Problem).
The term is about visibility timing. It does not change what validator weights mean, and it does not replace the consensus process that later interprets available validator signals.
Validators still set weights, while the chain handles the concealed commit and later reveal path. The mechanism changes when weight data becomes readable and usable, not the basic meaning of the submitted weights (Commit Reveal).
That places Commit Reveal before the open consensus calculation. The mechanism protects the timing of weight disclosure; Yuma Consensus later interprets available validator signals (Commit Reveal, Yuma Consensus).
Timing Model
At a high level, the mechanism separates a concealed phase from a later reveal phase. That two-step timing model is the core of the mechanism (Commit Reveal).
The documentation also fixes when commits are made: weight commits land in the last 10 blocks of each tempo, so committing happens in a set window near the tempo boundary rather than at an arbitrary point (Commit Reveal).
The concealment period is measured through the subnet’s configured Commit Reveal interval. During that period, the committed weights remain encrypted and are not yet included in Yuma Consensus (Commit Reveal, Yuma Consensus).
After the interval elapses, committed weights follow the reveal path that makes them readable for the next consensus calculation (Commit Reveal).
That timing model keeps the concept distinct from consensus scoring. Commit Reveal answers when weight information can be seen; available validator signals are aggregated into subnet outcomes through Yuma Consensus (Yuma Consensus).
That commit window is separate from activity cutoff vocabulary. Activity cutoff names how long a validator may remain without an on-chain update before its stake is masked inactive for consensus, measured from last update rather than from an early-epoch submission deadline (Subnet Hyperparameters: Activity Cutoff, Implementation of the Yuma Consensus Epoch: Network State Collection).
A validator can commit inside the last ten tempo blocks while remaining eligible for the epoch pass only if it is still treated as active under that last-update inactivity rule (Yuma Consensus).
How Concealment Limits Weight Copying
The weight-copying problem comes from visible weight information being useful to validators that did not independently evaluate subnet work (Weight Copying Problem, Glossary: Validator Weights).
Commit Reveal reduces that timing advantage by hiding fresh weight signals until a later reveal point. A validator that wants to copy fresh weights cannot read encrypted weights during the concealment interval, so the copied signal is less useful for immediate weight-setting behavior (Commit Reveal, Weight Copying Problem).
That protection is narrow: it makes recent signals harder to copy before disclosure. Historical public weights can still be read after reveal, but the mechanism reduces the value of copying weights before their intended reveal point (Commit Reveal).
Validators submit weights as usual, and the chain performs the time-lock encryption and reveal process around those weights rather than requiring a separate manual disclosure step (Commit Reveal).
The transaction-fee documentation lists both commit_weights and reveal_weights as fee-free
extrinsics. They pay neither the weight nor length transaction-fee component, so their commit and
reveal submissions are documented separately from ordinary fee-bearing state changes
(Transaction Fees in Bittensor,
Commit Reveal).
Once readable, revealed weights are still ordinary validator signals in the subnet’s consensus path. Commit Reveal changes their visibility schedule; it does not turn them into a separate kind of consensus input (Glossary: Validator Weights, Yuma Consensus).
Drand Locks Committed Weights Until Beacon Round
After the configured interval, the chain reveals weights when the corresponding Drand beacon pulse is available. Drand time-lock encryption keeps committed ciphertext unreadable until that target round, even for the validator who created it (Commit Reveal, Glossary: Drand/time-lock encryption).
Commit Reveal is the conceal-and-reveal scheme; Drand supplies the delayed-readability primitive. The committed weights decrypt automatically once the target Drand round’s randomness is published, with no manual reveal step required from the validator who created them (Commit Reveal, Glossary: Drand/time-lock encryption).
Subnet Settings
The mechanism belongs to subnet-specific settings, and subnet hyperparameters provide the broader vocabulary for subnet mechanism settings (Commit Reveal, Subnet Hyperparameters).
That makes Commit Reveal a subnet mechanism rather than a universal description of every validator-weight path. A subnet can be discussed in terms of whether this visibility delay is part of its weight path, while the article definition stays focused on the mechanism itself.
The subnet setting controls whether the mechanism is active and how long the reveal interval lasts. That places Commit Reveal beside subnet hyperparameter vocabulary without making it a general subnet-quality label (Commit Reveal, Subnet Hyperparameters).
This keeps the setting separate from the validator’s evaluation. A subnet can configure the visibility mechanism, while validators still supply the weight signals that later enter consensus.
Two Safety Constraints Worth Knowing
The interval setting carries a configuration gotcha and the automatic reveal closes a strategic exploit. The documentation states that a subnet’s miner immunity period, in blocks, should always be larger than the commit-reveal interval, because otherwise the immunity period expires before a miner’s scores become available and the miner can be deregistered without having its work counted. Automatic reveal, meanwhile, removes an exploit from the earlier manual-reveal design, where a validator could wait until other weights were revealed and then choose whether to reveal its own based on whether doing so would help or hurt its validator trust. Because reveal now happens on its own, a validator can no longer decline to reveal after seeing unfavorable consensus forming (Commit Reveal).
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For commit reveal on a subnet such as netuid 1, that sequence changes how readers should interpret concealed weight submission and reveal-timing examples.
In localnet, commit-reveal flows can be tested in an isolated environment. Local reveal intervals and weight visibility do not represent production subnet behavior.
On testnet, commit-reveal hyperparameters can be exercised in a shared non-production network. Testnet concealment windows on a selected netuid are separate from mainnet subnet state.
On mainnet, commit reveal is a live per-subnet mechanism on production networks. Observed reveal timing and weight visibility depend on the selected subnet’s hyperparameter settings (Subnet Hyperparameters).
The Bittensor Networks reference separates mainnet, testnet, and localnet. A commit-reveal example from one environment should not be read as representing production weight-disclosure behavior in another environment.
Distinction from Activity Cutoff
Commit reveal and activity cutoff are different weight-timing rules. Commit reveal delays when submitted validator weights become visible, concealing fresh weights for a reveal window, while activity cutoff vocabulary names how long a validator may remain without an on-chain update before its stake is masked inactive for consensus (Commit Reveal, Subnet Hyperparameters: Activity Cutoff, Subnet Hyperparameters: Activity Cutoff Factor, Yuma Consensus).
On dynamic-tempo subnets the fixed block hyperparameter is deprecated; the live inactivity span comes from activity cutoff factor and tempo instead (Subnet Hyperparameters).
Visibility-delay vocabulary and inactivity-mask vocabulary answer different participation questions on the same weight path. Commit reveal governs when ciphertext becomes readable; activity cutoff governs whether a validator’s stake still counts once last update exceeds the effective inactivity span (Subnet Metagraph, Yuma Consensus).
- Commit reveal — delays when submitted weights become visible.
- Activity cutoff — inactivity span before a stale validator is masked out of consensus.
Distinction from Immunity Period
Commit reveal and immunity period are both hyperparameter timing comparisons on the same netuid, but they protect different lifecycle risks. Commit reveal conceals fresh validator weights for a reveal interval; immunity period shields a newly registered neuron from deregistration for a block-counted window (Commit Reveal, Glossary: Immunity Period).
Official guidance recommends keeping immunity period longer than the concealed-weight interval measured in blocks so newcomers are not displaced before their scores can count under hidden weights (Commit Reveal, Subnet Hyperparameters: ImmunityPeriod).
Visibility-delay vocabulary and post-registration displacement vocabulary should be cited together from the same netuid’s settings rather than collapsed into one timing rule (Subnet Hyperparameters).
- Commit reveal — delayed visibility for validator weight signals.
- Immunity period — post-registration window that can block early displacement.
Distinction from MEV Shield
Commit Reveal and MEV Shield are both pre-inclusion concealment mechanisms, but they protect different things. Commit Reveal conceals validator weight submissions until a later reveal so recently produced weights are harder to copy, while MEV Shield encrypts sensitive pending transaction contents, such as staking and unstaking, until block inclusion so front-running and sandwich attacks cannot read them in the mempool (Commit Reveal, MEV Shield).
The two answer different questions. Commit Reveal protects a validator’s fresh weights from copiers, while MEV Shield protects a trader’s pending transaction from mempool observers, so one belongs to weight-disclosure timing and the other to transaction-ordering safety even though both delay when sensitive data becomes readable (MEV Shield).
Distinction from Weights Rate Limit
Commit reveal changes when committed weights become visible, while the weights rate limit changes how frequently a validator can submit new commits. Commit reveal is a visibility-timing mechanism; the weights rate limit is a submission-pacing hyperparameter (Commit Reveal, Subnet Hyperparameters: Weights Rate Limit).
Neither setting defines validator inactivity tolerance. Activity cutoff names the allowed silence span measured from last update before stake is masked inactive for consensus—a separate participation input on the same weight path (Subnet Hyperparameters: Activity Cutoff, Yuma Consensus).
- Commit reveal — concealment interval before weights become readable.
- Weights rate limit — minimum block wait between weight commits from the same validator.
Distinction from Weight Copying
Weight copying is reusing another validator’s visible weights instead of independent evaluation. Commit reveal delays when fresh committed weights become readable (Weight Copying Problem, Commit Reveal).
- Weight copying — dependence on copied visible weight signals.
- Commit reveal — visibility delay before weights become readable.
Distinction from Yuma Consensus
Commit reveal delays when validator weight signals become visible to observers. Validators still submit weights, but the chain conceals those signals until the configured reveal window opens (Commit Reveal, Glossary: Commit Reveal).
Yuma Consensus is the later step that aggregates revealed validator signals into subnet incentive outcomes at tempo boundaries. It concerns reward settlement once readable weights are present, not the concealment schedule that precedes them (Yuma Consensus, Commit Reveal).
- Commit reveal — delayed visibility for validator weight signals.
- Yuma Consensus — aggregation that turns revealed weights into emission shares.
Distinction from Weight Setting
Weight setting is the validator action that records miner scores on chain. Commit reveal delays when those committed weights become visible to observers (Glossary: Weight Setting, Commit Reveal).
- Weight setting — validator submission of miner scores.
- Commit reveal — concealment interval before weights are readable.
Action vocabulary names submission; commit-reveal vocabulary names delayed visibility (Subnet Hyperparameters).
Distinction from Commit Reveal Period
Commit reveal is the conceal-and-reveal weight scheme. The commit reveal period is the hyperparameter that sets how many subnet tempos the hidden window lasts (Commit Reveal, Subnet Hyperparameters).
The mechanism names the encrypted commit-and-reveal path; the period names its duration in tempos. Precise timing claims should cite the subnet whose hyperparameters are being read.
Distinction from Consensus-Based Weights
Consensus-based weights adjust validator bonds around consensus alignment as a separate copier deterrent. Commit reveal limits when fresh weight signals become visible (Consensus-based Weights, Commit Reveal).
Delayed visibility and bond adjustment address different parts of the weight-copying problem. One changes readability timing; the other changes how aligned or stale signals affect bond outcomes.
Distinction from Yuma Consensus 3
Yuma Consensus 3 and Commit Reveal act at different points around validator weights. Commit Reveal changes when weight information becomes visible, while YC3 changes how far an already submitted weight influences bond formation after consensus is known (Commit Reveal, How Yuma Consensus 3 Makes Bittensor More Fair).
- Commit Reveal — controls when weight information becomes visible.
- Yuma Consensus 3 — controls how submitted weights shape bonds after consensus.
Distinction from Drand Time-Lock Encryption
Commit Reveal is the commit-then-reveal weight submission process. Drand time-lock encryption is the timing layer that keeps committed ciphertext unreadable until the public beacon reaches the target round (Commit Reveal, Glossary: Drand/time-lock encryption, Glossary: Weight Vector).
- Commit Reveal — the two-step submission pattern that separates commit from later reveal.
- Drand time-lock encryption — the beacon-timed lock that keeps committed weights concealed until reveal.
Reader Boundary
Commit Reveal should not be read as a replacement for Yuma Consensus, a guarantee against all weight copying, proof that independent evaluation occurred, or the activity cutoff rule that masks stale validator stake. It names delayed visibility for validator weight signals before those signals become readable to observers (Commit Reveal, Glossary: Commit Reveal, Subnet Hyperparameters: Activity Cutoff).