Risco de cascata na crise do KelpDAO e direitos de intervenção emergencial

Pontos principais: A vulnerabilidade de ponte de 290 milhões de dólares da KelpDAO desencadeou uma reação em cadeia, congelando mais de 6,7 bilhões de dólares em liquidez WETH em cinco cadeias, afetando usuários que nunca tiveram contato com rsETH. Este evento também revelou os limites práticos de sistemas “permissionless”: o Conselho de Segurança do Arbitrum, por meio de uma autorização de governança, executou uma atualização de contrato atômico que forçou uma mudança de estado, transferindo 30.766 ETH sem a assinatura do detentor.

Em 18 de abril de 2026, a ponte cross-chain da KelpDAO para rsETH foi atacada, resultando em uma perda de aproximadamente 290 milhões de dólares, tornando-se o maior incidente de segurança DeFi deste ano. A investigação inicial aponta para Lazarus Group, uma organização de ataque de nível estatal com histórico de ataques a infraestrutura de criptomoedas [1]. O ataque não explorou uma vulnerabilidade de contrato inteligente, mas sim uma injeção de toxina em um nó de uma rede de validação descentralizada (DVN) que dependia de infraestrutura RPC, falsificando mensagens cross-chain, e, na ausência de queima correspondente na cadeia de origem, liberou tokens rsETH.

LayerZero [1] e KelpDAO [2] já forneceram detalhes sobre o ataque. Este artigo aborda de outro ângulo: não repetir o processo de ataque, mas examinar o que aconteceu após ele — como uma dependência de infraestrutura de ponto único desencadeou uma cascata de congelamento de dezenas de bilhões de dólares em liquidez em cinco cadeias, e como essa cascata forçou uma governança descentralizada a exercer poderes centralizados em uma situação de emergência perante o público.

A cadeia de causas do incidente da KelpDAO atravessa três camadas do stack de tecnologia “descentralizado”: a dependência de ponto único na DVN possibilitou o ataque; a composabilidade do DeFi (ou seja, “lego DeFi”, onde protocolos se encaixam como blocos de montar) transformou essa vulnerabilidade de ponte em uma crise sistêmica de liquidez; e a escala da crise, por sua vez, expôs o exercício de poderes centralizados na estrutura de governança.

Contexto: Resumo do ataque à KelpDAO

A KelpDAO é a emissora do rsETH. rsETH é um token de liquidez de staking repledge (LRT), representando posições de ETH staked distribuídas em múltiplos operadores. Para viabilizar a circulação cross-chain do rsETH, a KelpDAO integrou o protocolo de mensagens LayerZero. Este protocolo depende de uma DVN (rede de validação descentralizada) para verificar a legitimidade das mensagens cross-chain antes de sua execução na cadeia de destino.

Configuração chave: A aplicação rsETH da KelpDAO usa uma configuração de DVN 1-de-1, ou seja, apenas uma DVN operada pela LayerZero Labs é usada como única validadora. Isso significa que toda a segurança cross-chain do rsETH depende de uma única entidade de validação. A documentação de integração do LayerZero recomenda explicitamente o uso de múltiplas DVNs redundantes, e a LayerZero afirmou que, antes do incidente, comunicou à KelpDAO essa prática recomendada [1]. A KelpDAO respondeu que a configuração 1/1 é “documentada na documentação do LayerZero e publicada como configuração padrão para qualquer novo deployment de OFT”, além de ter sido considerada adequada durante a expansão para L2 [2].

O atacante invadiu dois nós RPC usados pela DVN do LayerZero Labs, substituindo seus binários por versões maliciosas. Esses nós maliciosos retornavam apenas dados falsificados de estado na cadeia para o IP de origem, aparentando normalidade para todos os demais observadores (incluindo a infraestrutura de monitoramento do LayerZero). Ao mesmo tempo, um ataque de DDoS direcionado aos nós RPC não invadidos forçou a transferência de falha do sistema para os nós contaminados. Como resultado: a DVN confirmou uma mensagem cross-chain de uma cadeia de origem que nunca ocorreu, sem queima correspondente na cadeia de origem, e liberou tokens rsETH na interface do lado Ethereum (0x85d4…8ef3) para um total de 116.500 rsETH [1, 3]. A transação de liberação foi 0x1ae232…db4222. As evidências na cadeia são claras: o endpoint de destino na Ethereum aceitou nonce 308, enquanto o nonce máximo de saída reportado pelo endpoint de origem Unichain ainda era 307 [10].

