Uma ferramenta de IA de código aberto que ninguém acompanha, alertou há 12 dias sobre a vulnerabilidade de 292 milhões de dólares do Kelp DAO.

Autor: Zengineer

Tradução: Deep潮 TechFlow

Deep潮 Introdução: Em 18 de abril, o Kelp DAO foi roubado em 292 milhões de dólares, sendo o maior incidente DeFi desde 2026. A vulnerabilidade não estava no código do contrato inteligente, mas na configuração do nó de validação LayerZero cross-chain 1-de-1 — uma única falha pode falsificar mensagens entre cadeias. Há 12 dias, ao usar minha ferramenta de auditoria de código aberto com IA para escanear o Kelp, já tinha marcado esse risco. Este artigo revisa todo o processo do ataque e também reflete honestamente sobre três coisas que nossa ferramenta não fez corretamente na época.

O que é o Kelp DAO

Kelp DAO é um protocolo de recompartilhamento de liquidez construído sobre o EigenLayer. O mecanismo funciona assim: usuários depositam ETH ou tokens de recompartilhamento de liquidez (stETH, ETHx) no contrato do Kelp, que por sua vez delega esses ativos a nós operadores do EigenLayer para recompartilhamento — ao mesmo tempo, fornecendo segurança a múltiplos serviços de validação ativa (AVS). Como recompensa, os usuários recebem rsETH como prova. Diferente de recompartilhar diretamente no EigenLayer (onde os ativos ficam lockados), o rsETH é líquido — pode ser negociado, usado como garantia em protocolos de empréstimo como Aave, ou transferido entre cadeias.

Para possibilitar essa liquidez cross-chain, o Kelp usa o padrão OFT (Omnichain Fungible Token, token fungível omnichain) do LayerZero, implantando rsETH em mais de 16 blockchains. Quando você transfere rsETH do Ethereum para uma Layer 2, a DVN (Rede de Verificadores Descentralizados) do LayerZero verifica se a mensagem cross-chain é legítima. Essa arquitetura de ponte é o núcleo da história que vem a seguir.

O Kelp foi iniciado por Amitej Gajjala e Dheeraj Borra (ex-cofundadores da Stader Labs), lançado em dezembro de 2023, com TVL máximo de 2,09 bilhões de dólares, governança com multiassinatura 6/8 e um período de bloqueio de 10 dias para atualizações de contrato. O token de governança KERNEL controla as linhas de produtos Kelp, Kernel e Gain.

O incidente de roubo

Em 18 de abril de 2026, o atacante retirou 116.500 rsETH do bridge cross-chain do Kelp DAO, equivalente a aproximadamente 292 milhões de dólares — o maior ataque DeFi desde 2026. A causa raiz não foi uma falha no contrato inteligente, mas uma configuração: um DVN de 1-de-1 (apenas um nó de validação, com assinatura única) permitiu que um nó comprometido falsificasse mensagens cross-chain.

Há 12 dias, em 6 de abril, minha ferramenta de auditoria de segurança de código aberto já tinha marcado esse vetor de ataque.

Primeiro, uma coisa: esse roubo foi causado por uma pessoa real perdendo dinheiro de verdade. Usuários que nunca interagiram com rsETH, como depositantes de WETH na Aave, tiveram seus fundos congelados; LPs em vários protocolos enfrentaram perdas que eles nem assinaram. Este artigo analisa o que aconteceu, o que nossa ferramenta detectou — mas o custo real para as pessoas foi maior do que qualquer pontuação de risco poderia indicar.

O relatório completo está no GitHub, com timestamps verificáveis por qualquer um. A seguir, o que detectamos, o que deixamos passar e o que isso significa para as ferramentas de segurança DeFi.

46 minutos, impacto no DeFi

Às 17h35 UTC de 18 de abril, o atacante comprometeu o nó DVN isolado e fez com que ele “aprovasse” uma mensagem falsificada. O endpoint LayerZero viu o DVN aprovar, e enviou a mensagem para o contrato OFT do Kelp via lzReceive — que então, na rede principal do Ethereum, cunhou 116.500 rsETH. A mensagem afirmava que outros blockchains tinham bloqueado ativos equivalentes como garantia. Mas esses ativos nunca existiram.

Depois, seguiu-se um procedimento padrão de lavagem de dinheiro no DeFi:

Usar o rsETH roubado como garantia em Aave V3, Compound V3, Euler

Emprestar cerca de 236 milhões de dólares em WETH usando essas garantias sem respaldo real

Concentrar aproximadamente 74.000 ETH, sacar via Tornado Cash

Após 46 minutos, às 18h21, o multisig de emergência do Kelp congelou o contrato. O atacante tentou duas vezes (cada uma com 40.000 rsETH, cerca de 100 milhões de dólares), mas as transações foram revertidas — a pausa impediu perdas de cerca de 200 milhões de dólares.

Ainda assim, o impacto foi grande. Aave V3 absorveu cerca de 177 milhões de dólares em perdas. O token AAVE caiu 10,27%. ETH caiu 3%. A utilização de WETH na Aave atingiu 100%, com os depositantes tentando retirar seus fundos. Os rsETH em mais de 20 L2s tornaram-se ativos de valor duvidoso da noite para o dia.

O que o relatório de 6 de abril revelou

No começo de abril, pouco depois do roubo de 285 milhões de dólares no Drift Protocol em 1º de abril, criei uma estrutura de avaliação de risco de arquitetura com IA chamada crypto-project-security-skill — usando dados públicos (DeFiLlama, GoPlus, Safe API, verificações on-chain) para avaliar protocolos DeFi. Não é um scanner de código nem uma verificação formal. O incidente do Drift mostrou que as maiores perdas não estavam no código, mas em vulnerabilidades de governança, configurações e arquitetura — áreas que os scanners de código não alcançam. Então, criei uma ferramenta específica para avaliar esses aspectos: governança, dependência de oráculos, mecanismos econômicos, arquitetura cross-chain, comparando com ataques históricos (Drift, Euler, Ronin, Harmony, Mango).

Em 6 de abril, executei uma auditoria completa no Kelp DAO. O relatório completo está no GitHub, com timestamps imutáveis.

A pontuação geral do Kelp foi 72/100 (risco moderado). Depois, percebi que essa nota foi muito branda — as lacunas de informações sobre a configuração cross-chain, que poderiam ter reduzido a nota, não foram consideradas. Mesmo com risco moderado, o relatório apontou o vetor de ataque que foi explorado posteriormente.

Abaixo, uma captura da seção “lacunas de informação” do relatório — sobre a configuração DVN do Kelp, que acabou sendo a causa do roubo de 292 milhões de dólares:

Legenda: Seção “lacunas de informação” do relatório de 6 de abril, destacando a configuração opaca do DVN

Vamos comparar o que o relatório apontou, com o que foi realmente vulnerável.

Descoberta 1: Configuração DVN opaca (alerta)

Texto do relatório: “Configuração do DVN do LayerZero (conjunto de validadores por cadeia, requisitos de threshold) não divulgada”

O que realmente aconteceu: O Kelp usou uma configuração de 1-de-1 no DVN. Um nó. Um ponto único de falha. Se um nó for comprometido, o atacante pode falsificar mensagens. Se fosse 2-de-3 (recomendado na indústria), o atacante precisaria comprometer pelo menos dois validadores independentes.

Para esclarecer: esse é um problema do Kelp, não do LayerZero. LayerZero fornece a infraestrutura — o framework DVN — e cada protocolo escolhe sua configuração: quantos validadores, quem são, thresholds por cadeia. O Kelp escolheu 1-de-1 ao implantar o OFT. LayerZero suporta 2-de-3 ou mais, mas o Kelp não ativou.

Exemplo: AWS oferece MFA (autenticação multifator). Se sua conta foi roubada por você nunca ter ativado MFA, o problema é seu, não da AWS. LayerZero fornece mecanismos de segurança, o Kelp não os usou.

