Kelp DAO abandona LayerZero por Chainlink tras el robo de 292 millones

292 millones de dólares, un solo nodo de verificación y una decisión que ningún otro protocolo quería tomar primero. El 18 de abril de 2026, un atacante vació el bridge de Kelp DAO falsificando un único mensaje cross-chain en LayerZero, llevándose 116.500 rsETH, aproximadamente el 18% de la oferta total del token. Semanas después llegó la respuesta que realmente importa: Kelp migró rsETH de LayerZero a Chainlink. No es un detalle técnico menor. Afecta directamente a la forma en que gran parte de DeFi mantiene unidas sus cadenas.

¿Cómo se vacía un bridge sin tocar el código?

Básicamente, el contrato no tenía ningún fallo. El engaño estaba en otro lugar. Kelp usaba una Decentralized Verifier Network configurada como “1-of-1”: un único verificador decidía si un mensaje procedente de otra cadena era auténtico. Bastaba con convencer a ese solo nodo. Los atacantes, vinculados al grupo norcoreano Lazarus según el análisis de Chainalysis y LayerZero, accedieron a la lista de RPC del verificador, comprometieron dos nodos y sustituyeron los binarios en ejecución, mientras un ataque DDoS silenciaba los externos. Resultado: el adaptador de Kelp en Ethereum liberó rsETH reales contra un “burn” que nunca ocurrió, y cada transacción, on-chain, parecía completamente válida.

Earlier today we identified suspicious cross-chain activity involving rsETH. We have paused rsETH contracts across mainnet and several L2s while we investigate.

We are working with @LayerZero_Core, @unichain, our auditors and top security experts on RCA.

We will keep you…

, Kelp (@KelpDAO) April 18, 2026

Dos mensajes falsificados adicionales, por más de 100 millones de dólares, ya habían pasado antes de que el multisig de emergencia lograra activar la pausa, 46 minutos después del inicio del ataque. El peso creciente de Pyongyang en los ataques cripto de 2026 es un patrón documentado por TRM Labs y Chainalysis a lo largo del año.

Por qué era un problema de todos, no solo de Kelp

Aquí está la parte incómoda. Kelp sostuvo que la configuración de verificador único no era un atajo descuidado, sino el comportamiento por defecto documentado en las guías de LayerZero. LayerZero respondió que esa elección es de nivel aplicativo y queda fuera del alcance de su bug bounty. Pero el dato numérico es el que debería hacer reflexionar: según las configuraciones on-chain de LayerZero de mayo de 2026, casi la mitad de las aplicaciones activas en la red funcionaba con ese mismo esquema. Un único punto de fallo, replicado por todas partes, normalizado. Tras el exploit, LayerZero prohibió las configuraciones 1-of-1 e impuso la migración hacia esquemas multi-verificador. Eso confirma que el riesgo no era un incidente aislado: era arquitectura.