Kelp afirma que LayerZero aprobó la configuración que culpó por el hackeo de puente de 292 millones de dólares

Kelp DAO afirma que el personal de LayerZero aprobó la configuración del verificador 1-de-1, una decisión que LayerZero ha citado desde entonces como la razón por la cual un atacante vinculado a Corea del Norte extrajo aproximadamente 292 millones de dólares desde el puente rsETH de Kelp.

La afirmación va en contra de la de LayerZeroInforme post mortem del 19 de abril, que indicó que la aplicación rsETH de Kelp dependía de LayerZero Labs como su único verificador y que la configuración "contradice directamente" el modelo multi-DVN recomendado por LayerZero.

El memorando de Kelp indica que el personal de LayerZero revisó sus configuraciones durante más de 2.5 años y en ocho discusiones de integración, sin advertir que una configuración 1-de-1 representaba un riesgo de seguridad material.

El memorándum, titulado “Aclarando los hechos en torno al hackeo del puente LayerZero,” incluye capturas de pantalla de intercambios en Telegram que documentan el conocimiento de LayerZero y la falta de objeción respecto a la configuración del verificador de Kelp.

Una captura de pantalla muestra a un miembro del equipo de LayerZero diciendo: “No hay problema en usar los valores predeterminados tampoco — solo etiquetando a [redactado] aquí ya que mencionó que quizás quisieras usar una configuración DVN personalizada para verificar mensajes, ¡pero dejaré eso a tu equipo!” Kelp dice que los “valores predeterminados” mencionados en el intercambio fueron la configuración DVN 1-de-1 de LayerZero Labs, que luego fue citada por LayerZero como la configuración a nivel de aplicación que permitió la explotación.

CoinDesk no pudo autenticar de manera independiente la captura de pantalla.

Plantillas de LayerZero

Kelp también señala el alcance del programa de recompensas por errores de LayerZero, OFT Quickstart y los ejemplos para desarrolladores como evidencia de que LayerZero trató las opciones de red de verificador como una configuración a nivel de aplicación, mientras mostraba a los desarrolladores una configuración de una sola DVN.

LayerZero's alcance publicado del programa de recompensas por errores en Immunefi excluye de las recompensas los "impactos a las OApps mismas como resultado de su propia mala configuración," incluyendo redes verificadoras y ejecutores.

El Inicio Rápido de LayerZero OFT y el configuración oficial de ejemplo OFT en GitHub muestran a LayerZero Labs como el DVN requerido, sin que se haya definido un DVN opcional.

El memorando de Kelp cita un Publicación del 19 de abril del investigador de seguridad de Spearbit, Sujith Somraaj, en el que Somraaj afirmó haber presentado un informe de recompensa por errores describiendo el mismo patrón de ataque y que LayerZero lo rechazó.

"Mi recompensa por errores: no es una vulnerabilidad, requiere todos los DVN," escribió Somraaj en X. "Su implementación: elimina la parte de 'todos'. Hackers: obtienen una recompensa de 295 millones de dólares en su lugar." Somraaj es un auditor previo de LayerZero, según su Perfil de Cantina.

Kelp se traslada a Chainlink

Kelp también indicó que está trasladando rsETH fuera de LayerZero hacia de ChainlinkProtocolo de Interoperabilidad Entre Cadenas. El cambio traslada rsETH del estándar OFT de LayerZero al estándar de Token Cross-Chain de Chainlink.

La explotación drenó 116,500 rsETH, valorados aproximadamente en $292 millones, del puente de Kelp impulsado por LayerZero. Dos transacciones adicionales falsificadas, que suman más de $100 millones, fueron firmadas y procesadas por el DVN de LayerZero Labs antes de que Kelp pausara sus contratos, según informó el protocolo.

LayerZero declaró atacantes probablemente están vinculados al Grupo Lazarus de Corea del Norte, quienes accedieron a la lista de RPCs utilizados por LayerZero Labs DVN, comprometieron dos nodos RPC y reemplazaron los binarios que se ejecutaban en ellos.

Los atacantes luego lanzaron un ataque DDoS contra nodos RPC no comprometidos, obligando a un failover hacia los nodos contaminados. LayerZero indicó que el DVN entonces confirmó transacciones que no habían ocurrido.

Kelp sostiene que la configuración 1-de-1 estaba muy extendida. CoinGecko, citando datos de Dune Analytics, indicó que el 47 % de aproximadamente 2.665 contratos activos de aplicaciones LayerZero OApp operaron con una configuración DVN 1-de-1 durante un período de 90 días que terminó alrededor del 22 de abril, con más de $4,5 mil millones en valor de mercado asociado expuestos al mismo tipo de riesgo.

El informe postmortem de LayerZero indicó que el protocolo "funcionó exactamente como se esperaba." La compañía comunicó que ya no firmará mensajes para ninguna aplicación que opere con una configuración 1-de-1, un cambio de política que entró en vigor después del hackeo.

Kelp alega que su equipo tuvo que señalar la vulnerabilidad a LayerZero en lugar de que fuera LayerZero quien lo hiciera, lo que plantea interrogantes sobre la supervisión de LayerZero.

El memorando también alega una superposición sustancial en las direcciones a las que se les otorgó ADMIN_ROLE tanto en el LayerZero Labs DVN como en el Nethermind DVN, enumerando diez el 8 de abril de 2026 y cinco adicionales el 6 de febrero de 2025. CoinDesk no ha verificado de forma independiente la afirmación en cadena.

LayerZero no respondió a una solicitud de comentarios por parte de la publicación.

En al menos dos cadenas integradas, Dinari y Skale, el DVN de LayerZero Labs sigue siendo listado como el único certificador disponible, según la documentación.

En un comunicado, un portavoz de LayerZero declaró: "Sujith tiene razón, la configuración 1/1 está fuera del alcance del programa de recompensas por errores. Nuestra recompensa se centra en vulnerabilidades del propio protocolo LayerZero, en lugar de elecciones de configuración a nivel de aplicación. De lo contrario, cualquier aplicación podría desplegarse y configurarse como el único DVN para colectar una recompensa de manera malintencionada. Sobre los valores predeterminados de OFT y los ejemplos de GitHub: los valores predeterminados del protocolo en casi todos los caminos son multi-DVN. En los casos donde se utiliza una configuración 1 de 1 en plantillas, apunta a un contrato 'DeadDVN' que rechaza mensajes y alerta a los desarrolladores para que configuren adecuadamente su pila de seguridad antes de lanzarse en vivo. La afirmación de que Kelp utilizó configuraciones predeterminadas de LayerZero es inexacta. Ellos desplegaron multiDVN y luego degradaron manualmente a un 1/1."

ACTUALIZACIÓN (5 de mayo de 2026, 22:22 UTC): Agrega declaración de LayerZero.