Nosso relatório na época não pôde verificar o threshold exato do DVN (pois o Kelp não revelou), mas listou essa opacidade como uma lacuna de risco. Não divulgar é um sinal de alerta.

Descoberta 2: Falha de ponto único em 16 cadeias (impacto direto)

Texto do relatório: “Falha de ponto único do DVN do LayerZero pode afetar as 16 cadeias suportadas do rsETH”

O que realmente aconteceu: A mensagem falsificada atingiu diretamente a rede principal do Ethereum, e o impacto se espalhou para todas as cadeias que tinham rsETH. LayerZero pausou preventivamente todas as pontes OFT saindo do Ethereum. Os detentores de rsETH em mais de 20 L2s ficaram sem garantia clara de seus tokens.

Esse é um risco sistêmico de deploy multi-chain: rsETH circula em Arbitrum, Optimism, Base, Scroll, etc., mas seu valor depende dos ativos na rede principal. Se a ponte principal for comprometida, o rsETH em todas as L2s perde garantia — os detentores não podem resgatar nem verificar o valor de seus tokens. Serviços como earnETH da Lido (com exposição a rsETH) e a ponte LayerZero da Ethena também tiveram que pausar. O raio de impacto é maior que o próprio Kelp.

Descoberta 3: Controle de governança cross-chain não verificado (problema relevante)

Texto do relatório: “Controle de governança do DVN do LayerZero por cada cadeia não verificado — especialmente: esses controles pertencem ao mesmo multi-sig 6/8 e lock de 10 dias, ou a chaves independentes?”

O que realmente aconteceu: A configuração do DVN não está sob governança estrita do protocolo principal. Se as configurações da ponte mudarem, elas podem ser controladas por um multi-sig 6/8 com lock de 10 dias, ou por chaves independentes. Como o DVN é de 1-de-1, um único operador pode alterar a configuração, o que é um risco.

Isso revela uma armadilha comum de governança: muitos protocolos têm multi-sig e lock de 10 dias para atualizações de contratos principais, mas operações diárias — configurações de ponte, oráculos, listas brancas — muitas vezes são controladas por uma única chave de admin. O Kelp tem uma governança avançada (6/8 + lock de 10 dias), mas essa proteção não cobre o maior vetor de ataque: a configuração da ponte cross-chain.

Descoberta 4: Modo de ataque semelhante ao Ronin/Harmony (impacto direto)

Texto do relatório: “O padrão de ataque mais relevante na história envolve segurança de ponte. A implantação do LayerZero do Kelp em 16 cadeias traz complexidade operacional semelhante à arquitetura multi-chain do Ronin.”

O que realmente aconteceu: O ataque seguiu quase exatamente o roteiro do Ronin — validadores comprometidos, mensagens falsificadas, retirada de ativos. Nosso módulo de detecção de padrões de ataque identificou corretamente essa arquitetura como de alto risco, comparando com ataques históricos.

Contexto histórico: em 2022, a ponte Ronin teve 5 validadores (de 9) comprometidos, perdendo 625 milhões de dólares; no mesmo ano, a ponte Horizon da Harmony, com 2 de 5 validadores, perdeu 100 milhões. O caso do Kelp é ainda mais extremo — com apenas 1 validador, o limiar de ataque é mínimo. Nosso sistema consegue marcar esse risco porque compara a arquitetura com ataques históricos, não apenas o código.

Descoberta 5: Sem pool de seguro (aumenta o dano)

Texto do relatório: “O protocolo não possui um pool de seguro dedicado, nem mecanismo de compartilhamento de perdas para absorver eventos de penalização.”

O que realmente aconteceu: Sem reserva de seguro, as perdas de 292 milhões de dólares foram absorvidas por protocolos downstream. A reserva de recuperação do Aave cobriu menos de 30% do bad debt de 177 milhões de dólares. LPs que não assinaram o contrato de rsETH assumiram a maior parte do impacto.

