Una herramienta de IA de código abierto que nadie miraba, advirtió hace 12 días sobre la vulnerabilidad de 292 millones de dólares de Kelp DAO.

Autor: Zengineer

Traducido por: Deep潮 TechFlow

Deep潮 introducción: El 18 de abril, Kelp DAO fue hackeado por 292 millones de dólares, la mayor operación DeFi hasta la fecha en 2026. La vulnerabilidad no estaba en el código del contrato inteligente, sino en la configuración del nodo de verificación LayerZero cross-chain 1-de-1—una sola falla en un punto puede falsificar mensajes entre cadenas. Hace 12 días, cuando el autor escaneó Kelp con su herramienta de auditoría de código abierto basada en IA, ya había marcado este riesgo. Este artículo revisa todo el proceso del ataque y reflexiona honestamente sobre las tres cosas que nuestra herramienta no hizo bien en ese momento.

¿Qué es Kelp DAO?

Kelp DAO es un protocolo de staking líquido construido sobre EigenLayer. El mecanismo funciona así: los usuarios depositan ETH o tokens de staking líquido (stETH, ETHx) en el contrato de Kelp, que luego delega los activos a los nodos operativos de EigenLayer para hacer staking adicional—proporcionando seguridad a múltiples AVS (Actively Validated Services, Servicios de Validación Activa). Como recompensa, los usuarios reciben rsETH como prueba. A diferencia del staking directo en EigenLayer (donde los activos están bloqueados), rsETH es líquido—puede negociarse, usarse como colateral en protocolos de préstamo como Aave, y también puede transferirse entre cadenas.

Para lograr esta liquidez entre cadenas, Kelp usa el estándar OFT (Omnichain Fungible Token, Token Fungible Omnicanal) de LayerZero para desplegar rsETH en más de 16 cadenas. Cuando transfieres rsETH desde Ethereum a una capa L2, la red DVN (Decentralized Verifier Network, Red de Verificadores Descentralizados) de LayerZero verifica si el mensaje de cross-chain es válido. Esta arquitectura de puente es el núcleo de la historia que sigue.

Kelp fue iniciado por Amitej Gajjala y Dheeraj Borra (ex cofundadores de Stader Labs), lanzado en diciembre de 2023, con un TVL máximo de 2.09 mil millones de dólares, gobernanza mediante multisig 6/8 y un período de bloqueo de 10 días para actualizaciones de contrato. El token de gobernanza KERNEL administra las tres líneas de productos: Kelp, Kernel y Gain.

Evento de robo

El 18 de abril de 2026, un atacante extrajo 116,500 rsETH del puente cross-chain de Kelp DAO, equivalente a aproximadamente 292 millones de dólares—la mayor operación DeFi en 2026. La causa raíz no fue una vulnerabilidad en el contrato inteligente, sino un problema de configuración: una configuración DVN 1-de-1 (solo un nodo de verificación, con una firma válida) permitió al atacante falsificar mensajes entre cadenas usando un solo nodo comprometido.

Hace 12 días, el 6 de abril, nuestra herramienta de auditoría de seguridad de código abierto basada en IA ya había marcado esta vulnerabilidad.

Primero, una aclaración: este robo fue causado por personas reales que perdieron dinero. Los depositantes en Aave que tenían rsETH y WETH quedaron con fondos congelados; varios LP en diferentes protocolos asumieron pérdidas que no habían acordado. Este artículo analiza qué ocurrió, qué detectamos y qué no detectamos en su momento—pero el costo real para las víctimas es más importante que cualquier puntuación de riesgo.

El informe completo está en GitHub, con timestamps verificables. A continuación, contamos qué detectamos, qué pasamos por alto y qué significa esto para las herramientas de seguridad DeFi.

46 minutos, conmoción en DeFi

