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潮 leitura: Em 18 de abril, o Kelp DAO foi roubado de 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. O autor, há 12 dias, ao usar sua ferramenta de auditoria de código aberto com IA para escanear o Kelp, já havia 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 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 operacionais do EigenLayer para recompartilhamento — ao mesmo tempo, fornecendo segurança a múltiplos AVS (Serviços de Validação Ativa). Como recompensa, os usuários recebem rsETH como comprovante. Diferente de recompartilhar na 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 (Token Fungível Omnichaínico) do LayerZero, implantando rsETH em mais de 16 blockchains. Quando você transfere rsETH do Ethereum para uma camada L2, 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.

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, aproximadamente 292 milhões de dólares — o maior ataque DeFi até hoje em 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), permitindo 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á havia marcado esse vetor de ataque.

Primeiro, uma coisa: esse roubo foi causado por pessoas reais perdendo dinheiro de verdade. Usuários que nunca interagiram com rsETH, como depositantes de WETH na Aave, tiveram seus fundos congelados; múltiplos protocolos tiveram LPs assumindo 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 de impacto, sacudindo o DeFi

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

Depois, uma rotina padrão de lavagem de dinheiro DeFi:

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

Com esses garantidores sem respaldo real, emprestar cerca de 236 milhões de dólares em WETH

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 freneticamente. Mais de 20 L2s com rsETH viraram 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 pelo Drift em 1º de abril, criei uma ferramenta de avaliação de risco de arquitetura de IA de código aberto — 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 me mostrou: as maiores perdas não vêm do código do contrato, mas de vulnerabilidades de governança, configurações e arquitetura — áreas que os scanners tradicionais 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 do 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 totalmente consideradas. Mesmo com risco moderado, o relatório apontou o vetor de ataque que foi explorado posteriormente.

A seguir, uma captura de tela 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 e como foi realmente vulnerado.

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

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

O que realmente aconteceu: O Kelp usou uma configuração de 1-de-1 no DVN. Um nó. Um ponto único de falha. Se o atacante comprometer esse nó, pode falsificar mensagens cross-chain. Se fosse 2-de-3 (recomendação mínima do setor), o atacante precisaria comprometer vários validadores independentes ao mesmo tempo.

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, quais nós usar, thresholds. O Kelp escolheu 1-de-1 ao implantar o OFT. LayerZero suporta 2-de-3 ou mais, mas o Kelp não ativou essa opção.

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 nunca revelou), mas listamos essa opacidade como uma lacuna de risco não resolvida. 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 até 16 cadeias suportadas com rsETH”

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

Esse é um risco sistêmico de deploy multi-chain: rsETH circula em Arbitrum, Optimism, Base, Scroll, etc., mas seu valor depende do ativo na rede principal. Se a ponte principal for comprometida, o valor do rsETH em todas as cadeias é afetado simultaneamente — os usuários não podem resgatar nem verificar o valor de seus tokens. O uso de rsETH como garantia na Lido (earnETH), Ethena e outras pontes LayerZero também foi suspenso. O raio de impacto é maior do que o próprio Kelp.

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

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 com período de bloqueio de 10 dias, ou a chaves de gestão independentes?”

O que realmente aconteceu: A configuração do DVN não está sob governança centralizada do protocolo. Se as mudanças de configuração da ponte também fossem controladas por um multi-sig 6/8 com período de 10 dias, um DVN de 1-de-1 precisaria de 6 assinaturas de 8 — o que é improvável que seja sempre gerenciado por uma única entidade.

Isso revela uma lacuna comum na governança: muitos protocolos têm controle rígido de atualizações de contratos principais, mas mudanças operacionais — configuração da ponte, parâmetros de oráculos, gerenciamento de whitelist — geralmente são feitas por uma única chave de administrador. O Kelp usa uma governança avançada (multi-sig 6/8 + período de 10 dias), mas essas proteções não se estendem ao maior vetor de ataque: a 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 pontes. A implantação do LayerZero do Kelp em 16 cadeias traz complexidade operacional semelhante à arquitetura multi-chain do Ronin.”

O que realmente aconteceu: O caminho do ataque replica quase exatamente o roteiro do Ronin — comprometer validadores, falsificar mensagens, esvaziar 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 comprometidos, 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 automaticamente 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 atualmente não possui um pool de seguro dedicado, nem mecanismo de compartilhamento de perdas para absorver penalidades.”

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% dos 177 milhões de dólares em perdas. Os LPs de protocolos que aceitaram rsETH como garantia — sem assinatura ou consentimento — sofreram o maior impacto.

