Un validateur auquel vous avez délégué cesse d’apparaître dans l’ensemble actif, et vos récompenses cessent d’arriver. Rien n’a été confisqué et aucun message ne l’a expliqué. Le validateur est en jail : c’est un état dans lequel la chaîne le place, et non des frais qu’elle lui facture ; et pour en sortir, il faut que quelqu’un agisse, pas qu’il attende.
Ce qu’est réellement le jailing
Le jailing est un indicateur d’état posé sur la fiche d’un validateur. Quand il est levé, la chaîne retire ce validateur de l’index qui lui sert à construire l’ensemble actif : dès le bloc suivant, le validateur ne signe plus, ne propose plus et ne touche plus de part des récompenses de bloc.
C’est une suspension d’éligibilité, pas un prélèvement. Au moment du jailing, rien n’est déduit. Le coût, ce sont les revenus qui n’arrivent pas tant que l’indicateur est levé, et l’indicateur reste levé jusqu’à ce qu’on l’efface explicitement.
Le jailing n’est pas le slashing
On emploie ces deux mots comme s’ils désignaient une seule chose, alors que ce sont deux mécanismes distincts que les mêmes événements déclenchent. Le slashing brûle un pourcentage de la mise. Le jailing retire le validateur de l’ensemble actif. Face à la même faute, une chaîne peut faire l’un, l’autre, les deux ou rien du tout : ce qu’elle fait est un paramètre que chaque chaîne fixe pour elle-même.
Ce dernier point est là où se loge l’essentiel de la confusion. Sur les chaînes en Cosmos SDK, le chemin de l’indisponibilité passe bel et bien par le module de slashing : l’indisponibilité peut donc entraîner une combustion et pas seulement une suspension. Mais la taille de cette combustion est un paramètre, et certaines chaînes le mettent à zéro. Osmosis, Celestia et Injective tournent toutes avec une fraction de slashing pour indisponibilité nulle, ce qui veut dire qu’un validateur qui passe hors ligne sur ces chaînes est mis en jail sans qu’aucune mise ne soit brûlée.
L’énoncé sûr est donc étroit : l’indisponibilité est traitée par le module de slashing, et savoir si elle coûte de la mise dépend de la chaîne que vous regardez. Ne présumez rien dans un sens ni dans l’autre, et ne transportez pas un chiffre d’une chaîne à une autre.
Ce qui envoie un validateur en jail
Les fautes se rangent en deux catégories, et elles sont traitées très différemment.
L’indisponibilité se mesure sur une fenêtre glissante de blocs récents : ce qui est jugé n’est donc pas la disponibilité affichée comme pourcentage global, mais le fait que les signatures soient tombées dans cette fenêtre. Un validateur qui manque de signer plus qu’une fraction autorisée de celle-ci est mis en jail. La fenêtre comme la fraction autorisée sont des paramètres de chaîne, et c’est ici qu’on voit le plus nettement pourquoi des valeurs par défaut ne sont pas des valeurs réelles. Le Cosmos SDK est livré avec une fenêtre par défaut de 100 blocs, une fraction minimale signée de 50 % et un slashing pour indisponibilité de 1 %. Cosmos Hub tourne avec une fenêtre de 10 000 blocs, une fraction minimale signée de 5 % et un slashing pour indisponibilité de 0,01 %.
Lisez ces deux lignes l’une contre l’autre. Chaque nombre diffère, et l’un d’eux diffère d’un facteur cent. Un guide qui cite les valeurs par défaut du SDK comme si elles décrivaient une chaîne en service ne décrit rien qui existe.
La double signature est l’autre catégorie, et elle n’est pas affaire de degré. Signer deux blocs contradictoires à la même hauteur est la preuve d’une faute que le réseau ne peut pas tolérer : elle entraîne donc un slashing bien plus lourd et un jail définitif, que Cosmos appelle le tombstoning. Un validateur tombstoned ne peut pas être libéré. Ses opérateurs doivent tout reprendre avec une nouvelle clé, et ses délégateurs doivent partir.
Les deux fautes côte à côte
| Indisponibilité | Double signature | |
|---|---|---|
| Ce que la chaîne a observé | Trop de blocs manqués dans la fenêtre | Deux blocs contradictoires à une même hauteur |
| Retiré de l’ensemble actif | Oui | Oui |
| Mise brûlée | Un paramètre de chaîne, nul sur certaines | Oui, et bien plus lourde |
| Libération possible | Oui, après un délai d’attente | Non, le jail est définitif |
| Nom Cosmos du cas définitif | Sans objet | Tombstoned |
La sortie est une transaction, pas un minuteur
C’est la partie qui surprend les délégateurs. Le délai d’attente qui suit un jailing pour indisponibilité doit s’écouler, mais une fois écoulé, rien ne se produit tout seul. L’opérateur du validateur doit soumettre une transaction unjail, et la chaîne la rejette si le validateur n’est pas en jail, si le délai n’a pas expiré, si l’auto-délégation est sous le minimum ou si le validateur est tombstoned.
La conséquence pratique, c’est qu’un validateur en jail peut y rester indéfiniment pendant que son opérateur dort, est en vacances ou a laissé tomber son installation. Le délai d’attente est un plancher sur la date à laquelle il peut revenir, pas un calendrier de son retour.
Ce que cela veut dire si vous avez délégué
Tant que votre validateur est en jail, vous cessez d’accumuler de nouvelles récompenses, parce que les récompenses sont réparties à chaque bloc sur l’ensemble lié et qu’un validateur en jail n’en fait pas partie. Les récompenses accumulées avant le jailing ne sont pas touchées et restent réclamables.
Vos options ne sont pas symétriques, et la différence mérite d’être connue avant d’en avoir besoin. Déplacer votre mise vers un autre validateur est une redélégation, et elle prend effet immédiatement au sens où votre mise est enregistrée au nom du nouveau validateur dans la même transaction. Elle commencera à rapporter dès que ce nouveau validateur sera lui-même dans l’ensemble actif. Sortir complètement du staking est un retrait de délégation, et celui-là parcourt toujours l’intégralité de la période de déliaison, comptée à partir du moment où vous le soumettez.
Il y a une subtilité de plus, et elle joue en votre faveur. Quand vous redéléguez depuis un validateur déjà en cours de déliaison, l’attente attachée à cette redélégation hérite de l’horloge du validateur lui-même au lieu d’en démarrer une neuve. Plus il est resté longtemps en jail, moins il reste de cette fenêtre pour vous. Ce que cette fenêtre gouverne, ce n’est pas le moment où vous recommencez à gagner ; elle gouverne votre capacité à sauter ensuite vers encore un autre validateur, et le fait que votre mise puisse ou non être encore atteinte par un slashing pour quelque chose que l’ancien validateur a fait plus tôt.
Jail est un mot de Cosmos
Le vocabulaire ne voyage pas, et la mécanique non plus. Jail, unjail et tombstone sont des termes du Cosmos SDK dotés de significations définies on-chain.
Solana a une étiquette qui semble équivalente et ne l’est pas. Un validateur peut être signalé comme delinquent, mais c’est un classement appliqué par le nœud RPC auquel vous vous êtes adressé, à partir d’un seuil que l’appelant transmet lui-même. Ce n’est pas un état de consensus. Un validateur delinquent n’est retiré de rien, conserve les créneaux de leader que son poids de mise lui a valus et n’a aucune procédure de libération à accomplir, puisqu’il n’y a rien dont le libérer.
Ethereum n’a pas non plus d’état équivalent. Les chemins qui retirent un validateur de son ensemble actif sont la sortie volontaire, l’éjection quand le solde effectif tombe trop bas, et la sortie forcée après un slashing. Il n’y existe pas de suspension temporaire dont on revient.
La règle à retenir, c’est que tout ce vocabulaire appartient à une seule famille de chaînes. Vérifiez comment la chaîne que vous utilisez vraiment nomme la situation, et ce qu’elle en fait, plutôt que de supposer que les mots veulent dire la même chose partout. La même prudence vaut pour la lecture sur les validateurs en général et pour la comparaison des conceptions entre réseaux en preuve d’enjeu.
En résumé
Le jailing suspend l’éligibilité d’un validateur ; le slashing brûle sa mise. Ils sont déclenchés ensemble assez souvent pour qu’on les confonde, mais savoir si l’indisponibilité coûte de la mise est un paramètre que certaines chaînes mettent à zéro.
Si un validateur auquel vous avez délégué est en jail, trois choses sont vraies en même temps. Vous n’accumulez pas de nouvelles récompenses. Personne n’est tenu de régler le problème, puisque la libération exige que l’opérateur envoie une transaction. Et passer à un autre validateur est plus rapide que quitter le staking pour de bon, parce qu’une redélégation ne remet pas l’horloge à zéro comme le fait un retrait de délégation. Pour continuer à apprendre les fondamentaux, suivez d’autres contenus de Bitbase Academy.
Articles associés
Autres articles Bitbase sur ce sujet :
- Capitalisation automatique ou staking manuel : ce que vaut la différence
- Qu'est-ce que Lido : stETH, opérateurs de nœuds et Dual Governance
- Qu'est-ce qu'une commission de transaction crypto ?
Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance. Les cryptoactifs sont volatils ; évaluez votre propre risque. Rédigé en septembre 2026 ; référez-vous aux informations officielles les plus récentes.
Sources
[1] Cosmos SDK, x/slashing/types/params.go (v0.55.0, commit 64fd208a11fb54f7ffdca1a1290c2cfbbc254e49) raw.githubusercontent.com
[2] Cosmos Hub (cosmoshub-4), paramètres de slashing on-chain rest.cosmos.directory
[3] Osmosis, paramètres de slashing on-chain (fraction de slashing pour indisponibilité fixée à zéro) rest.cosmos.directory
[4] Cosmos SDK, x/staking README (même commit) raw.githubusercontent.com
[5] Cosmos SDK, x/staking/keeper/delegation.go (même commit) raw.githubusercontent.com
[6] Documentation RPC de Solana, getVoteAccounts solana.com
[7] Spécifications de consensus d’Ethereum, phase0 beacon chain (v1.5.0) raw.githubusercontent.com
