Riesgo de cascada en crisis de KelpDAO y derechos de intervención de emergencia

Puntos clave: La brecha de puente de 290 millones de dólares de KelpDAO desencadenó una reacción en cadena, congelando más de 6,7 mil millones de dólares en liquidez de WETH en cinco cadenas, afectando incluso a usuarios que nunca interactuaron con rsETH. Este evento también revela los límites prácticos de los sistemas “permissionless”: el Consejo de Seguridad de Arbitrum, mediante una autorización de gobernanza, ejecutó una actualización forzada de un contrato atómico que realizó una conversión de estado sin necesidad de firma del poseedor, transfiriendo 30,766 ETH.

El 18 de abril de 2026, la puente cross-chain de rsETH de KelpDAO fue atacada, con una pérdida aproximada de 290 millones de dólares, convirtiéndose en el mayor incidente de seguridad en DeFi de este año. La investigación preliminar apunta al Grupo Lazarus, una organización de ataque de nivel estatal con antecedentes comprobados y a largo plazo dirigida contra infraestructura criptográfica [1]. Este ataque no explotó una vulnerabilidad en un contrato inteligente, sino que mediante la inyección de datos en un nodo único de la red de validación descentralizada (DVN) dependiente de infraestructura RPC, falsificó mensajes cross-chain y, sin una destrucción correspondiente en la cadena fuente, liberó tokens rsETH.

LayerZero [1] y KelpDAO [2] han proporcionado detalles sobre el ataque en sí. Este artículo aborda otro ángulo: en lugar de repetir el proceso del ataque, examina qué ocurrió después: cómo una dependencia en infraestructura de punto único provocó la congelación en cascada de decenas de miles de millones en liquidez en cinco cadenas, y cómo esta cascada forzó a los marcos de gobernanza descentralizados a ejercer poderes centralizados en vista pública.

La cadena causal del incidente de KelpDAO atraviesa tres niveles del stack tecnológico “descentralizado”: la dependencia en DVN de punto único hizo posible el ataque; la composabilidad de DeFi (el “Lego DeFi”, donde los protocolos encajan como bloques) convirtió la vulnerabilidad del puente en una crisis sistémica de liquidez; y la escala de la crisis, a su vez, expuso el ejercicio de poderes centralizados en los marcos de gobernanza.

Contexto: Resumen del ataque a KelpDAO

KelpDAO es el emisor de rsETH. rsETH es un token de liquidez de re-pledge (LRT), que representa posiciones de staking de ETH distribuidas en múltiples operadores. Para facilitar la circulación cross-chain de rsETH, KelpDAO integró el protocolo de mensajería LayerZero. Este protocolo depende de DVN (red de validación descentralizada) para verificar la legitimidad de los mensajes cross-chain antes de su ejecución en la cadena destino.

Configuración clave: La aplicación rsETH de KelpDAO usa una configuración DVN 1-de-1, es decir, solo un DVN operado por LayerZero Labs como único validador. Esto significa que toda la seguridad cross-chain de rsETH depende de una única entidad de validación. La documentación de integración de LayerZero recomienda explícitamente usar configuraciones con múltiples DVN redundantes, y LayerZero informó a KelpDAO antes del incidente que esta era la mejor práctica [1]. KelpDAO respondió que la configuración 1/1 es “la que está documentada en LayerZero y que se publica como configuración predeterminada para cualquier despliegue de OFT nuevo”, además de que “en la expansión a L2 ya fue claramente considerada adecuada” [2].

