292 millones de dólares robados sin tocar un solo contrato inteligente. El 18 de abril de 2026, el protocolo de restaking líquido KelpDAO fue drenado a través de su bridge de LayerZero — no por un bug en Solidity, sino porque un solo verificador era suficiente para aprobar mensajes cross-chain, y el atacante envenenó los nodos RPC que ese verificador consultaba. En 46 minutos, Kelp pausó el protocolo y evitó otros 200 millones en pérdidas. Pero el daño estaba hecho: Aave enfrenta hasta 230 millones en deuda incobrable, el TVL de DeFi cayó un 25 % en horas, y los investigadores señalan al mismo grupo que drenó Drift Protocol 17 días antes — el Grupo Lazarus de Corea del Norte. 575 millones de DeFi en 18 días, con dos vectores completamente distintos.
Este artículo desglosa la mecánica del exploit, por qué la configuración por defecto de LayerZero era una bomba de relojería, quién paga la factura, y qué significa para cualquiera que tenga fondos en protocolos que usan bridges cross-chain.
Aviso editorial: este artículo es informativo y se basa en datos públicos del post-mortem de LayerZero (20 de abril), declaraciones de Aave y KelpDAO, y análisis de investigadores on-chain. La situación sigue en evolución. Los datos reflejan el estado al 21 de abril de 2026.
¿Cómo robaron 292 millones sin explotar un contrato inteligente?
A las 17:35 UTC del 18 de abril, el atacante llamó a lzReceive en el contrato EndpointV2 de LayerZero, instruyendo al OFTAdapter de Kelp en Ethereum a liberar 116.500 rsETH — aproximadamente el 18 % del suministro circulante del token. Ningún burn correspondiente ocurrió en la cadena de origen (Unichain). El atacante fabricó un mensaje cross-chain falso que el bridge aceptó como legítimo.
¿Cómo? No rompieron criptografía ni encontraron un bug en el código. Envenenaron la infraestructura:
- Obtuvieron la lista de endpoints RPC que el Decentralized Verifier Network (DVN) de LayerZero consultaba para leer el estado de Unichain.
- Sustituyeron los binarios de dos nodos independientes con versiones modificadas que devolvían datos falsos al DVN — pero respondían correctamente a los sistemas de monitorización.
- Lanzaron un ataque DDoS contra los endpoints de respaldo para forzar que el DVN usara los nodos envenenados.
- El malware se autodestruyó después del ataque para eliminar rastros forenses.
La condición que lo hizo posible: Kelp usaba una configuración 1-de-1 en su bridge — un solo verificador era suficiente para aprobar cualquier mensaje cross-chain. Sin redundancia, sin segundo check. Un único punto de fallo para 292 millones.
¿46 minutos bastaron para evitar otros 200 millones en pérdidas?
El multisig de emergencia de Kelp ejecutó pauseAll a las 18:21 UTC — 46 minutos después del drenaje. A las 18:26 y 18:28, el atacante intentó dos transacciones adicionales para drenar otros 40.000 rsETH cada una (~100 millones por intento). Ambas revertieron porque el protocolo ya estaba pausado.
Si la pausa hubiera llegado 10 minutos más tarde, el robo total habría alcanzado los 391 millones.
Qué hizo el atacante con los fondos
En minutos, 89.567 de los 116.500 rsETH robados fueron depositados como colateral en Aave V3/V4 a través de siete wallets. Contra ese colateral, el atacante pidió prestados 82.650 WETH (190,9 millones) y 821 wstETH (2,3 millones). Algunas estimaciones elevan el total prestado a 126.000 WETH (236 millones) sumando otros protocolos. El WETH prestado fue canalizado a través de Tornado Cash — el mismo mixer que había financiado la wallet del atacante con 1 ETH diez horas antes del robo.
¿Quién paga la factura de 230 millones en deuda incobrable?
El robo directo de 292 millones es solo una parte del daño. Porque el atacante convirtió rsETH robado en activos reales prestados en protocolos de lending, varias plataformas enfrentan deuda que no se puede cobrar:
| Plataforma | Deuda incobrable estimada | Estado |
|---|---|---|
| Aave V3/V4 | 124 – 230 M$ | Informe de Chaos Labs publicado, pausa del módulo Umbrella recomendada |
| Compound V3 | ~39 M$ | Propuesta para deshabilitar rsETH como colateral en 5 cadenas |
| Euler | < 1 M$ | Contenido |
Los contratos de Aave no fueron comprometidos — el fundador Stani Kulechov confirmó que el vector fue completamente externo. Pero el protocolo sufrió más de 5.400 millones en retiros en horas, empujando los pools de WETH, USDT y USDC al 100 % de utilización. Los depositantes quedaron atrapados. El mismo patrón que vimos con USR-Morpho en marzo — cuando un colateral se rompe, la liquidez del pool se evapora y los prestamistas no pueden salir.
El token AAVE cayó entre un 10 y un 18 %. El TVL de DeFi se desplomó de ~110.000 millones a ~82.400 millones — un drawdown del 25 % que refleja huida de riesgo, no solo pérdidas directas.
La única recuperación significativa: el 21 de abril, el Consejo de Seguridad de Arbitrum congeló 30.766 ETH (~71 millones) en una wallet intermediaria, actuando por información de las fuerzas de seguridad. Eso representa un 24 % de los fondos robados.
¿De quién es la culpa — LayerZero o KelpDAO?
La guerra pública entre ambos importa porque determina si el ~47 % de las aplicaciones integradas con LayerZero necesitan reconfigurarse inmediatamente.
LayerZero dice: Kelp "eligió" la configuración de un solo verificador. El exploit fue consecuencia directa de esa decisión. A partir de ahora, LayerZero se niega a firmar mensajes para aplicaciones que sigan en configuración 1-de-1.
Kelp responde: la configuración 1-de-1 era el default documentado de LayerZero. A pesar de tener un canal de comunicación directo abierto desde julio de 2024, nunca les advirtieron específicamente que debían cambiarla.
Desarrolladores independientes corroboraron la versión de Kelp: el archivo de configuración por defecto de LayerZero V2 (layerzero.config.ts) se entrega con un setup de 1-required / 0-optional. Y el DVN comprometido era infraestructura propia de LayerZero Labs, no un verificador de terceros.
La lectura honesta: ambos comparten responsabilidad. LayerZero creó defaults inseguros que hacían trivial la configuración peligrosa, y un protocolo que custodia miles de millones debería haber endurecido más allá de los defaults. El incidente revela que la revisión de configuración de bridges es una disciplina de seguridad diferente de las auditorías de contratos inteligentes — y una que la mayoría de protocolos ha tratado como un checkbox.
¿575 millones en 18 días — qué está haciendo el Grupo Lazarus?
Los investigadores — incluido el equipo de Chainalysis y ZachXBT — atribuyen preliminarmente el ataque a la subunidad TraderTraitor del Grupo Lazarus de Corea del Norte. Es el mismo grupo vinculado a:
| Ataque | Fecha | Monto | Vector |
|---|---|---|---|
| Bybit | 2025 | 1.400 M$ | Compromiso de infraestructura |
| Drift Protocol | 1 abr 2026 | 285 M$ | Manipulación de oráculo + ingeniería social |
| KelpDAO | 18 abr 2026 | 292 M$ | Envenenamiento de RPC + bridge 1-de-1 |
575 millones de DeFi en 18 días con dos vectores estructuralmente diferentes. No es un script kiddie repitiendo el mismo truco — es una campaña sofisticada que identifica las costuras entre sistemas (bridges, gobernanza, oráculos) donde las auditorías de código no llegan.
Chainalysis lo resumió: "Detectar código malicioso no es suficiente; los protocolos deben detectar cuando un sistema entra en un estado imposible."
¿Qué significa para el restaking y los bridges cross-chain?
No hay contagio estructural al sector LST/LRT más amplio. stETH, wstETH, rETH y cbETH no están afectados. Los depósitos de rsETH en Ethereum mainnet siguen respaldados por posiciones legítimas en EigenLayer.
Pero el rsETH bridgeado a otras cadenas enfrenta una crisis de paridad severa: los holders no pueden saber si sus tokens tienen respaldo, porque el atacante inyectó 116.500 unidades sin colateral en el suministro circulante. Kelp no ha publicado un plan de asignación de pérdidas.
La respuesta precautoria fue inmediata: Lido pausó earnETH, Ethena pausó sus bridges LayerZero durante 6 horas (sin exposición a rsETH), y más de 20 protocolos — Ether.fi, Curve, Morpho, Kamino, Lombard, Beefy, Maple, Mantle entre otros — pausaron temporalmente sus bridges LayerZero. SparkLend y Fluid congelaron los mercados de rsETH.
¿Qué debería revisar cualquier usuario de DeFi ahora?
- ¿Tienes tokens bridgeados? Cualquier token que cruzó un bridge (rsETH, pero también wETH, USDC bridgeado, etc.) hereda el riesgo de la configuración del bridge, no solo del contrato del token. Un wrapped token en una L2 puede tener un perfil de riesgo fundamentalmente distinto al token nativo en su cadena de origen.
- ¿Usas rsETH como colateral? Si tienes posiciones en Aave, Compound o Euler con rsETH, tu Health Factor depende ahora de un activo cuyo respaldo está en disputa. Monitoriza activamente.
- ¿Tus protocolos usan bridges LayerZero? Verifica si la aplicación usa configuración 1-de-1 o multisig. El ~47 % de las aplicaciones LayerZero estaban en configuración vulnerable antes del ataque.
- Diversifica riesgo de bridge. No concentres exposición cross-chain en un solo proveedor de bridge. La base de tu pirámide de fragilidad no debería depender de un punto único de fallo.
El exploit de Kelp es el primer hack de nueve cifras cuya causa raíz está completamente fuera de Solidity — en la seguridad operativa de infraestructura off-chain que alimenta un verificador de bridge. Durante cinco años, la industria endureció contratos inteligentes con auditorías, verificación formal y bug bounties. Los atacantes se han movido aguas arriba, a capas de infraestructura donde esas defensas no aplican. La configuración por defecto no es una configuración segura a escala — y esa lección acaba de costar 292 millones de dólares.
¿Sabes en cuántos bridges está distribuido tu capital?
CleanSky muestra tus posiciones por cadena y protocolo — para que veas dónde tienes exposición cross-chain antes de que un bridge falle. Sin custodiar tus fondos. Descubre cómo funciona.