Validator Jailed: What It Means and How Unjailing Works

2026-09-03

A validator you delegated to stops appearing in the active set, and your rewards stop arriving. Nothing was confiscated and no message explained it. The validator is jailed, which is a state the chain puts it in rather than a fee it charges, and getting out requires someone to do something rather than wait.

Validator Jailed: What It Means and How Unjailing Works: key points at a glance

What jailing actually is

Jailing is a status flag on a validator record. When it is set, the chain removes that validator from the index it uses to build the active set, so from the next block onward the validator is not signing, not proposing, and not receiving a share of block rewards.

It is a suspension of eligibility, not a charge. Nothing is deducted at the moment of jailing. The cost is the income that does not arrive while the flag is set, and the flag stays set until it is explicitly cleared.

Jailing is not slashing

These two words get used as if they were one thing, and they are separate mechanisms that happen to be triggered by the same events. Slashing burns a percentage of the stake. Jailing removes the validator from the active set. A chain can do either, both, or neither in response to the same fault, and what it does is a parameter each chain sets for itself.

That last point is where most confusion lives. On Cosmos SDK chains the downtime path does run through the slashing module, so downtime can carry a burn and not only a suspension. But the size of that burn is a parameter, and some chains set it to zero. Osmosis, Celestia and Injective all run with a downtime slash fraction of zero, which means a validator on those chains that goes offline is jailed without any stake being burned.

So the safe statement is narrow: downtime is handled by the slashing module, and whether it costs stake depends on the chain you are looking at. Do not assume either way, and do not carry a figure from one chain to another.

What puts a validator in jail

Two categories of fault, and they are treated very differently.

Downtime is measured over a sliding window of recent blocks, so the thing being judged is not uptime as a headline percentage but whether signatures landed inside that window. A validator that fails to sign more than a permitted fraction of it gets jailed. Both the window and the permitted fraction are chain parameters, and this is the clearest place to see why defaults are not values. The Cosmos SDK ships a default window of 100 blocks with a minimum signed fraction of 50%, and a downtime slash of 1%. Cosmos Hub runs a window of 10,000 blocks with a minimum signed fraction of 5%, and a downtime slash of 0.01%.

Read those two rows against each other. Every number differs, and one of them differs by a factor of a hundred. A guide that quotes SDK defaults as though they described a live chain is describing nothing that exists.

Double signing is the other category, and it is not a matter of degree. Signing two conflicting blocks at the same height is evidence of a fault the network cannot tolerate, so it carries a much larger slash and a permanent jail, which Cosmos calls tombstoning. A tombstoned validator cannot be released. Its operators have to start over with a new key, and its delegators have to move.

The two faults side by side

	Downtime	Double signing
What the chain observed	Missed too many blocks in the window	Signed two conflicting blocks at one height
Removed from the active set	Yes	Yes
Stake burned	A chain parameter, zero on some chains	Yes, and larger
Can it be released	Yes, after a waiting period	No, the jail is permanent
Cosmos name for the permanent case	Not applicable	Tombstoned

Getting out is a transaction, not a timer

This is the part that surprises delegators. The waiting period after a downtime jailing has to elapse, but when it does, nothing happens automatically. The validator operator has to submit an unjail transaction, and the chain rejects it if the validator is not jailed, if the period has not expired, if the self-delegation is below the minimum, or if the validator is tombstoned.

The practical consequence is that a jailed validator can stay jailed indefinitely while its operator is asleep, on holiday, or has abandoned the setup. The waiting period is a floor on how soon it can return, not a schedule for when it will.

What it means if you delegated

While your validator is jailed you stop accruing new rewards, because rewards are allocated across the bonded set each block and a jailed validator is not in it. Rewards you accrued before the jailing are unaffected and remain claimable.

Your options are not symmetrical, and the difference is worth knowing before you need it. Moving your stake to a different validator is a redelegation, and it takes effect immediately in the sense that your stake is recorded against the new validator in the same transaction. It will begin earning as soon as that new validator is itself in the active set. Exiting staking altogether is an undelegation, and that one always runs the full unbonding period counted from the moment you submit it.

There is a further wrinkle that works in your favour. When you redelegate away from a validator that is already unbonding, the waiting attached to that redelegation inherits the validator's own clock rather than starting a fresh one. The longer it has already been jailed, the less of that window is left for you. What that window governs is not when you start earning again; it governs whether you can hop onward to yet another validator, and whether your stake can still be reached by a slash for something the old validator did earlier.

Jail is a Cosmos word

The vocabulary does not travel, and neither do the mechanics. Jail, unjail and tombstone are Cosmos SDK terms with defined on-chain meanings.

Solana has a label that looks equivalent and is not. A validator can be reported as delinquent, but that is a classification applied by whichever RPC node you asked, using a threshold the caller passes in. It is not a consensus state. A delinquent validator is not removed from anything, keeps the leader slots its stake weight earned it, and has no release procedure to perform, because there is nothing to be released from.

Ethereum has no equivalent state either. The paths that remove a validator from its active set are voluntary exit, ejection once the effective balance falls too low, and forced exit after a slashing. There is no temporary suspension you apply to come back from.

The rule to carry away is that this whole vocabulary belongs to one family of chains. Check what the chain you are actually using calls the situation, and what it does about it, rather than assuming the words mean the same thing everywhere. The same caution applies to reading about validators in general, and to comparing designs across proof-of-stake networks.

The bottom line

Jailing suspends a validator's eligibility; slashing burns its stake. They are triggered together often enough to be confused, but whether downtime costs stake at all is a parameter that some chains set to zero.

If a validator you delegated to is jailed, three things are true at once. You are not accruing new rewards. Nobody is obliged to fix it, since release requires the operator to send a transaction. And moving to another validator is faster than leaving staking altogether, because a redelegation does not restart the clock the way an undelegation does. To keep learning the fundamentals, follow more from Bitbase Academy.