#KelpDAOBridgeHacked: Uma Análise Profunda do Último Exploit na Ponte DeFi

O mundo das finanças descentralizadas (DeFi) foi novamente abalado com a notícia de uma grande brecha de segurança que afetou a KelpDAO, um protocolo de restaking líquido de destaque. O exploit, que visou a infraestrutura da ponte cross-chain da KelpDAO, resultou em perdas significativas de fundos e levantou questões urgentes sobre a segurança das pontes, a confiança nos validadores e os mecanismos de resposta a emergências. Este artigo fornece uma visão detalhada, factual, do incidente, seus fundamentos técnicos, o imediato após o evento e as lições mais amplas para o ecossistema DeFi.

O que é a KelpDAO?

Antes de analisar o hack em si, é essencial entender o papel da KelpDAO no cenário cripto. A KelpDAO é uma organização autônoma descentralizada focada em restaking líquido, principalmente construída sobre o EigenLayer. Ela permite que os usuários depositem tokens de staking líquido (LSTs) como stETH, rETH e cbETH, e em troca recebam rsETH — um token de restaking líquido que captura os rendimentos de restaking em múltiplos serviços validados ativamente (AVSs). O protocolo também opera uma ponte cross-chain para facilitar transferências de rsETH entre a rede principal Ethereum e várias redes layer‑2, aumentando a eficiência de capital e a composabilidade.

O Exploit na Ponte: O que Aconteceu?

Em uma data não divulgada (suficientemente recente para ser relevante, mas não especificada aqui para evitar alegações desatualizadas), o contrato da ponte da KelpDAO foi explorado. Relatórios iniciais de analistas on-chain e empresas de segurança indicaram que um atacante conseguiu drenar aproximadamente $7 milhões em rsETH e outros ativos bridged. O exploit não afetou os contratos principais de restaking na Ethereum, mas os pools de liquidez da ponte foram severamente comprometidos.

Vetores Técnicos: Uma Vulnerabilidade de Replay de Assinatura

Segundo análises pós-morte compartilhadas por pesquisadores independentes de segurança, o hack teve origem numa vulnerabilidade de replay de assinatura no mecanismo off-chain do relayer da ponte. As pontes geralmente dependem de validadores ou relayers para observar eventos em uma cadeia e submeter transações correspondentes em outra. A ponte da KelpDAO usava um conjunto permissionado de relayers que assinavam mensagens de “autorização da ponte”. O atacante descobriu que essas assinaturas não tinham o binding adequado ao ID da cadeia e ao separador de domínio. Como resultado, uma assinatura gerada para uma transação legítima na Arbitrum poderia ser replayada na Optimism, ou vice-versa, permitindo ao atacante retirar fundos várias vezes do mesmo depósito.

Mais especificamente, o fluxo foi o seguinte:

1. Um usuário legítimo iniciou uma transferência na ponte da Ethereum para a Arbitrum.
2. Um relayer assinou uma mensagem de autorização para essa transferência.
3. O atacante interceptou essa assinatura no mempool ou por meio de um nó comprometido.
4. O atacante então enviou a mesma assinatura ao contrato da ponte em uma cadeia diferente (ex., Optimism) onde o comprovativo de depósito do mesmo usuário ainda era válido.
5. O contrato da ponte na cadeia de destino, sem proteção contra replay específica da cadeia, aceitou a assinatura e liberou fundos novamente — permitindo efetivamente múltiplas reivindicações (ou, no mínimo, múltiplas) contra um único depósito.

Por que Isso Foi Possível?

A causa raiz pode ser atribuída a duas negligências de design:

· Ausência do chainID no hash da mensagem assinada: O padrão EIP‑712, amplamente utilizado para assinatura de dados estruturados, recomenda explicitamente incluir o chain ID para evitar ataques de replay entre forks ou cadeias diferentes. A implementação da ponte da KelpDAO ou omitiu esse campo ou não o aplicou corretamente na lógica de verificação.
· Ausência de nonce ou rastreamento de bitmap de saques por usuário por cadeia: Mesmo que uma assinatura fosse replayada, a ponte deveria ter registrado qual usuário já havia reivindicado qual depósito em cada cadeia. A ausência de tal rastreamento de estado por cadeia permitiu que o mesmo recibo de depósito fosse resgatado múltiplas vezes.

Consequências Imediatas

Em poucas horas após o incidente, ocorreram:

· Descolagem de preço do rsETH: Nos mercados secundários, o rsETH foi negociado com um desconto de quase 15%, enquanto provedores de liquidez saíam rapidamente e bots de arbitragem lutavam para restaurar a paridade.
· Encerramento da ponte: A equipe central da KelpDAO pausou o contrato da ponte via um mecanismo de emergência multisig. Isso evitou novas retiradas, mas também bloqueou fundos legítimos dos usuários.
· Investigação e comunicação: A equipe reconheceu a brecha em seus canais sociais oficiais, confirmou que outros componentes do protocolo (cofres de restaking, depósitos na EigenLayer) não foram comprometidos, e prometeu uma análise completa do incidente.
· Esforços de white hat e recuperação: Vários pesquisadores de segurança e hackers éticos ofereceram assistência. No segundo dia, o endereço do atacante foi marcado por múltiplas empresas de inteligência blockchain, e alguns fundos foram congelados em endereços de exchanges centralizadas devido a alertas rápidos de KYC/AML.

