Autor: Zengineer
Compilación: Deep Tide TechFlow
Guía de Deep Tide: El 18 de abril, Kelp DAO fue hackeado por 292 millones de dólares, el mayor incidente DeFi hasta ahora en 2026. La vulnerabilidad no estaba en el código del contrato, sino en la configuración del nodo validador 1-de-1 del puente cross-chain de LayerZero: un único punto de falla que permitió falsificar mensajes cross-chain. Hace 12 días, cuando el autor escaneó Kelp con su propia herramienta de auditoría de IA de código abierto, ya había marcado este punto. Este artículo analiza todo el proceso del ataque y reflexiona honestamente sobre tres cosas que la herramienta hizo mal en ese momento.
Qué es Kelp DAO
Kelp DAO es un protocolo de re-staking de liquidez construido sobre EigenLayer. El mecanismo es 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 operadores de nodos de EigenLayer para re-staking—proveyendo seguridad a múltiples AVS (Servicios de Validación Activa) simultáneamente. Como recompensa, los usuarios reciben rsETH como certificado. A diferencia del re-staking directo en EigenLayer (donde los activos quedan bloqueados), rsETH es líquido—se puede negociar, usar como colateral en protocolos de préstamo como Aave, o transferir cross-chain.
Para lograr esta liquidez cross-chain, Kelp utilizó el estándar OFT (Token Fungible Omnicadena) de LayerZero para desplegar rsETH en más de 16 cadenas. Cuando transfieres rsETH desde Ethereum a una L2, la DVN (Red de Verificadores Descentralizada) de LayerZero verifica si el mensaje cross-chain es legítimo. Esta arquitectura de puente es el núcleo de la historia posterior.
Kelp fue iniciado por Amitej Gajjala y Dheeraj Borra (anteriormente cofundadores de Stader Labs), se lanzó en diciembre de 2023, alcanzó un TVL máximo de 2.09 mil millones de dólares, y su gobierno utiliza una multisig 6/8 más un timelock de 10 días para upgrades de contratos. El token de gobierno KERNEL gestiona tres líneas de producto: Kelp, Kernel y Gain.
El incidente del robo
El 18 de abril de 2026, un atacante extrajo 116,500 rsETH del puente cross-chain de Kelp DAO, equivalentes a aproximadamente 292 millones de dólares—el mayor ataque DeFi hasta la fecha en 2026. La causa raíz no fue una vulnerabilidad de contrato inteligente, sino un problema de configuración: una configuración DVN 1-de-1 (es decir, solo 1 nodo validador, con 1 firma suficiente) permitió al atacante falsificar mensajes cross-chain comprometiendo un único nodo.
12 días antes, el 6 de abril, mi herramienta de auditoría de seguridad de código abierto ya había marcado este vector de ataque.
Primero, una aclaración: este robo implica pérdidas reales de dinero real para personas reales. Los depositantes de WETH en Aave que nunca tocaron rsETH ven sus fondos congelados; los LPs en múltiples protocolos deben absorber deudas incobrables que nunca acordaron asumir. Este artículo analiza lo que sucedió y lo que nuestra herramienta capturó—pero el costo real de las pérdidas humanas es más importante que cualquier puntuación.
El informe completo está en GitHub, con una marca de tiempo de commit que cualquiera puede verificar. A continuación, lo que detectamos, lo que nos perdimos y lo que esto significa para las herramientas de seguridad DeFi.
46 minutos que conmovieron al DeFi
A las 17:35 UTC del 18 de abril, el atacante comprometió ese nodo validador DVN aislado y luego lo hizo "aprobar" un mensaje cross-chain falso. El Endpoint de LayerZero, al ver que la DVN lo aprobaba, pasó el mensaje vía lzReceive al contrato OFT de Kelp—que procedió a acuñar 116,500 rsETH en Ethereum mainnet. El mensaje afirmaba que activos equivalentes estaban bloqueados como garantía en otra cadena. Esos activos nunca existieron.
Lo siguió un flujo estándar de lavado de dinero en DeFi:
- Depositar los rsETH robados como colateral en Aave V3, Compound V3, Euler
- Usar este colateral sin garantía real para pedir prestados aproximadamente 236 millones de dólares en WETH
- Consolidar alrededor de 74,000 ETH y retirarlos through Tornado Cash
46 minutos después, a las 18:21, la multisig de pausa de emergencia de Kelp congeló el contrato. Dos intentos de seguimiento del atacante (40,000 rsETH cada uno, ~100 millones USD) revertieron—esta pausa bloqueó otros ~200 millones.
Pero el radio de impacto aún fue severo. Aave V3 absorbió ~177 millones en deuda incobrable. El token AAVE cayó un 10.27%. ETH cayó un 3%. La utilización de WETH en Aave se disparó al 100%, con depositantes apresurándose a retirar. Los rsETH en más de 20 L2s se convirtieron de la noche a la mañana en activos de valor cuestionable.
6 de abril, qué capturó el informe
A principios de abril, justo después de que Drift Protocol fuera hackeado por 285 millones el 1 de abril, escribí una skill de Claude Code de código abierto, crypto-project-security-skill—un marco de evaluación de riesgos arquitectónicos asistido por IA, usando datos públicos (DeFiLlama, GoPlus, Safe API, verificación on-chain) para evaluar protocolos DeFi. No es un escáner de código ni una herramienta de verificación formal. El incidente de Drift me hizo ver claramente que lo que realmente causa las mayores pérdidas no está en el código del contrato inteligente—sino en vulnerabilidades de gobierno, descuidos de configuración, puntos ciegos arquitectónicos, lugares que los escáneres de código nunca ven. Así que escribí una herramienta que evalúa específicamente estas capas: estructura de gobierno, dependencias de oráculos, mecanismos económicos, arquitectura cross-chain, comparando cada protocolo con patrones de ataque históricos famosos (Drift, Euler, Ronin, Harmony, Mango).
El 6 de abril, ejecuté una auditoría completa en Kelp DAO. El informe completo está público en GitHub, con una marca de tiempo de commit inmutable.
La puntuación de triaje compuesta del informe para Kelp fue 72/100 (riesgo medio). En retrospectiva, esta calificación fue demasiado indulgente—esas brechas de información cross-chain no resueltas deberían haberla reducido. Pero incluso con una calificación de riesgo medio, el informe señaló el vector de ataque que luego fue explotado.
La siguiente captura de pantalla es el texto original de la sección "Brechas de Información" del informe—esa pregunta sobre la configuración DVN de Kelp que se convirtió en la causa raíz del robo de 292M:
Leyenda: Capítulo "Brechas de Información" del informe del 6 de abril, la opacidad de la configuración DVN fue señalada directamente
A continuación, un desglose de lo que el informe marcó versus lo que realmente sucedió.
Hallazgo 1: Opacidad de la configuración DVN (Señal de advertencia)
Texto original del informe: «La configuración de LayerZero DVN (conjunto de validadores por cadena, requisitos de umbral) no está divulgada públicamente»
Qué sucedió realmente: Kelp ejecutaba una configuración DVN 1-de-1. Un nodo. Un único punto. El atacante comprometió este único nodo y falsificó mensajes cross-chain. Si la configuración hubiera sido 2-de-3 (el mínimo recomendado en la industria), el atacante habría tenido que comprometer múltiples partes validadoras independientes simultáneamente.
Queda claro: esto es un problema de Kelp, no de LayerZero. LayerZero es infraestructura—proporciona el marco DVN, cada protocolo elige su configuración: cuántos validadores (1-de-1, 2-de-3, 3-de-5...), qué nodos usar, qué umbrales por cadena. Kelp eligió 1-de-1 al desplegar su puente OFT. LayerZero soporta completamente 2-de-3 o superior—Kelp simplemente no lo habilitó.
Una analogía: AWS ofrece MFA (autenticación multifactor). Si tu cuenta es hackeada porque nunca activaste MFA, es tu problema, no de AWS. LayerZero puso los mecanismos de seguridad ahí, Kelp no los usó.
Nuestro informe no pudo determinar el umbral DVN específico en ese momento (porque Kelp nunca lo divulgó), pero listamos explícitamente esta opacidad como una brecha de información no resuelta y un elemento de riesgo. La falta de voluntad para divulgar es en sí misma una bandera roja.
Hallazgo 2: Punto único de falla en 16 cadenas (Acierto directo)
Texto original del informe: «Un punto único de falla en la DVN de LayerZero podría afectar simultáneamente a rsETH en las 16 cadenas soportadas»
Qué sucedió realmente: El mensaje falso impactó directamente Ethereum mainnet, y la onda expansiva se extendió a todas las cadenas donde rsETH estaba desplegado. LayerZero suspendió preventivamente todos los puentes OFT salientes de Ethereum. Los tenedores de rsETH en más de 20 L2s vieron cómo sus tokens一夜之间 se volvieron activos de valor cuestionable.
Este es el riesgo sistémico de los despliegues multi-cadena: rsETH circula simultáneamente en Arbitrum, Optimism, Base, Scroll y otras L2, pero el valor de todos estos tokens se deriva de los activos en Ethereum mainnet. El puente de mainnet es comprometido, y rsETH en cada L2 pierde instantáneamente su garantía—los tenedores no pueden canjear, ni verificar si sus tokens aún tienen valor. El earnETH de Lido (con exposición a rsETH), el puente LayerZero de Ethena—todos se vieron forzados a pausar. El radio de explosión fue mucho más allá del propio Kelp.
Hallazgo 3: Control de gobierno cross-chain no verificado (Problema relacionado)
Texto original del informe: «El control de gobierno sobre la configuración OFT de LayerZero en cada cadena no está verificado—específicamente: si estos controles pertenecen a la misma multisig 6/8 y timelock de 10 días, o están manejados por claves admin independientes»
Qué sucedió realmente: La configuración DVN claramente no estaba bajo el estricto gobierno del protocolo central. Si los cambios de configuración del puente también estuvieran gobernados por la multisig 6/8 + timelock de 10 días, una configuración DVN 1-de-1 requeriría el acuerdo de 6 de 8 firmantes—es poco probable que tal configuración pasara desapercibida.
Esto expone un punto ciego de gobierno: muchos protocolos establecen multisigs estrictas y timelocks para upgrades de contratos centrales, pero en cambios a nivel operativo—configuración de puentes, parámetros de oráculos, gestión de whitelists—a menudo solo una clave admin puede modificarlos. El gobierno del protocolo central de Kelp era líder en la industria (multisig 6/8 + timelock 10 días), pero estas protecciones no se extendieron a su mayor superficie de ataque: el puente cross-chain.
Hallazgo 4: Coincide con el patrón de ataque de Ronin/Harmony (Acierto directo)
Texto original del informe: «Los precedentes históricos más relevantes involucran seguridad de puentes. El despliegue de Kelp en 16 cadenas con LayerZero introduce una complejidad operativa similar a la arquitectura multi-cadena de Ronin»
Qué sucedió realmente: La ruta de ataque casi replica perfectamente el guion de Ronin—comprometer validadores del puente, falsificar mensajes, drenar activos. El módulo de matching de patrones de ataque de nuestra herramienta, que compara la arquitectura del protocolo con categorías de ataques históricos, identificó correctamente esto como el vector de ataque de mayor riesgo.
Antecedentes históricos: En 2022, el puente de Ronin perdió 625 millones tras comprometer 5 (de 9) validadores; ese mismo año, el puente Horizon de Harmony perdió 100 millones tras comprometer 2 (de 5) validadores. La situación de Kelp era más extrema—solo 1 validador, llevando el listón de ataque al mínimo absoluto. La herramienta pudo marcar este riesgo porque automáticamente contrasta la arquitectura del protocolo con estos patrones de ataque históricos, no solo mirando el código.
Hallazgo 5: Sin pool de seguro (Amplificó las pérdidas)
Texto original del informe: «El protocolo actualmente no tiene un pool de seguro dedicado, ni un mecanismo de socialización de pérdidas para absorber eventos de slashing»
Qué sucedió realmente: Al no haber reservas de seguro, los 292 millones de pérdidas fueron absorbidos entirely por los protocolos aguas abajo. La reserva de recuperación de Aave cubrió menos del 30% de sus 177 millones en deuda incobrable. Los LPs que no tenían nada que ver con las decisiones de configuración del puente de Kelp—absorbieron el mayor impacto.
El atacante depositó los rsETH robados como colateral en Aave V3, Compound V3, Euler, y luego tomó prestado WETH real. Una vez que se confirmó que rsETH no tenía garantía, estas posiciones se convirtieron en deuda incobrable "inliquidable"—el colateral se volvió papel mojado, pero el WETH prestado ya se había ido. La utilización de WETH en Aave se disparó al 100%, los usuarios normales no podían ni retirar. Si eras un depositante de WETH en Aave, incluso si nunca tocaste rsETH, tus fondos se vieron afectados. La asociación de seguros de Kelp con Nexus Mutual solo cubría productos específicos de vault, no la exposición central del protocolo rsETH.
Esto fue un fallo en ambos lados. Lado Kelp: un protocolo manejando 1.3B TVL, cero pool de seguro, cero mecanismo de absorción de pérdidas. Cuando el puente fue comprometido, no hubo amortiguación para absorber el daño. Lado Aave: Aceptó rsETH como colateral, pero no evaluó suficientemente el riesgo de configuración de su puente cross-chain. Los parámetros de riesgo de Aave (LTV, umbral de liquidación) fueron diseñados para volatilidad de precios normal, pero no consideraron el riesgo de cola de "configuración de puente comprometida hace que el colateral caiga a cero overnight". La reserva de recuperación ni siquiera cubría el 30% de la deuda incobrable. Esencialmente, fue una falla en la fijación de precios del riesgo: Aave trató a rsETH como un activo de volatilidad normal, pero en realidad llevaba un riesgo de cola binario de fallo del puente. Los fallos de ambos lados se superpusieron—Kelp no tenía seguro para evitar que colateral malo entrara al sistema, Aave no hizo un modelado de riesgo lo suficientemente granular para limitar la exposición en este escenario.
Dónde nos equivocamos
Tres cosas que deberían haberse hecho mejor:
La calificación de riesgo fue demasiado baja. Calificamos el riesgo del puente cross-chain como "medio". 3 de las 5 brechas de información no resueltas en el informe estaban relacionadas con la configuración del puente LayerZero, además de coincidir con patrones de ataque históricos de Ronin/Harmony—esto debería haber sido "Alto" o "Crítico". La opacidad en sí misma debería haber sido una señal más fuerte.
No pudimos penetrar la capa de configuración. El informe pidió repetidamente a Kelp que divulgara el umbral DVN, pero no pudimos verificarlo independientemente. Este es exactamente el mismo punto ciego estructural señalado por el análisis post-mortem de 鉅亨網: las herramientas de auditoría existentes se centran en la lógica del código, no capturan los riesgos a nivel de configuración. Marcamos el problema, pero no pudimos responderlo.
No verificamos on-chain. La configuración DVN en realidad se puede leer directamente on-chain a través del contrato EndpointV2 de LayerZero. Podríamos haber consultado el registro ULN302 para verificar independientemente el umbral DVN de Kelp, en lugar de marcarlo como "no divulgado". Si lo hubiéramos hecho, habríamos visto directamente la configuración 1-de-1, sin necesidad de que Kelp lo divulgara. Esta es la mejora más concreta para la herramienta: agregar verificación on-chain de la configuración DVN en el paso de evaluación cross-chain.
Los hallazgos no fueron lo suficientemente específicos, ni accionables. Decir "configuración DVN no divulgada" es observar una falta de documentación—no predecir un ataque. Estos riesgos (concentración de oráculos, dependencia de puentes, falta de seguro) son igualmente prevalentes en la mayoría de los protocolos DeFi cross-chain. La herramienta marcó la opacidad de Kelp, pero también ha marcado patrones similares en docenas de protocolos que no fueron atacados. Sin publicar una tasa de falsos positivos, afirmar "lo predijimos" es exagerar. La declaración más honesta es: Hicimos algunas preguntas correctas que nadie más estaba haciendo, y una de ellas resultó ser el punto de apoyo crítico.
Sobre la "divulgación responsable"
Una pregunta justa: Si marcamos estos riesgos el 6 de abril, ¿por qué no notificamos a Kelp antes del ataque del 18 de abril?
No notificamos. La razón: El informe identificó opacidad—"configuración DVN no divulgada", no una vulnerabilidad explotable concreta. No sabíamos que la configuración era 1-de-1, solo sabíamos que la configuración no era pública. No había nada lo suficientemente concreto para divulgar. "La configuración de tu puente no está documentada" es una observación de gobierno, no un reporte adecuado para un programa de bug bounty.
En retrospectiva, podríamos haber contactado directamente al equipo de Kelp y preguntado sobre su umbral DVN. Esa conversación podría haber expuesto la configuración 1-de-1 y provocado una reparación. No lo hicimos. Es una lección: incluso si un hallazgo parece demasiado vago para un proceso de divulgación formal, vale la pena enviar un mensaje privado para preguntar.
Qué significa esto para la seguridad DeFi
El robo de Kelp—al igual que el robo de Drift 17 días antes—no fue una vulnerabilidad de contrato inteligente. Los escáneres de código automatizados como Slither, Mythril, o incluso GoPlus, no lo habrían captado. La vulnerabilidad estaba escondida en la configuración de despliegue, brechas de gobierno, decisiones arquitectónicas, situadas por encima de la capa de código.
Esta es también la tesis central de crypto-project-security-skill:
La seguridad del protocolo no es solo seguridad del código. Un protocolo puede tener Solidity perfecto, cinco auditorías de empresas top, una bug bounty de 250k dólares—y aun así ser robado por 292 millones debido a un problema de configuración de validadores de puente.
La herramienta es de código abierto en GitHub—cualquiera puede revisar la metodología, ejecutarla por su cuenta, o mejorarla.
Cronología
12 días. La señal ya estaba ahí. La pregunta es: ¿cómo construye el ecosistema herramientas que puedan ver estas señales antes de que caiga el próximo puente?
Qué puedes hacer
Si tienes activos en protocolos DeFi con puentes cross-chain:
- Ejecuta una auditoría tú mismo. La herramienta es open source. No nos creas—verifica por ti mismo.
- Verifica la configuración de validadores del puente. Si un protocolo se niega a divulgar su umbral DVN, considéralo una bandera roja. Nuestro informe hizo exactamente eso, y acertó.
- No asumas que las auditorías de código cubren todo. Kelp tenía 5+ auditorías de código de empresas y plataformas conocidas (Code4rena, SigmaPrime, MixBytes). Las auditorías de código tradicionales no están diseñadas para capturar riesgos a nivel de configuración como la configuración del umbral DVN—ese es otro tipo de análisis, no una falla de la empresa auditora.
- Evalúa la cobertura de seguros. Si un protocolo no tiene pool de seguro, y eres un LP en una plataforma de préstamos que acepta su token como colateral, estás asegurándolo implícitamente. Los depositantes de WETH en Aave aprendieron esto de la manera más dura.
El panorama más amplio: Agentes IA como capa de seguridad
Este artículo trata sobre una herramienta y un robo. Pero la propuesta subyacente es más grande: Los Agentes IA pueden ser una capa de seguridad independiente para los inversores DeFi.
El modelo de seguridad tradicional de la criptoindustria es así: el protocolo contrata una empresa auditora, la auditoría revisa el código, la auditoría emite un informe. Este modelo tiene puntos ciegos—el incidente de Kelp lo demuestra, se centra en la corrección del código pero pasa por alto los riesgos de configuración, gobierno y arquitectura.
Claude Code y este tipo de herramientas de skills ofrecen otro camino: cualquiera puede usar datos públicos para ejecutar una evaluación de riesgos asistida por IA en cualquier protocolo en minutos. No necesitas gastar 200k en una empresa auditora. No necesitas saber leer Solidity. Le pides al agent que compare la arquitectura del protocolo con patrones de ataque conocidos, y te planteará las preguntas que deberías hacer antes de depositar dinero.
Esto no reemplaza las auditorías profesionales—pero reduce el listón de la primera capa de due diligence a algo que todos pueden usar. Un LP considerando desplegar capital en un nuevo protocolo de re-staking ahora puede ejecutar un `audit defi
Ese informe de Kelp no fue perfecto. Calificó el riesgo del puente como medio, debería haber sido crítico. No penetró la capa de configuración. Pero hizo las preguntas correctas—si el equipo de Kelp o cualquier LP las hubiera tomado en serio entonces, se podrían haber evitado pérdidas de 292 millones.
