Restaking en EigenLayer: AVS, operadores y un segundo circuito de slashing
Restaking es una ampliación voluntaria de las reglas del staking: ETH ya staked (o LST) se delega adicionalmente en EigenLayer para que una misma garantía proteja la seguridad de varios servicios.
El error principal es reducir el restaking a “más rentabilidad”. En el modelo de EigenLayer no solo se añade una fuente de pagos, sino también un circuito independiente de sanciones: las condiciones de slashing no las define solo Ethereum, sino también servicios externos.
EigenLayer vincula el stake de Ethereum con servicios externos a través de AVS: el servicio paga a los operadores por cumplir las reglas y obtiene un mecanismo de sanciones (slashing) como garantía criptoeconómica.
En una sola frase: el restaking en EigenLayer es la conexión de ETH ya staked (o LST) con servicios externos (AVS) a través de operadores, para que la garantía pase a ser slashable según sus reglas.
Mecánica mínima: el restaker delega la garantía a un operador → el operador presta servicio al AVS elegido → el AVS paga una recompensa → si se incumplen las reglas, el AVS inicia el slashing según una política predefinida.
A continuación se explican los roles de restaker / operator / AVS, la arquitectura de conexión de la garantía (native ETH y LST), las fuentes de pagos (pagos de AVS) y las fuentes de riesgo (política de slashing del AVS, elección del operador y fallos correlacionados).
Restaking: convierte ETH en una garantía “reutilizable”: un mismo stake protege la seguridad de Ethereum y de los AVS elegidos, y el precio de esos pagos son las reglas de slashing de los AVS y la dependencia de los operadores.
Material actualizado → se reforzó el foco en la arquitectura de EigenLayer (AVS/operadores) y en el segundo circuito de slashing.
- Se separaron mejor las intersecciones → “qué es restaking” se movió al ángulo de “mercado de responsabilidad / price of error”.
- Se precisaron los escenarios de RSFi → el descuento de LRT se vinculó al riesgo AVS y a los eventos correlacionados.
Cómo funciona el protocolo EigenLayer en el ecosistema Ethereum
EigenLayer es un protocolo de smart contracts en Ethereum que permite hacer slashable (sujeto a sanciones) ETH ya staked (o LST) según las reglas de servicios externos (AVS) mediante delegación a operadores.
Flujo básico: la garantía se conecta a EigenLayer → se delega a un operador → el operador presta servicio a los AVS elegidos → el AVS paga por el funcionamiento correcto → si se incumplen las reglas del AVS, se aplica una sanción (slashing) a la garantía asignada.
Roles en EigenLayer: restaker / operator / AVS
| Rol | Qué aporta | Qué ejecuta | Dónde surge el riesgo |
|---|---|---|---|
| Restaker | Garantía (ETH/LST) delegada a un operador | Elección del operador y del conjunto de AVS a respaldar | Slashing según las reglas del AVS + dependencia del comportamiento del operador |
| Operator | Infraestructura y ejecución del stack AVS | Firmas/pruebas/disponibilidad según los requisitos del AVS | Sanciones por incumplir las reglas del AVS; error operativo |
| AVS | Reglas de validación y política de slashing/recompensas | Comprobación de la corrección de las acciones de los operadores (según su propia lógica) | Errores en el diseño de reglas, bugs en contracts/verificación |
Conexión de la garantía: native ETH y LST
- Native ETH: el validador vincula la dirección de retirada a EigenPod para que el stake se contabilice en EigenLayer y pueda quedar sujeto a las reglas del AVS.
- LST: los LST se depositan en las estrategias de EigenLayer y luego se delegan a un operador sin lanzar un nodo propio.
Slashing en restaking: reglas del AVS y garantía asignada
- Las condiciones las define el AVS: las infracciones se formulan a nivel del servicio (por ejemplo, firmas incorrectas, incumplimiento de tareas o violación de los requisitos de disponibilidad).
- La sanción se vincula a la garantía asignada: el castigo se aplica a la parte del stake delegado que participa en el servicio de un AVS concreto según sus reglas.
Filtro práctico de riesgo: el perfil de riesgo lo determinan el conjunto de AVS del operador, su política de slashing y la capacidad del operador para prestar servicio a ese conjunto sin caída de uptime ni de calidad de ejecución.
EigenLayer conecta el stake delegado y los servicios externos a través de operadores: el AVS paga por cumplir las reglas, y el incumplimiento puede llevar al slashing de la garantía asignada.
Ejemplos de uso de EigenLayer y restaking en la práctica
AVS (Actively Validated Services) usan restaking como mecanismo de responsabilidad: el operador recibe pagos por cumplir las reglas del servicio, y el incumplimiento puede llevar al slashing de la garantía asignada en Ethereum.
Plantilla AVS: el servicio define una obligación → define una comprobación (cómo se registra la infracción) → define una sanción (volumen y condiciones) → el operador responde con la garantía delegada.
Data Availability (EigenDA y análogos)
Los servicios DA responden a la pregunta del ecosistema rollup: si están disponibles los datos necesarios para comprobar el estado y reconstruir el historial.
- Qué se compromete a hacer el operador: almacenar fragmentos de datos (chunks — partes de un conjunto de datos) y entregarlos según las reglas del protocolo en ventanas de tiempo definidas.
- Qué se considera infracción: falta de disponibilidad de datos, negativa a entregarlos, confirmación de disponibilidad sin entrega real.
- Por qué aquí se necesita restaking: la disponibilidad de datos pasa a ser una obligación sancionable, y no una promesa del proveedor.
- Qué obtiene el mercado: la capa DA escala por separado de L1, reduciendo la carga sobre Ethereum sin almacenamiento “de confianza”.
El restaking convierte DA en una
Oráculos y servicios de datos
En los oráculos, el valor del restaking está en el “precio del error”: datos incorrectos desencadenan liquidaciones y cambian parámetros de riesgo, por eso se necesita una sanción económica por distorsionar el flujo.
- Qué se compromete a hacer el operador: publicar datos correctos (por ejemplo, el precio) según el formato, la frecuencia y las fuentes acordadas.
- Qué se considera infracción: sustitución intencionada, manipulación coordinada, retraso sistemático de actualizaciones (stale data — datos “desactualizados”).
- Por qué aquí se necesita restaking: atacar los datos debe ser más caro que la ganancia potencial; de lo contrario, los incentivos se rompen.
- Cómo suele “integrarse” la responsabilidad: el AVS define las reglas de participación y sanción; el peso o las cuotas pueden tener en cuenta el stake delegado, pero el riesgo lo determinan las condiciones de slashing del servicio concreto.
El restaking eleva el
Restaked rollups y componentes L2
Parte de la infraestructura de L2 puede trasladarse a un AVS y vincularse a la responsabilidad sancionable de los operadores, en lugar de construir una propia “economía de validadores” (un conjunto separado de participantes e incentivos de seguridad).
- Qué se compromete a hacer el operador: cumplir las reglas del componente L2 (orden de acciones, publicaciones y comprobaciones acordadas) en las condiciones establecidas.
- Qué se considera infracción: afirmaciones conflictivas sobre el estado, censura, negativa a prestar servicio o violación de las garantías del protocolo del servicio.
- Por qué aquí se necesita restaking: la responsabilidad sancionable reduce la dependencia de la “buena fe” de un conjunto limitado de operadores.
- Qué obtiene el mercado: lanzamiento rápido de servicios y menos incentivos para construir un token separado solo por seguridad.
Un componente L2 puede recibir
Cómputo y resultados verificables
En los AVS de cómputo, la tarea se formula como un contrato sobre el resultado: el pago se realiza por la ejecución según el protocolo, y el sabotaje pasa a ser un riesgo sancionable.
- Qué se compromete a hacer el operador: ejecutar un cálculo o procedimiento y proporcionar una confirmación del resultado según las reglas del servicio.
- Qué se considera infracción: sustitución del resultado, incumplimiento o incompatibilidad con el formato de verificación o prueba.
- Por qué aquí se necesita restaking: la “honestidad de ejecución” se traslada de la confianza en el proveedor a la responsabilidad económica.
- Qué obtiene el mercado: infraestructura de cómputo con un precio del error controlado y obligaciones sancionables para los participantes.
El restaking convierte la calidad de ejecución en una
Categorías AVS: puentes y mensajeros cross-chain (stablecoins bridged vs native), módulos ZK (verificación de pruebas de conocimiento cero), redes DePIN (infraestructura física descentralizada) y servicios de coordinación donde es importante fijar la responsabilidad económica de los operadores por incumplir las reglas.
Criterio de aplicación: el restaking se usa allí donde se necesita un precio del error elevado: el AVS paga por el cumplimiento de reglas; el incumplimiento hace que el stake asignado de los operadores sea sancionable.
Restaking como mercado de responsabilidad: security budget y precio del error
En EigenLayer, los pagos no aparecen “por el simple hecho de hacer staking”, sino por asumir obligaciones adicionales: el AVS compra la corrección de ejecución sancionable, y el riesgo lo determinan la política de slashing y la complejidad operativa.
Marco corto: security budget es “cuánto cuesta un ataque o sabotaje”. El restaking eleva el presupuesto de seguridad no con promesas, sino con el vínculo “regla verificable → trigger formal de infracción → sanción a la garantía asignada”.
-
El AVS compra responsabilidad, no “liquidez”.
- Sentido del acuerdo: el servicio paga por cumplir requisitos (firmas, disponibilidad y resultados correctos), y el incumplimiento se convierte en daño medible mediante slashing.
- Qué se fija: el “precio del error” lo definen las reglas del AVS, y no la reputación del proveedor.
-
El restaking cubre la debilidad inicial de los nuevos protocolos.
- Problema: el conjunto propio de validadores al inicio es pequeño, por lo que el coste del ataque suele ser bajo.
- Efecto práctico: el servicio accede a un pool más grande de stake delegado sin emitir un token separado “por seguridad”.
-
El rendimiento es un pago por el riesgo y la complejidad de ejecución.
- Fuente de pagos: pagos de AVS a operadores (teniendo en cuenta comisiones y requisitos).
- Precio de los pagos: la probabilidad de slashing crece junto con el número de AVS, la complejidad del stack y las correlaciones de infraestructura.
Regla del mercado: el restaking es un mercado de seguridad compartida donde el “coste” lo definen la política de slashing, los caps de daño y la calidad de la ejecución operativa, y no los porcentajes de escaparate.
EigenLayer monetiza la seguridad como servicio: el AVS paga por reglas y garantías sancionables, y el stake recibe un flujo adicional de pagos junto con un circuito adicional de slashing.
Ventajas de restaking en EigenLayer para validadores y holders de ETH
Restaking añade al staking de ETH un segundo circuito de responsabilidad: los pagos provienen de los AVS, y el riesgo lo definen sus reglas de slashing y la calidad de los operadores.
Lógica de las ventajas: los pagos adicionales aparecen solo allí donde el stake asume responsabilidad adicional. En restaking, la responsabilidad la define la política de slashing de AVS concretos y la calidad de ejecución de los operadores.
Ventajas del restaking: fuente de pagos y precio del riesgo
-
Pagos por encima del staking básico
Fuente: pagos del AVS por prestar servicio a las reglas del servicio (a través del operador y su comisión).
Precio: slashing según las reglas del AVS y dependencia de la fiabilidad operativa del operador.
-
Diversificación de flujos de pagos
Fuente: conjunto de AVS del operador (distintos modelos de pago y distintos requisitos).
Precio: superposición de riesgos: un fallo del operador puede afectar a varios AVS al mismo tiempo.
-
Participación sin nodo propio mediante LST/LRT
Fuente: estructuras líquidas (LST) y capas superiores (LRT) que combinan recompensas básicas y pagos AVS en un solo activo.
Precio: circuitos adicionales de riesgo: smart contracts, depeg o descuento, liquidez de salida y condiciones del protocolo LRT.
-
Flexibilidad en la distribución de la responsabilidad
Fuente: la delegación al operador y la elección de AVS determinan qué parte del stake queda sujeta a qué reglas.
Precio: la limitación del riesgo solo funciona mediante límites formales y arquitectura de estrategias, y no mediante intenciones.
-
Demanda de stake de ETH como “servicio de seguridad”
Fuente: los AVS compran seguridad al mercado de stake de Ethereum en lugar de emitir un token para validadores.
Precio: la seguridad se convierte en un mercado competitivo: cambian las condiciones de pago, los conjuntos de AVS y los requisitos para operadores.
Ejemplo (sin cifras): la recompensa básica por el staking de Ethereum se mantiene, y encima puede aparecer un pago de uno o varios AVS. El resultado final lo determinan dos parámetros: (1) la suma de pagos AVS; (2) el perfil de riesgo: política de slashing y probabilidad de errores operativos del operador elegido.
El restaking eleva la eficiencia del capital (una garantía respalda varios circuitos de pagos y responsabilidad) gracias a los pagos AVS, pero amplía el circuito de slashing y hace que la gestión del riesgo sea una parte obligatoria del modelo.
Riesgos del restaking: slashing, errores correlacionados y presión sobre Ethereum
Los pagos de AVS son la contraprestación por una responsabilidad adicional: al slashing de Ethereum se suman reglas de sanción de servicios externos, y los fallos correlacionados aumentan la probabilidad de escenarios en cascada.
Dos circuitos de sanción: Ethereum define el slashing para el consenso de L1, y el restaking añade slashing según las reglas del AVS. El riesgo lo determinan la política de slashing del AVS y la fiabilidad operativa del operador.
Slashing según las reglas del AVS
El operador asume obligaciones formales frente a cada AVS, y el incumplimiento de las reglas lleva a una sanción sobre la garantía asignada.
- Triggers: downtime, firmas incorrectas, procesamiento de datos incorrecto, acciones conflictivas e incompatibilidad tras actualizar el cliente.
- Escala del daño: la determina la política del AVS (condiciones, límites y graduación de las infracciones) y el volumen de stake que realmente trabaja para ese AVS.
- Limitadores: límites de exposición por AVS, distribución entre operadores, rechazo de AVS con política de slashing poco definida o con alta complejidad operativa.
Observación: cuantos más AVS tenga un operador, más puntos de fallo independientes habrá y mayor será la probabilidad de sanción ante fallos comunes.
Eventos correlacionados y sanciones masivas
Una sola causa común puede afectar a muchos operadores al mismo tiempo, incluidos participantes honestos.
- Triggers: bug en la lógica del AVS, configuración discutible, reglas ambiguas o actualización sincronizada errónea en muchos operadores.
- Escala del daño: las deducciones masivas provocan pérdidas simultáneas y refuerzan la salida de stake del servicio o protocolo.
- Limitadores: caps sobre la sanción máxima, límites a la cuota de stake en un solo AVS, verificación independiente y mecanismos de seguro o compensación (si el diseño del mercado los prevé).
Observación: un bug común o una configuración discutible del AVS pueden desencadenar deducciones masivas en un solo momento.
Debilitamiento de la disciplina del stake ante un gran daño fuera de L1
Una sanción fuerte a nivel de AVS puede reducir bruscamente la “apuesta” económica del validador, debilitando el papel disciplinador de la garantía.
- Triggers: slashing profundo en un AVS o serie de sanciones en varios servicios por un problema operativo común.
- Escala del daño: la reducción de la garantía disminuye el “precio del error” para el participante y eleva la inclinación a decisiones arriesgadas.
- Limitadores: localización de casos discutibles dentro de la capa de restaking, límites a la profundidad de las sanciones y procedimientos de resolución de conflictos a nivel del servicio, y no del consenso de Ethereum.
Observación: los casos de slashing discutibles y subjetivos deben mantenerse, de forma crítica, dentro de la capa de restaking.
Concentración alrededor de un AVS grande y presión sistémica
El aumento de la cuota de validadores vinculados a un AVS eleva la probabilidad de que un conflicto local se convierta en sistémico.
- Triggers: sanción discutible, fallo crítico o actualización conflictiva en un AVS dominante.
- Escala del daño: se ve afectada una parte significativa de operadores y stake delegado, y se complica una resolución “silenciosa” del conflicto.
- Limitadores: diversificación entre AVS, límites de concentración y procedimientos de resolución de conflictos a nivel del servicio o de la capa de restaking, y no a nivel de Ethereum.
Observación: una alta concentración en torno a un solo AVS dificulta aislar conflictos sin efecto sistémico.
El restaking añade riesgos que no existen en el staking básico de ETH: AVS-slashing, fallos correlacionados y situaciones conflictivas en torno a las reglas. La reducción de exposición suele apoyarse en límites sobre la cuota de stake, diversificación entre operadores y revisión periódica del conjunto de AVS y de su política de slashing. Una sanción puede neutralizar por completo la ganancia acumulada.
Condición de sostenibilidad: el restaking intensifica los riesgos del staking de ETH a través de AVS-slashing y eventos de infraestructura correlacionados. Sin límites de exposición y sin comprender la política de slashing, el modelo pasa antes a ser una fuente de pérdidas que un flujo estable de pagos.
Restaking, LST, delegación y LRT: límites de los términos y puntos de riesgo
Restaking añade al stake un segundo circuito de reglas: slashing según la política del AVS. LST resuelve la liquidez del stake. Delegación define quién ejecuta. LRT agrega estrategias de restaking en un solo token y traslada el riesgo AVS al precio.
Límite de los términos: LST = representación tokenizada del stake; delegación = elección de operador o validador; restaking = conexión del stake con AVS mediante una política de slashing independiente; LRT = capa superior que agrega estrategias de restaking en un solo token.
| Instrumento | Qué se fija | De dónde vienen los pagos | Qué pasa a ser riesgo |
|---|---|---|---|
| Delegación | Quién ejecuta las reglas de la red | Recompensas del consenso L1 | Fallos operativos del ejecutor dentro de las reglas de L1 |
| LST | Participación en el stake mediante un token líquido | Recompensas de staking + mecánica del protocolo LST | Riesgos de smart contracts, descuento o depeg, liquidez de salida |
| Restaking | La garantía se vuelve slashable según las reglas del AVS | Pagos del AVS (a través de operadores) | AVS-slashing, fallos correlacionados y dependencia del conjunto de AVS del operador |
| LRT | Paquete de estrategias (LST + restaking) en un solo token | Recompensas de staking + pagos AVS | Hereda AVS-slashing, riesgos de estrategia o contracts, descuento como precio del riesgo AVS |
Construcción práctica: la cadena “staking → LST → restaking → LRT” añade capas: primero liquidez (LST), luego responsabilidad AVS (restaking) y después agregación de estrategias (LRT). Cada nivel siguiente añade sus propias reglas y sus propios puntos de fallo.
Separación de roles: la delegación elige al ejecutor, LST aporta liquidez, restaking añade un segundo circuito de slashing según las reglas del AVS, y LRT traslada el perfil de riesgo AVS al precio del token.
Restaking en DeFi: RSFi, LRT y traslado del riesgo AVS al precio de la garantía
Restaking crea la base para RSFi (restaking finance): productos LRT, estrategias de rendimiento y esquemas de seguro ante slashing, pero la característica clave es el traslado del riesgo AVS y de las correlaciones de operadores al precio del LRT y a la calidad de la garantía.
Canal clave de transmisión del riesgo: en RSFi, el estado del restaking se manifiesta a través del precio del LRT. El descuento del LRT frente a ETH refleja no solo la liquidez de salida, sino también una reevaluación de la probabilidad de AVS-slashing y de eventos de infraestructura correlacionados; en lending esto suele manifestarse mediante un aumento del cómo crece el LTV y se activan las liquidaciones.
-
El LRT tokeniza una “cartera de obligaciones”.
- Mecánica: las recompensas básicas del staking se complementan con pagos AVS, y la estrategia se tokeniza en un LRT.
- Composición del riesgo: AVS-slashing, riesgo del operador, fallos correlacionados del conjunto de AVS y riesgo contractual y estratégico del empaquetado.
-
El LRT como garantía refuerza la conexión de los escenarios sistémicos.
- Escenario: el LRT se usa en lending, pools o derivados y sigue vinculado al riesgo de restaking.
- Consecuencia: un mismo stake económico participa simultáneamente en los circuitos de Ethereum, AVS y posiciones DeFi.
-
El descuento del LRT acelera las liquidaciones a través de la calidad de la garantía.
- Triggers: expectativa de slashing, aumento de la incertidumbre operativa en los operadores, concentración alrededor de un AVS grande, actualizaciones discutibles o incidentes en el AVS.
- Transmisión a DeFi: el descuento empeora la garantía, eleva el LTV efectivo y acelera las liquidaciones en protocolos vinculados.
-
El seguro frente a slashing se convierte en una capa independiente del diseño.
- Mecánica: una parte de los pagos AVS se dirige a un pool de seguro o a una reserva de compensación.
- Estructura: las capas conservadoras reciben menos pagos, pero tienen prioridad en compensación; las agresivas asumen más riesgo.
Por qué esto puede convertirse en riesgo sistémico: el precio del LRT afecta a la garantía en muchos protocolos al mismo tiempo. Cuando se reevalúa el riesgo AVS, el descuento del LRT empeora la calidad de la garantía y acelera las liquidaciones, reforzando ventas en cascada.
Ejemplo de escenario: ETH → LST → restaking → LRT → uso de LRT como garantía para un préstamo de stablecoins. En esta cadena, un mismo stake protege a Ethereum, presta servicio a AVS y sostiene una posición crediticia, por lo que el descuento del LRT acelera el riesgo de liquidación.
Fuente de las cascadas: RSFi se construye alrededor de LRT y de pagos AVS, y el principal canal de efectos sistémicos es el traslado de expectativas de AVS-slashing y fallos correlacionados al precio de la garantía y a la liquidez de salida.
Futuro del restaking y modelos de seguridad compartida
Restaking avanza hacia el formato de “seguridad compartida”: los proyectos se conectan a una capa de mercado de responsabilidad (pagos por reglas y sanciones) en lugar de construir su propia economía de validadores.
Gran punto de bifurcación del crecimiento: la escala del restaking la determinan los estándares de integración, el diseño del slashing y los procedimientos de localización de incidentes, y no solo el número de nuevos AVS.
| Qué cambia | Para qué sirve | Qué reduce |
|---|---|---|
| Estandarización de interfaces AVS y perfiles de riesgo | Comparabilidad de condiciones y reducción del “coste de integración” de seguridad | Fragmentación de integraciones y errores por implementaciones únicas |
| Rigor formal (auditorías, verificación, post-mortems) | Acceso a stake grande solo para módulos maduros | Riesgo de bugs críticos y “cajas negras” sin explicación |
| Engineering de slashing (caps, graduaciones, triggers claros) | Precio del error controlado y previsibilidad del daño | Deducciones masivas por eventos raros o discutibles |
| Procedimientos de incidentes (resolvers, arbitraje, compensaciones) | Localización de conflictos dentro de la capa de restaking | Traslado de disputas y presión a la capa base de Ethereum |
Qué se convertirá en la “norma de mercado” para operadores de seguridad:
- Cartera de AVS y límites de exposición. Conjunto de servicios y restricciones formales sobre la cuota de stake bajo cada política de slashing.
- Procesos en lugar de promesas. Reglamentos de actualizaciones, monitorización, respuesta, pruebas y registro de incidentes.
- Transparencia y reputación. Historial de fallos y slashing, informes públicos y reglas claras para trabajar con conflictos y compensaciones (si están previstas).
- Control de correlaciones. Consideración de componentes comunes del stack y de los riesgos de “un mismo bug para todos” en actualizaciones masivas.
Etapa de transición: los primeros grandes escenarios de estrés son casi inevitables (bugs, sanciones discutibles y fallos correlacionados). La sostenibilidad del modelo la determinan los caps sobre el daño, los procedimientos transparentes de revisión y los mecanismos para localizar conflictos a nivel de restaking, y no a nivel del consenso de Ethereum.
Dirección: si la estandarización tiene éxito, la seguridad puede convertirse en un servicio de infraestructura con garantías criptoeconómicas, donde las “condiciones de responsabilidad” se lean con la misma claridad que las tarifas y los SLA en servicios clásicos de infraestructura.
Factor de éxito: el futuro del restaking lo determina la ingeniería de la responsabilidad: estandarización de AVS, slashing previsible y procedimientos de localización de incidentes sin cascadas sistémicas.
FAQ sobre restaking y el protocolo EigenLayer
Respuestas breves a preguntas frecuentes: qué es restaking y qué es AVS, si hacen falta 32 ETH, de dónde vienen los pagos y dónde aparece exactamente el riesgo de slashing.
¿Qué es restaking en palabras simples?
¿Qué es un AVS en el contexto de EigenLayer?
¿Hace falta tener 32 ETH para participar en restaking?
¿Qué rendimiento puede dar el restaking?
¿En qué se diferencia el restaking del liquid staking (LST)?
¿Es posible perder capital por el restaking?
¿No debilitará el restaking la seguridad de Ethereum?
Resumen final: restaking, LST, delegación y LRT
El restaking añade al staking de ETH un segundo circuito de responsabilidad: el stake pasa a ser slashable según las reglas del AVS. Esto crea un mercado de seguridad compartida y pagos por tareas de infraestructura, pero amplía el circuito de riesgos para el stake y para las cadenas DeFi alrededor de LRT.
Resumen en una línea: EigenLayer conecta el stake de ETH con servicios externos y convierte las obligaciones de los operadores frente a los AVS en una responsabilidad sancionable mediante el slashing de la garantía asignada.
Dónde aparece la utilidad (qué compra el mercado):
- Seguridad como servicio. Los AVS obtienen protección basada en el stake de Ethereum sin lanzar su propia economía de validadores.
- Lanzamiento rápido de infraestructura. Los protocolos conectan una capa de responsabilidad ya preparada en lugar de un “token para validadores”.
- Nuevos primitivos para DeFi. Los productos LRT y RSFi tokenizan pagos y responsabilidad, pero junto con ellos también se tokenizan los riesgos.
Dónde aparece el riesgo (qué se convierte en el precio de los pagos):
- AVS-slashing. Sobre las reglas de Ethereum aparecen políticas de slashing separadas para cada servicio.
- Fallos correlacionados. Componentes comunes del stack y actualizaciones masivas pueden provocar infracciones sincronizadas en muchos operadores.
- Cascadas a través del precio del LRT. El descuento del LRT empeora la calidad de la garantía y acelera liquidaciones en protocolos de crédito.
Esencia del modelo: el restaking en EigenLayer no es un “extra sobre el porcentaje”, sino un modelo con responsabilidad ampliada. La sostenibilidad se apoya en límites de exposición, diversificación entre operadores y AVS y preparación ante slashing y fallos correlacionados.
Condición del estándar: el restaking se consolidará como estándar de infraestructura si los incidentes se localizan dentro de la capa de restaking (caps de daño, procedimientos de revisión y reservas o compensaciones), y si el riesgo se evalúa con el mismo rigor que los smart contracts y las garantías en DeFi.