Commit Reveal Period
Commit reveal period is a per-subnet hyperparameter, listed in the documentation as
CommitRevealPeriod, that sets how many
tempos must elapse before committed
validator weights are revealed under the
commit-reveal weight scheme. The
Subnet Hyperparameters reference
describes it as the number of tempos, or epochs, that must elapse before validator weights are
revealed.
What It Controls
The hyperparameter sets the delay, counted in tempos, between when a validator commits an encrypted weight set and when that weight set is revealed and usable in consensus. Commit-reveal exists so that validator weights are hidden while they are fresh, which reduces weight copying; the period is the length of that hidden window (Commit Reveal).
It does not enable or disable the scheme itself. Whether commit-reveal is on is a separate boolean setting; commit reveal period only governs how long the reveal is deferred once the scheme is active (Subnet Hyperparameters).
Documented Type, Default, and Setter
The Subnet Hyperparameters
reference lists CommitRevealPeriod as a u64 with a default of 1, meaning one tempo elapses
before reveal by default. Because each subnet carries its own hyperparameters, the period on netuid
1 can differ from another subnet’s reveal delay
(Subnet Hyperparameters).
The setter name does not match the parameter name. While the hyperparameter is CommitRevealPeriod
and the btcli command is btcli sudo set --param commit_reveal_period, the underlying extrinsic
is sudo_set_commit_reveal_weights_interval. The reference marks the permission required to set it
as subnet owner, so a subnet owner can change the reveal delay for their own subnet
(Subnet Hyperparameters).
Operationally, the value is changed through the documented btcli sudo set form
btcli sudo set --param commit_reveal_period --value <tempos> --netuid <netuid>, supplying the
reveal delay in tempos for the target subnet
(Subnet Hyperparameters).
The value in force is per-subnet chain state and can differ from the documented default, so a
subnet’s real reveal delay should be read for that subnet rather than assumed from the reference
value. For the documented example netuid 1 on Finney mainnet it can be read with
btcli subnet hyperparameters --netuid 1 --network finney, keeping the reveal-delay claim
reproducible against a parseable netuid
(Subnet Hyperparameters: View hyperparameters).
Because the period is counted in tempos rather than blocks, the real-time length of the hidden
window depends on the subnet’s tempo as well as the period itself. The same CommitRevealPeriod of
one tempo conceals committed weights for more blocks on a subnet with a long tempo than on one with
a short tempo, so two subnets that share the same period value can still reveal weights after
different numbers of blocks
(Subnet Hyperparameters,
Glossary: Tempo,
Commit Reveal).
That block conversion matters for miner immunity. The commit-reveal guide warns that the subnet’s
immunity period, measured in blocks, should be larger than the reveal interval after conversion:
CommitRevealPeriod × tempo. Otherwise a newly registered miner’s immunity can expire before its
concealed scores are available, allowing deregistration before the work has been counted
(Commit Reveal: Commit Reveal and the neuron immunity period,
Subnet Hyperparameters: ImmunityPeriod).
The documentation illustrates that conversion with a worked example: a CommitRevealPeriod of 3 at
the documented default tempo of 360 blocks reveals committed weights after 3 tempos, or 1080 blocks
(Subnet Hyperparameters: CommitRevealPeriod,
Glossary: Tempo).
Distinction from Commit Reveal
Commit-reveal is the weight-privacy scheme that hides committed weights until reveal, while commit reveal period sets how many tempos that hidden window lasts. One names the mechanism; the other sets its timing (Commit Reveal, Subnet Hyperparameters).
- Commit reveal — the scheme that commits encrypted weights and later reveals them.
- Commit reveal period — the number of tempos before the reveal happens.
Distinction from Tempo
Tempo is the block-length cadence of a subnet’s consensus cycle, while commit reveal period is measured in those tempos. Tempo sets how long one epoch is; commit reveal period sets how many of those epochs pass before a reveal (Glossary: Tempo, Subnet Hyperparameters, Commit Reveal).
- Tempo — the length of one consensus cycle, in blocks.
- Commit reveal period — a count of tempos until weights are revealed.
Distinction from Weights Version Key
The commit reveal period sets how many tempos pass before a committed weight set is revealed under commit-reveal, while the weights version key rejects submissions carrying an outdated weights version. One delays when accepted weights become visible; the other screens which submissions are accepted (Subnet Hyperparameters, Commit Reveal).
- Commit reveal period — tempos before committed weights are revealed.
- Weights version key — gates submissions by required version.
Distinction from Weight Copying
Commit reveal period is the hyperparameter count of tempos before committed validator weights are revealed. Weight copying is the problem where validators reuse visible weight signals instead of evaluating miner work independently (Subnet Hyperparameters, Weight Copying Problem).
The reveal delay blunts copying by hiding fresh weights until the period elapses, so a copier cannot ride the latest signal before reveal (Commit Reveal).
- Commit reveal period — tempos before committed weights become visible.
- Weight copying — reusing visible weights instead of independent evaluation.
Distinction from Time Lock Encryption
The commit reveal period is the CommitRevealPeriod hyperparameter that sets how many tempos pass
before committed weights are revealed. Time-lock encryption is the cryptographic primitive that
keeps committed weights unreadable across that window
(Subnet Hyperparameters,
Commit Reveal,
Glossary: Drand / Time-Lock Encryption).
- Commit reveal period — how many tempos committed weights stay hidden.
- Time-lock encryption — the crypto that enforces that concealment for the full period.
Chain Reads for netuid 1
Readers can verify live hyperparameter values for the documented example netuid with
btcli subnet hyperparameters --netuid 1 --network finney
(Subnet Hyperparameters: View hyperparameters).
That read path keeps live hyperparameter claims tied to a parseable netuid.
Per-Subnet Live Value Boundary
Commit reveal period is per-subnet chain state. The tempo count before committed validator weights become visible applies only on the subnet where commit-reveal is active and can differ from the reference default of one tempo (Subnet Hyperparameters, Commit Reveal).
Enabling commit-reveal and setting its period are separate controls. The period names how long weights stay hidden once the scheme is on; it does not by itself turn commit-reveal on for a subnet (Subnet Hyperparameters).
This article’s infobox uses netuid 1 as an example label when reading one subnet’s hyperparameter table on Finney mainnet. That example helps readers verify one row; it is not proof that every subnet exposes the same live reveal delay (Bittensor Networks).
Commit reveal period governs disclosure timing; Yuma Consensus still aggregates revealed validator weights into emission shares each epoch on the active subnet (Yuma Consensus).
- Commit reveal period — tempos before committed weights are revealed on a subnet.
- Per-subnet boundary — live delay is chain state on one netuid.
Distinction from Yuma Consensus
Commit reveal period is a per-subnet hyperparameter that counts tempos before committed validator weights become visible. That disclosure-timing rule is separate from the settlement pass that aggregates revealed weights into emission shares (Subnet Hyperparameters, Yuma Consensus).
Validators may commit weights privately during the period, then reveal them for aggregation. Yuma credits miner incentives and validator dividends from the included weight matrix when the epoch closes (Emission).
Readers should keep weight-disclosure timing and settlement timing separate. Commit reveal period names how long weights stay hidden; Yuma names how revealed submissions become credited shares (Commit Reveal).
- Commit reveal period — tempo delay before committed weights reveal.
- Yuma Consensus — on-chain settlement that turns validator weights into emission shares.
Reader Boundary
This page defines commit reveal period at a high level. It does not report the live
CommitRevealPeriod value on any particular subnet or whether commit-reveal is enabled there. Those
are per-subnet hyperparameter settings that should be checked for the relevant netuid
(Subnet Hyperparameters).