#LayerZeroCEOAdmitsProtocolFlaws

CEO da LayerZero admite falhas no protocolo após $292M Hack — Mas Kelp DAO diz "Você aprovou a configuração que agora está culpando"
Por semanas, a LayerZero apontou o dedo para a Kelp DAO pelo exploit de 292 milhões de dólares que abalou a DeFi. "Eles usaram uma configuração de verificador 1-de-1 — avisamos contra isso." Essa era a narrativa. Mas agora, o CEO da LayerZero, Bryan Pellegrino, reconheceu publicamente as deficiências no nível do protocolo, prometendo uma reformulação de segurança. E a Kelp DAO acabou de divulgar evidências que podem virar o jogo de culpa de cabeça para baixo.
Deixe-me explicar por que isso importa para toda ponte cross-chain em que você já confiou.
🔥 A Confissão que Mudou Tudo
Em 4 de maio, Pellegrino publicou uma declaração pública reconhecendo as falhas do protocolo da LayerZero após o exploit da Kelp DAO, comprometendo-se com uma reformulação de segurança abrangente. Essa é uma mudança significativa em relação ao post-mortem inicial de 20 de abril, que enquadrava o ataque inteiramente como uma falha de configuração "a nível de aplicação" pela Kelp DAO — não um problema de nível de protocolo.
Por que a mudança? Porque as evidências estavam se tornando impossíveis de ignorar.
🔍 Resposta Devastadora da Kelp DAO
Em 5 de maio, a Kelp DAO publicou uma resposta detalhada que contradiz diretamente a alegação central da LayerZero. Aqui está o que eles revelaram:
1. A LayerZero APROVOU a configuração do verificador 1-de-1 que agora culpam a Kelp DAO, compartilhando capturas de tela de comunicações privadas com membros da equipe da LayerZero onde um funcionário da LayerZero disse explicitamente: "Sem problema em usar os padrões padrão também — estou marcando [redacted] aqui já que ele mencionou que você talvez quisesse usar uma configuração personalizada de DVN para verificar mensagens, mas deixarei isso para sua equipe!" Os "padrões padrão" referidos eram a configuração DVN de 1-de-1 da LayerZero Labs — a mesma configuração que a LayerZero citou posteriormente como a vulnerabilidade crítica que permitiu o exploit.
2. A configuração "perigosa" era a padrão enviada pela LayerZero. A LayerZero chamou a configuração padrão de 1-de-1 de uma escolha marginal e irresponsável. O argumento da Kelp: essa era a configuração padrão do sistema, usada por centenas de outras aplicações no ecossistema. Se a maioria das integrações da LayerZero usa 1-de-1, chamá-la de "erro do usuário" quando falha é como vender um carro sem airbags e depois culpar o motorista por não tê-los instalado depois.
3. A própria infraestrutura da LayerZero foi comprometida. O ataque funcionou porque os atacantes comprometeram dois nós RPC nos quais o verificador da LayerZero confiava e DDoSaram o restante. A infraestrutura DVN da LayerZero — o sistema justamente criado para validar mensagens cross-chain — foi invadida. Zach Rynes, o contato da comunidade do Chainlink, chamou isso diretamente: "A LayerZero está desviando a responsabilidade de que sua própria infraestrutura de nós DVN foi comprometida e causou o exploit na ponte $290M ."
4. Quatro perguntas sem resposta da Kelp DAO. A Kelp levantou questões específicas que a LayerZero não respondeu publicamente: Como as listas de endpoints RPC foram acessadas? Como os padrões documentados da LayerZero se reconciliam com o grande número de configurações 1-de-1 no ecossistema? Por que a monitoração não detectou o comprometimento da infraestrutura? Quanto tempo os nós comprometidos ficaram ativos antes da mensagem falsificada ser assinada?
Estas não são perguntas retóricas — são demandas de responsabilidade que a admissão de falhas do protocolo pela LayerZero torna ainda mais difícil de ignorar.
🧠 A Verdadeira Lição: Risco de Código vs. Risco Operacional
A análise de segurança da OpenZeppelin destacou um ponto que a maioria ignorou: NÃO havia bug nos contratos inteligentes da Kelp DAO. O código foi auditado e está sólido. O que falhou foi a configuração operacional e de integração ao redor da infraestrutura da ponte — algo que fica fora das revisões e auditorias tradicionais de código.
Essa é a distinção que a indústria raramente discute. Você pode ter contratos perfeitamente auditados e ainda assim perder 292 milhões de dólares se a camada de infraestrutura abaixo deles tiver um único ponto de falha. O modelo da LayerZero depende de Redes de Verificadores Descentralizados (DVNs) — mas quando a configuração padrão é 1-de-1 (um verificador = a própria LayerZero Labs), "descentralizado" vira uma palavra de marketing, não uma realidade de segurança. Um nó comprometido. Uma mensagem falsificada. 292 milhões de dólares sumiram.
📊 Impacto no Preço do ZRO — O Mercado Está Votando
O ZRO está sendo negociado a US$1,395, uma queda de -5,1% em 24 horas e -29,6% em 30 dias. O quadro técnico mostra uma história clara:
Médias móveis diárias em forte tendência de baixa (MA7 < MA30 < MA120) — tendência de baixa sustentada
PDI < MDI com ADX em 34,4 — forte momentum de declínio
Hoje, caindo -4,4% em relação ao BTC — desempenho abaixo do esperado
O interesse aberto de futuros caiu -11,6% em 24 horas — posições estão sendo liquidadas, não construídas
MAS: o MACD diário acabou de formar um cruzamento de ouro (DIF cruzou acima do DEA) e o CCI/WR de 15 minutos estão em território de sobrevenda — potencial de bounce de curto prazo existe
O mercado está precificando dano à reputação e incerteza. A admissão do CEO da LayerZero sobre falhas no protocolo é um passo em direção à responsabilidade, mas as evidências da Kelp DAO levantam uma questão mais difícil: isso foi sempre apenas um "erro de configuração do usuário", ou o design padrão do protocolo era fundamentalmente inseguro desde o início?
⚡ O Que Isso Significa para Infraestrutura Cross-Chain
1. Padrões padrão importam mais do que documentação. Se um protocolo envia um verificador 1-de-1 como padrão, isso não é uma recomendação — é o nível de segurança que realmente oferece. Documentação dizendo "você deve configurar multi-verificador" não protege os usuários que seguem os padrões padrão. A verdadeira segurança de um sistema é definida pelo que a maioria dos usuários realmente executa, não pelo que a documentação diz que eles poderiam executar.
2. Risco de infraestrutura é invisível até explodir. Auditorias de contratos inteligentes detectam bugs no código. Não detectam nós RPC comprometidos, validadores DDoSados ou pontos únicos de confiança nas camadas de mensagens. O próximo grande exploit na DeFi provavelmente não virá de uma vulnerabilidade de contrato — virá da infraestrutura operacional na qual os contratos dependem, mas que não podem controlar.
3. Responsabilidade não pode ser retroativa. A admissão do CEO da LayerZero é bem-vinda, mas veio após semanas desviando a culpa para a Kelp DAO. Se a admissão tivesse ocorrido em 20 de abril, junto com o post-mortem — ao invés de uma narrativa de "a Kelp configurou errado" — a resposta da comunidade seria muito diferente. A confiança é construída nas primeiras 48 horas após uma crise, não na terceira semana.
4. A migração da Kelp DAO para o Chainlink CCIP é o veredito do mercado. A Kelp anunciou que está migrando o rsETH do padrão OFT da LayerZero para o Protocolo de Interoperabilidade Cross-Chain do Chainlink. Quando seu maior parceiro de integração deixa seu protocolo após um exploit, isso não é apenas uma decisão de negócios — é um veredito de segurança de alguém que testou seu sistema em condições reais e achou insuficiente.
💡 A Conclusão
A admissão do CEO da LayerZero sobre falhas no protocolo é um passo necessário — mas é apenas o primeiro passo. O verdadeiro teste é se a LayerZero consegue responder publicamente às quatro perguntas da Kelp DAO, reformular suas configurações padrão de segurança e reconstruir a confiança com os integradores que agora questionam se "verificador descentralizado" significa alguma coisa quando o padrão é uma única empresa verificando tudo.
292 milhões de dólares perdidos. Zero bugs nos contratos. A vulnerabilidade não estava no código — estava no modelo de confiança. E toda ponte cross-chain usando uma arquitetura semelhante deveria estar se perguntando a mesma coisa agora.
Criadores de protocolos devem ser responsabilizados por defaults inseguros, ou sempre é responsabilidade do usuário configurar além do que é fornecido? Este debate pode redesenhar como cada protocolo de ponte projeta sua arquitetura de segurança — deixe sua posição abaixo 👇
‍@Gate_Square
‍$ZRO $ETH