Como os especialistas técnicos veem o incidente de hacking do Kelp DAO

Autor: Grvt Deep Research Institute

Na madrugada de 19 de abril, a ponte cross-chain rsETH baseada em LayerZero do Kelp DAO foi comprometida, com 116.500 tokens rsETH saindo do OFTAdapter principal sem registros de queima correspondentes, equivalendo a aproximadamente 292 milhões de dólares na cotação da época. Em uma hora, o Kelp executou urgentemente pauseAll, mas o atacante realizou duas ataques adicionais posteriormente; se o contrato não tivesse sido pausado, a perda total se aproximaria de 391 milhões de dólares.

Menos de um dia após o incidente, a Aave congelou os mercados de rsETH e wrsETH, com a utilização dos pools críticos atingindo 100%, dificultando a retirada de ETH, WETH e até USDT, USDC. Pelo menos 9 protocolos acionaram respostas de emergência consecutivamente. Este é o maior prejuízo único na DeFi até 2026; há três semanas, o Drift Protocol sofreu um ataque de 285 milhões de dólares. Juntos, esses eventos levantam uma questão cada vez mais difícil de ignorar na indústria: o atual quadro de segurança da DeFi é suficiente para enfrentar as ameaças de hoje?

Como o ataque aconteceu

Para entender este incidente, é preciso primeiro compreender a arquitetura cross-chain do Kelp.

O Kelp utiliza o padrão OFT do LayerZero. O contrato OFTAdapter no mainnet detém as permissões de cunhagem e resgate do rsETH, enquanto mais de 20 L2s usam contratos OFT padrão para mapeamento. Não há versões wrapped na ponte, que opera com um mecanismo de liquidação de débito-crédito 1:1 — a queima no L2 corresponde à liberação no mainnet, e o bloqueio no mainnet corresponde à cunhagem no L2.

O ponto central dessa mecânica é a função lzReceive, que teoricamente aceita apenas mensagens cross-chain verificadas pelo LayerZero. No entanto, o atacante conseguiu contornar essa verificação, falsificando uma mensagem sem registros de queima na origem, acionando diretamente a liberação de reservas pelo Adapter principal. Sem débito na origem, houve crédito no destino. A oferta omnichain, que deveria ser conservada, foi quebrada neste momento.

O CTO da Cyvers, Meir Dolev, comparou o ataque a: “O cofre não tem problema, os guardas são honestos, a fechadura funciona normalmente. A mentira é sussurrada diretamente para a única pessoa que pode abrir a porta.” Essa metáfora descreve precisamente o problema — não há uma falha no design do sistema, mas uma vulnerabilidade na cadeia de validação, onde um único nó de confiança pode ser comprometido.

Opiniões de especialistas: uma falha estrutural previsível

O Kelp optou pela configuração de segurança mais fraca permitida pelo LayerZero: 1/1 DVN, ou seja, uma mensagem cross-chain que precisa apenas de uma assinatura de verificador para passar.

Shalev Keren, cofundador da Sodot, uma empresa de segurança criptográfica, afirmou em entrevista que isso representa “uma falha de ponto único, independentemente de como a estratégia de marketing seja embalada”. Ele acrescentou que, com um único nó de verificação comprometido, os fundos podem sair da ponte, e essa vulnerabilidade não pode ser consertada por auditorias ou revisões de segurança — a única solução é “remover a confiança unilateral na arquitetura”.

Mais importante ainda, essa não é uma vulnerabilidade que só será descoberta após o fato. Em janeiro de 2025, uma equipe de desenvolvimento já havia alertado na fórum de governança da Aave para expandir para múltiplos verificadores DVN. Passaram-se 15 meses, e o segundo verificador ainda não foi adicionado.

O LayerZero afirmou posteriormente que solicitou várias vezes que o Kelp atualizasse para uma configuração de múltiplos verificadores e anunciou que deixaria de aprovar mensagens de aplicações que ainda utilizassem apenas um verificador. No entanto, essa declaração também levanta uma questão: se o risco era conhecido, por que o protocolo não tomou medidas mais rígidas mais cedo, deixando a decisão totalmente para a camada de aplicação?

