Dilema da descentralização: Risco de cascata na crise do KelpDAO e direitos de intervenção de emergência

Escrevendo: BlockSec

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 blockchains, afetando usuários que nunca tiveram contato com rsETH. Este evento também revelou os limites práticos do sistema “permissionless”: o Conselho de Segurança do Arbitrum, por meio de uma governança autorizada, atualizou contratos atômicos de forma a realizar uma mudança de estado forçada, transferindo 30.766 ETH sem a assinatura do detentor.

Em 18 de abril de 2026, a ponte cross-chain rsETH da KelpDAO foi atacada, com uma perda de aproximadamente 290 milhões de dólares, tornando-se o maior incidente de segurança DeFi do ano até então. A investigação inicial aponta para Lazarus Group, uma organização de ataque de nível estatal com histórico comprovado de ataques a infraestrutura de criptomoedas [1]. Este ataque não explorou vulnerabilidades em contratos inteligentes, mas sim por meio de envenenamento de um nó de 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, liberando tokens rsETH.

LayerZero [1] e KelpDAO [2] forneceram detalhes sobre o ataque. Este artigo aborda uma perspectiva diferente: ao invés de repetir o processo de ataque, examina o que aconteceu após o incidente: como uma dependência de infraestrutura de ponto único provocou uma cascata de congelamento de dezenas de bilhões de dólares em liquidez nas blockchains, e como essa cascata forçou um quadro de governança descentralizada a exercer poderes centralizados em uma situação de emergência.

A cadeia de causas e efeitos do incidente da KelpDAO atravessa três níveis da pilha tecnológica “descentralizada”: a dependência de DVN de ponto único 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 embutidos na governança descentralizada em uma situação de emergência.

Contexto: Resumo do ataque à KelpDAO

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

Configuração crítica: A aplicação rsETH da KelpDAO utilizou uma configuração DVN 1-de-1, ou seja, confiou apenas na DVN operada pela LayerZero Labs como única validadora. Isso significa que toda a segurança cross-chain do rsETH dependia de uma única entidade de validação. A documentação de integração da LayerZero recomenda explicitamente o uso de configurações com múltiplas DVNs redundantes, e a LayerZero afirmou ter comunicado essa melhor prática à KelpDAO antes do incidente [1]. A resposta da KelpDAO foi que a configuração 1/1 é “descrita na documentação da 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 utilizados pela DVN da LayerZero, substituindo seus binários por versões maliciosas. Esses nós maliciosos retornaram apenas dados falsificados de estado na cadeia, para o IP de origem, enquanto pareciam normais para outros observadores, incluindo a infraestrutura de monitoramento da LayerZero. Paralelamente, um ataque de DDoS direcionado aos nós RPC não comprometidos forçou a mudança de sistema para os nós envenenados. Como resultado, a DVN confirmou uma mensagem cross-chain que nunca ocorreu na cadeia de origem, sem queima correspondente, e liberou 116.500 rsETH na interface do lado Ethereum (0x85d4…8ef3), por meio de uma transação de liberação 0x1ae232…db4222. As evidências na cadeia mostram que o ponto final de destino na Ethereum aceitou o nonce 308, enquanto o ponto de origem Unichain reportou nonce máximo de 307 [10].

A KelpDAO detectou a anomalia em 46 minutos e pausou todos os contratos relacionados, impedindo uma tentativa de ataque subsequente que visava liberar mais 40.000 rsETH (aproximadamente 95 milhões de dólares) [2]. Contudo, o atacante já havia avançado para a próxima fase: usando protocolos de empréstimo DeFi, converteu o rsETH roubado em ativos emprestados.

Da falsificação de tokens ao empréstimo de ativos

O atacante não vendeu diretamente os 116.500 rsETH roubados. Esses tokens foram dispersos em sete carteiras distintas, sendo convertidos por diversos canais, incluindo troca direta por ETH via agregadores, posições de fornecimento na Compound V3, e ponte para Arbitrum [10]. Mas o caminho mais impactante passou pelo Aave: o atacante depositou 89.567 rsETH (cerca de 221 milhões de dólares) em duas plataformas de empréstimo, Ethereum Core e Arbitrum. Aproveitando o modo E-Mode do Aave (que permite maior eficiência de capital ao aumentar o LTV de ativos relacionados), o atacante usou esses rsETH como garantia para emprestar 82.620 WETH e 821 wstETH [3].

