Validators can be jailed for several reasons, such as double signing a block, signing an invalid block, or excessive downtime. Each of these reasons will have different ramifications for the validator.
When a validator is jailed, it is removed from the validator sets and cannot participate in consensus. The validator node can still run and process the new blocks. A jailed validator can also still receive bonds.
When the protocol determines that a validator will be jailed, the jailing and validator set removal will occur at the beginning of the next new epoch.
You can check if a validator is jailed by querying its state with the following command:
namadac validator-state --validator <validator_address>
Once jailed, validators remain jailed indefinitely. They can only be unjailed by an
unjail-validator transaction using the validator's signing keys. This can be done with the following command:
namadac unjail-validator --validator <validator_address>
Because the validator alias sometimes clashes with the alias for the implicit account and or established account in the wallet, it is recommended to use the validator address instead of the alias. In order to find the validator address, you can use the following command:
namadaw list --addr | grep <validator-alias>
then make sure it is the corresponding
If the transaction is successful, then the validator will be reinstated into one of the validator sets at the pipeline length relative to the current epoch (typically 2 epochs in the future).
There may be certain restrictions on unjailing your validator depending on the original reason for jailing. These will be described below.
Protocol misbehaviors include the aforementioned double signing of a block and signing of an invalid block.
In these cases, the validator will also be slashed - it and its delegates will lose stake and voting power.
When a slash is detected and enqueued by the protocol, it is scheduled to be processed
unbonding_len + cubic_slashing_window_len + 1 epochs after the infraction epoch. This is to allow for sufficient time to detect all possible correlated infractions to be considered for cubic slashing.
The validator will also be considered to be frozen until it no longer has any unprocessed, enqueued slashes. While frozen, unbonding from the validator is prohibited, and unjailing is forbidden.
A validator's slash history, with previously processed slashes and enqueued slashes for future processing, can be queried with the following command:
namadac slashes --validator <validator_address>
Additionally, all slashes in the network can be queried without the
While a validator is in the consensus set, its uptime and voting history are tracked to ensure sufficient liveness. Two proof-of-stake parameters are used to determine if a validator will be jailed for liveness:
Namada liveness requires that a consensus validator vote on at least a
liveness_threshold fraction of the last
liveness_window_check blocks. If at any point this fraction dips below the
liveness_threshold, then the validator will be jailed.
The values of these parameters can be queried with the command:
Since jailing for downtime occurs without the presence of slashes (they are not frozen), the jailed validator can unjail themselves as soon as they become jailed.