O Dilema da Descentralização: Risco em Cascata e Poder de Emergência na Crise do KelpDAO

Em 18 de abril de 2026, a ponte cross-chain rsETH da KelpDAO foi explorada em aproximadamente $290 milhões, tornando-se o maior incidente de segurança em DeFi do ano. A atribuição preliminar aponta para o Lazarus Group, um agente de ameaça patrocinado por estado com histórico bem documentado de ataques à infraestrutura cripto [1]. O ataque não explorou uma vulnerabilidade em contrato inteligente. Em vez disso, envenenou a infraestrutura de RPC subjacente a um único nó de Rede de Verificadores Descentralizados (DVN), forjando mensagens cross-chain que liberaram tokens rsETH sem a correspondente queima na cadeia de origem.

O exploit em si foi coberto em detalhes pelo LayerZero [1] e pela KelpDAO [2]. Este artigo adota um ângulo diferente. Em vez de reproduzir o ataque, examinamos o que aconteceu após o exploit: como uma dependência de infraestrutura de ponto único possibilitou uma cascata que congelou bilhões em liquidez em cinco redes, e como essa cascata forçou os frameworks de governança descentralizada a exercer poderes de emergência centralizados em plena visibilidade pública.

O incidente da KelpDAO traça uma cadeia causal que atravessa três camadas da pilha "descentralizada": uma dependência de DVN de ponto único tornou o exploit possível; a componibilidade do DeFi (também conhecida como "DeFi Lego"), a propriedade que permite que protocolos se conectem entre si como blocos de construção, transformou o exploit da ponte em uma crise de liquidez sistêmica; e a escala da crise, por sua vez, forçou os frameworks de governança a revelar os poderes de emergência centralizados embutidos neles.

Contexto: O Exploit da KelpDAO em Resumo

A KelpDAO é a emissora do rsETH, um token de restaking líquido (LRT) que representa posições de ETH apostado em múltiplos operadores. Para viabilizar a movimentação cross-chain do rsETH, a KelpDAO integrou-se ao protocolo de mensagens da LayerZero, que depende de DVNs — verificadores independentes que confirmam se as mensagens cross-chain são legítimas antes de serem executadas na cadeia de destino.

A escolha de configuração crítica: o OApp rsETH da KelpDAO utilizou uma configuração DVN 1-de-1, com o DVN operado pela LayerZero Labs como único verificador. Isso significava que toda a segurança cross-chain do rsETH dependia de uma única entidade de verificação. A documentação de integração da LayerZero recomenda explicitamente configurações multi-DVN com redundância, e a LayerZero afirma ter comunicado essa prática recomendada à KelpDAO antes do incidente [1]. A KelpDAO, por sua vez, sustenta que a configuração 1/1 era "a configuração documentada na documentação da LayerZero e entregue como padrão para qualquer novo deployment de OFT," e que os "padrões foram afirmativamente confirmados como apropriados" durante sua expansão para L2 [2].

Os atacantes comprometeram dois nós RPC utilizados pelo DVN da LayerZero Labs, substituindo seus binários por versões maliciosas que retornavam dados de estado de cadeia forjados exclusivamente ao endereço IP do DVN, enquanto apareciam normais para todos os outros observadores, incluindo a própria infraestrutura de monitoramento da LayerZero. Um ataque DDoS simultâneo contra os nós RPC não comprometidos forçou o failover para os nós envenenados. O resultado: o DVN confirmou uma mensagem cross-chain que nunca ocorreu na cadeia de origem, liberando 116.500 rsETH do adaptador no lado Ethereum (0x85d4...8ef3) sem nenhuma queima correspondente no lado de origem [1, 3]. A transação de liberação é 0x1ae232...db4222. A evidência on-chain é inequívoca: o endpoint de destino na Ethereum aceitou o nonce 308, enquanto o endpoint de origem na Unichain ainda reporta um nonce máximo de saída de 307 [10].

A KelpDAO detectou a anomalia e pausou todos os contratos relevantes em 46 minutos. Essa intervenção bloqueou uma tentativa subsequente visando 40.000 rsETH adicionais (~$95M) [2]. Mas naquele ponto, o atacante já havia avançado para a próxima etapa: converter os rsETH roubados em ativos emprestados por meio de protocolos de empréstimo DeFi.

De Tokens Forjados a Ativos Emprestados