UTC 17:35 del 18 de abril, el atacante comprometió el nodo DVN aislado y le hizo “aprobar” un mensaje falsificado de cross-chain. El Endpoint de LayerZero, al ver que DVN aprobó, envió el mensaje a través de lzReceive al contrato OFT de Kelp—el contrato mintió en la red principal de Ethereum, creando 116,500 rsETH. El mensaje afirmaba que otras cadenas habían bloqueado activos equivalentes como garantía, pero esos activos nunca existieron.

Luego, se siguió un proceso típico de lavado de dinero en DeFi:

Usar los rsETH robados como colateral en Aave V3, Compound V3, Euler

Con estos colaterales sin respaldo real, pedir préstamos por aproximadamente 236 millones de dólares en WETH

Concentrar unos 74,000 ETH y retirar fondos a través de Tornado Cash

A las 18:21, 46 minutos después, Kelp activó un bloqueo de emergencia mediante multisig. El atacante realizó dos ataques de seguimiento (cada uno con 40,000 rsETH, unos 100 millones de dólares), que fueron revertidos—el bloqueo evitó pérdidas cercanas a 200 millones de dólares.

Aún así, el impacto fue severo. Aave V3 asumió aproximadamente 177 millones de dólares en pérdidas incobrables. El token AAVE cayó un 10.27%. ETH bajó un 3%. La utilización de WETH en Aave alcanzó el 100%, y los depositantes comenzaron a retirar en masa. Los rsETH en más de 20 L2 se volvieron activos de valor dudoso de la noche a la mañana.

El 6 de abril, ¿qué detectamos?

A principios de abril, poco después de que Drift Protocol fuera hackeado por 285 millones de dólares, escribí una herramienta de evaluación de riesgos basada en IA llamada crypto-project-security-skill—un marco de evaluación de riesgos arquitectónicos que usa datos públicos (DeFiLlama, GoPlus, Safe API, verificaciones en cadena) para evaluar protocolos DeFi. No es un escáner de código ni una verificación formal. El incidente de Drift me hizo entender: las mayores pérdidas no estaban en el código del contrato, sino en fallos de gobernanza, configuración y arquitectura—lugares que los escáneres de código no ven. Por eso, desarrollé una herramienta específica para evaluar estos aspectos: estructura de gobernanza, dependencia de oráculos, mecanismos económicos y arquitectura cross-chain, comparando cada protocolo con ataques históricos (Drift, Euler, Ronin, Harmony, Mango).

El 6 de abril, realicé una auditoría completa de Kelp DAO. El informe completo está en GitHub, con timestamps inalterables.

La puntuación global para Kelp fue 72/100 (riesgo medio). Con el tiempo, esa puntuación fue demasiado permisiva—los gaps en la información de cross-chain deberían haber reducido la nota. Pero incluso con una calificación de riesgo medio, el informe identificó la vulnerabilidad que luego fue explotada.

La siguiente captura muestra la sección “brechas de información” del informe—sobre la configuración DVN de Kelp, que fue la causa raíz del robo de 292 millones:

Pie de foto: En la sección “brechas de información” del informe del 6 de abril, se señala directamente la opacidad en la configuración DVN

A continuación, comparo lo que marcamos en el informe con cómo fue realmente vulnerado.

Hallazgo 1: Configuración DVN opaca (señal de advertencia)

Texto del informe: “La configuración DVN de LayerZero (conjunto de validadores por cadena, requisitos de umbral) no es pública”

Lo que ocurrió en realidad: Kelp usó una configuración DVN 1-de-1. Un solo nodo. Un punto único de fallo. El atacante tomó control de ese nodo y falsificó mensajes entre cadenas. Si la configuración hubiera sido 2-de-3 (recomendación mínima de la industria), el atacante habría tenido que comprometer múltiples validadores independientes.

Aclaremos: esto es un problema de Kelp, no de LayerZero. LayerZero es la infraestructura—proporciona el marco DVN, pero cada protocolo elige su configuración: cuántos validadores (1-de-1, 2-de-3, 3-de-5…), quiénes son, los umbrales por cadena. Kelp desplegó OFT con configuración 1-de-1. LayerZero soporta 2-de-3 o más, pero Kelp no habilitó esa opción.

