¿Cómo ven los expertos en tecnología el incidente de hackeo de Kelp DAO?

Autor: Grvt Deep Research Institute

A la madrugada del 19 de abril, Kelp DAO fue hackeado a través del puente cross-chain rsETH basado en LayerZero, 116,500 rsETH salieron sin registros de quema correspondientes desde el OFTAdapter en la red principal, lo que equivale aproximadamente a 292 millones de dólares según el precio en ese momento. En una hora, Kelp ejecutó urgentemente pauseAll, pero el atacante realizó dos ataques adicionales posteriormente; si el contrato no hubiera sido pausado, la pérdida total habría alcanzado casi 391 millones de dólares.

Menos de un día después del incidente, Aave congeló los mercados de rsETH y wrsETH, la utilización de los pools clave alcanzó el 100%, y los usuarios tuvieron dificultades para retirar ETH, WETH e incluso USDT, USDC. Al menos 9 protocolos activaron respuestas de emergencia consecutivamente. Este es el mayor daño en DeFi en 2026, después de que hace tres semanas Drift Protocol sufriera un ataque por 285 millones de dólares. La suma de estos eventos ha planteado una cuestión cada vez más difícil de ignorar en la industria: ¿Son suficientes los marcos de seguridad actuales de DeFi para hacer frente a las amenazas de hoy?

¿Cómo ocurrió el ataque?

Para entender este incidente, primero hay que comprender la arquitectura cross-chain de Kelp.

Kelp utiliza el estándar OFT de LayerZero. La red principal posee permisos de emisión y redención de rsETH a través del contrato OFTAdapter, y más de 20 cadenas L2 se conectan mediante contratos OFT estándar que hacen de mapeo. No hay versiones wrapped en el cross-chain, sino que se emplea un mecanismo de liquidación 1:1 de débito y crédito: la destrucción en L2 se refleja en la liberación en la red principal, y la red principal bloquea los tokens para su emisión en L2.

El núcleo de este mecanismo es lzReceive, que en teoría solo acepta mensajes cross-chain verificados por LayerZero. En este caso, el atacante evadió esa lógica de verificación, falsificando un mensaje sin registros de quema en la cadena fuente, y activó directamente la liberación de reservas en el OFTAdapter en la red principal. Sin débito en la fuente, ocurrió un crédito en el destino. La conservación de la oferta omnichain, que normalmente se mantiene, fue rota en ese momento.

El CTO de Cyvers, Meir Dolev, comparó el ataque con: «La bóveda no tiene problema, los guardianes son honestos, la cerradura funciona normalmente. La mentira se susurra directamente a la única persona que puede abrir la puerta.» Esta metáfora describe con precisión el problema: no es un fallo en el diseño del sistema, sino que hay un eslabón de verificación en la cadena de confianza que puede ser comprometido.

¿Expertos qué opinan? Una falla estructural previsible

Kelp eligió la configuración de seguridad más débil permitida por LayerZero: 1/1 DVN, es decir, solo un verificador para validar los mensajes cross-chain.

Shalev Keren, cofundador de la firma de seguridad criptográfica Sodot, en una entrevista, afirmó directamente que esto representa «un fallo de punto único, sin importar cómo se empaquete la narrativa de marketing». Además, dijo que un solo nodo verificador comprometido sería suficiente para que los fondos salgan del puente, y que esta vulnerabilidad no puede ser reparada mediante auditorías o revisiones de seguridad; la única solución sería «eliminar la confianza unilateral en la arquitectura misma».

Más aún, esto no es un punto ciego que solo se pueda detectar después. Desde enero de 2025, un equipo de desarrollo ya había advertido en el foro de gobernanza de Aave que Kelp debería ampliar a múltiples verificadores DVN. Han pasado 15 meses y el segundo verificador aún no se ha añadido.

LayerZero afirmó posteriormente que ha instado varias veces a Kelp a actualizar a una configuración de múltiples verificadores, y anunció que dejará de aprobar mensajes para aplicaciones que sigan usando un solo verificador. Pero esta declaración también genera preguntas: si el riesgo ya era conocido, ¿por qué el protocolo no tomó medidas más estrictas antes, dejando la decisión completamente en manos de la capa de aplicación?

El debate sobre la «responsabilidad del protocolo» versus la «responsabilidad de la capa de aplicación» aún no tiene respuesta. Haoze Qiu, líder de Blockchain en Grvt, en una entrevista, señaló: «Kelp DAO aceptó una configuración de puente con poca redundancia para un volumen de activos de esta magnitud, lo que creó un punto único de fallo en la verificación. Al mismo tiempo, LayerZero también tiene responsabilidad, ya que el ataque involucró infraestructura relacionada con su stack de verificadores, aunque esto no fue considerado una vulnerabilidad central del protocolo. En DeFi interconectado, a los usuarios no les importa qué capa falló; lo que quieren saber es si el sistema es lo suficientemente robusto para proteger sus activos en momentos críticos.»

¿Cómo se propagó la infección?

La falla técnica fue solo la primera parte del incidente. La verdadera vulnerabilidad estructural se desplegó en la segunda mitad del ataque.

El atacante depositó los rsETH robados en plataformas de préstamos como Aave V3, V4, Compound V3, Euler, para obtener préstamos en activos reales con garantías casi sin valor. Solo en Aave, se prestaron aproximadamente 196 millones de dólares, con una deuda total superior a 236 millones. Desde el momento en que estos colaterales fueron depositados, las reservas en la red principal ya estaban vacías, imposibilitando su liquidación normal.

Luego, Aave congeló los mercados relacionados, la liquidez se contrajo abruptamente, y se produjo una ola de retiros por más de 100 mil millones de dólares. Fluid también congeló el mercado de rsETH, Upshift suspendió dos de sus vaults, Lido Earn detuvo los depósitos de earnETH en rsETH por exposición, y Ethena, por precaución, suspendió su puente OFT basado en LayerZero durante unas horas.

La cadena de contagio se extendió en pocas horas a nodos muy concentrados, no por un fallo de control de riesgo en un solo protocolo, sino como resultado directo de la sobreacumulación de LRT como colateral: staking, re-staking, despliegue cross-chain, préstamos y garantías, cada capa adicional añadía una confianza implícita. Cuando las reservas en la base se vaciaron, toda la cadena se desbalanceó.

Un dato relevante es que SparkLend ya eliminó rsETH de su lista de activos colaterales en enero de 2026. Frente a LRT, diferentes protocolos tomaron decisiones de control de riesgo muy distintas. Esta divergencia indica que en la industria aún no hay consenso sobre el riesgo sistémico de activos tipo LRT.

¿De quién fue la culpa? Lo que sabemos y lo que no

LayerZero, en su análisis posterior, atribuyó el ataque al grupo Lazarus de Corea del Norte, específicamente a su subunidad TraderTraitor, y señaló que ataques previos a Axie Infinity Ronin Bridge y WazirX también estaban relacionados con esa organización.

Pero Cyvers, en su análisis independiente, no comparte esa conclusión. Dolev afirmó que, aunque algunos patrones del ataque muestran similitudes en complejidad, escala y coordinación con acciones conocidas del DPRK, no hay evidencia concluyente de que wallets vinculadas a esa organización hayan estado involucradas.

El software malicioso utilizado por los atacantes se autolimpió tras el ataque, borrando binarios y logs, dificultando mucho la investigación posterior.

Que dos agencias de seguridad lleguen a conclusiones diferentes revela un problema: la industria de DeFi carece de mecanismos sistemáticos para compartir inteligencia y realizar análisis conjuntos. Saber quién lanzó el ataque es importante, pero entender cómo fue planeado y ejecutado, y cómo mejorar la detección de amenazas, es una prioridad mayor.

¿Cómo debe evolucionar la gestión de seguridad?

Tras este incidente, ya hay varias discusiones en marcha que merecen atención.

En el nivel de diseño del protocolo, la configuración de un solo verificador, como opción predeterminada, representa un riesgo de exposición. La decisión de LayerZero de dejar de aprobar aplicaciones con un solo verificador es una medida tardía pero necesaria. La cuestión más profunda es qué umbrales y mecanismos de imposición deben establecerse en el nivel de protocolo cuando se permite a las aplicaciones hacer decisiones de degradación de seguridad.

En la gestión de garantías, los protocolos de préstamos deben aplicar estándares más estrictos en la evaluación de activos LRT en listas blancas. La seguridad del puente cross-chain, la auditabilidad de las reservas, y la viabilidad de liquidaciones en escenarios extremos, han dependido en el pasado de declaraciones del propio protocolo en lugar de auditorías independientes. La decisión de SparkLend de retirar rsETH tres meses antes muestra que una evaluación prudente es posible, solo requiere estar dispuesto a sacrificar parte del TVL a corto plazo. Para plataformas que integran fondos de usuarios en DeFi, la lógica es la misma: monitoreo continuo, decisiones rápidas, y ajuste proactivo de exposición antes de que la incertidumbre se convierta en pérdida. En este incidente, Grvt adoptó esta estrategia, ajustando rápidamente su exposición DeFi tras detectar presión en el mercado para proteger los fondos de los usuarios.

En la capa de operación y seguridad, la infiltración en la cadena de suministro de Drift y la planificación previa en Kelp muestran que los ataques de alto riesgo no solo ocurren en la cadena. La gestión de claves, los procesos internos, y las auditorías de terceros deben integrarse formalmente en el sistema de seguridad del protocolo, no dejarse en un área gris de «mejores prácticas de ingeniería».

En la colaboración de la industria, la discrepancia en las atribuciones de los ataques revela que la compartición de inteligencia en cadena y la estandarización aún son deficientes. Se requiere un mecanismo más sistemático de intercambio de información entre firmas de seguridad, equipos de protocolos e infraestructura, en lugar de análisis aislados post-evento.

Conclusión

En los primeros cuatro meses de 2026, las pérdidas por ataques en DeFi ya alcanzan casi mil millones de dólares. Drift y Kelp han contribuido con dos incidentes superiores a 280 millones cada uno, en menos de tres semanas.

No se trata de un cisne negro probabilístico, sino de una señal clara para la industria: los modelos de amenaza asumidos por los marcos de seguridad existentes ya no cubren las formas reales de ataque actuales.

La evolución de la gestión de seguridad en DeFi no puede ser responsabilidad de un solo protocolo. Requiere que diseñadores, infraestructura, plataformas de préstamos y expertos en seguridad recalibren sus hipótesis de riesgo y encuentren formas conjuntas de fortalecer la resiliencia del ecosistema.

Este diálogo apenas comienza.