292 milhões de dólares roubados sem tocar em um único contrato inteligente. Em 18 de abril de 2026, o protocolo de restaking líquido KelpDAO foi drenado através de sua bridge LayerZero — não por um bug em Solidity, mas porque um único verificador era suficiente para aprovar mensagens cross-chain, e o atacante envenenou os nós RPC que esse verificador consultava. Em 46 minutos, a Kelp pausou o protocolo e evitou outros 200 milhões em perdas. Mas o dano já estava feito: Aave enfrenta até 230 milhões em dívidas incobráveis, o TVL de DeFi caiu 25% em horas, e os pesquisadores apontam para o mesmo grupo que drenou o Drift Protocol 17 dias antes — o Grupo Lazarus da Coreia do Norte. 575 milhões de DeFi em 18 dias, com dois vetores completamente distintos.
Este artigo detalha a mecânica do exploit, por que a configuração padrão da LayerZero era uma bomba-relógio, quem paga a conta e o que isso significa para qualquer pessoa com fundos em protocolos que usam bridges cross-chain.
Aviso editorial: este artigo é informativo e se baseia em dados públicos do post-mortem da LayerZero (20 de abril), declarações da Aave e KelpDAO, e análises de pesquisadores on-chain. A situação ainda está em evolução. Os dados refletem o estado em 21 de abril de 2026.
Como roubaram 292 milhões sem explorar um contrato inteligente?
Às 17:35 UTC de 18 de abril, o atacante chamou lzReceive no contrato EndpointV2 da LayerZero, instruindo o OFTAdapter da Kelp no Ethereum a liberar 116.500 rsETH — aproximadamente 18% do fornecimento circulante do token. Nenhuma queima correspondente ocorreu na cadeia de origem (Unichain). O atacante fabricou uma mensagem cross-chain falsa que a bridge aceitou como legítima.
Como? Eles não quebraram criptografia nem encontraram um bug no código. Envenenaram a infraestrutura:
- Obtiveram a lista de endpoints RPC que a Decentralized Verifier Network (DVN) da LayerZero consultava para ler o estado da Unichain.
- Substituíram os binários de dois nós independentes por versões modificadas que retornavam dados falsos ao DVN — mas respondiam corretamente aos sistemas de monitoramento.
- Lançaram um ataque DDoS contra os endpoints de backup para forçar o DVN a usar os nós envenenados.
- O malware se autodestruiu após o ataque para eliminar rastros forenses.
A condição que tornou isso possível: a Kelp usava uma configuração 1-de-1 em sua bridge — um único verificador era suficiente para aprovar qualquer mensagem cross-chain. Sem redundância, sem segunda verificação. Um único ponto de falha para 292 milhões.
46 minutos foram suficientes para evitar outros 200 milhões em perdas?
O multisig de emergência da Kelp executou pauseAll às 18:21 UTC — 46 minutos após a drenagem. Às 18:26 e 18:28, o atacante tentou duas transações adicionais para drenar outros 40.000 rsETH cada (~100 milhões por tentativa). Ambas reverteram porque o protocolo já estava pausado.
Se a pausa tivesse chegado 10 minutos depois, o roubo total teria atingido 391 milhões.
O que o atacante fez com os fundos
Em minutos, 89.567 dos 116.500 rsETH roubados foram depositados como colateral na Aave V3/V4 através de sete carteiras. Contra esse colateral, o atacante pegou emprestado 82.650 WETH (190,9 milhões) e 821 wstETH (2,3 milhões). Algumas estimativas elevam o total emprestado para 126.000 WETH (236 milhões) somando outros protocolos. O WETH emprestado foi canalizado através do Tornado Cash — o mesmo mixer que havia financiado a carteira do atacante com 1 ETH dez horas antes do roubo.
Quem paga a conta de 230 milhões em dívidas incobráveis?
O roubo direto de 292 milhões é apenas uma parte do dano. Como o atacante converteu rsETH roubado em ativos reais emprestados em protocolos de lending, várias plataformas enfrentam dívidas que não podem ser cobradas:
| Plataforma | Dívida incobrável estimada | Status |
|---|---|---|
| Aave V3/V4 | 124 – 230 M$ | Relatório da Chaos Labs publicado, pausa do módulo Umbrella recomendada |
| Compound V3 | ~39 M$ | Proposta para desabilitar rsETH como colateral em 5 cadeias |
| Euler | < 1 M$ | Contido |
Os contratos da Aave não foram comprometidos — o fundador Stani Kulechov confirmou que o vetor foi completamente externo. Mas o protocolo sofreu mais de 5,4 bilhões em saques em horas, empurrando os pools de WETH, USDT e USDC para 100% de utilização. Os depositantes ficaram presos. O mesmo padrão que vimos com USR-Morpho em março — quando um colateral se rompe, a liquidez do pool evapora e os credores não conseguem sair.
O token AAVE caiu entre 10% e 18%. O TVL de DeFi despencou de ~110 bilhões para ~82,4 bilhões — uma queda de 25% que reflete fuga de risco, não apenas perdas diretas.
A única recuperação significativa: em 21 de abril, o Conselho de Segurança da Arbitrum congelou 30.766 ETH (~71 milhões) em uma carteira intermediária, agindo por informações das forças de segurança. Isso representa 24% dos fundos roubados.
De quem é a culpa — LayerZero ou KelpDAO?
A guerra pública entre os dois importa porque determina se ~47% das aplicações integradas com LayerZero precisam ser reconfiguradas imediatamente.
LayerZero diz: Kelp "escolheu" a configuração de um único verificador. O exploit foi consequência direta dessa decisão. A partir de agora, a LayerZero se recusa a assinar mensagens para aplicações que continuem na configuração 1-de-1.
Kelp responde: a configuração 1-de-1 era o padrão documentado da LayerZero. Apesar de ter um canal de comunicação direto aberto desde julho de 2024, nunca os alertaram especificamente que deveriam mudá-la.
Desenvolvedores independentes corroboraram a versão da Kelp: o arquivo de configuração padrão da LayerZero V2 (layerzero.config.ts) é entregue com uma configuração de 1-required / 0-optional. E o DVN comprometido era infraestrutura própria da LayerZero Labs, não um verificador de terceiros.
A leitura honesta: ambos compartilham responsabilidade. A LayerZero criou padrões inseguros que tornavam trivial a configuração perigosa, e um protocolo que custodia bilhões deveria ter endurecido além dos padrões. O incidente revela que a revisão de configuração de bridges é uma disciplina de segurança diferente das auditorias de contratos inteligentes — e uma que a maioria dos protocolos tratou como um checkbox.
575 milhões em 18 dias — o que o Grupo Lazarus está fazendo?
Os pesquisadores — incluindo a equipe da Chainalysis e ZachXBT — atribuem preliminarmente o ataque à subunidade TraderTraitor do Grupo Lazarus da Coreia do Norte. É o mesmo grupo vinculado a:
| Ataque | Data | Valor | Vetor |
|---|---|---|---|
| Bybit | 2025 | 1.400 M$ | Comprometimento de infraestrutura |
| Drift Protocol | 1 abr 2026 | 285 M$ | Manipulação de oráculo + engenharia social |
| KelpDAO | 18 abr 2026 | 292 M$ | Envenenamento de RPC + bridge 1-de-1 |
575 milhões de DeFi em 18 dias com dois vetores estruturalmente diferentes. Não é um script kiddie repetindo o mesmo truque — é uma campanha sofisticada que identifica as falhas entre sistemas (bridges, governança, oráculos) onde as auditorias de código não chegam.
A Chainalysis resumiu: "Detectar código malicioso não é suficiente; os protocolos devem detectar quando um sistema entra em um estado impossível."
O que isso significa para o restaking e as bridges cross-chain?
Não há contágio estrutural para o setor LST/LRT mais amplo. stETH, wstETH, rETH e cbETH não são afetados. Os depósitos de rsETH na mainnet do Ethereum continuam respaldados por posições legítimas na EigenLayer.
Mas o rsETH bridgeado para outras cadeias enfrenta uma crise de paridade severa: os holders não podem saber se seus tokens têm respaldo, porque o atacante injetou 116.500 unidades sem colateral no fornecimento circulante. A Kelp não publicou um plano de alocação de perdas.
A resposta precautória foi imediata: a Lido pausou o earnETH, a Ethena pausou suas bridges LayerZero por 6 horas (sem exposição a rsETH), e mais de 20 protocolos — Ether.fi, Curve, Morpho, Kamino, Lombard, Beefy, Maple, Mantle entre outros — pausaram temporariamente suas bridges LayerZero. SparkLend e Fluid congelaram os mercados de rsETH.
O que qualquer usuário de DeFi deve verificar agora?
- Você tem tokens bridgeados? Qualquer token que cruzou uma bridge (rsETH, mas também wETH, USDC bridgeado, etc.) herda o risco da configuração da bridge, não apenas do contrato do token. Um wrapped token em uma L2 pode ter um perfil de risco fundamentalmente distinto do token nativo em sua cadeia de origem.
- Você usa rsETH como colateral? Se você tem posições na Aave, Compound ou Euler com rsETH, seu Health Factor agora depende de um ativo cujo respaldo está em disputa. Monitore ativamente.
- Seus protocolos usam bridges LayerZero? Verifique se a aplicação usa configuração 1-de-1 ou multisig. Cerca de 47% das aplicações LayerZero estavam em configuração vulnerável antes do ataque.
- Diversifique o risco de bridge. Não concentre a exposição cross-chain em um único provedor de bridge. A base da sua pirâmide de fragilidade não deveria depender de um único ponto de falha.
O exploit da Kelp é o primeiro hack de nove dígitos cuja causa raiz está completamente fora do Solidity — na segurança operacional da infraestrutura off-chain que alimenta um verificador de bridge. Durante cinco anos, a indústria endureceu contratos inteligentes com auditorias, verificação formal e bug bounties. Os atacantes se moveram para cima, para camadas de infraestrutura onde essas defesas não se aplicam. A configuração padrão não é uma configuração segura em escala — e essa lição acaba de custar 292 milhões de dólares.
Você sabe em quantas bridges seu capital está distribuído?
CleanSky mostra suas posições por cadeia e protocolo — para que você veja onde tem exposição cross-chain antes que uma bridge falhe. Sem custodiar seus fundos. Descubra como funciona.