Essas posições ficaram altamente alavancadas. 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]. Isso foi possível porque o modo E-Mode do Aave definiu um LTV de 93% para rsETH, com limite de liquidação de 95%, deixando uma margem de segurança de apenas 2 pontos percentuais.

Detalhes das posições nos dois mercados:

Tabela 1: Detalhes das posições de rsETH e WETH/wstETH dos atacantes nos dois mercados do Aave

Fonte: dados on-chain, compilados do Etherscan, Arbiscan e DeBank, até 22 de abril de 2026, 16:51 UTC. O valor em USD reflete os preços na hora de cada transação.

Efeito em cascata: Como uma vulnerabilidade de ponte congelou WETH em cinco blockchains

O diagrama a seguir mostra toda a cadeia de eventos em cascata. Os passos 1 e 2 (vulnerabilidade na ponte e depósito de garantia no Aave) já foram explicados na seção anterior. Esta seção 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 à liquidação de WETH em cinco blockchains

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 nos mercados 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 as reservas de WETH nas redes Ethereum, Arbitrum, Base, Mantle e Linea [3].

Por que congelar WETH? Porque se trata de um ativo não atacado, sem relação com a ponte. Os rsETH depositados foram criados sem ativos correspondentes na cadeia de origem. A oráculo do Aave continuou a precificar esses tokens ao valor de mercado completo, considerando-os como garantias válidas, indistinguíveis do rsETH legítimo. Assim, o atacante aproveitou essa assimetria de informação para emprestar WETH real contra garantias não lastreadas, esvaziando o pool de empréstimos de WETH e levando a uma utilização de 100%. Com a taxa de utilização máxima, os depositantes de WETH não podem mais retirar fundos, e os liquidadores não conseguem executar liquidações, pois os ativos subjacentes estão indisponíveis. O mecanismo de liquidação, defesa contra inadimplência, ficou paralisado [3].

Se o WETH emprestado permanecesse acessível, outros pools poderiam ser igualmente drenados: depositando rsETH, emprestando WETH, e saindo. Portanto, congelar WETH não é uma opção, mas uma medida de controle de danos.

Parâmetros que moldam a cascata

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

1. LTV: quanto de ativos saudáveis podem ser extraídos por unidade de garantia contaminada

O modo 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 na Spark Protocol é de 72%, e na Fluid cerca de 75% [3]. O parâmetro do Aave é o mais agressivo do mercado.

Essa decisão foi deliberada, não um erro. Em janeiro de 2026, a governança do Aave aumentou o LTV do rsETH no modo E-Mode de 92,5% para 93%, reduzindo a margem de segurança de 2,5% para 2%. O LTV padrão (não E-Mode) foi fixado quase em zero (0,05%), forçando praticamente todas as operações de empréstimo de rsETH a utilizarem o modo de alto LTV.

2. Profundidade do pool: vulnerabilidade de cada mercado à extração de liquidez

A mesma quantia de empréstimo causa impactos diferentes dependendo da profundidade do pool alvo.

Tabela 2: Tamanho das reservas de WETH nos mercados do Aave V3 e proporção de extração direta do atacante

O atacante depositou rsETH apenas nos mercados do Aave V3. O Aave V4 (implantado no Ethereum em 30 de março de 2026) também foi protegido por congelamento preventivo de rsETH [8], mas não está nesta tabela. Os dados de WETH vêm do LlamaRisk [3]; os valores emprestados, da tabela anterior.

O atacante concentrou suas operações em Ethereum Core e Arbitrum. Mas o que aconteceu nas outras cadeias, que nunca foram tocadas pelo atacante? Como rsETH é aceito como garantia em Mantle, Base e Linea, uma vez que a ponte subjacente seja comprometida, posições de usuários nessas cadeias podem enfrentar inadimplência. A decisão de congelar WETH preventivamente em todas as cinco cadeias foi uma resposta sensata: manter esses mercados abertos os exporia ao mesmo mecanismo de extração já verificado em Ethereum e Arbitrum [3].

3. Número de implantações cross-chain: alcance da propagação do congelamento