Ejemplo: AWS ofrece MFA (autenticación multifactor). Si tu cuenta fue comprometida porque nunca activaste MFA, el problema es tuyo, no de AWS. LayerZero proporciona mecanismos de seguridad; Kelp no los usó.

Nuestro informe no pudo verificar el umbral DVN exacto (porque Kelp nunca lo divulgó), pero sí lo listamos como una brecha de información y un riesgo no resuelto. La opacidad en sí misma es una señal de alerta.

Hallazgo 2: Fallo en una de las 16 cadenas (impacto directo)

Texto del informe: “El fallo de un solo punto en DVN de LayerZero puede afectar a las 16 cadenas soportadas y sus rsETH”

Lo que ocurrió: el mensaje falsificado impactó directamente en Ethereum, y la ola se extendió a todas las cadenas con rsETH desplegado. LayerZero suspendió preventivamente todos los puentes OFT que salían de Ethereum. Los poseedores de rsETH en más de 20 L2 no sabían si sus tokens tenían respaldo.

Este es un riesgo sistémico en despliegues multichain: rsETH circula en Arbitrum, Optimism, Base, Scroll, etc., pero su valor depende de los activos en Ethereum. Cuando el puente principal se rompe, los rsETH en todas esas cadenas pierden respaldo—los usuarios no pueden canjear ni verificar si sus tokens siguen valiendo algo. Los productos como earnETH de Lido (que usan rsETH) y el puente LayerZero de Ethena también se detuvieron. La escala del impacto supera a Kelp mismo.

Hallazgo 3: Control de gobernanza en cross-chain sin verificar (problema relacionado)

Texto del informe: “El control de gobernanza sobre la configuración OFT en cada cadena no está verificado—especialmente: si estos controles pertenecen a la misma multisig 6/8 y bloqueo de 10 días, o a claves independientes”

Lo que ocurrió en realidad: la configuración DVN claramente no está bajo gobernanza estricta del protocolo central. Si los cambios en el puente también los controla la multisig 6/8 con bloqueo de 10 días, entonces la configuración 1-de-1 requiere 6 de 8 firmas—una configuración improbable sin gestión activa.

Esto revela una zona ciega común: muchos protocolos tienen gobernanza estricta para actualizaciones del contrato principal, pero en la operación diaria—configuración del puente, parámetros de oráculos, listas blancas—solo un administrador tiene control. Kelp tiene una gobernanza avanzada (6/8 multisig + bloqueo de 10 días), pero esas protecciones no cubren la mayor vulnerabilidad: el puente cross-chain.

Hallazgo 4: Coincidencia con ataques Ronin/Harmony (impacto directo)

Texto del informe: “El escenario más relevante en la historia son los ataques a puentes. La implementación de LayerZero en 16 cadenas en Kelp tiene una complejidad operacional similar a Ronin”

Lo que ocurrió: la ruta del ataque replica casi exactamente el esquema Ronin—romper validadores, falsificar mensajes, vaciar fondos. Nuestra herramienta, mediante su módulo de detección de patrones de ataque, comparó la arquitectura del protocolo con ataques históricos y lo identificó como la amenaza de mayor riesgo.

Contexto histórico: en 2022, Ronin perdió 625 millones de dólares tras comprometer 5 de sus 9 validadores; ese mismo año, Harmony Horizon perdió 100 millones tras atacar 2 de sus 5 validadores. La situación de Kelp es aún más extrema—solo un validador, con un umbral mínimo. La herramienta detectó este riesgo porque compara automáticamente la arquitectura con ataques pasados, no solo el código.

Hallazgo 5: Sin fondo de seguro (amplifica pérdidas)

Texto del informe: “El protocolo no tiene un fondo de seguro dedicado ni mecanismos de responsabilidad social para absorber pérdidas por sanciones”

Lo que ocurrió: sin reservas de seguro, las pérdidas de 292 millones de dólares fueron asumidas por protocolos downstream. La reserva de recuperación de Aave cubrió menos del 30% de los 177 millones en pérdidas incobrables. Los LP que aceptaron rsETH como colateral asumieron la mayor parte del impacto.

