Documentation / Concepts Bittensor / Chaîne et Runtime
Commit Reveal
Dernière vérification le 2026-10-05
Designed to stop weight copying: validators commit timelock-encrypted weights, and the chain reveals them a set number of tempos later.
What is Commit Reveal?
Commit Reveal is designed to stop weight-copying validators. See Weight Copying.
On a subnet with Commit Reveal on, every validator's weights stay encrypted for a set number of tempos. Yuma Consensus only uses them after they are decrypted. A validator that copies weights can only see stale data, which lowers its score and makes weight copying much less profitable.
Subnet settings
Commit Reveal is on by default for every subnet. Three hyperparameters control it:
| Hyperparameter | Default | Who can set it | Meaning |
|---|---|---|---|
commit_reveal_weights_enabled | true | subnet owner or root | Turns Commit Reveal on or off for the subnet |
commit_reveal_period | 1 | subnet owner or root | Number of tempos between a commit and its reveal (set with sudo_set_commit_reveal_weights_interval) |
commit_reveal_version | 4 | root only | Network-wide format version; commits with any other version are rejected with IncorrectCommitRevealVersion |
The subnet owner's changes are subject to the usual hyperparameter rate limits.
Setting weights
When Commit Reveal is on, the chain rejects plain set_weights and set_mechanism_weights calls with CommitRevealEnabled. Instead, validators:
- Encrypt locally. The validator's client encrypts the weights with drand timelock encryption, bound to a future drand round. The Bittensor SDK and btcli do this automatically.
- Commit. The validator submits the ciphertext with
commit_timelocked_weights(orcommit_timelocked_mechanism_weightsfor a specific mechanism). The chain stores it against the current epoch. - Reveal.
commit_reveal_periodtempos later, the chain decrypts the commit with the drand pulse for that round and applies the weights. There is no separate reveal transaction and no hash-compare step.
When Commit Reveal is off, commit_timelocked_weights is rejected with CommitRevealDisabled, and validators use set_weights.
Miner ramifications
If you make changes to your miner, the resulting scores show up several tempos later:
New miner
Tempo 1: Start a miner. Validators evaluate it.
Tempo 2: Validators commit their initial weights for you.
Tempo 2 + commit_reveal_period: your initial weight appears.
Miner crashes
Tempo x: Miner crashes and stops responding to validator requests.
Tempo x+1: Validators begin lowering your score.
(Intervening tempos: scores continue to drop.)
Tempo x+1+commit_reveal_period: you start seeing the dropped scores.
Miners should not use validator scores to check whether their miners are up. With Commit Reveal, by the time the drop shows up, deregistration is almost certain.