A KelpDAO detectou a anomalia em 46 minutos e pausou todos os contratos relacionados. Isso impediu uma tentativa de ataque subsequente envolvendo mais 40.000 rsETH (aproximadamente 95 milhões de dólares) [2]. Mas, nesse momento, o atacante já avançava para a próxima fase: converter os rsETH roubados em ativos emprestados via protocolos DeFi.

De tokens falsificados a ativos emprestados

O atacante não vendeu diretamente os rsETH roubados. Os 116.500 tokens foram dispersos em sete carteiras secundárias, sendo convertidos por diversos canais, incluindo troca direta por ETH via agregadores, posições de fornecimento no Compound V3 e ponte para Arbitrum [10]. Mas o caminho mais impactante foi através do Aave: o atacante depositou 89.567 rsETH (aproximadamente 221 milhões de dólares) em duas plataformas de empréstimo em diferentes cadeias: Ethereum Core e Arbitrum. Usando o recurso E-Mode do Aave (que permite maior eficiência de capital ao aumentar o LTV para ativos relacionados), o atacante tomou emprestado 82.620 WETH e 821 wstETH usando o rsETH depositado como garantia [3].

Essas posições foram alavancadas ao limite. Os fatores de saúde dos sete endereços do atacante variaram entre 1,01 e 1,03, pouco acima do limite de liquidação [3]. A razão: o E-Mode do Aave definiu um LTV de 93% para rsETH, enquanto o limite de liquidação era 95%, deixando uma margem de segurança de apenas 2 pontos percentuais.

Os detalhes das posições nos dois mercados são os seguintes:

Tabela 1: Detalhes de fornecimento de rsETH e empréstimos de WETH/wstETH dos atacantes nos dois mercados do Aave

Fonte: dados on-chain, compilados do Etherscan, Arbiscan e DeBank, até 22/04/2026 16:51 UTC. Valores em USD refletem preços na época de cada transação.

Efeito em cascata: como uma vulnerabilidade de ponte congelou WETH em cinco cadeias

O diagrama a seguir resume toda a cadeia de eventos. Os passos 1 e 2 (vulnerabilidade na ponte e depósito de garantia no Aave) já foram descritos na seção anterior. Esta parte analisa profundamente os passos 3 a 5: por que o WETH precisou ser congelado, quais parâmetros moldaram a gravidade da cascata, e qual foi o custo real do congelamento.

Figura 1: Fluxo em cascata do ataque à vulnerabilidade na ponte até o congelamento de WETH em cinco cadeias

Por que o WETH precisa ser congelado

Em 19 de abril, o Protocol Guardian do Aave congelou todas as posições de rsETH e wrsETH nas versões V3 e V4, proibindo novos depósitos e empréstimos com rsETH como garantia [8]. Essa foi a primeira resposta prevista.

De forma inesperada, em 20 de abril, o Aave congelou os reserves de WETH nas redes Ethereum, Arbitrum, Base, Mantle e Linea [3, 8].

Por que congelar WETH? Porque se trata de um ativo não atacado, sem relação com a ponte cross-chain. Os rsETH depositados foram criados sem qualquer correspondência de ativos na cadeia de origem. A oráculo do Aave continua a precificar esses tokens ao valor de mercado completo, considerando-os como garantias válidas indistinguíveis do rsETH legítimo. O atacante aproveitou essa assimetria de informação para emprestar WETH real, representando uma dívida não garantida, usando esses tokens como garantia. Isso drenou WETH dos pools de empréstimo, levando a uma utilização de 100% nas posições afetadas. Com a utilização máxima, os depositantes de WETH não podem mais retirar fundos, e os liquidadores não podem executar liquidações, pois os ativos subjacentes estão indisponíveis. O mecanismo de liquidação, que é a principal defesa contra inadimplência, ficou efetivamente paralisado [3].

Se o WETH emprestado permanecesse aberto, a liquidez restante nas outras cadeias poderia ser igualmente drenada: depositando rsETH, emprestando WETH e saindo. Portanto, congelar WETH não é uma opção, mas uma medida de controle de dano.

Parâmetros que moldaram a cascata