El atacante comprometió dos nodos RPC utilizados por el DVN de LayerZero, reemplazando sus archivos binarios por versiones maliciosas. Estos nodos maliciosos solo respondían con datos falsificados del estado en la cadena para la IP del DVN, y se comportaban normalmente ante todos los demás observadores (incluyendo la infraestructura de monitoreo de LayerZero). Simultáneamente, un ataque DDoS dirigido a los nodos RPC no comprometidos forzó una conmutación por error a los nodos envenenados. Como resultado: el DVN confirmó un mensaje cross-chain en una cadena fuente que nunca ocurrió, sin una destrucción correspondiente en la cadena fuente, y desde el adaptador en Ethereum (0x85d4…8ef3) se liberaron 116,500 rsETH [1, 3]. La transacción de liberación fue 0x1ae232…db4222. La evidencia en la cadena es clara: el endpoint de destino en Ethereum aceptó un nonce 308, mientras que el nonce máximo reportado por el endpoint en la cadena fuente (Unichain) seguía siendo 307 [10].

KelpDAO detectó la anomalía en 46 minutos y pausó todos los contratos relacionados. Esto evitó un ataque posterior que habría podido liberar otros 40,000 rsETH (aproximadamente 95 millones de dólares) [2]. Pero en ese momento, el atacante ya había avanzado a la siguiente fase: convertir los rsETH robados en activos prestados mediante protocolos DeFi.

De tokens falsificados a activos prestados

El atacante no vendió directamente los rsETH robados. Los 116,500 tokens se dispersaron en siete wallets, y se monetizaron a través de varias vías, incluyendo intercambios directos por ETH mediante agregadores, posiciones de suministro en Compound V3 y puentes a Arbitrum [10]. Pero la vía más impactante fue a través de Aave: el atacante depositó 89,567 rsETH (unos 221 millones de dólares) en los mercados de préstamo en dos cadenas: Ethereum Core y Arbitrum. Aprovechando la función E-Mode de Aave (que permite un mayor ratio de préstamo para activos relacionados), el atacante tomó un préstamo de 82,620 WETH y 821 wstETH usando los rsETH depositados como garantía [3].

Estas posiciones estaban altamente apalancadas. Los factores de salud de las siete direcciones del atacante en estos mercados estaban entre 1.01 y 1.03, apenas por encima del umbral de liquidación [3]. La razón: la E-Mode de Aave estableció un LTV del 93% para rsETH, con un umbral de liquidación del 95%, dejando un margen de seguridad de solo 2 puntos porcentuales.

Los detalles en los dos mercados son los siguientes:

Tabla 1: Detalles de la provisión de rsETH y los préstamos en WETH/wstETH de los atacantes en los mercados de Aave

Fuente: datos en cadena, recopilados de Etherscan, Arbiscan y DeBank, al 22-04-2026 16:51 UTC. El valor en USD refleja los precios en el momento de cada transacción.

Efecto en cascada: cómo una vulnerabilidad en el puente congeló WETH en cinco cadenas

El diagrama a continuación resume toda la cadena en cascada. Los pasos 1 y 2 (vulnerabilidad en el puente y depósito en Aave) ya se explicaron en la sección anterior. Este apartado profundiza en los pasos 3 a 5: por qué WETH debe ser congelado, qué parámetros determinan la gravedad de la cascada y cuáles son los costos reales de la congelación.

Figura 1: Flujo en cascada desde la vulnerabilidad en el puente hasta la congelación de WETH en cinco cadenas

¿Por qué WETH debe ser congelado?

El 19 de abril, el Guardian del protocolo de Aave congeló todos los mercados de rsETH y wrsETH en Aave V3 y V4, prohibiendo nuevos depósitos y préstamos con rsETH como garantía [8]. Esta fue la primera respuesta prevista.

La segunda respuesta inesperada ocurrió el 20 de abril: Aave congeló las reservas de WETH en Ethereum, Arbitrum, Base, Mantle y Linea [3, 8].

¿por qué congelar WETH? Es un activo que no fue atacado y no tiene relación con el puente cross-chain. La razón: los rsETH depositados fueron creados sin respaldo en activos en la cadena fuente. La oráculo de Aave continúa valorando estos tokens a precios de mercado completos, considerándolos como garantías válidas indistinguibles del rsETH legítimo del puente. El atacante aprovechó esta asimetría de información para tomar préstamos en WETH sin respaldo, representando pasivos no garantizados en el sistema. Esto drenó WETH de los pools de préstamo, alcanzando una utilización del 100% en los mercados afectados. Con la utilización al máximo, los depositantes de WETH no pueden retirar y los liquidadores no pueden ejecutar liquidaciones, ya que los activos subyacentes están bloqueados. La mecánica de liquidación, que es la línea de defensa contra la morosidad, se ha paralizado [3].