El atacante usó rsETH como colateral en Aave V3, Compound V3, Euler, y pidió WETH real. Cuando se confirmó que rsETH no tenía respaldo, esas posiciones se volvieron incobrables—el colateral quedó inútil, pero los WETH ya estaban fuera. La utilización de WETH en Aave se disparó al 100%, y los usuarios no podían retirar fondos. Incluso los depositantes en WETH en Aave, sin haber interactuado con rsETH, se vieron afectados. La colaboración de Kelp con Nexus Mutual para seguros solo cubre ciertos productos, no la exposición principal a rsETH.

Aquí fallaron ambas partes: Kelp, que gestiona 1.3 mil millones de dólares en TVL, no tiene fondo de seguro ni mecanismo de absorción de pérdidas; y Aave, que acepta rsETH sin evaluar adecuadamente el riesgo de puente. Los parámetros de riesgo (LTV, umbrales de liquidación) están diseñados para fluctuaciones normales, no para escenarios donde el puente se rompe y el respaldo desaparece de la noche a la mañana. La reserva de recuperación no cubre ni el 30% de las pérdidas. Es una falla en la valoración del riesgo: Aave trató rsETH como un activo normal, sin considerar el riesgo de tail de puente. La suma de fallos de ambas partes permitió que la pérdida ocurriera.

¿Dónde fallamos?

Tres cosas que debimos hacer mejor:

1. Calificación de riesgo demasiado baja.
   Subestimamos el riesgo del puente cross-chain como “medio”. En el informe, 3 de 5 brechas de información relacionadas con la configuración de LayerZero deberían haber elevado la calificación a “alto” o “grave”. La opacidad en sí misma debería ser una señal fuerte.

2. No penetramos en la capa de configuración.
   Solicitamos repetidamente a Kelp que revelara el umbral DVN, pero no pudimos verificarlo independientemente. Esto es un problema estructural: las herramientas actuales se enfocan en el código, no en la configuración. Marcamos el problema, pero no pudimos responder.

3. No verificamos en cadena.
   La configuración DVN puede leerse directamente en la cadena mediante el contrato EndpointV2 de LayerZero. Podríamos consultar el registro ULN302 para verificar el umbral DVN de Kelp sin que ellos lo revelaran. Si hubiéramos consultado, veríamos que la configuración es 1-de-1, sin necesidad de que Kelp la divulgue. La mejora concreta sería agregar en la evaluación cross-chain la verificación en cadena de la configuración DVN.

¿La detección fue demasiado vaga o poco accionable?
Decir “la configuración DVN no se divulgó” es solo una observación documental, no una vulnerabilidad explotable concreta. Riesgos como concentración de oráculos, dependencia de puentes, falta de seguro, son comunes en muchos protocolos cross-chain. La herramienta marcó la opacidad de Kelp, pero también detectó patrones similares en otros protocolos no atacados. Sin una tasa de falsos positivos conocida, afirmar que “predijimos” es exagerado. La forma más honesta es decir: hicimos las preguntas correctas que otros no hacen, y una de esas preguntas tocó un punto clave.

¿Sobre la “divulgación responsable”?

Una pregunta justa: si detectamos estos riesgos el 6 de abril, ¿por qué no advertimos a Kelp antes del ataque del 18 de abril?

No advertimos. Porque la advertencia era sobre opacidad—“configuración DVN no divulgada”, no una vulnerabilidad concreta. No teníamos datos específicos que permitieran explotar algo. La opacidad en la configuración es una observación de gobernanza, no un bug listo para explotar.

Con perspectiva, podríamos haber contactado a Kelp y preguntar por su umbral DVN. Esa conversación quizás habría revelado la configuración 1-de-1 y facilitado una corrección. No lo hicimos. La lección: incluso si un hallazgo parece vago, vale la pena preguntar en privado.

¿Qué significa esto para DeFi?