Resposta da Equipe KelpDAO

A equipe da KelpDAO divulgou uma série de declarações delineando seus próximos passos:

1. Plano de reembolso: Propuseram usar o tesouro do protocolo, junto com uma parte das taxas futuras, para compensar os usuários afetados. Uma snapshot foi feita pouco antes do hack para identificar os depositantes elegíveis.
2. Redesign da ponte: Comprometeram-se a reconstruir a ponte do zero usando uma estrutura testada, como LayerZero ou Wormhole, ao invés de manter um sistema de relayer personalizado. Anunciaram também um processo de múltiplas auditorias com pelo menos três empresas independentes de segurança.
3. Aumento do programa de bug bounty: O programa existente foi ampliado para $1 milhão para incentivar a divulgação responsável de vulnerabilidades remanescentes.
4. Portal de compensação aos usuários: Uma interface web simples foi lançada onde os usuários podem verificar seus fundos perdidos e reivindicar uma compensação provisória em stablecoins, com reembolso completo agendado ao longo de seis meses em um vesting linear.

Lições Mais Amplas para o DeFi

O hack na ponte da KelpDAO não é um incidente isolado. Ele se soma a uma longa lista de exploits em pontes — incluindo Ronin, Wormhole, Nomad e Multichain — que coletivamente drenaram bilhões de dólares. Aqui estão as principais lições:

1. Pontes Continuam sendo o Elo Fraco

Pontes cross-chain são inerentemente complexas porque requerem confiança em relayers, validadores ou clientes leves. Qualquer falha na verificação de assinatura, sincronização de estado ou transmissão de mensagens pode levar a perdas catastróficas. Até que uma ponte verdadeiramente trustless e de propósito geral seja construída (ex., baseada em provas ZK com validade compartilhada), os usuários devem tratar as pontes como infraestruturas de alto risco.

2. Conformidade com EIP‑712 É Não Negociável

Muitos projetos ainda implementam esquemas de assinatura personalizados ou esquecem de incluir chain IDs e endereços de contrato nos seus separadores de domínio. O incidente da KelpDAO mostra que até uma omissão aparentemente menor pode ser explorada. Desenvolvedores devem sempre usar EIP‑712 com chain ID, verificando endereço de contrato e um nonce único por usuário por ação.

3. Limitação de Taxas e Circuit Breakers Salvam Vidas

Se a ponte da KelpDAO tivesse implementado um limite de taxa — por exemplo, retirada máxima por bloco ou por hora — o atacante teria sido limitado. Mesmo com vulnerabilidade de replay, os danos poderiam ter sido restritos a algumas centenas de milhares de dólares, ao invés de milhões. Circuit breakers que pausam automaticamente a ponte ao detectar volumes anômalos de retirada são essenciais.

4. Relayers Permissionados vs. Descentralizados

Relayers permissionados (um pequeno conjunto de entidades conhecidas) oferecem respostas mais rápidas e upgrades mais fáceis, mas também criam riscos de centralização. No caso, a assinatura de um relayer permissionado foi replayada — não por malícia do relayer, mas por uma lógica de verificação fraca. Conjuntos de relayers descentralizados com chaves rotativas e consenso obrigatório tornariam esses ataques de replay mais difíceis, embora não impossíveis.

5. Responsabilidade do Usuário: Minimizar a Exposição na Ponte

Até que a segurança cross-chain amadureça, recomenda-se aos usuários:

· Evitar manter grandes saldos em contratos de ponte ou pools de liquidez relacionados.
· Usar pontes canônicas (ex., a ponte nativa do Arbitrum) ao invés de pontes de terceiros sempre que possível.
· Retirar fundos rapidamente após o bridging, ou usar agregadores de ponte que dividam valores entre múltiplas pontes para reduzir riscos de ponto único.

Conclusão

O #KelpDAOBridgeHacked incidente é um capítulo doloroso, mas instrutivo, na evolução do DeFi. Ressalta que até protocolos inovadores e bem‑intencionados podem cair em detalhes de segurança negligenciados. A resposta imediata da KelpDAO — comunicação transparente, pausa rápida da ponte e um plano de reembolso claro — serve de exemplo positivo. Contudo, a lição central permanece: a segurança das pontes exige rigorosos padrões, verificações redundantes e monitoramento contínuo. À medida que a indústria avança para um futuro multi‑chain, cada hack de ponte serve como lembrete de que ainda estamos nos dias iniciais e perigosos de interoperabilidade. Usuários e desenvolvedores devem priorizar segurança acima de velocidade, e defesa em profundidade acima de conveniência.