A gravidade da cascata não foi acidental. Três parâmetros do protocolo determinaram a extensão do dano direto e o alcance da propagação do congelamento.

1. LTV: quanto de ativo contaminado pode ser extraído por unidade de garantia saudável

O E-Mode do Aave para rsETH define um LTV de 93%, ou seja, a cada dólar de rsETH contaminado depositado, é possível emprestar 0,93 dólares de WETH. Em comparação, o LTV do rsETH no Spark Protocol era 72%, e na Fluid cerca de 75% [3]. O parâmetro do Aave é o mais agressivo do mercado.

Essa decisão foi cuidadosamente pensada, não um descuido. Em janeiro de 2026, a governança do Aave aumentou o limite de fornecimento de rsETH de 480.000 para 530.000 na Ethereum Core, e de 52.000 para 70.000 na Mantle [E0]. Embora isso não indique causalidade (o período de preparação do atacante provavelmente foi anterior a esses ajustes), evidencia como ajustes de parâmetros podem, inadvertidamente, ampliar o impacto de eventos futuros.

Impacto real do congelamento

Resultado: uma vulnerabilidade de ponte de 290 milhões de dólares congelou liquidez de WETH em cinco cadeias, afetando pools com reservas superiores a 67 bilhões de dólares.

A perda direta limita-se ao valor emprestado pelo atacante. Mas, no DeFi de empréstimos, o congelamento não é uma simples interrupção operacional. Ele bloqueia liquidez de usuários, impede saques, desorganiza posições ativas e enfraquece a capacidade de o protocolo se proteger contra inadimplência via liquidações. A maioria dos usuários afetados nunca teve contato com rsETH, KelpDAO ou qualquer ponte cross-chain. São depositantes e tomadores de WETH na Aave, participando de mercados de empréstimo que consideram como operações de empréstimo diretas e transparentes.

WETH é o ativo de liquidez mais fundamental do DeFi. Congelá-lo equivale a fechar o maior banco da cidade, por uma instituição financeira que foi vítima de fraude com um produto que a maioria dos depositantes nunca ouviu falar.

O relatório de incidentes do LlamaRisk [3] constrói dois modelos de cenário de inadimplência, fornecendo uma previsão de shortfall por cadeia, sendo a análise de risco de propagação mais detalhada até o momento. Mas mesmo essa análise foca no potencial de inadimplência, não nos custos operacionais mais amplos do congelamento — incluindo bloqueio de saques, impedimento de posições e enfraquecimento da capacidade de liquidação dos mercados afetados. Uma quantificação completa do impacto da cascata ainda é uma questão em aberto.

Se a cascata de ataque é complexa, o processo de recuperação também não é simples. A composabilidade, ao mesmo tempo que impõe restrições, também limita a reparação. O Aave não pode simplesmente “descongelar tudo”. Cada mercado precisa ser avaliado individualmente, considerando sua exposição a rsETH, a utilização de WETH e a atividade do atacante, diante de diferentes riscos. A linha do tempo mostra claramente:

19 de abril: Protocol Guardian congela todas as posições de rsETH e wrsETH no Aave V3 e V4 ###.

20 de abril: WETH é congelado nas redes Ethereum, Arbitrum, Base, Mantle e Linea [3, 8].

21 de abril: WETH no Ethereum Core V3 é descongelado, com LTV zerado como medida preventiva. WETH nas redes Ethereum Prime, Arbitrum, Base, Mantle e Linea permanece congelado [8].

Quatro dias após o ataque, apenas um dos mercados afetados foi descongelado. O caminho de recuperação é tão complexo quanto o de ataque: avançando de protocolo em protocolo, de cadeia em cadeia, cada passo requer coordenação de governança e avaliação de risco.

Resposta emergencial: como o Arbitrum transferiu 30.766 ETH sem assinatura do detentor

Enquanto o Aave lidava com a cascata de empréstimos, uma ação paralela ocorreu no Arbitrum. Em 21 de abril, o Conselho de Segurança do Arbitrum anunciou uma ação emergencial: congelar os 30.766 ETH que o atacante possuía na rede Arbitrum One [3]. Esses fundos foram transferidos para um endereço intermediário de congelamento (0x…0DA0), que só poderá ser movimentado após uma votação de governança do Arbitrum ###.

[3] Ação de governança

O Conselho de Segurança do Arbitrum é uma parte formal da estrutura de governança do DAO do Arbitrum, não uma entidade externa ou comissão temporária. A ação emergencial foi anunciada publicamente no fórum de governança do Arbitrum [3], e executada após a confirmação da identidade do atacante, com detalhes completos da transação disponíveis para verificação pública. O Conselho agiu dentro de suas competências, ponderando o compromisso com a segurança e integridade da comunidade do Arbitrum, sem prejudicar usuários ou aplicações [3].

Este não foi um decisão de câmara secreta, mas uma ação autorizada por governança, executada de forma transparente, com evidências na cadeia claramente visíveis.

[8] Mecanismo técnico

O que torna essa ação notável não é a decisão de governança em si, mas sua execução na cadeia. Com base na análise do rastreamento Phalcon da BlockSec [8], o Conselho de Segurança utilizou uma operação atômica de três etapas:

O executor de upgrade temporariamente atualizou o contrato de inbox do Ethereum (DelayedInbox), adicionando uma nova função chamada sendUnsignedTransactionOverride.

Essa função foi usada para criar uma mensagem cross-chain que se passou pelo endereço do atacante. A mensagem foi injetada via Bridge.enqueueDelayedMessage, tipo=3, correspondente ao L1MessageType_L2Message no stack Nitro do Arbitrum. Este tipo de mensagem permite a execução de L2MessageKind_UnsignedUserTx na L2. O ponto-chave: essa operação não requer validação de assinatura. O parâmetro sender foi alterado do padrão msg.sender para uma entrada controlada pelo chamador, que, por sua vez, carrega o endereço do atacante por meio de uma conversão de alias de endereço L1→L2.

Após a execução na L2, o contrato de inbox foi restaurado à sua implementação original.

As transações na L1 [6] e as transações resultantes na L2 [7] podem ser visualizadas publicamente no Phalcon Explorer. As transações na L2 aparecem como “do atacante para 0x…0DA0”, mas isso não é uma transferência padrão assinada pelo usuário, e sim uma mudança de estado forçada na cadeia: uma atualização de infraestrutura de governança que, sem a chave privada do proprietário, transfere ativos.

A crise da descentralização

O princípio é simples: contratos upgradeáveis conferem poderes ilimitados. Se um contrato pode ser atualizado, seu comportamento pode ser alterado para fazer qualquer coisa, incluindo transferir ativos sem assinatura do proprietário. Essa é uma capacidade inerente a qualquer sistema construído com contratos upgradeáveis. Os 30.766 ETH atualmente estão em um endereço de congelamento. A decisão de seu destino só pode ser tomada por uma votação de governança do Arbitrum posteriormente [7]. O padrão de atualização-execução-restauração atômico não deixa alterações permanentes no contrato de inbox, nem afeta outros usuários ou aplicações [6].

Na avaliação geral, a ação do Conselho de Segurança do Arbitrum é considerada correta. O atacante foi identificado como um ator de nível estatal, as autoridades participaram, o processo de governança foi transparente, e os ativos roubados de 71 milhões de dólares foram recuperados ou pelo menos impedidos de serem lavados novamente.

Por outro lado, a capacidade que possibilita tudo isso é muito mais ampla. O mesmo mecanismo de atualização-execução-restauração, em princípio, pode ser usado para transferir qualquer ativo de qualquer endereço na rede Arbitrum One. O poder do Conselho não se limita ao endereço do atacante ou aos fundos roubados; é uma capacidade geral, regulada por governança, não por código.

Este é o dilema. Os usuários, ao interagir com a L2, carregam uma expectativa implícita: “Meus ativos estão sob controle da minha chave privada, ninguém pode transferi-los sem minha assinatura.” O incidente da KelpDAO mostra que esse modelo é incompleto. Em Arbitrum, e em qualquer L2 com contratos de ponte upgradeáveis e Conselho de Segurança, ativos podem ser transferidos por ações de governança que ignoram a assinatura do proprietário.

Arbitrum não é uma exceção. A paralisação do mercado do Aave também foi uma ação de emergência conduzida por governança. No incidente da KelpDAO, múltiplos protocolos exerceram poderes centralizados de emergência: Aave congelou mercados em cinco cadeias, o Conselho de Segurança do Arbitrum executou transferências forçadas, e a KelpDAO colocou contratos em pausa global. Essas respostas, embora necessárias e eficazes, demonstram que o ecossistema “descentralizado” na prática é uma coordenação de poderes centralizados.

A questão não é se esses poderes de emergência deveriam existir. O caso da KelpDAO reforça a necessidade de tais poderes. Mas o que importa é se seus limites, condições de ativação e mecanismos de responsabilização são suficientemente transparentes. Usuários que depositam ativos na L2 devem poder responder a uma pergunta básica: sob quais condições o Conselho de Segurança pode transferir meus fundos? Quais são meus direitos de recurso?

Situação atual dos fundos roubados

O rastreamento independente na cadeia (visualização completa no MetaSleuth [6]) mostra que o atacante dispersou 116.500 rsETH em 7 endereços primários, sendo que a maior parte foi depositada na Aave (Ethereum Core e Arbitrum) como garantia de WETH e wstETH, e os tokens emprestados foram trocados por DEXs e enviados para um endereço comum 0x5d39…7ccc (Ethereum / Arbitrum). Até 22/04/2026 05:42 UTC, os fundos roubados estão distribuídos em quatro estados:

Tabela 3: Distribuição dos fundos roubados em quatro estados (até 22/04/2026 05:42 UTC)

Desses, cerca de 31% estão congelados ou interceptados, 23% permanecem em um endereço inativo na Ethereum, e 46% já foram ou estão sendo dispersos para 103 endereços secundários. Os fundos depositados como garantia de rsETH na Aave ainda não foram resgatados, e os empréstimos de WETH e wstETH não foram devolvidos. As posições de empréstimo foram abandonadas.

A cadeia de causas do incidente da KelpDAO atravessa as três camadas do stack de tecnologia “descentralizado”.

O ponto de partida é a dependência de ponto único. A configuração 1-de-1 da DVN da KelpDAO reduz a validação cross-chain a uma única entidade, permitindo que toda a ponte seja vulnerável a uma única infraestrutura comprometida. A arquitetura suporta descentralização, mas a configuração não.

A composabilidade, por sua vez, transformou uma vulnerabilidade de ponte em uma crise de liquidez sistêmica. Um ataque que congelou o ativo mais fundamental do DeFi, WETH, afetou cinco cadeias, impactando dezenas de bilhões de dólares em liquidez, envolvendo usuários que nunca tiveram contato com rsETH ou KelpDAO. A extensão da propagação da cascata é moldada por parâmetros quantificáveis: configurações de LTV agressivas, pools de baixa profundidade e ampla implantação de garantias cross-chain.

A escala da crise, por sua vez, forçou a governança descentralizada a exercer poderes centralizados de emergência. O Conselho de Segurança do Arbitrum, por meio de uma atualização atômica autorizada por governança, transferiu 30.766 ETH sem assinatura do proprietário. O Aave, por sua vez, congelou mercados em múltiplas cadeias. Essas respostas foram eficazes, transparentes e necessárias, demonstrando os limites práticos do sistema “permissionless”.

A dependência de ponto único possibilitou o ataque, a composabilidade ampliou o dano, e a centralização de poderes revelou uma vulnerabilidade embutida em contratos upgradeáveis e na governança. Para enfrentar esses problemas interligados, é necessário que todos os participantes atuem conjuntamente:

Para os protocolos: a segurança geral depende do elo mais fraco, que neste caso foi a infraestrutura da DVN, não os contratos inteligentes ###. Uma avaliação de segurança abrangente deve incluir segurança de código, infraestrutura, gestão de chaves e operações. Monitoramento on-chain é essencial para respostas rápidas, assim como rastreamento de fundos cross-chain para coordenação de congelamentos e recuperação. Para protocolos de empréstimo, garantias de ativos cross-chain devem ser testadas sob cenários de comprometimento total.

Para a governança de L2 e DAOs: poderes de emergência devem ser transparentes e responsáveis. A maioria das L2 principais possui esses mecanismos, mas muitas vezes eles estão escondidos na documentação técnica. As regras de ativação, limites, prazos e responsabilizações devem estar claramente definidas.

Para os usuários: entender os riscos sistêmicos inerentes à composabilidade do DeFi. No incidente, depositantes de WETH que nunca tiveram contato com rsETH foram afetados pelo congelamento em cinco cadeias. O risco de uma posição individual é apenas uma parte do risco total; a interação com protocolos, pools, garantias e cadeias forma um panorama de risco interligado.