El slashing es una penalización de proof-of-stake que elimina parte de los activos en staking cuando un validador incumple reglas que la red puede demostrar onchain. No es lo mismo que dejar de ganar recompensas, estar offline durante un periodo corto o sufrir una caída del precio del token. En Ethereum, por ejemplo, el protocolo distingue las penalizaciones normales por inactividad de acciones penalizables como proponer bloques conflictivos o emitir attestations incompatibles; la documentación oficial de recompensas y penalizaciones de Ethereum describe el slashing como una salida forzada del validador acompañada de pérdida de ETH en staking.
Para un usuario, la pregunta práctica no es solo “¿pueden hacer slashing a un validador?”, sino “¿qué capital está expuesto, en qué condiciones y cómo cambia el riesgo entre solo staking, delegación, liquid staking y staking a través de un exchange?”. La respuesta depende de la red y del servicio. Las reglas son específicas de cada protocolo y el proveedor puede añadir condiciones contractuales u operativas adicionales.
Puntos clave
- El slashing es una penalización del protocolo por fallos demostrables del validador; el downtime normal puede recibir un castigo distinto y normalmente menor.
- En redes donde los delegadores comparten riesgo, el comportamiento del validador puede afectar tanto a su propio stake como al capital delegado.
- Ethereum separa actualmente las penalizaciones por inactividad de las violaciones slashables y aumenta el riesgo económico cuando muchos validadores son penalizados de forma correlacionada.
- Las cadenas basadas en Cosmos SDK pueden configurar parámetros diferentes, por lo que no existe un único “porcentaje Cosmos”.
- En Polkadot, los nominators pueden perder parte del DOT vinculado si el validador respaldado recibe una penalización.
- Liquid staking no elimina el slashing; cambia quién opera los validadores y cómo puede distribuirse la pérdida.
- Comparar staking solo por APY deja fuera riesgos de operación, custodia, smart contracts, liquidez y slashing.
Slashing frente a penalizaciones normales
La palabra “slashing” se usa con demasiada amplitud.
Un sistema proof-of-stake suele tener varias formas de castigar mal comportamiento. No siempre trata igual una attestation perdida, un nodo offline, una firma doble y un intento activo de atacar el consenso.
Ethereum es un ejemplo claro. Su explicación oficial de proof-of-stake indica que un validador puede perder recompensas si no participa y puede perder stake si se comporta de forma deshonesta. La documentación identifica como slashables acciones como firmar dos bloques para un mismo slot o emitir attestations contradictorias.
Por eso una caída temporal de Internet no equivale automáticamente a un double-sign.
Modelo práctico de tres niveles
| Evento | Respuesta típica del protocolo | ¿Siempre es slashing? |
|---|---|---|
| El validador pierde tareas brevemente | Pérdida de recompensas o pequeñas penalizaciones | No |
| El validador permanece offline durante una falta prolongada de finality | Pueden aumentar las penalizaciones de inactividad | No necesariamente |
| Firma mensajes de consenso conflictivos demostrables | Pérdida de stake y posible salida forzada o jailing | Sí, cuando la red lo define como falta slashable |
Los parámetros concretos cambian según la red. La tabla sirve para pensar el riesgo, no como lista universal de porcentajes.
Cómo funciona el slashing en Ethereum
Ethereum documenta sus reglas con bastante precisión.
Según la documentación de recompensas y penalizaciones, un validador puede ser penalizado por:
- proponer y firmar dos bloques diferentes para el mismo slot;
- hacer un surround vote incompatible con la historia del consenso;
- votar dos veces por candidatos distintos para el mismo target.
Para un validador con balance efectivo de 32 ETH, la documentación actual describe una penalización inicial de 0,0078125 ETH y un periodo de salida forzada de 36 días. Aproximadamente a mitad del proceso se aplica una correlation penalty cuyo tamaño depende de cuánto stake haya sido penalizado alrededor del mismo periodo.
El diseño intenta separar un error aislado de un fallo coordinado capaz de amenazar el consenso. Si se penaliza a un solo validador, la pérdida puede ser relativamente pequeña frente a todo el stake. Si muchos validadores dependen de la misma infraestructura y fallan de la misma forma, el coste puede crecer de manera importante.
Por eso la concentración operativa importa. Un proveedor que ejecute muchos validadores con el mismo cliente, proveedor cloud, sistema de claves o lógica de failover puede convertir un único error en un evento correlacionado.
Downtime no equivale a slashing en Ethereum
La guía oficial de solo staking explica que estar offline mientras la red sigue finalizando no activa slashing. El validador recibe penalizaciones por inactividad que, en condiciones normales, son mucho más cercanas a las recompensas que habría ganado estando online.
La situación cambia si la red deja de alcanzar finality. Cuando más de un tercio del stake no participa correctamente, Ethereum puede activar un inactivity leak que reduce progresivamente balances hasta que el stake activo vuelve a alcanzar la supermayoría necesaria.
La escala de riesgo puede pensarse así:
- downtime breve — recompensas perdidas y pérdidas pequeñas;
- fallo prolongado de participación a escala de red — penalizaciones crecientes;
- violación slashable del consenso — pérdida de stake y salida forzada.
Un usuario que compara proveedores debería preguntar qué nivel cubre la arquitectura del servicio y no limitarse a una promesa de “uptime alto”.
Cómo funciona en cadenas Cosmos SDK
Cosmos SDK implementa slashing como un módulo configurable.
El módulo oficial de staking de Cosmos SDK describe validadores cuyo stake puede reducirse por mal comportamiento. El riesgo también puede alcanzar a delegadores porque el cálculo sigue el capital que estaba vinculado cuando ocurrió la infracción, incluyendo determinadas posiciones en unbonding o redelegation.
El diseño distingue fallos como double-sign de problemas de liveness. Un validador puede quedar jailed por downtime y, según las reglas, enviar después una transacción para volver al set. Un validador tombstoned por double-sign no puede simplemente volver con la misma identidad de consenso.
La conclusión práctica es que “slashing de Cosmos” no significa un porcentaje fijo. Las cadenas construidas con Cosmos SDK pueden configurar parámetros distintos. Antes de delegar ATOM u otro token de una cadena basada en Cosmos, hay que comprobar los parámetros específicos de esa red.
Polkadot: el nominator comparte riesgo
Polkadot deja muy claro el riesgo del delegador.
La documentación oficial para nominators advierte que hay que seleccionar validadores con cuidado porque un comportamiento incorrecto puede provocar slashing y hacer que el nominator pierda parte de su DOT.
La documentación avanzada de staking explica además que el slash se calcula como un porcentaje, por lo que posiciones más grandes pierden más tokens en términos absolutos ante la misma tasa.
Para un nominator, la pregunta deja de ser “¿quién ofrece más recompensa?” y pasa a incluir:
- concentración de infraestructura;
- historial operativo;
- diversidad de clientes cuando sea relevante;
- transparencia de prácticas;
- comisión;
- tratamiento del slashing;
- tiempo necesario para cambiar o hacer unbond.
Quién pierde dinero cuando ocurre un slash
Depende del modelo.
Validador propio
El operador controla el nodo y asume directamente las penalizaciones del protocolo.
Delegación
En redes donde los delegadores comparten riesgo, una parte del stake delegado puede perderse por el comportamiento del validador aunque el usuario no haya cometido el error técnico.
Staking-as-a-service
El usuario puede conservar credenciales de withdrawal y delegar únicamente la operación del validador. La guía de staking delegado de Ethereum recuerda que el rendimiento deficiente del proveedor sigue siendo un riesgo fuera del control directo del usuario y que un validador slashado es expulsado.
La compensación del cliente es una cuestión contractual aparte. El protocolo no garantiza automáticamente un reembolso.
Staking en exchange
El exchange puede agrupar el riesgo, compensar usuarios o reservarse condiciones especiales. Hay que leer los términos concretos y no asumir que cada pérdida del protocolo se traslada exactamente igual al cliente.
Liquid staking
Un protocolo coordina operadores y emite un token líquido. El riesgo de slashing sigue existiendo en el nivel de validadores. La forma en que afecta al usuario depende del conjunto de operadores, reservas, seguros, diseño de withdrawals y contabilidad del token líquido.
Ejemplo: por qué el APY anunciado no basta
Supongamos dos servicios:
- Servicio A: 4,5% anual antes de comisiones.
- Servicio B: 5,2%.
Mirando solo el rendimiento, B parece mejor.
Ahora añadimos riesgo:
- A usa varios operadores independientes, publica rendimiento y tiene una política clara ante pérdidas.
- B concentra infraestructura y ofrece poca información sobre slashing.
Los 0,7 puntos porcentuales adicionales no son gratuitos. El usuario recibe más rendimiento mientras acepta un perfil operativo y contractual diferente.
Una fórmula conceptual más útil es:
Resultado neto = recompensas − comisiones − pérdidas por inactividad − pérdidas por slashing − costes de liquidez − pérdidas de custodia o smart contract
Varias variables son inciertas, que es precisamente el motivo por el que APY no puede ser la única métrica.
Matriz de riesgo de slashing
| Modelo | ¿Quién opera el validador? | ¿Puede el usuario estar expuesto? | Riesgo adicional |
|---|---|---|---|
| Solo staking | Usuario | Sí | Claves, uptime, failover, clientes |
| Servicio no custodial | Proveedor | Sí | Operación del proveedor y contrato |
| Delegación / nomination | Validador | Frecuentemente sí | Selección del validador y unbonding |
| Liquid staking | Operadores del protocolo | Sí | Smart contracts, liquidez y set de operadores |
| Staking en exchange | Exchange o partner | Potencialmente | Custodia y tratamiento agregado de pérdidas |
La matriz es cualitativa. La exposición real debe comprobarse para cada red y servicio.
Riesgo correlacionado
Uno de los riesgos más infravalorados aparece cuando validadores aparentemente separados dependen de la misma infraestructura.
Ejemplos:
- misma versión de cliente;
- mismo proveedor cloud;
- mismo sistema de claves;
- mismo middleware de firma;
- misma lógica de failover;
- configuraciones copiadas;
- un único operador detrás de gran parte de un pool.
La correlation penalty de Ethereum está diseñada para que slashings simultáneos puedan ser más costosos. Incluso en redes con otras fórmulas, una dependencia común puede concentrar pérdidas.
Por eso la diversidad de operadores importa al staker aunque nunca ejecute un nodo.
¿Se puede sufrir slashing después de iniciar el unstake?
En algunos diseños, sí.
Cosmos SDK puede aplicar penalizaciones a determinadas posiciones en unbonding o redelegation si la infracción ocurrió cuando el stake aún estaba vinculado. Así se evita que un validador o delegador escape de una penalización previsible corriendo a retirar fondos después de la falta.
Otras redes utilizan reglas diferentes.
La suposición segura no es “he pulsado unstake, por tanto el riesgo terminó”. Hay que revisar el periodo de unbonding y cómo trata la cadena infracciones descubiertas con retraso.
Errores comunes
“Cualquier downtime causa slashing”
No. Muchas redes distinguen la inactividad de las violaciones slashables. Ethereum lo hace explícitamente.
“Los delegadores no pueden ser penalizados porque no operan servidores”
Incorrecto en redes donde el stake delegado comparte la penalización del validador. Polkadot y muchos modelos basados en Cosmos SDK lo contemplan.
“Liquid staking elimina el riesgo de validador”
No. Abstrae o diversifica operadores, pero los validadores subyacentes siguen sujetos a las reglas.
“Un slash siempre es el mismo porcentaje”
No. Puede depender de parámetros de red, tipo de infracción o correlación con otros fallos.
“El validador con mayor APY es el mejor”
El rendimiento es solo una variable. Concentración, historial, custodia, smart contracts, comisiones y tratamiento de pérdidas pueden ser más importantes.
Checklist antes de hacer staking
- ¿Qué acciones define la red como slashables?
- ¿El downtime normal recibe un tratamiento distinto?
- ¿Delegadores o nominators pueden perder stake?
- ¿El proveedor identifica a sus operadores?
- ¿Los validadores usan infraestructura independiente?
- ¿Existe historial público de rendimiento?
- ¿Hay política explícita de slashing o reembolso?
- ¿Quién controla las withdrawal credentials?
- ¿Cuánto dura el unbonding o exit?
- ¿Una infracción pasada puede afectar fondos después de solicitar unstake?
- En liquid staking, ¿cómo se absorben pérdidas del set de validadores?
- ¿El mayor rendimiento proviene de eficiencia o de asumir más riesgo?
Para una visión más amplia de control operativo y custodia, la guía de BTC-Pulse sobre riesgo de custodia de Bitcoin —recurso interno en inglés— explica por qué control legal, control de claves y operación son capas diferentes.
Casos límite
Un solo operador controla muchos validadores
Miles de validadores no implican necesariamente miles de dominios de fallo. Un único operador puede seguir concentrando el riesgo.
El proveedor anuncia “seguro”
Hay que revisar la cobertura concreta. Puede excluir slashing, negligencia, smart-contract exploits, eventos extremos o pérdidas por encima de un límite.
El protocolo cambia parámetros
Los sistemas proof-of-stake evolucionan. Un upgrade puede cambiar balance efectivo, penalizaciones, unbonding o recompensas. La evaluación debe repetirse después de cambios importantes.
La red usa “jailing” en lugar de “slashing”
Jailing y slashing están relacionados, pero no son idénticos. Un validador puede salir temporalmente del set activo sin sufrir la misma pérdida que un double-sign.
Preguntas frecuentes
¿Qué significa slashing en cripto?
Es una penalización del protocolo que reduce activos en staking cuando un validador comete una infracción demostrable definida por una red proof-of-stake.
¿Puedo perder todo el depósito?
En algunas redes y circunstancias severas o correlacionadas, la pérdida puede ser grande. El máximo depende del protocolo. No existe un porcentaje universal.
¿Ethereum hace slashing por estar offline?
El downtime ordinario no activa slashing por sí solo. Ethereum aplica penalizaciones por inactividad y reserva slashing para determinadas acciones de consenso conflictivas.
¿Los delegadores pueden sufrir slashing?
Sí en redes donde el stake delegado queda económicamente vinculado al comportamiento del validador.
¿Un token de liquid staking elimina el riesgo?
No. Puede cambiar la distribución del riesgo, pero los validadores subyacentes continúan expuestos.
BTC-Pulse Take
El slashing es mejor entendido como un mecanismo de seguridad que como una simple comisión de staking. Las redes proof-of-stake ponen capital real en riesgo para hacer costosos determinados ataques o fallos graves.
Para el usuario, la distinción central está entre riesgo de protocolo y riesgo de servicio. El protocolo decide qué acciones se penalizan. El proveedor decide cómo opera validadores, cuánto concentra la infraestructura, si compensa pérdidas y qué transparencia ofrece.
Por eso una decisión de staking debería empezar por las condiciones de pérdida antes que por el APY. Un rendimiento más alto puede ser atractivo, pero solo después de entender qué puede reducir el principal.
Este artículo es educativo y no constituye asesoramiento financiero ni de staking. Las reglas cambian entre redes y versiones; verifica siempre la documentación actual del protocolo y del servicio concreto.
Fuentes
- Ethereum.org — Proof-of-stake rewards and penalties
- Ethereum.org — Proof-of-stake
- Ethereum.org — Solo home staking
- Ethereum.org — Delegated staking
- Cosmos SDK — Staking module
- Polkadot Wiki — Nominator
- Polkadot Wiki — Advanced staking concepts
- Consensys — Understanding slashing in Ethereum staking