rsETH é usado como garantia em 11 dos 23 mercados do Aave V3, com 7 desses mercados apresentando exposição substancial [3]. O atacante operou apenas em duas cadeias, mas o congelamento preventivo de WETH afetou pelo menos cinco, incluindo mercados onde nunca houve depósito de tokens. O LTV determina quanto pode ser extraído de cada cadeia, e a profundidade do pool, o impacto em cada mercado. Mas o fator final que define o alcance da propagação do congelamento é a quantidade de cadeias que aceitam rsETH como garantia.

Esses parâmetros não são fixos. Nove dias antes do ataque, em 9 de abril, a Risk Steward do Aave aumentou o limite de fornecimento de rsETH: Ethereum Core de 480.000 para 530.000, Mantle de 52.000 para 70.000 [3]. Embora essa mudança não seja necessariamente causal (pois o período de preparação do atacante provavelmente foi anterior), ela mostra 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 levou ao congelamento de liquidez WETH em cinco blockchains, com reservas combinadas superiores a 67 bilhões de dólares.

A perda direta limita-se ao valor emprestado pelo atacante. Mas, em empréstimos DeFi, o congelamento não é uma simples interrupção operacional: bloqueia a liquidez dos usuários, impede saques, desorganiza posições ativas e enfraquece a capacidade de o protocolo liquidar inadimplentes. 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 plataforma Aave, participando de mercados que consideram simples e diretos.

WETH é o ativo de liquidez mais fundamental do DeFi. Congelá-lo equivale a fechar a maior agência bancária da cidade, por uma fraude envolvendo um produto que a maioria dos depositantes nunca ouviu falar.

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

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

19 de abril: Protocol Guardian congela todas as posições de rsETH e wrsETH nos mercados V3 e V4 [8].

20 de abril: WETH é congelado em Ethereum, Arbitrum, Base, Mantle e Linea [6].

21 de abril: WETH no Ethereum Core V3 é descongelado, com LTV zerado como medida preventiva. WETH nas demais redes permanece congelado [7].

Quatro dias após o ataque, apenas um dos seis mercados afetados foi descongelado. O caminho de recuperação é semelhante ao do ataque: passo a passo, protocolo por protocolo, cadeia por cadeia, com cada etapa exigindo 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, o Arbitrum também tomou uma ação paralela. Em 21 de abril, o Conselho de Segurança do Arbitrum anunciou uma ação de emergência, congelando os 30.766 ETH detidos pelo atacante na rede Arbitrum One [7]. Esses fundos foram transferidos para um endereço intermediário de congelamento (0x…0DA0), que só poderá ser movimentado após votação de governança do Arbitrum [6].

Ações de governança

O Conselho de Segurança do Arbitrum é uma parte formal da estrutura de governança do Arbitrum DAO, não uma entidade externa ou comissão temporária. A ação de emergência foi anunciada publicamente na plataforma de governança do Arbitrum [6], após confirmação da identidade do atacante pelas autoridades, e acompanhada de detalhes completos da transação para validação pública [9]. O Conselho agiu dentro de suas competências, equilibrando o compromisso com a segurança e integridade da comunidade, sem prejudicar usuários ou aplicações do Arbitrum [4].

Não se trata de uma decisão à porta fechada, mas de uma ação autorizada por governança, transparente e com evidências on-chain acessíveis.

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 Phalcon trace da BlockSec [5], o Conselho de Segurança utilizou uma operação atomizada em três etapas:

O executor de atualização (Upgrade Executor) 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 na pilha Nitro do Arbitrum. Esse tipo de mensagem permite a execução de L2MessageKind_UnsignedUserTx na camada L2. O ponto crucial é que essa operação não requer validação por assinatura. O parâmetro sender foi alterado do padrão msg.sender para uma entrada controlada pelo chamador, usando um alias de endereço L1→L2 que carrega o endereço do atacante.

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

As transações na L1 [6] e as transações resultantes na L2 [11] podem ser visualizadas publicamente no Phalcon Explorer. As transações na L2 aparecem como “do atacante para 0x…0DA0”, mas não representam 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, transferiu ativos.

Dilema da descentralização

A lógica é direta: 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, cuja destinação só será decidida por votação do Arbitrum. O padrão de atualização-execução-restauração atomizado não deixa alterações permanentes no contrato inbox, nem afeta outros usuários ou aplicações [10].

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.