O atacante não simplesmente vendeu os rsETH roubados. Os 116.500 tokens foram dispersos por sete carteiras ramificadas e monetizados por múltiplos canais, incluindo trocas diretas para ETH via agregadores, posições de fornecimento no Compound V3 e re-bridging para Arbitrum [10]. Mas o caminho mais consequente passou pelo Aave: o atacante depositou 89.567 rsETH (aproximadamente $221 milhões) nos mercados de empréstimo do Aave em duas redes: Ethereum Core e Arbitrum. Usando o E-Mode do Aave — um recurso de eficiência de capital que permite taxas mais altas de empréstimo em relação ao valor para ativos correlacionados —, o atacante tomou emprestado 82.620 WETH e 821 wstETH contra o rsETH depositado [3].

As posições foram alavancadas ao máximo. Os fatores de saúde nos sete endereços do atacante variavam de 1,01 a 1,03, mal acima do limiar de liquidação [3]. Isso foi possível porque o LTV do E-Mode do Aave para rsETH estava definido em 93%, com um limiar de liquidação de 95%, deixando uma margem de segurança de apenas 2 pontos percentuais.

O detalhamento por endereço em ambos os mercados:

Fonte: dados on-chain agregados do Etherscan, Arbiscan e DeBank em 2026-04-22 16:51 UTC. Valores em USD refletem os preços dos tokens no momento de cada transação.

A Cascata: Como um Exploit de Ponte Congelou WETH em Cinco Redes

A figura abaixo resume a cascata completa. Os passos 1 e 2 (o exploit da ponte e o depósito de garantia no Aave) são abordados na seção de Contexto acima. O restante desta seção examina os passos 3 a 5 em detalhes: por que o WETH precisou ser congelado, quais parâmetros moldaram a gravidade da cascata e o que o congelamento realmente custou.

Por que o WETH Precisou Ser Congelado

Em 19 de abril, o Guardião de Protocolo do Aave congelou todos os mercados de rsETH e wrsETH no Aave V3 e V4, impedindo novos depósitos e empréstimos contra garantias em rsETH [8]. Essa foi a primeira resposta esperada.

O segundo passo inesperado ocorreu em 20 de abril: o Aave congelou as reservas de WETH na Ethereum, Arbitrum, Base, Mantle e Linea [3, 8].

Por que congelar o WETH, um ativo que não foi explorado e não tem nada a ver com pontes cross-chain? Porque o atacante havia depositado rsETH cunhado sem qualquer lastro correspondente na cadeia de origem. O oráculo do Aave continuou a precificar esses tokens pelo valor de mercado cheio, tratando-os como garantia legítima indistinguível do rsETH devidamente ponteado. O atacante explorou essa assimetria de informação para tomar emprestado WETH real contra garantias que, no nível do sistema, representavam passivos sem lastro. Isso drenou WETH dos pools de empréstimo, elevando a utilização a 100% nos mercados afetados. Com utilização total, os depositantes existentes de WETH não conseguem sacar, e os liquidadores não conseguem receber o ativo subjacente necessário para executar liquidações. O mecanismo de liquidação — a principal defesa do protocolo contra dívidas inadimplentes — foi efetivamente paralisado [3].

Se os empréstimos em WETH permanecessem abertos, a liquidez restante dos pools em outras redes poderia ser drenada pelo mesmo mecanismo: depositar rsETH, tomar WETH emprestado e sair. Congelar o WETH não era opcional. Era a única forma de limitar o dano.

Três Parâmetros que Moldaram a Cascata

A gravidade desta cascata não foi acidental. Três parâmetros de protocolo determinaram tanto o dano direto quanto o escopo do congelamento resultante.

1. LTV: quanto de ativo saudável cada unidade de garantia contaminada pode extrair

O LTV do E-Mode do Aave para rsETH era de 93%, o que significa que cada dólar de rsETH contaminado depositado podia tomar emprestado $0,93 em WETH. Para contextualizar, o Spark Protocol definiu o LTV do rsETH em 72% durante o mesmo período, e o Fluid em aproximadamente 75% [3]. O parâmetro do Aave era o mais agressivo do mercado.