O atacante usou o rsETH roubado como garantia em Aave V3, Compound V3, Euler, e emprestou WETH real. Quando o rsETH foi considerado sem respaldo, essas posições se tornaram bad debt “não liquidável” — garantias viraram papel, mas o WETH emprestado desapareceu. A utilização de WETH na Aave atingiu 100%, impedindo saques. Mesmo depositantes de WETH na Aave, que nunca interagiram com rsETH, tiveram seus fundos afetados. O seguro do Nexus Mutual cobre apenas certos produtos, não a exposição principal ao rsETH.

Ambos os lados falharam: a Kelp, que gerencia US$ 1,3 bilhão em TVL, não tem seguro ou mecanismo de absorção de perdas; e a Aave, que aceita rsETH como garantia, não avaliou adequadamente o risco de configuração da ponte. Seus parâmetros de risco (LTV, limiar de liquidação) são para volatilidade normal, não para o risco de ponte comprometida que zeraria garantias de uma noite para outra. A reserva de recuperação não cobre nem 30% do bad debt. É uma falha de precificação de risco: a Aave trata o rsETH como um ativo normal, mas ele carrega o risco de falha da ponte. A soma dessas falhas resultou na perda de 292 milhões de dólares — a falta de seguro na Kelp e a avaliação inadequada de risco na Aave criaram uma combinação fatal.

Onde erramos

Três coisas poderiam ter sido feitas melhor:

Avaliação de risco subestimada. Classificamos o risco do bridge como “moderado”. No relatório, 3 das 5 lacunas de informação relacionadas à configuração do LayerZero poderiam ter elevado o risco para “alto” ou “grave”. A opacidade por si só deveria ser um sinal mais forte.

Não penetramos na camada de configuração. Repetidamente, pedimos ao Kelp que revelasse o threshold do DVN, mas não conseguimos verificar de forma independente. Essa é uma armadilha estrutural que o análise pós-mortem do JingHeng apontou: ferramentas atuais focam na lógica do código, não na configuração. Marcamos o problema, mas não conseguimos responder.

Não verificamos na cadeia. A configuração do DVN pode ser lida diretamente pelo contrato LayerZero EndpointV2 na cadeia. Poderíamos consultar o registry ULN302 para verificar o threshold do DVN do Kelp, sem depender da divulgação. Se tivéssemos feito isso, veríamos que a configuração era 1-de-1, sem precisar do Kelp revelar. Essa é uma melhoria concreta: incluir validação on-chain do DVN na avaliação cross-chain.

A avaliação foi pouco específica e pouco acionável. Dizer que “a configuração do DVN não foi divulgada” é uma observação de documentação, não uma previsão de ataque. Esses riscos (centralização de oráculos, dependência de ponte, falta de seguro) são comuns na maioria dos protocolos cross-chain. Nossa ferramenta marcou a opacidade do Kelp, mas também detectou padrões semelhantes em dezenas de protocolos não atacados. Sem uma taxa de falsos positivos, afirmar que “previmos” é exagero. A verdade mais honesta é: fizemos perguntas relevantes que outros não fizeram, e uma delas acabou sendo a causa principal.

Sobre “divulgação responsável”

Uma questão justa: se em 6 de abril já havíamos marcado esses riscos, por que não avisamos o Kelp antes do ataque de 18 de abril?

Não avisamos. Porque o que detectamos foi opacidade — “configuração do DVN não divulgada” — não uma vulnerabilidade específica. Não sabíamos se a configuração era 1-de-1, só que ela não era pública. Sem detalhes concretos, não havia como divulgar um bug. “Falta de documentação da ponte” é uma questão de governança, não um bug a ser reportado.

Depois, poderíamos ter entrado em contato com o time do Kelp para perguntar sobre o threshold do DVN. Essa conversa poderia ter revelado a configuração 1-de-1 e ajudado a evitar o roubo. Não fizemos. Essa é uma lição: mesmo que uma descoberta pareça vaga demais para uma divulgação formal, uma mensagem privada ainda vale a pena.