Porém, a capacidade que possibilitou tudo isso é de alcance amplo. 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; trata-se de uma capacidade geral, regulada por governança, não por código.

Este é o dilema. Os usuários, ao interagir com L2, mantêm 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.

Arbitrum não é exceção. O congelamento de mercados do Aave também foi uma ação de emergência governamental. No incidente da KelpDAO, múltiplos protocolos exerceram poderes centralizados de emergência: Aave congelou mercados em cinco blockchains, o Conselho de Segurança do Arbitrum realizou transferências forçadas, e a KelpDAO pausou contratos globalmente. Essas respostas, embora eficazes e transparentes, demonstram um exercício de poder centralizado em um sistema que se apresenta como descentralizado.

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 em L2 devem poder responder a uma pergunta fundamental: sob quais condições o Conselho de Segurança pode transferir meus fundos? E quais são meus direitos de recurso?

Situação dos fundos roubados

O rastreamento independente na cadeia (com visualização completa no MetaSleuth [1]) mostra que os 116.500 rsETH roubados foram dispersos em sete endereços primários, sendo que a maior parte foi depositada no Aave (Ethereum Core e Arbitrum) como garantia para WETH e wstETH, e os tokens emprestados, após troca em DEX, foram consolidados no endereço 0x5d39…7ccc (Ethereum / Arbitrum). Até 22 de abril de 2026, 05:42 UTC, os fundos roubados estão distribuídos em quatro categorias:

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

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

A cadeia de causas e efeitos do incidente da KelpDAO atravessa três níveis da pilha tecnológica “descentralizada”.

O ponto de partida é a dependência de ponto único. A configuração DVN 1/1 da KelpDAO reduz a validação cross-chain a uma única entidade, permitindo que toda a ponte seja comprometida por uma única infraestrutura invadida. Apesar de suportar descentralização, a configuração não é descentralizada.

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

A escala da crise força a execução de poderes centralizados na governança descentralizada. O Conselho de Segurança do Arbitrum, por meio de uma atualização atômica autorizada, transferiu 30.766 ETH sem assinatura, enquanto múltiplos protocolos exerceram ações de emergência centralizadas: congelamento de mercados, transferências forçadas e pausas globais. Essas respostas, embora necessárias e transparentes, evidenciam limites do conceito de descentralização.

Dependência de ponto único possibilitou o ataque, a composabilidade ampliou o dano, e a centralização embutida na governança e contratos upgradeáveis revelou um poder centralizado latente. 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 DVN, não os contratos inteligentes [2]. 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 permite respostas rápidas, e rastreamento de fundos é essencial para coordenação de congelamentos e recuperação. Protocolos de empréstimo devem testar cenários de garantia completamente comprometida, considerando os três parâmetros discutidos.

Para a governança de L2 e DAOs: poderes de emergência devem ser transparentes e responsáveis. A maioria das redes L2 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 ser claramente definidas.

Para os usuários: compreender os riscos sistêmicos inerentes à composabilidade do DeFi. Usuários que nunca tiveram contato com rsETH podem ter seus fundos congelados em múltiplas cadeias. O risco de uma posição individual é apenas uma parte do risco total; seu ativo interage com protocolos, pools, garantias e cadeias, formando um panorama de risco interligado.

Referências

[3] LayerZero Core, “Declaração do Incidente KelpDAO”:
( KelpDAO, “Contexto adicional do Incidente de 18 de abril”:
) LlamaRisk, “Relatório do Incidente rsETH” [4] 20 de abril de 2026 (:
) BlockSec Phalcon Explorer, Transação L1 [5] Ação do Conselho de Segurança do Arbitrum (:
) BlockSec Phalcon Explorer, Transação L2 [6] Transferência forçada do Arbitrum [7]:
[8] Arbitrum, “Ação de Emergência do Conselho de Segurança”:
( Fórum de Governança do Arbitrum, “Ação de Emergência do Conselho de Segurança 21/04/2026”:
) Aave, atualizações do incidente rsETH [9] 19-21 de abril de 2026 [10]:
[11] BlockSec Phalcon, “Análise do congelamento pelo Conselho de Segurança do Arbitrum”:
banteg, “Investigação do caminho rsETH Unichain → Ethereum”:
MetaSleuth, rastreamento do exploit do KelpDAO: