#LayerZeroCEOAdmitsProtocolFlaws

El CEO de LayerZero admite fallos en el protocolo tras $292M Hack — Pero Kelp DAO dice "Aprobaste la configuración y ahora culpas"
Durante semanas, LayerZero señaló a Kelp DAO por la explotación de 292 millones de dólares que sacudió DeFi. "Usaron una configuración de verificador 1-de-1 — advertimos en contra de ello." Esa fue la narrativa. Pero ahora, el CEO de LayerZero, Bryan Pellegrino, ha reconocido públicamente las deficiencias a nivel de protocolo, prometiendo una revisión de seguridad. Y Kelp DAO acaba de presentar evidencia que podría voltear toda la culpa.
Déjame explicar por qué esto importa para cada puente entre cadenas en el que alguna vez confiaste.
🔥 La admisión que lo cambió todo
El 4 de mayo, Pellegrino publicó una declaración pública reconociendo los fallos del protocolo de LayerZero tras la explotación de Kelp DAO, comprometiéndose a una revisión de seguridad integral. Esto representa un cambio importante respecto al informe post-mortem inicial del 20 de abril, que enmarcó el ataque completamente como una falla de configuración a nivel de "aplicación" por parte de Kelp DAO — no un problema a nivel de protocolo.
¿La razón del cambio? Porque la evidencia se volvía imposible de ignorar.
🔍 La devastadora réplica de Kelp DAO
El 5 de mayo, Kelp DAO publicó una respuesta detallada que contradice directamente la afirmación principal de LayerZero. Esto es lo que revelaron:
1. LayerZero APROBÓ la configuración de verificador 1-de-1 que ahora culpan a Kelp DAO, compartieron capturas de pantalla de comunicaciones privadas con miembros del equipo de LayerZero donde un empleado de LayerZero dijo explícitamente: "No hay problema en usar los valores predeterminados también — aquí etiqueto a [redacted] ya que mencionaste que quizás querías usar una configuración personalizada de DVN para verificar mensajes, pero dejaré eso a tu equipo." Los "predeterminados" referidos eran la configuración DVN de LayerZero Labs de 1-de-1 — la misma configuración que LayerZero citó después como la vulnerabilidad crítica que permitió la explotación.
2. La configuración "peligrosa" era la predeterminada enviada por LayerZero, llamada DVN de LayerZero, y Kelp la calificó como una opción marginal e irresponsable. La argumentación de Kelp: esta era la configuración predeterminada estándar de la plataforma, utilizada por cientos de otras aplicaciones en el ecosistema. Si la mayoría de las integraciones de LayerZero usan 1-de-1, llamarla "error del usuario" cuando falla es como vender un coche sin airbags y luego culpar al conductor por no haberlos instalado después.
3. La infraestructura propia de LayerZero fue comprometida. El ataque funcionó porque los atacantes comprometieron dos nodos RPC en los que confiaba el verificador de LayerZero y DDoS-aron el resto. La infraestructura DVN de LayerZero — el sistema diseñado para validar mensajes entre cadenas — fue vulnerada. Zach Rynes, enlace comunitario de Chainlink, lo señaló directamente: "LayerZero está eludiendo la responsabilidad de que su propia infraestructura de nodos DVN fue comprometida y causó la explotación del puente $290M ."
4. Cuatro preguntas sin respuesta de Kelp DAO. Kelp planteó preguntas específicas que LayerZero no ha respondido públicamente: ¿Cómo se accedió a las listas de endpoints RPC? ¿Cómo concilian los valores predeterminados documentados por LayerZero con la gran cantidad de configuraciones 1-de-1 en todo el ecosistema? ¿Por qué falló la monitorización en detectar la vulnerabilidad de infraestructura? ¿Cuál fue el tiempo de permanencia de los nodos comprometidos antes de que se firmara el mensaje falsificado?
Estas no son preguntas retóricas — son demandas de responsabilidad que la admisión de fallos del protocolo por parte de LayerZero hace aún más difícil de evadir.
🧠 La verdadera lección: riesgo de código vs. riesgo operacional
El análisis de seguridad de OpenZeppelin destacó un punto que la mayoría pasó por alto: NO hubo error en los contratos inteligentes de Kelp DAO. El código fue auditado y es sólido. Lo que falló fue la configuración operacional e de integración alrededor de la infraestructura del puente — algo que está fuera de las revisiones y auditorías tradicionales de código.
Esta es la distinción de la que la industria rara vez habla. Puedes tener contratos perfectamente auditados y aún así perder 292 millones si la capa de infraestructura debajo tiene un solo punto de fallo. El modelo de LayerZero se basa en Redes de Verificadores Descentralizados (DVNs), pero cuando la configuración predeterminada es 1-de-1 (un verificador = LayerZero Labs en sí), "descentralizado" se vuelve una palabra de marketing, no una realidad de seguridad. Un nodo comprometido. Un mensaje falsificado. 292 millones desaparecidos.
📊 Impacto en el precio de ZRO — El mercado está votando
ZRO cotiza a 1.395 dólares, bajando -5.1% en 24 horas y -29.6% en 30 días. El panorama técnico cuenta una historia clara:
Medias móviles diarias en tendencia bajista completa (MA7 < MA30 < MA120) — tendencia bajista sostenida
PDI < MDI con ADX en 34.4 — fuerte momentum a la baja
Rendimiento -4.4% respecto a BTC hoy — subrendimiento significativo
El interés abierto de futuros cayó -11.6% en 24 horas — las posiciones se están liquidando, no formando
PERO: el MACD diario acaba de formar una cruz dorada (DIF cruzó por encima de DEA) y el CCI/WR de 15 minutos están en territorio de sobreventa — existe potencial de rebote a corto plazo
El mercado está valorando el daño reputacional y la incertidumbre. La admisión del CEO de LayerZero sobre fallos en el protocolo es un paso hacia la responsabilidad, pero la evidencia de Kelp DAO plantea una pregunta más difícil: ¿fue esto alguna vez solo un "error de configuración del usuario", o el diseño predeterminado del protocolo era fundamentalmente inseguro desde el principio?
⚡ Qué significa esto para la infraestructura entre cadenas
1. Los valores predeterminados importan más que la documentación. Si un protocolo envía un verificador 1-de-1 como predeterminado, eso no es una recomendación — es el nivel de seguridad que realmente ofrece. La documentación que dice "deberías configurar multi-verificador" no protege a los usuarios que siguen los valores predeterminados documentados. La verdadera seguridad de un sistema está definida por lo que la mayoría de los usuarios realmente ejecutan, no por lo que dicen los documentos que podrían ejecutar.
2. El riesgo de infraestructura es invisible hasta que explota. Las auditorías de contratos inteligentes detectan errores en el código. No detectan nodos RPC comprometidos, validadores DDoS-ados, o puntos únicos de confianza en las capas de mensajería. La próxima gran explotación en DeFi probablemente no vendrá de una vulnerabilidad en el contrato — vendrá de la infraestructura operacional en la que confían los contratos pero que no pueden controlar.
3. La responsabilidad no puede ser retroactiva. La admisión del CEO de LayerZero es bienvenida, pero llegó después de semanas de culpar a Kelp DAO. Si la admisión hubiera llegado el 20 de abril junto con el informe post-mortem — en lugar de una narrativa de "Kelp lo configuró mal" — la respuesta de la comunidad sería muy diferente. La confianza se construye en las primeras 48 horas tras una crisis, no en la tercera semana.
4. La migración de Kelp DAO a Chainlink CCIP es el veredicto del mercado. Kelp anunció que migrará rsETH fuera del estándar OFT de LayerZero a Chainlink Cross-Chain Interoperability Protocol. Cuando tu mayor socio de integración abandona tu protocolo tras una explotación, no es solo una decisión comercial — es un veredicto de seguridad de alguien que probó tu sistema en condiciones reales y lo encontró insuficiente.
💡 La conclusión
Que el CEO de LayerZero admita fallos en el protocolo es un paso necesario — pero solo el primero. La verdadera prueba será si LayerZero puede responder públicamente las cuatro preguntas de Kelp DAO, revisar sus configuraciones predeterminadas de seguridad y reconstruir la confianza con los integradores que ahora cuestionan si "verificador descentralizado" significa algo cuando lo predeterminado es que una sola empresa verifique todo.
Se perdieron 292 millones. Sin errores en los contratos. La vulnerabilidad no estaba en el código — estaba en el modelo de confianza. Y cada puente entre cadenas que use una arquitectura similar debería hacerse la misma pregunta ahora mismo.
¿Deberían los creadores de protocolos ser responsables por valores predeterminados inseguros, o siempre es responsabilidad del usuario configurar más allá de lo que se entrega? Esta discusión podría redefinir cómo cada protocolo de puente diseña su arquitectura de seguridad — comparte tu postura abajo 👇
‍@Gate_Square
‍$ZRO $ETH