Por Canuto  

La disputa entre Kelp DAO y LayerZero escaló tras el hackeo de USD $292 millones al puente de rsETH. Kelp asegura que la configuración de seguridad que luego fue señalada como causa del exploit había sido revisada y aceptada por personal de LayerZero durante años, mientras el protocolo anuncia su salida hacia Chainlink CCIP.
***

  • Kelp afirma que personal de LayerZero aprobó la configuración DVN 1-de-1 que luego fue culpada por el hackeo.
  • El exploit drenó 116.500 rsETH, valorados en unos USD $292 millones, y fue vinculado al grupo Lazarus de Corea del Norte.
  • Tras la controversia, Kelp anunció la migración de rsETH desde OFT de LayerZero hacia CCIP de Chainlink.

 

La disputa entre Kelp DAO y LayerZero sumó un nuevo capítulo tras el exploit que vació cerca de USD $292 millones del puente rsETH. Kelp sostiene que la configuración de verificación 1-de-1, señalada después por LayerZero como causa clave del incidente, había sido revisada y aceptada por personal del propio proveedor de interoperabilidad durante un período de más de 2,5 años.

El caso golpea a uno de los temas más delicados del ecosistema multicadena: quién asume la responsabilidad cuando una aplicación integra una infraestructura de mensajería entre redes usando configuraciones que, aunque técnicamente posibles, terminan siendo inseguras en la práctica. En este contexto, Kelp no solo rechaza la explicación pública de LayerZero, sino que además anunció que moverá rsETH hacia la infraestructura CCIP de Chainlink.

De acuerdo con la cobertura publicada por CoinDesk, el memorando de Kelp contradice directamente el informe post mortem del 19 de abril emitido por LayerZero. En ese documento, LayerZero afirmó que la aplicación rsETH de Kelp dependía de LayerZero Labs como único verificador y que esa decisión contradecía su modelo recomendado de múltiples DVN, o redes descentralizadas de verificadores.

Kelp, sin embargo, asegura que esa lectura omite un detalle central. Según su versión, el equipo de LayerZero revisó sus configuraciones a lo largo de ocho discusiones de integración y nunca advirtió que el modelo 1-de-1 representara un riesgo material de seguridad. Para respaldar esa tesis, el memorando incluye capturas de pantalla de conversaciones en Telegram donde, presuntamente, miembros del equipo de LayerZero conocían la configuración y no objetaron su uso.

La acusación de Kelp contra LayerZero

Uno de los intercambios citados por Kelp muestra a una persona identificada como integrante del equipo de LayerZero diciendo que no había problema en usar los valores predeterminados, mientras mencionaba que el equipo podía optar por una configuración DVN personalizada para verificar mensajes. Kelp interpreta que esos “valores predeterminados” eran precisamente la configuración 1-de-1 de LayerZero Labs que más tarde fue descrita como el punto débil que abrió la puerta al exploit.

La autenticidad de esa captura no pudo ser verificada de forma independiente. Aun así, el señalamiento añade presión sobre LayerZero porque desplaza el debate desde una supuesta mala configuración exclusiva de la aplicación hacia la calidad de la guía técnica, el soporte de integración y los estándares predeterminados ofrecidos por la plataforma.

Kelp también argumenta que las plantillas y herramientas públicas de LayerZero reforzaban el uso de ese esquema. Entre los elementos citados aparecen el alcance del programa de recompensas por errores en Immunefi, el OFT Quickstart y ejemplos oficiales en GitHub, donde LayerZero Labs figuraba como DVN requerido sin DVN opcionales configurados.

Ese punto es relevante porque LayerZero había sostenido que el protocolo funcionó exactamente como estaba previsto. Si los desarrolladores eran guiados hacia configuraciones de un solo verificador, la crítica de Kelp sugiere que el problema no fue únicamente una decisión aislada del integrador, sino una práctica más extendida dentro del ecosistema.

El memorando de Kelp también cita al investigador de seguridad Sujith Somraaj, de Spearbit, quien dijo el 19 de abril que había enviado un reporte de bug bounty describiendo el mismo patrón de ataque y que LayerZero lo rechazó. En su publicación, Somraaj resumió el problema con una frase contundente: su hallazgo fue descartado por requerir todos los DVN, pero luego el despliegue eliminó precisamente esa exigencia, permitiendo que los atacantes “cobraran” una recompensa mucho mayor.

Qué ocurrió en el exploit de rsETH

El ataque drenó 116.500 rsETH, con un valor aproximado de USD $292 millones, desde el puente de Kelp impulsado por LayerZero. Según el protocolo, además de esa extracción principal, se firmaron y procesaron dos transacciones falsificadas adicionales por más de USD $100 millones antes de que Kelp lograra pausar sus contratos.

LayerZero indicó que los atacantes probablemente están vinculados al grupo Lazarus de Corea del Norte. La firma explicó que los responsables obtuvieron acceso a la lista de RPC usadas por el DVN de LayerZero Labs, comprometieron dos nodos RPC y reemplazaron los binarios que se ejecutaban en ellos.

Después, de acuerdo con esa explicación, se lanzó un ataque DDoS contra nodos RPC no comprometidos. Eso habría forzado un proceso de failover hacia los nodos envenenados. A partir de allí, el DVN de LayerZero habría confirmado transacciones que en realidad nunca ocurrieron, lo que permitió la falsificación de mensajes y el drenaje del puente.

Más allá del vector técnico, el episodio reavivó una vieja discusión del sector: en los sistemas de interoperabilidad, la seguridad real depende no solo del protocolo base, sino también de cómo se seleccionan verificadores, ejecutores y supuestos de confianza. Un diseño que opera con un solo verificador puede simplificar la integración, pero también crea un punto único de falla con consecuencias millonarias.

La magnitud del problema y el cambio hacia Chainlink

Kelp asegura que su caso no fue una excepción marginal. Citando datos de Dune Analytics recopilados por CoinGecko, el protocolo indicó que el 47% de unos 2.665 contratos OApp activos de LayerZero usaron una configuración DVN 1-de-1 durante un período de 90 días que terminó alrededor del 22 de abril. Ese conjunto habría expuesto más de USD $4.500 millones en valor de mercado a una clase de riesgo similar.

Tras el incidente, LayerZero cambió su política y dijo que ya no firmaría mensajes para aplicaciones que operen bajo una configuración 1-de-1. La modificación entró en vigor después del hackeo. Para Kelp, esa decisión refuerza su postura, porque sugiere que el modelo antes permitido pasó a ser considerado inaceptable solo cuando ya había ocurrido el daño.

En paralelo, Kelp anunció que moverá rsETH fuera de LayerZero. El activo dejará el estándar OFT del protocolo y pasará al estándar Cross-Chain Token de Chainlink, soportado por su Protocolo de Interoperabilidad Cross-Chain, conocido como CCIP. La migración es una señal fuerte, ya que transforma un conflicto técnico en una ruptura comercial y reputacional.

El memorando también introduce otra acusación sensible. Kelp afirmó que hubo una superposición sustancial en las direcciones que recibieron el ADMIN_ROLE tanto en el DVN de LayerZero Labs como en el DVN de Nethermind, enumerando diez direcciones el 8 de abril de 2026 y cinco adicionales el 6 de febrero de 2025. Esa afirmación onchain no ha sido verificada de forma independiente.

Kelp añadió, además, que su equipo tuvo que alertar a LayerZero sobre el exploit en lugar de recibir primero una advertencia desde el propio proveedor. Si esa secuencia fue correcta, abriría preguntas sobre la supervisión operativa y la capacidad de detección temprana ante eventos críticos en infraestructura multicadena.

Al momento de la publicación original, LayerZero no había respondido a una solicitud de comentarios. Entretanto, según la documentación citada, en al menos dos cadenas integradas, Dinari y Skale, el DVN de LayerZero Labs todavía aparecía como el único atestiguador disponible.

El caso deja una conclusión incómoda para el sector. En cripto, la frase “funcionó como fue diseñado” no siempre equivale a “era suficientemente seguro”. Cuando la configuración recomendada, tolerada o predeterminada termina convertida en un vector de pérdida sistémica, la discusión pasa del código a la gobernanza, la documentación y la responsabilidad compartida entre protocolos e integradores.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados