# Commit Reveal

Designed to stop weight copying: validators commit timelock-encrypted weights, and the chain reveals them a set number of tempos later.

_Source: https://beta.taostats.io/docs/concepts/chain-runtime/commit-reveal-30_

_Last reviewed: 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](https://beta.taostats.io/docs/concepts/validators/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:

1. **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.
2. **Commit.** The validator submits the ciphertext with `commit_timelocked_weights` (or `commit_timelocked_mechanism_weights` for a specific mechanism). The chain stores it against the current epoch.
3. **Reveal.** `commit_reveal_period` tempos 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.