O que isso significa para a segurança do DeFi

O roubo do Kelp — assim como o de Drift 17 dias antes — não foi uma falha no código. Ferramentas automáticas como Slither, Mythril ou GoPlus não detectam esse tipo de vulnerabilidade. A falha está na configuração, na governança e na arquitetura, acima do código.

Essa é a principal tese do crypto-project-security-skill:

Segurança de protocolos não é só código. Um protocolo pode ter um código Solidity perfeito, cinco auditorias de empresas renomadas, uma recompensa de US$ 250 mil — e ainda assim ser roubado por causa de uma configuração de validação de ponte mal feita, levando a uma perda de 292 milhões de dólares.

A ferramenta está aberta no GitHub — qualquer um pode revisar a metodologia, rodar localmente ou melhorar.

Linha do tempo

12 dias. O sinal estava lá. A questão é: como a comunidade pode criar ferramentas que detectem esses sinais antes que uma ponte seja derrubada?

O que você pode fazer

Se você tem ativos em protocolos DeFi com bridges cross-chain:

Faça sua própria auditoria. A ferramenta é open source. Não confie só na nossa palavra — verifique você mesmo.

Verifique a configuração do bridge. Se um protocolo não quiser divulgar seu threshold do DVN, considere isso um sinal de alerta. Nosso relatório faz exatamente isso, e a experiência mostra que acertamos.

Não confie apenas na auditoria de código. O Kelp passou por mais de cinco auditorias de empresas renomadas (Code4rena, SigmaPrime, MixBytes). Auditorias tradicionais focam na lógica do código, não na configuração de DVN — que é uma análise diferente, e não uma falha de auditoria.

Avalie a cobertura de seguro. Se um protocolo não tem um pool de seguro, e você é LP de uma plataforma que aceita seus tokens como garantia, você está implicitamente assumindo esse risco. Como os depositantes de WETH na Aave, que aprenderam isso na prática.

Visão maior: IA como camada de segurança

Este artigo fala de uma ferramenta e de um roubo, mas a mensagem maior é: agentes de IA podem se tornar uma camada de segurança autônoma para o DeFi.

O modo tradicional de segurança no cripto é: protocolos contratam auditorias, que revisam o código, que geram relatórios. Mas esse método tem lacunas — o incidente do Kelp mostra isso: ele foca na correção do código, mas ignora configurações, governança e arquitetura.

Claude Code e ferramentas similares oferecem uma alternativa: qualquer pessoa pode usar dados públicos para rodar uma avaliação de risco com IA em minutos. Você não precisa pagar US$ 200 mil por uma auditoria, nem saber Solidity. O agente compara a arquitetura do protocolo com ataques conhecidos, e gera perguntas que você deveria fazer antes de investir.

Isso não substitui auditorias profissionais — mas reduz a barreira para uma análise inicial de due diligence. Um LP que pensa em investir em um novo protocolo de recompartilhamento pode rodar uma avaliação estruturada de riscos de governança, oráculos, ponte e mecanismos econômicos. Para investidores de varejo e de médio porte, é uma mudança real na autoproteção.

A avaliação do Kelp não foi perfeita. Marcou risco de ponte como moderado, deveria ser grave. Não penetramos na configuração. Mas fez as perguntas certas — e se a equipe do Kelp ou qualquer LP tivesse levado essas questões a sério, poderia ter evitado a perda de 292 milhões de dólares.

Referências

CoinDesk: 2026 Year’s Biggest Crypto Attack — Kelp DAO Stolen $292M

Crypto Briefing: Kelp DAO suffers $292M bridge attack

DL News: Hacker ataca protocolo DeFi Kelp DAO, perda de cerca de $300M

Bitcoin.com: ZachXBT revela ataque de mais de $280M ao KelpDAO

鉅亨網: Vulnerabilidade de $293M não está no código

Declaração oficial do Aave no X

Relatório completo de segurança do Kelp DAO (6 de abril de 2026)

Código fonte do crypto-project-security-skill