Um validador para quem você delegou some do conjunto ativo e suas recompensas param de chegar. Nada foi confiscado e nenhuma mensagem explicou o motivo. O validador está em jail, que é um estado em que a rede o coloca e não uma taxa que ela cobra dele, e sair de lá exige que alguém faça alguma coisa em vez de esperar.
O que o jailing é de fato
O jailing é uma marca de estado no registro de um validador. Quando ela está ligada, a rede tira esse validador do índice que usa para montar o conjunto ativo, então do bloco seguinte em diante ele não assina, não propõe e não recebe parte das recompensas de bloco.
É uma suspensão de elegibilidade, não uma cobrança. No momento do jailing nada é descontado. O custo é a renda que deixa de chegar enquanto a marca está ligada, e a marca continua ligada até ser explicitamente apagada.
Jailing não é slashing
Essas duas palavras são usadas como se fossem uma só, e são mecanismos separados que por acaso são disparados pelos mesmos eventos. O slashing queima uma porcentagem da participação. O jailing tira o validador do conjunto ativo. Diante da mesma falta, uma rede pode fazer uma coisa, a outra, as duas ou nenhuma, e o que ela faz é um parâmetro que cada rede define por conta própria.
Esse último ponto é onde mora quase toda a confusão. Nas redes com Cosmos SDK o caminho da inatividade passa mesmo pelo módulo de slashing, então a inatividade pode trazer queima e não só suspensão. Mas o tamanho dessa queima é um parâmetro, e algumas redes o colocam em zero. Osmosis, Celestia e Injective rodam com fração de slashing por inatividade igual a zero, o que significa que um validador que cai fora do ar nessas redes vai para o jail sem que nenhuma participação seja queimada.
Por isso a afirmação segura é estreita: a inatividade é tratada pelo módulo de slashing, e se ela custa participação depende da rede que você está olhando. Não presuma nada em nenhuma das direções e não leve um número de uma rede para outra.
O que manda um validador para o jail
As faltas vêm em duas categorias, e elas são tratadas de formas bem diferentes.
A inatividade é medida sobre uma janela deslizante de blocos recentes, então o que se julga não é a disponibilidade como porcentagem geral, e sim se as assinaturas caíram dentro daquela janela. O validador que deixa de assinar mais do que uma fração permitida dela vai para o jail. Tanto a janela quanto a fração permitida são parâmetros da rede, e este é o lugar mais claro para ver por que valores padrão não são valores reais. O Cosmos SDK vem com uma janela padrão de 100 blocos, uma fração mínima assinada de 50% e um slashing por inatividade de 1%. A Cosmos Hub roda com uma janela de 10.000 blocos, uma fração mínima assinada de 5% e um slashing por inatividade de 0,01%.
Leia essas duas linhas uma contra a outra. Todo número muda, e um deles muda por um fator de cem. Um guia que cita os padrões do SDK como se descrevessem uma rede em operação não descreve nada que exista.
A dupla assinatura é a outra categoria, e não é questão de grau. Assinar dois blocos conflitantes na mesma altura é prova de uma falta que a rede não pode tolerar, então ela traz um slashing bem maior e um jail permanente, que a Cosmos chama de tombstoning. Um validador com tombstone não pode ser liberado. Seus operadores têm de recomeçar com uma chave nova, e seus delegadores têm de se mudar.
As duas faltas lado a lado
| Inatividade | Dupla assinatura | |
|---|---|---|
| O que a rede observou | Blocos demais perdidos na janela | Dois blocos conflitantes em uma mesma altura |
| Sai do conjunto ativo | Sim | Sim |
| Participação queimada | Um parâmetro da rede, zero em algumas | Sim, e bem maior |
| Dá para liberar | Sim, depois de um período de espera | Não, o jail é permanente |
| Nome na Cosmos para o caso permanente | Não se aplica | Tombstoned |
Sair é uma transação, não um cronômetro
Esta é a parte que surpreende os delegadores. O período de espera depois de um jailing por inatividade precisa correr, mas quando ele corre, nada acontece sozinho. O operador do validador tem de enviar uma transação de unjail, e a rede a rejeita se o validador não estiver em jail, se o período não tiver vencido, se a autodelegação estiver abaixo do mínimo ou se o validador estiver com tombstone.
A consequência prática é que um validador em jail pode ficar em jail por tempo indeterminado enquanto seu operador dorme, está de férias ou simplesmente abandonou a instalação. O período de espera é um piso sobre quão cedo ele pode voltar, não um cronograma de quando vai voltar.
O que isso significa se você delegou
Enquanto seu validador está em jail você para de acumular recompensas novas, porque as recompensas são distribuídas a cada bloco pelo conjunto vinculado e um validador em jail não está nele. As recompensas acumuladas antes do jailing não são afetadas e continuam resgatáveis.
Suas opções não são simétricas, e vale conhecer a diferença antes de precisar dela. Mover sua participação para outro validador é uma redelegação, e ela vale de imediato no sentido de que sua participação fica registrada no novo validador na mesma transação. Ela começa a render assim que esse novo validador estiver ele próprio no conjunto ativo. Sair do staking por completo é uma desdelegação, e essa sempre percorre o período de desvinculação inteiro, contado do momento em que você a envia.
Há ainda um detalhe que joga a seu favor. Quando você redelega saindo de um validador que já está se desvinculando, a espera ligada a essa redelegação herda o relógio do próprio validador em vez de começar um novo. Quanto mais tempo ele já passou em jail, menos sobra dessa janela para você. O que essa janela governa não é quando você volta a render; ela governa se você pode pular adiante para mais um validador, e se sua participação ainda pode ser alcançada por um slashing por algo que o validador antigo fez antes.
Jail é uma palavra da Cosmos
O vocabulário não viaja, e a mecânica também não. Jail, unjail e tombstone são termos do Cosmos SDK com significados definidos on-chain.
A Solana tem um rótulo que parece equivalente e não é. Um validador pode ser reportado como delinquent, mas essa é uma classificação aplicada pelo nó RPC a que você perguntou, usando um limiar que o próprio chamador passa. Não é um estado de consenso. Um validador delinquent não é removido de nada, mantém os slots de líder que o peso da sua participação lhe rendeu e não tem procedimento de liberação a cumprir, porque não há de que ser liberado.
A Ethereum também não tem estado equivalente. Os caminhos que tiram um validador do seu conjunto ativo são a saída voluntária, a ejeção quando o saldo efetivo cai demais e a saída forçada depois de um slashing. Não existe ali uma suspensão temporária da qual se volta.
A regra a levar embora é que todo esse vocabulário pertence a uma família de redes. Verifique como a rede que você realmente usa chama a situação, e o que ela faz a respeito, em vez de supor que as palavras significam a mesma coisa em toda parte. O mesmo cuidado vale para ler sobre validadores em geral e para comparar desenhos entre redes de prova de participação.
Em resumo
O jailing suspende a elegibilidade de um validador; o slashing queima a participação dele. Eles são disparados juntos com frequência suficiente para serem confundidos, mas se a inatividade custa participação é um parâmetro que algumas redes colocam em zero.
Se um validador para quem você delegou está em jail, três coisas são verdadeiras ao mesmo tempo. Você não está acumulando recompensas novas. Ninguém é obrigado a consertar, já que a liberação exige uma transação do operador. E mudar para outro validador é mais rápido do que sair do staking por completo, porque uma redelegação não reinicia o relógio do jeito que uma desdelegação reinicia. Para continuar aprendendo os fundamentos, acompanhe mais conteúdos da Bitbase Academy.
Leituras relacionadas
Outros artigos da Bitbase sobre este tema:
- Capitalização automática versus staking manual: quanto vale a diferença
- O que é Lido? stETH, operadores de nós e Dual Governance
- O que é uma taxa de transação em cripto?
Aviso: Este artigo é conteúdo educacional da Bitbase Academy, fornecido apenas para fins informativos. Não constitui aconselhamento de investimento, negociação, tributário ou financeiro. Criptoativos são voláteis; avalie seu próprio risco. Escrito em setembro de 2026; consulte as informações oficiais mais recentes.
Fontes
[1] Cosmos SDK, x/slashing/types/params.go (v0.55.0, commit 64fd208a11fb54f7ffdca1a1290c2cfbbc254e49) raw.githubusercontent.com
[2] Cosmos Hub (cosmoshub-4), parâmetros de slashing on-chain rest.cosmos.directory
[3] Osmosis, parâmetros de slashing on-chain (fração de slashing por inatividade igual a zero) rest.cosmos.directory
[4] Cosmos SDK, x/staking README (mesmo commit) raw.githubusercontent.com
[5] Cosmos SDK, x/staking/keeper/delegation.go (mesmo commit) raw.githubusercontent.com
[6] Documentação de RPC da Solana, getVoteAccounts solana.com
[7] Especificações de consenso do Ethereum, phase0 beacon chain (v1.5.0) raw.githubusercontent.com