El robo a Kelp, igual que el de Drift 17 días antes, no fue por un bug en el código. Herramientas automáticas como Slither, Mythril o GoPlus no detectan esto. La vulnerabilidad está en la configuración, gobernanza y arquitectura, por encima del código.

Este es el núcleo de la filosofía de crypto-project-security-skill:

La seguridad en protocolos no es solo código. Un protocolo puede tener un código Solidity perfecto, auditorías de primera línea, recompensas de bug de 250,000 USD—pero aún así, por un problema en la configuración del puente, puede ser robado por 292 millones de dólares.

La herramienta es de código abierto en GitHub—cualquiera puede revisar, ejecutar o mejorar la metodología.

Línea de tiempo

12 días. La señal estuvo allí desde el principio. La cuestión es: ¿cómo construir herramientas que puedan detectar estos signos antes de que un puente colapse?

¿Qué puedes hacer tú?

Si tienes activos en protocolos DeFi con puentes cross-chain:

Haz una auditoría tú mismo. La herramienta es open source. No confíes solo en nosotros—verifica por ti mismo.

Verifica la configuración del puente. Si un protocolo no quiere divulgar su umbral DVN, tómalo como señal de advertencia. Nuestro informe ya lo hizo, y resultó correcto.

No pienses que la auditoría de código cubre todo. Kelp ya tuvo más de 5 auditorías de firmas reconocidas (Code4rena, SigmaPrime, MixBytes). La auditoría tradicional se enfoca en lógica de código, no en riesgos de configuración como el umbral DVN—eso requiere análisis diferente, no una falla del auditor.

Evalúa la cobertura de seguros. Si un protocolo no tiene fondo de seguro y tú eres LP en un préstamo que acepta su token como colateral, en cierto modo estás asegurando esa exposición. En esta ocasión, los depositantes en WETH en Aave aprendieron esa lección de la forma más dura.

Un panorama más amplio: agentes IA como capa de seguridad

Este artículo trata de una herramienta y un robo, pero la idea más grande es que los agentes IA puedan ser una capa de seguridad independiente para inversores en DeFi.

El modo tradicional en cripto: los protocolos contratan auditorías, las firmas revisan código, y emiten informes. Pero este modelo tiene ciegas—el caso Kelp lo demuestra: se enfoca en la corrección del código, pero pasa por alto riesgos de configuración, gobernanza y arquitectura.

Claude Code y herramientas similares ofrecen otra vía: cualquiera puede usar datos públicos para que un agente IA evalúe riesgos en minutos. No necesitas pagar 200,000 USD a una firma de auditoría. No necesitas saber Solidity. El agente compara la arquitectura del protocolo con patrones de ataque conocidos y te plantea las preguntas que deberías hacer antes de invertir.

No reemplaza auditorías profesionales, pero reduce la barrera para la diligencia debida inicial. Un LP que considere invertir en un nuevo protocolo de staking líquido puede correr una evaluación estructurada de riesgos en governance, oráculos, puentes y economía—una verdadera transformación para inversores minoristas y de tamaño medio.

La auditoría de Kelp no fue perfecta. La calificó como riesgo medio, cuando en realidad debería haber sido grave. No penetró en la capa de configuración. Pero hizo las preguntas correctas—si el equipo de Kelp o cualquier LP hubiera tomado en serio esas preguntas, la pérdida de 292 millones de dólares podría haberse evitado.

Referencias

CoinDesk: La mayor operación de ataque en criptomonedas en 2026—Kelp DAO fue robado por 292 millones

Crypto Briefing: Kelp DAO sufrió un ataque de puente por 292 millones

DL News: Hackeo a protocolo DeFi Kelp DAO, pérdida de aproximadamente 300 millones

Bitcoin.com: ZachXBT revela ataque a KelpDAO por más de 280 millones

鉅亨網: La vulnerabilidad de 293 millones no está en el código

Declaración oficial de Aave en X

Informe completo de seguridad de Kelp DAO (6 de abril de 2026)

Código fuente de crypto-project-security-skill