O atacante usou o rsETH roubado como garantia em Aave V3, Compound V3, Euler, emprestando WETH real. Sem garantia, essas posições se tornaram inadimplentes — garantias viraram papel, mas o WETH emprestado já tinha desaparecido. A utilização de WETH na Aave atingiu 100%, impedindo saques normais. Mesmo depositantes de WETH na Aave, que nunca interagiram com rsETH, tiveram seus fundos afetados. O seguro do Nexus Mutual cobre apenas certos produtos de vault, não a exposição principal do protocolo rsETH.

Ambos os lados falharam: a Kelp, que gerencia 1,3 bilhões de dólares em TVL, não possui reserva de 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 cobre menos de 30% das perdas — uma falha de precificação de risco. A Aave trata o rsETH como um ativo de volatilidade normal, mas ele carrega o risco de falha na ponte — uma combinação de riscos de cauda. 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 vulnerabilidade combinada.

Onde erramos

Três pontos que poderiam ter sido feitos melhor:

1. Avaliação de risco subestimada. Classificamos o risco do bridge como “moderado”. Mas as cinco lacunas de informação não resolvidas relacionadas à configuração do LayerZero, combinadas com ataques históricos semelhantes ao Ronin/Harmony, deveriam ter elevado essa classificação para “alto” ou “grave”. A opacidade por si só já é um sinal forte.

2. Não penetramos na camada de configuração. Repetidamente, pedimos ao Kelp que divulgasse o threshold do DVN, mas não conseguimos verificar de forma independente. Essa é uma das principais limitações de ferramentas atuais: focam na lógica do código, não na configuração. Marcamos o problema, mas não conseguimos responder completamente.

3. 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 precisar que eles divulguem. Se tivéssemos feito isso, veríamos imediatamente a configuração 1-de-1, sem depender de divulgação. Essa é uma direção de 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 detectou a opacidade do Kelp, mas também marcou padrões semelhantes em dezenas de protocolos não atacados. Sem uma taxa de falsos positivos divulgada, afirmar que “previsões foram feitas” é exagero. A forma mais honesta de dizer é: fizemos perguntas que poucos fazem, e uma delas bateu na vulnerabilidade.

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 nossa análise identificou 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 o que divulgar. “Falta de documentação da ponte” é uma questão de governança, não um bug a ser reportado.

Depois, percebemos que poderíamos ter entrado em contato com a equipe 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 isso. Essa é uma lição: mesmo que uma descoberta pareça vaga demais para uma divulgação formal, uma mensagem privada pode fazer a diferença.

O que isso significa para a segurança DeFi

O roubo do Kelp — assim como o de Drift 17 dias antes — não foi uma falha de código. Ferramentas automáticas como Slither, Mythril, GoPlus não detectam. A vulnerabilidade 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 Solidity perfeito, cinco auditorias de empresas top, recompensas de 250 mil dólares — e ainda assim ser roubado por uma falha de configuração na ponte, como aconteceu com 292 milhões de dólares.

Nossa ferramenta é open source no GitHub — qualquer um pode revisar a metodologia, rodar 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 de uma próxima ponte cair?

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 gente — verifique você mesmo.

Verifique a configuração do validador da ponte. Se um protocolo não quiser divulgar seu threshold do DVN, considere isso um sinal de alerta. Nosso relatório faz exatamente isso, e mostrou-se preciso.

Não confie apenas na auditoria de código. Kelp já passou por mais de cinco auditorias de empresas renomadas (Code4rena, SigmaPrime, MixBytes). Mas auditorias focam na lógica do código, não na configuração de camada — que é uma análise diferente. Não é negligência das empresas, é uma limitação atual.

Avalie a cobertura de seguro. Se um protocolo não tem um pool de seguro, e você é LP de um empréstimo que aceita seu token como garantia, você está implicitamente assumindo esse risco. Na prática, depositantes de WETH na Aave aprenderam isso da pior forma.

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 DeFi.

O modo tradicional de segurança na cripto é: protocolos contratam auditorias, que revisam o código, que geram relatórios. Mas esse método tem pontos cegos — o caso 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 200 mil dólares por uma auditoria. Você não precisa entender 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 por qualquer investidor. Um LP considerando 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 300 milhões de dólares

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

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

Declaração oficial da 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