Essa foi uma decisão de design deliberada, não uma supervisão. Em janeiro de 2026, a governança do Aave elevou o LTV do E-Mode para rsETH de 92,5% para 93%, comprimindo ainda mais a já estreita margem de segurança de 2,5% para 2% [3]. O LTV base (fora do E-Mode) foi intencionalmente definido próximo a zero (0,05%), forçando efetivamente todos os empréstimos relevantes em rsETH pelo caminho de E-Mode com LTV elevado.

2. Profundidade do pool: o quão vulnerável cada mercado está à drenagem de liquidez

A mesma quantidade em dólares de empréstimos tem impactos radicalmente diferentes dependendo da profundidade do pool-alvo.

O atacante depositou rsETH apenas nos mercados Aave V3. O Aave V4 (somente Ethereum, lançado em 2026-03-30) também foi sujeito ao congelamento preventivo de rsETH [8], mas não está refletido nesta tabela. Dados de reserva de WETH da LlamaRisk [3]; empréstimos do atacante derivados do detalhamento por endereço acima.

O atacante concentrou os empréstimos no Ethereum Core e Arbitrum. Mas a observação crítica é o que aconteceu com as redes que o atacante nunca tocou. Como o rsETH era aceito como garantia em Mantle, Base e Linea, quaisquer posições de usuários existentes lastreadas em rsETH nessas redes carregavam risco latente de dívida inadimplente após o comprometimento do lastro da ponte subjacente. A decisão do Aave de congelar preventivamente o WETH em todas as cinco redes foi uma resposta racional: deixar esses mercados abertos os exporia ao mesmo mecanismo de drenagem que o atacante já havia demonstrado na Ethereum e no Arbitrum [3, 8].

3. Contagem de deployments cross-chain: até onde o congelamento se propaga

O rsETH estava listado como garantia em 11 dos 23 mercados Aave V3, com 7 apresentando exposição material [3]. O atacante operou em apenas 2 redes. Mas o congelamento preventivo do WETH atingiu pelo menos 5 redes, incluindo mercados onde o atacante nunca depositou um único token. O LTV determina quanto é extraído por rede; a profundidade do pool determina o quão severamente cada mercado é afetado. Mas é o número de redes onde o rsETH foi aceito como garantia que, em última instância, decidiu até onde o congelamento se propagou.

Esses parâmetros não são estáticos. Nove dias antes do exploit, em 9 de abril, o Administrador de Risco do Aave elevou os limites de fornecimento do rsETH: Ethereum Core de 480.000 para 530.000, e Mantle de 52.000 para 70.000 [3]. Embora isso não implique causalidade (a linha de tempo de preparação do atacante provavelmente antecede essas mudanças), isso ressalta como ajustes rotineiros de parâmetros podem inadvertidamente ampliar o raio de impacto de um incidente futuro.

O Impacto Real do Congelamento

O resultado: um exploit de ponte de $290M levou a congelamentos de liquidez de WETH em cinco redes, afetando mercados com reservas combinadas superiores a $6,7 bilhões.

As perdas diretas limitaram-se aos empréstimos do atacante. Mas em empréstimos DeFi, um congelamento não é um inconveniente operacional menor. Ele bloqueia a liquidez dos usuários, impede saques, interrompe posições ativas e prejudica os mecanismos de liquidação que protegem o protocolo contra dívidas inadimplentes. A grande maioria dos usuários afetados nunca havia interagido com rsETH, KelpDAO ou qualquer ponte cross-chain. Eram depositantes e tomadores de WETH no Aave, participantes do que razoavelmente entendiam ser um mercado de empréstimo simples.

O WETH é o ativo de liquidez mais fundamental do DeFi. Congelá-lo é o equivalente a fechar os saques no maior banco da cidade porque uma instituição financeira diferente, usando um produto que a maioria dos depositantes nunca ouviu falar, foi vítima de fraude.

O relatório de incidente da LlamaRisk [3] modelou dois cenários de dívida inadimplente com projeções de déficit por rede, fornecendo a análise mais detalhada disponível sobre propagação de risco. Mas mesmo essa análise focou em dívidas inadimplentes potenciais, não nos custos operacionais mais amplos do congelamento em si — incluindo saques bloqueados, posições interrompidas e capacidade de liquidação prejudicada em todos os mercados afetados. Uma quantificação abrangente do impacto total em cascata permanece um problema em aberto.

