---
title: "Riesgo de slashing correlacionado en el restaking"
description: "El restaking puede exponer una cartera a varios servicios sujetos a slashing. Descubre cómo operadores, software, infraestructura y demoras de salida compartidos pueden producir pérdidas correlacionadas."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Riesgo de slashing correlacionado en el restaking
> Solo con fines educativos; no constituye asesoramiento de inversión. El restaking puede causar la pérdida parcial o total del capital.
## Respuesta directa
El riesgo de slashing correlacionado es la posibilidad de que un fallo subyacente cause pérdidas simultáneas en varias exposiciones de restaking. Compartir operadores, sistemas de firma, clientes, regiones de nube, oráculos, gobernanza o contratos inteligentes puede hacer que servicios aparentemente separados fallen juntos.
El restaking reutiliza stake económico para proteger servicios adicionales, llamados con frecuencia servicios validados activamente (AVS). Pueden acumularse las recompensas, pero también los riesgos de protocolo, operador, contrato inteligente, liquidez y salida. El rendimiento anunciado no mide de forma fiable la pérdida máxima.
La cantidad sujeta a slashing depende de los contratos vigentes, el stake asignado a cada conjunto de operadores, la política de cada servicio y cualquier periodo de retiro o desasignación que siga siendo sancionable. No debe deducirse de un porcentaje genérico ni del historial de incidentes.
## Cómo funciona
En el modelo actual de stake único de EigenLayer, un operador asigna partes del stake delegado a conjuntos de operadores. Las asignaciones de una estrategia no pueden superar el 100% y una misma parte no puede ser stake único de dos conjuntos. Cada servicio puede penalizar la parte asignada a su conjunto según sus reglas.
Esta contabilidad limita el doble uso del mismo stake único, pero no independiza las pérdidas. Un despliegue defectuoso puede afectar varias partes asignadas, muchos operadores pueden compartir una dependencia y los validadores nativos de ETH también pueden sufrir penalizaciones o slashing del consenso de Ethereum.
Rendimiento neto esperado = recompensas esperadas - comisiones - coste de oportunidad - pérdidas esperadas por slashing y liquidez
Estima las pérdidas por escenarios, no sumando rendimientos anunciados. Revisa al menos lo siguiente:
- Registra la estrategia, operador, conjunto, porcentaje asignado y cantidad sancionable de cada servicio.
- Lee cada condición sancionable, norma probatoria, autoridad, proceso de disputa o veto y slashing máximo.
- Identifica clientes, claves, firmantes, regiones de nube, oráculos, administradores de actualización y participantes de gobernanza compartidos.
- Comprueba las demoras de retiro y desasignación, pues las participaciones en cola pueden seguir sujetas a slashing hasta que termine la demora.
## Ejemplo
Supón que 100 ETH se delegan a un operador: 40% al conjunto A, 30% al B y 30% queda sin asignar. Si un fallo de software compartido hace que A penalice el 50% de su asignación y B el 100%, la pérdida es 20 ETH + 30 ETH = 50 ETH. Es una ilustración, no una fórmula universal; las reglas, penalizaciones posteriores, sanciones de Ethereum y el descuento de mercado de un LRT pueden cambiar la pérdida realizada.
## Riesgos
- **Concentración oculta:** operadores con nombres distintos pueden usar el mismo cliente, firmante, centro de datos o región de nube.
- **Riesgo de reglas y gobernanza:** un servicio puede definir condiciones amplias o depender de un comité, clave de actualización o disputa que falle.
- **Riesgo residual de salida:** solicitar retiro o desasignación puede no terminar de inmediato la exposición al slashing.
- **Pérdida de liquidez:** un LRT puede cotizar bajo el valor de sus activos durante una crisis y añadir pérdidas antes de la liquidación contable.
## Errores comunes
### Mito 1: Más AVS diversifican automáticamente el riesgo
Solo diversifican cuando las fuentes de fallo y las asignaciones sancionables son realmente independientes.
### Mito 2: Si nunca hubo slashing, el riesgo es bajo
Un historial corto o tranquilo puede no incluir una prueba de estrés relevante. Los permisos y escenarios importan más que cero incidentes.
### Mito 3: Un fondo de seguros garantiza el reembolso
La cobertura depende del tamaño, eventos elegibles, exclusiones, prioridad y gobernanza. Anunciar seguro no equivale a cobertura financiada y exigible.
### Mito 4: Salir termina la responsabilidad de inmediato
Los retiros o desasignaciones en cola pueden seguir sujetos a slashing durante las demoras, y un LRT puede tener demoras de liquidez y reembolso.
## Temas relacionados
- [Seguridad criptoeconómica](/es/crypto/crypto-economic-security/)
- [Staking líquido](/es/crypto/liquid-staking/)
- [Restaking](/es/crypto/restaking/)
- [Slashing](/es/crypto/slashing/)
- [Cola de salida y retiro de validadores](/es/crypto/validator-exit-withdrawal-queue/)
## Fuentes
- [ELIP-002: Slashing mediante stake único y conjuntos de operadores](https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-002.md) - Eigen Foundation (consultado: 2026-08-21)
- [DelegationManager: slashing y contabilidad](https://github.com/Layr-Labs/eigenlayer-contracts/blob/main/docs/core/DelegationManager.md) - EigenLayer (consultado: 2026-08-21)
- [Recompensas y penalizaciones de prueba de participación](https://ethereum.org/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/) - Ethereum.org (consultado: 2026-08-21)
Source: https://wiki.fcontext.com/es/crypto/restaking-correlated-slashing-risk/index.mdx