O debate sobre “responsabilidade do protocolo” versus “responsabilidade da aplicação” ainda não tem uma resposta definitiva. Haoze Qiu, líder de Blockchain do Grvt, afirmou em entrevista: “O Kelp DAO aceitou uma configuração de segurança de ponte com redundância insuficiente para esse volume de ativos, uma escolha de design que criou um ponto de falha na validação. Ao mesmo tempo, o LayerZero também tem sua responsabilidade, pois o ataque envolveu infraestrutura relacionada ao seu stack de validadores, mesmo que isso não tenha sido classificado como uma vulnerabilidade central do protocolo. No ecossistema interconectado da DeFi, os usuários não se importam qual camada falhou; eles querem saber se o sistema é robusto o suficiente para proteger seus ativos em momentos críticos.”

Como a infecção ocorreu

A vulnerabilidade técnica é apenas a primeira parte do incidente. A verdadeira questão de risco estrutural se revela na segunda fase do ataque.

O atacante depositou os tokens rsETH roubados em plataformas de empréstimo como Aave V3, V4, Compound V3, Euler, usando-os como garantia de valor quase zero para emprestar ativos reais. Somente na Aave, foram emprestados cerca de 196 milhões de dólares, com uma dívida total superior a 236 milhões. Essas garantias, no momento do depósito, tiveram suas reservas principais esvaziadas, tornando impossível sua liquidação normal.

Aave posteriormente congelou esses mercados, restringindo drasticamente a liquidez e provocando uma corrida de saques superior a 100 bilhões de dólares. A Fluid também congelou o mercado de rsETH, a Upshift pausou duas de suas vaults, a Lido Earn suspendeu depósitos devido à exposição ao earnETH, e a Ethena, por precaução, pausou sua ponte LayerZero OFT por cerca de seis horas.

A cadeia de infecção se espalhou por vários nós em poucas horas, não por uma falha de controle de risco de um único protocolo, mas como consequência direta do uso excessivo de LRT como garantia — staking, re-staking, implantação cross-chain, empréstimos garantidos, cada camada adicional introduz uma hipótese de confiança. Quando as reservas mais profundas são esvaziadas, toda a cadeia fica desestabilizada.

Um contraste importante é que a SparkLend já removeu o rsETH de sua lista de garantias em janeiro de 2026. Diferentemente de outros protocolos, que fizeram avaliações de risco mais conservadoras, essa decisão mostra que é possível evitar riscos sistêmicos, mesmo que isso signifique sacrificar parte do TVL a curto prazo. Para plataformas que conectam fundos de usuários a protocolos DeFi, a lógica é a mesma: monitoramento contínuo, julgamento rápido e ajuste proativo de exposição antes que a incerteza se transforme em prejuízo. A Grvt, por exemplo, agiu rapidamente nesta crise, ajustando suas exposições DeFi ao detectar pressão de mercado, para proteger os fundos dos usuários.

No nível operacional, a infiltração na cadeia de suprimentos do Drift e a pré-planejamento do ataque ao Kelp demonstram que ataques de alto risco não acontecem apenas na cadeia. Gestão de chaves, processos internos, auditorias de terceiros — tudo isso deve fazer parte do escopo de segurança do protocolo, e não ficar na zona cinzenta das “melhores práticas de engenharia”.

No nível de cooperação da indústria, a divergência nas atribuições até agora revela que o compartilhamento de inteligência on-chain e a padronização ainda estão atrasados. Empresas de segurança, equipes de protocolos e infraestrutura precisam estabelecer mecanismos mais sistemáticos de troca de informações, ao invés de apenas publicar análises após o incidente.

Conclusão

Nos primeiros quatro meses de 2026, as perdas na DeFi por ataques já se aproximam de um bilhão de dólares. Drift e Kelp contribuíram com dois incidentes de mais de 280 milhões de dólares cada, em menos de três semanas.

Não se trata de um evento de cauda negra (black swan) probabilístico, mas de um sinal claro de que o modelo de ameaça assumido pelos quadros atuais de segurança não cobre mais as formas reais de ataque de hoje.

A evolução da segurança na DeFi não é uma questão que um único protocolo possa resolver sozinho. Requer que os projetistas de protocolos, infraestrutura, plataformas de empréstimo e pesquisadores de segurança reajustem suas hipóteses de risco e encontrem formas de fortalecer coletivamente a resiliência do ecossistema.

Esse diálogo está apenas começando.