Se a cascata do ataque foi complexa, a recuperação mostrou-se igualmente complexa. A componibilidade restringe o reparo assim como permite o dano. O Aave não pôde simplesmente "descongelar tudo." Cada mercado teve de ser avaliado de forma independente, com diferentes perfis de risco dependendo da exposição local ao rsETH, dos níveis de utilização do WETH e da atividade do atacante. A linha do tempo conta a história:

• 19 de abril: O Guardião de Protocolo congelou todas as reservas de rsETH e wrsETH no Aave V3 e V4 [8].
• 20 de abril: WETH congelado na Ethereum, Arbitrum, Base, Mantle e Linea [3, 8].
• 21 de abril: WETH descongelado apenas no Ethereum Core V3, com LTV permanecendo em 0 como medida preventiva. WETH no Ethereum Prime, Arbitrum, Base, Mantle e Linea permaneceu congelado [8].

Quatro dias após o exploit, cinco dos seis mercados afetados permanecem congelados. O caminho de recuperação espelha o caminho do ataque em complexidade: protocolo por protocolo, rede por rede, com cada etapa exigindo coordenação de governança e avaliação de risco.

A Resposta: Como o Arbitrum Moveu 30.766 ETH Sem a Assinatura do Titular

Enquanto o Aave gerenciava a cascata de empréstimos, uma resposta paralela se desenrolava no Arbitrum. Em 21 de abril, o Conselho de Segurança do Arbitrum anunciou que havia tomado uma ação de emergência para congelar 30.766 ETH mantidos pelo explorador no Arbitrum One [6]. Os fundos foram transferidos para um endereço congelado intermediário (0x...0DA0), acessível apenas por meio de ação subsequente de governança do Arbitrum [7].

A Ação de Governança

O Conselho de Segurança do Arbitrum é um componente formal da estrutura de governança da DAO do Arbitrum, não um ator externo ou comitê ad hoc. A ação de emergência foi anunciada publicamente por meio do fórum de governança do Arbitrum [7], executada com informações de autoridades policiais sobre a identidade do explorador [6], e documentada com detalhes completos das transações. O Conselho de Segurança agiu dentro de seu mandato estabelecido, sopesando "seu compromisso com a segurança e a integridade da comunidade Arbitrum sem impactar nenhum usuário ou aplicação do Arbitrum" [6].

Esta não foi uma decisão tomada nos bastidores. Foi uma ação de emergência sancionada pela governança, executada de forma transparente, com evidências on-chain para qualquer pessoa verificar.

O Mecanismo Técnico

O que torna esta ação notável não é a decisão de governança, mas como ela foi executada on-chain. Com base na análise de rastreamento Phalcon da BlockSec [9], o Conselho de Segurança empregou uma abordagem atômica de três etapas:

1. O Executor de Upgrade atualizou temporariamente o contrato de inbox da Ethereum (DelayedInbox), adicionando uma nova função chamada sendUnsignedTransactionOverride.

2. Esta função foi usada para criar uma mensagem cross-chain se passando pelo endereço do explorador. A mensagem foi injetada via Bridge.enqueueDelayedMessage com kind=3, que mapeia para L1MessageType_L2Message na pilha Nitro do Arbitrum. Este tipo de mensagem permite a execução de L2MessageKind_UnsignedUserTx no L2. Crucialmente, este caminho não requer verificação de assinatura. O parâmetro de remetente foi deslocado do caminho padrão msg.sender para uma entrada controlada pelo chamador, transformada por meio de aliasing de endereço L1→L2 para carregar o contexto do endereço do explorador.

3. Após a transferência ser executada no L2, o contrato de inbox foi restaurado à sua implementação original.

A transação L1 [4] e a transação L2 resultante [5] são ambas publicamente visíveis no Phalcon Explorer. O que a transação L2 mostra como "do explorador para 0x...0DA0" não é uma transferência padrão assinada pelo usuário. É uma transição de estado forçada no nível da cadeia — uma transação que moveu ativos sem a chave privada do titular, executada por meio de poderes de upgrade de infraestrutura em nível de governança.

O Dilema

O mecanismo é simples em princípio: contratos atualizáveis concedem capacidade ilimitada. Se um contrato pode ser atualizado, seu comportamento pode ser alterado para fazer qualquer coisa, incluindo transferir ativos sem a assinatura do titular. Essa capacidade é inerente a qualquer sistema construído sobre contratos atualizáveis. Os 30.766 ETH agora estão em um endereço congelado. Apenas uma votação subsequente de governança do Arbitrum pode determinar sua destinação. O padrão atômico de upgrade-execução-restauração não deixou nenhuma alteração permanente no contrato de inbox, e nenhum outro usuário ou aplicação foi afetado [6].

A ação do Conselho de Segurança do Arbitrum foi, pela maioria das avaliações razoáveis, a decisão certa. O explorador foi identificado como um agente patrocinado por estado. As autoridades policiais estavam envolvidas. O processo de governança foi público. E $71 milhões em ativos roubados foram recuperados, ou pelo menos impedidos de serem lavados ainda mais.

Mas a capacidade que tornou isso possível vai além deste caso específico. O mesmo mecanismo de upgrade-execução-restauração poderia, em princípio, ser usado para mover qualquer ativo mantido por qualquer endereço no Arbitrum One. O poder do Conselho de Segurança não se limita a endereços de exploradores ou fundos roubados. É uma capacidade de uso geral restringida por normas de governança, não por código.

Este é o dilema. Os usuários interagem com L2s sob um modelo mental implícito: "meus ativos são controlados pela minha chave privada, e ninguém pode movê-los sem minha assinatura." O incidente da KelpDAO demonstra que esse modelo é incompleto. No Arbitrum, e em qualquer L2 com contratos de ponte atualizáveis e um Conselho de Segurança, os ativos podem ser movidos por meio de ações de governança que ignoram completamente as verificações de assinatura.

O Arbitrum não é único a esse respeito. Os congelamentos de mercado do Aave também são ações de emergência impulsionadas pela governança. Durante o incidente da KelpDAO, múltiplos protocolos exerceram poderes de emergência centralizados simultaneamente: o Aave congelou mercados em cinco redes, o Conselho de Segurança do Arbitrum executou uma transferência forçada, e a KelpDAO pausou contratos globalmente. A resposta de crise do ecossistema "descentralizado" foi, na prática, um exercício coordenado de autoridade centralizada.

A questão não é se os poderes de emergência devem existir. O caso KelpDAO apresenta um argumento convincente de que devem. A questão é se os limites, condições de acionamento e mecanismos de responsabilização desses poderes são suficientemente transparentes. Usuários que depositam ativos em um L2 devem ser capazes de responder a uma pergunta básica: em que circunstâncias o Conselho de Segurança pode mover meus fundos, e que recurso tenho?

Status Atual dos Fundos Roubados

O rastreamento on-chain independente (visualização completa no MetaSleuth [11]) mostra o atacante distribuindo os 116.500 rsETH por sete endereços de primeiro salto, fornecendo a maior parte como garantia no Aave (Ethereum Core e Arbitrum) para tomar WETH e wstETH emprestados, e consolidando os recursos em um endereço compartilhado 0x5d39...7ccc em ambas as redes (Ethereum / Arbitrum). Em 2026-04-22 05:42 UTC, os fundos roubados encontram-se em quatro estados distintos:

Aproximadamente 31% dos recursos estão congelados ou interceptados, 23% permanecem ociosos em um único endereço Ethereum dormente, e 46% foram dispersos, ou estão sendo dispersos, por 103 endereços de primeiro salto. O rsETH postado como garantia no Aave permanece depositado, e o WETH e wstETH tomados emprestados não foram reembolsados — o atacante abandonou a posição de empréstimo.

Conclusão

O incidente da KelpDAO traça uma cadeia causal que atravessa três camadas da pilha "descentralizada".

Começou com uma dependência de ponto único. A configuração DVN 1-de-1 da KelpDAO reduziu a verificação cross-chain a uma única entidade, tornando toda a ponte explorável por meio de um único componente de infraestrutura comprometido. A arquitetura suportava a descentralização; a configuração não.

A componibilidade então transformou um exploit de ponte em uma crise de liquidez sistêmica. Um único ataque congelou o WETH, o ativo de liquidez mais fundamental do DeFi, em cinco redes, afetando bilhões de dólares em liquidez mantida por usuários sem nenhuma conexão com rsETH ou KelpDAO. O alcance da cascata foi moldado por parâmetros mensuráveis: configurações de LTV agressivas, pools de liquidez rasos e amplo deployment de garantias cross-chain.

A escala da crise, por sua vez, forçou a governança descentralizada a exercer poderes de emergência centralizados. O Conselho de Segurança do Arbitrum moveu 30.766 ETH sem a assinatura do titular por meio de um upgrade atômico de contrato sancionado pela governança. O Aave congelou mercados em múltiplas redes por meio de ações de emergência impulsionadas pela governança. A resposta foi eficaz, transparente e, argumentavelmente, necessária. Foi também uma demonstração de que "sem permissão" tem limites práticos.

A dependência de ponto único possibilitou o exploit; a componibilidade amplificou o dano; o dano revelou o poder centralizado que sempre esteve lá, embutido em contratos atualizáveis e frameworks de governança. Abordar essas dinâmicas interligadas requer ação de todos os participantes:

Para protocolos: A segurança geral de um protocolo é determinada por seu elo mais fraco, que neste caso foi a infraestrutura DVN e não os contratos inteligentes [10]. A segurança efetiva requer cobertura sistemática em múltiplas dimensões, incluindo segurança de código, segurança de infraestrutura, gerenciamento de chaves e segurança operacional. Avaliações abrangentes e testes de penetração devem testar sob estresse toda a pilha, não componentes individuais isoladamente. O monitoramento on-chain viabiliza respostas de emergência em minutos em vez de horas, e o rastreamento rápido de fundos cross-chain é essencial para coordenar congelamentos de ativos e maximizar a recuperação. Para protocolos de empréstimo especificamente, as garantias provenientes de ativos sintéticos cross-chain devem ser testadas sob estresse em um cenário de "comprometimento total da garantia" considerando os três parâmetros discutidos acima: LTV, profundidade do pool e contagem de deployments cross-chain.

Para governança de L2 e DAOs: Os poderes de emergência devem ser transparentes e responsabilizáveis. A maioria dos principais L2s já possui essas capacidades, mas elas frequentemente estão enterradas em documentação técnica em vez de serem apresentadas em materiais voltados ao usuário. Os frameworks de governança devem codificar condições de acionamento, limitações de escopo, restrições de tempo e requisitos de responsabilização pós-ação.

Para usuários: Compreenda o risco sistêmico inerente à componibilidade do DeFi. Neste incidente, depositantes de WETH que nunca tocaram em rsETH tiveram sua liquidez congelada em cinco redes. O risco da posição individual é apenas parte do quadro; os protocolos, pools, tipos de garantia e redes com os quais seus ativos interagem formam uma superfície de risco interconectada.

Referências

[1] LayerZero Core, "KelpDAO Incident Statement": https://x.com/LayerZero_Core/status/2046081551574983137

[2] KelpDAO, "April 18 Incident: Additional Context": https://x.com/KelpDAO/status/2046332070277091807

[3] LlamaRisk, "rsETH Incident Report" (20 de abril de 2026): https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[4] BlockSec Phalcon Explorer, Transação L1 (ação do Conselho de Segurança do Arbitrum): https://app.blocksec.com/phalcon/explorer/tx/eth/0x079984c56c5670108f5c6f664904178f9b364340351949a42e4637d1f645f770

[5] BlockSec Phalcon Explorer, Transação L2 (transferência forçada do Arbitrum): https://app.blocksec.com/phalcon/explorer/tx/arbitrum/0x5618044241dade84af6c41b7d84496dc9823700f98b79751e257608dac570f6b

[6] Arbitrum, "Security Council Emergency Action": https://x.com/arbitrum/status/2046435443680346189

[7] Fórum de Governança do Arbitrum, "Security Council Emergency Action 21/04/2026": https://forum.arbitrum.foundation/t/security-council-emergency-action-21-04-2026/30803

[8] Aave, atualizações sobre o incidente rsETH (19-21 de abril de 2026): https://x.com/aave/status/2045593585966252377

[9] BlockSec Phalcon, "Arbitrum Security Council freeze analysis": https://x.com/Phalcon_xyz/status/2046467830498173088

[10] banteg, "Kelp rsETH Unichain → Ethereum Path Investigation": https://gist.github.com/banteg/705d0284513b74ad20f61d90f5b5de62

[11] MetaSleuth, rastreamento do exploit KelpDAO: https://metasleuth.io/result/eth/0x1ae232da212c45f35c1525f851e4c41d529bf18af862d9ce9fd40bf709db4222?source=600c61cd-f0cd-4dff-8687-14e02f6ccd24