Si los préstamos en WETH permanecen abiertos, la liquidez restante en otras cadenas puede ser igualmente drenada: depositar rsETH, tomar WETH y salir. La congelación de WETH no es una opción, sino la única medida para limitar el daño.

Tres parámetros que configuran la cascada

La gravedad de esta cascada no es casualidad. Tres parámetros del protocolo determinan la magnitud del daño directo y el alcance de la congelación en cascada.

1. LTV: cuánto puede extraer una garantía contaminada por unidad

El LTV de rsETH en E-Mode de Aave está en 93%, lo que significa que por cada dólar de rsETH contaminado depositado, se puede tomar un préstamo de 0.93 dólares en WETH. En comparación, el LTV de rsETH en Spark Protocol en ese momento era del 72%, y en Fluid aproximadamente del 75% [3]. La configuración de Aave es la más agresiva del mercado.

Este no fue un descuido, sino una decisión de diseño deliberada. En enero de 2026, la gobernanza de Aave aumentó el LTV de rsETH en E-Mode del 92.5% al 93%, reduciendo aún más el margen de seguridad, que ya era escaso, del 2.5% al 2%. El LTV en modo no E-Mode se estableció intencionadamente cerca de cero (0.05%), forzando que todos los préstamos relevantes en rsETH pasen por la vía de alta LTV de E-Mode.

[3] 2. Profundidad del pool: vulnerabilidad de cada mercado a extracción de liquidez

La misma cantidad de préstamo en pools con diferentes profundidades tiene impactos muy distintos.

Tabla 2: Tamaño de reservas WETH en los mercados de Aave V3 y porcentaje de extracción directa del atacante

El atacante solo depositó rsETH en los mercados de Aave V3. La reserva de WETH en V4 (solo en Ethereum, lanzado en marzo de 2026) también está protegida por congelación preventiva de rsETH ###, pero no aparece en esta tabla. Los datos de reservas de WETH provienen de LlamaRisk [8]; los datos de préstamos del atacante, de la tabla anterior.

El atacante se concentró en Ethereum Core y Arbitrum para sus operaciones de préstamo. Pero lo importante es qué ocurrió en las cadenas que el atacante no tocó. Como rsETH en Mantle, Base y Linea fue aceptado como garantía, si se destruyen los respaldos en la puente, las posiciones existentes en esas cadenas que usan rsETH como garantía enfrentan potencialmente un riesgo de morosidad. La decisión de congelar preventivamente WETH en las cinco cadenas es una respuesta razonable: si se mantienen abiertas esas posiciones, estarán expuestas a la misma mecánica de extracción que ya fue validada en Ethereum y Arbitrum [3, 8].

[3] 3. Número de despliegues cross-chain: alcance de la propagación de la congelación

rsETH en 11 de los 23 mercados de Aave V3 está listado como garantía, y 7 de estos tienen exposición sustancial ###. El atacante solo operó en 2 cadenas, pero la congelación preventiva de WETH afectó al menos a 5, incluyendo mercados donde el atacante nunca depositó tokens. El LTV determina cuánto puede ser extraído en cada cadena, y la profundidad del pool determina el impacto en cada mercado. Pero la cantidad de cadenas que aceptan rsETH como garantía finalmente define el alcance de la propagación de la congelación.

Estos parámetros no son estáticos. Nueve días antes del ataque, el 9 de abril, la Risk Steward de Aave aumentó el límite de suministro de rsETH: en Ethereum Core, de 480,000 a 530,000, y en Mantle, de 52,000 a 70,000 [3]. Aunque esto no implica causalidad (el atacante probablemente ya había preparado el ataque antes de estos ajustes), muestra cómo cambios en parámetros habituales pueden inadvertidamente ampliar el impacto de eventos futuros.

Impacto real de la congelación

El resultado: una vulnerabilidad en el puente de 290 millones de dólares provocó la congelación de la liquidez de WETH en cinco cadenas, con reservas combinadas en los mercados afectados que superan los 67 mil millones de dólares.

Las pérdidas directas se limitan a los préstamos del atacante. Pero en DeFi, la congelación no es solo una interrupción operativa menor. Bloquea la liquidez de los usuarios, impide retiros, desordena posiciones activas y debilita la capacidad de los protocolos para liquidar y evitar morosidad. La mayoría de los usuarios afectados nunca interactuaron con rsETH, KelpDAO o cualquier puente cross-chain. Son depositantes y prestatarios de WETH en Aave, participando en mercados que consideran directos y transparentes.

WETH es el activo de liquidez más fundamental en DeFi. Congelarlo equivale a cerrar la vía de retiro del mayor banco de la ciudad, por una razón: una institución financiera usó un producto que la mayoría de los depositantes nunca ha oído, y fue víctima de un fraude.

El informe de evento de LlamaRisk [3] construye dos modelos de escenarios de morosidad, con predicciones de shortfall por cadena, y es el análisis más detallado de la propagación del riesgo hasta ahora. Pero incluso este análisis se centra en posibles morosidades, no en los costos operativos más amplios de la cascada, como bloqueos de retiros, impedimentos en posiciones y debilitamiento de la capacidad de liquidación en todos los mercados afectados. La cuantificación completa del impacto en cascada sigue siendo un tema abierto.

Si la cascada del ataque es compleja, la recuperación tampoco es sencilla. La composabilidad, que limita la destrucción, también limita la reparación. Aave no puede simplemente “descongelar todo”. Cada mercado debe evaluarse individualmente, considerando la exposición en rsETH, la utilización de WETH y la actividad del atacante, enfrentando diferentes riesgos. La línea de tiempo ilustra claramente esto:

19 de abril: Protocol Guardian congela todos los reserves de rsETH y wrsETH en Aave V3 y V4 [3].

20 de abril: WETH en Ethereum, Arbitrum, Base, Mantle y Linea se congela [8].

21 de abril: Solo se descongela WETH en Ethereum Core V3, manteniendo el LTV en 0 como medida preventiva. WETH en Ethereum Prime, Arbitrum, Base, Mantle y Linea permanece congelado [8].

Cuatro días después del ataque, solo uno de los seis mercados afectados se recupera. La ruta de recuperación es tan compleja como la del ataque: paso a paso, protocolo por protocolo, cadena por cadena, con decisiones de gobernanza y evaluación de riesgos en cada paso.

Respuesta de emergencia: cómo el Consejo de Seguridad de Arbitrum transfirió 30,766 ETH sin firma del poseedor

Mientras Aave gestionaba la cascada de préstamos, Arbitrum también ejecutaba una respuesta paralela. El 21 de abril, el Consejo de Seguridad de Arbitrum anunció una acción de emergencia: congelar los 30,766 ETH que el atacante tenía en Arbitrum One [6]. Estos fondos fueron transferidos a una dirección intermedia de congelación (0x…0DA0), y solo podrán ser gestionados mediante una votación posterior en la gobernanza de Arbitrum [7].

Acción de gobernanza

El Consejo de Seguridad de Arbitrum es una parte formal de la estructura de gobernanza de Arbitrum DAO, no un ente externo o comité temporal. La acción de emergencia se anunció públicamente en el foro de gobernanza de Arbitrum [7], y se ejecutó tras la confirmación de la identidad del atacante, con detalles completos de la transacción para verificación pública. El Consejo actúa dentro de sus competencias, equilibrando el compromiso con la seguridad y la integridad de la comunidad, sin afectar a usuarios o aplicaciones de Arbitrum [6].

No fue una decisión en secreto, sino una acción autorizada por gobernanza, transparente y pública, con evidencia en cadena claramente visible.

[6] Mecanismo técnico

Lo notable de esta acción no es la decisión de gobernanza en sí, sino cómo se ejecutó en la cadena. Basándose en el análisis de trazas Phalcon de BlockSec ###, el Consejo de Seguridad utilizó un proceso atómico en tres pasos:

El ejecutor de actualización (Upgrade Executor) realizó una actualización temporal del contrato de inbox en Ethereum (DelayedInbox), agregando una nueva función llamada sendUnsignedTransactionOverride.

Esta función se usó para crear un mensaje cross-chain que simulaba ser del atacante. El mensaje fue inyectado mediante Bridge.enqueueDelayedMessage, tipo=3, correspondiente a L1MessageType_L2Message en la pila de Arbitrum Nitro. Este tipo de mensaje permite ejecutar en L2 un L2MessageKind_UnsignedUserTx. Lo clave: esta ruta no requiere verificación de firma. El parámetro sender se cambió del estándar msg.sender a una entrada controlada por el llamante, que lleva la dirección del atacante a través de la conversión de alias de dirección L1→L2.

Tras completar la transferencia en L2, el contrato inbox se restauró a su implementación original.

Las transacciones en L1 [9] y las transacciones L2 resultantes [4] son públicas en Phalcon Explorer. La transacción en L2 aparece como “del atacante a 0x…0DA0”, pero no es una transferencia estándar firmada por un usuario, sino una conversión de estado forzada a nivel de cadena: mediante una actualización de infraestructura de gobernanza, se transfirieron activos sin la firma del propietario.

[5] La paradoja de la descentralización

Su principio es simple: los contratos actualizables otorgan capacidades ilimitadas. Si un contrato puede ser actualizado, su comportamiento puede ser modificado para hacer cualquier cosa, incluyendo transferir activos sin firma del propietario. Esa es una capacidad inherente a cualquier sistema construido con contratos actualizables. Los 30,766 ETH están ahora en una dirección congelada, y solo una votación futura en la gobernanza de Arbitrum decidirá su destino. La modalidad atómica de actualización-ejecución-restauración no deja cambios permanentes en el contrato inbox ni afecta a otros usuarios o aplicaciones ###.

Desde una evaluación razonable, la acción del Consejo de Seguridad de Arbitrum fue correcta. El atacante fue identificado como un actor de nivel estatal, con participación de las fuerzas del orden, y los fondos robados (o al menos, su lavado) fue detenido o impedido. La capacidad que hizo posible esto, sin embargo, no se limita a este caso particular. La misma mecánica de actualización-ejecución-restauración, en principio, puede usarse para transferir cualquier activo en Arbitrum One. La autoridad del Consejo no se limita a la dirección del atacante o a los fondos robados; es una capacidad general, regulada por gobernanza, no por código.

Este es el dilema. Los usuarios creen que “sus activos están controlados por su clave privada, y nadie puede transferirlos sin su firma”. La respuesta a la emergencia de KelpDAO muestra que ese modelo no es completo. En Arbitrum y en cualquier L2 con contratos puente actualizables y Consejo de Seguridad, los activos pueden ser transferidos mediante acciones de gobernanza que evaden la firma del propietario.

Arbitrum no es un caso aislado. La congelación en Aave también fue una acción de emergencia gobernada. En el incidente de KelpDAO, múltiples protocolos ejercieron poderes centralizados: Aave congeló mercados en cinco cadenas, el Consejo de Seguridad de Arbitrum realizó transferencias forzadas, y KelpDAO pausó contratos globalmente. La respuesta a esta crisis en un ecosistema “descentralizado” en realidad refleja un ejercicio coordinado de poderes centralizados.

No se trata de si estos poderes de emergencia deben existir, sino de si sus límites, condiciones de activación y mecanismos de rendición de cuentas son suficientemente transparentes. Los usuarios que depositan en L2 deben poder responder: ¿en qué circunstancias el Consejo puede transferir mis fondos? ¿Qué recursos de reclamación tengo?

Estado actual de los fondos robados

El rastreo independiente en cadena de los fondos robados (visualización completa en MetaSleuth [6]) muestra que el atacante dispersó 116,500 rsETH en 7 direcciones principales, la mayoría de las cuales se depositaron en Aave (Ethereum Core y Arbitrum) como garantía para WETH y wstETH, y los tokens prestados, tras intercambios menores en DEX, se consolidaron en la misma dirección 0x5d39…7ccc (Ethereum / Arbitrum). Hasta el 22-04-2026 05:42 UTC, los fondos robados están en cuatro estados:

El atacante aún no ha recuperado los rsETH en Aave, ni ha devuelto los WETH y wstETH prestados, y las posiciones de préstamo están abandonadas.

La cadena causal del incidente de KelpDAO atraviesa los tres niveles del stack “descentralizado”.

El punto de partida es la dependencia en un único punto. La configuración DVN 1/1 de KelpDAO reduce la validación cross-chain a una sola entidad, permitiendo que toda la puente sea vulnerada por un solo componente comprometido. La arquitectura soporta descentralización, pero la configuración no.

Luego, la composabilidad convirtió la vulnerabilidad en una crisis sistémica de liquidez. Un ataque que congeló el activo más básico de DeFi, WETH, afectó cinco cadenas, impactando decenas de miles de millones en liquidez, y afectó a usuarios sin relación con rsETH o KelpDAO. La gravedad de la cascada está determinada por parámetros cuantificables: configuraciones agresivas de LTV, pools poco profundos y despliegues amplios de garantías cross-chain.

Finalmente, la escala de la crisis forzó a la gobernanza descentralizada a ejercer poderes centralizados de emergencia. El Consejo de Seguridad de Arbitrum, mediante una actualización atómica autorizada por gobernanza, transfirió 30,766 ETH sin firma del propietario. Aave, mediante acciones de emergencia, congeló mercados en cinco cadenas. Estas respuestas fueron efectivas, transparentes y necesarias, demostrando los límites prácticos de un sistema “permissionless”.

La dependencia en un único punto hizo posible el ataque, la composabilidad amplificó el daño, y la centralización en la respuesta reveló un poder que siempre ha estado allí, incrustado en contratos actualizables y en la gobernanza. La solución requiere la participación coordinada de todos los actores:

• Para los protocolos: la seguridad global depende del eslabón más débil, en este caso, la infraestructura RPC de DVN, no los contratos inteligentes [11]. La seguridad efectiva requiere cobertura en múltiples dimensiones: seguridad del código, infraestructura, gestión de claves y operaciones. Evaluaciones de seguridad y pruebas de penetración deben someter toda la pila tecnológica a presión, no solo componentes aislados. La monitorización en cadena permite respuestas rápidas en minutos, y el rastreo de fondos en múltiples cadenas es clave para coordinar congelaciones y recuperaciones. En préstamos, los colaterales cross-chain deben ser evaluados bajo escenarios de “colateral completamente comprometido”, considerando los parámetros discutidos (LTV, profundidad del pool, despliegues cross-chain).

• Para la gobernanza y DAO en L2: los poderes de emergencia deben ser transparentes y responsables. La mayoría de los L2 principales ya tienen estas capacidades, pero a menudo están ocultas en documentación técnica, no en materiales para usuarios. La gobernanza debe definir claramente condiciones de activación, límites, duración y mecanismos de rendición de cuentas.

• Para los usuarios: entender los riesgos sistémicos inherentes a la composabilidad de DeFi. En este incidente, los depositantes de WETH en cinco cadenas quedaron con liquidez congelada, sin haber interactuado con rsETH, KelpDAO o puentes cross-chain. El riesgo de una posición individual es solo una parte del panorama; las interacciones con protocolos, pools, garantías y cadenas conforman un riesgo interconectado.