Lições de mil milhões de dólares: O foco da segurança DeFi está a mudar do código para a gestão operacional

Original text compiled by: 登链社区

Resumo do conteúdo e introdução:

Nos últimos doze meses, quase 1 bilhão de dólares foram perdidos em DeFi, e as verdadeiras perdas de grande valor não vêm mais principalmente de vulnerabilidades no código do contrato inteligente, mas de riscos relacionados à gestão de permissões, fluxo de assinaturas, ataques de engenharia social, infraestrutura de terceiros e riscos de interoperabilidade cross-chain. Aprendendo com a resiliência operacional do TradFi, as três linhas de defesa, congelamentos de emergência, governança de dados de risco e auditoria de entrada de ativos, combinados com análises de segurança assistidas por IA, são essenciais para manter a abertura e a composabilidade, ao mesmo tempo em que elevam a segurança dos fundos dos usuários.

Nós não precisaríamos ter perdido bilhões de dólares

Nos últimos doze meses, quase 1 bilhão de dólares foram perdidos devido a acidentes em DeFi, mas a maior parte poderia ter sido evitada.

Começando pelo exploit mais recente: 18 de abril, exploit de 292 milhões de dólares na Kelp DAO.

AAVE caiu 15%. Aave congelou o mercado rsETH em todas as implantações, e posteriormente congelou o empréstimo de WETH por precaução. Os contratos do próprio Aave nunca foram explorados, mas em poucas horas, a utilização do mercado WETH atingiu 100%. Fornecedores de WETH que nunca tinham interagido com rsETH de repente não podiam mais retirar fundos.

Depois veio a visão comum no crypto twitter: Bridge quebrado. DeFi quebrado. É por isso que fundos reais não entram.

Acredito que essas opiniões não capturam o ponto principal.

A maior parte dessas perdas de 1 bilhão de dólares decorreu de vetores de ataque já discutidos e com soluções conhecidas. As maiores perdas são impulsionadas por acessos privilegiados, fluxos de assinatura, engenharia social e infraestrutura de terceiros, e não por bugs isolados em contratos inteligentes. Contudo, essas soluções de correção não estão na documentação do DeFi, mas nos manuais de controle de risco bancário, estudos de resiliência de engenharia e nos playbooks operacionais que o TradFi aprimorou ao longo de décadas.

Kelp é o exemplo mais claro.

Um verificador. Um ponto de falha.

O exploit na Kelp não foi causado por um bug no contrato inteligente. A causa raiz foi a configuração do DVN (rede de validadores descentralizados) no LayerZero bridge, que optou por uma configuração 1-de-1. Segundo relatos, atacantes ligados ao Lazarus Group, grupo de crimes cibernéticos da Coreia do Norte, não invadiram o DVN em si. Primeiro, identificaram quais provedores RPC o DVN dependia. Depois, comprometeram dois deles, fazendo-os retornar dados falsificados. Em seguida, lançaram ataques DDoS nos demais provedores, forçando o sistema a fazer failover para os já comprometidos. O DVN assinou uma mensagem cross-chain falsa sob premissa de boa fé — e, sem outros verificadores para validar o resultado, essa assinatura foi suficiente.

Um verificador. Um ponto de falha.

116.500 rsETH foram liberados do LayerZero OFT Adapter (que gerencia tokens cross-chain) para os atacantes, deixando sem lastro os tokens rsETH em 16 camadas de L2. Os atacantes colocaram rsETH do lado Ethereum como garantia em Aave, Compound e Euler, e assim emprestaram 236 milhões de dólares em WETH, até que alguém descobriu. Agora, todos que possuem rsETH em alguma L2 têm apenas uma reivindicação contra um cofre esvaziado.

Esse risco claro foi marcado há doze dias.

6 de abril, engenheira @liliangjya5, da @get_truenorth, publicou uma skill de código aberto Claude, apontando a configuração opaca do DVN como maior vetor de risco, comparando as 16 chains com o exploit do Ronin e Harmony de 2022. O timestamp do commit é público — qualquer um pode ver.

[]

A Kelp nunca revelou seu limiar de DVN. LayerZero recomenda explicitamente o uso de configurações multi-DVN na checklist de integração. A Kelp escolheu ainda assim uma configuração 1-de-1. Ninguém os obrigou a divulgar ou modificar.

Doze dias depois, 292 milhões de dólares sumiram.

Os últimos doze meses não invalidam o DeFi

O exploit na Kelp foi o maior, mas não o único.

• Há duas semanas, em 1 de abril, o Drift perdeu 285 milhões de dólares após meses de ataque de engenharia social. Os atacantes usaram nonces duráveis do Solana para obter assinaturas válidas de administradores, whitelistaram um token sem valor como garantia e, com isso, esvaziaram ativos reais. Pelo menos outros 20 protocolos relataram impactos. O próprio Drift, após a reconstrução, adotou dispositivos de assinatura dedicados, timelock para ações administrativas e uma governança multisig reconstruída.

• Em 22 de março, o Resolv foi alvo de ataque via infraestrutura offchain. Os invasores acessaram o GitHub e o ambiente cloud de terceiros, obtendo permissões de assinatura no processo de minting, criando 80 milhões de USR sem lastro e roubando 25 milhões de dólares em ETH. O contrato inteligente permaneceu intacto; a vulnerabilidade estava nas chaves privilegiadas e na pilha operacional ao redor.

• Em 10 de março, a ferramenta de risco do Aave disparou uma liquidação de aproximadamente 26 milhões de dólares, envolvendo 34 contas, após uma discrepância na configuração de dois oráculos de paridade, fazendo o preço do wstETH cair 2,85%. Nesse caso, não houve ator malicioso nem exploit. A perda decorreu de uma atualização de configuração de boa fé, que não foi testada sob cenários hostis.

• Antes de 2026, também tivemos perdas na Cetus na Sui (2,23 bilhões de dólares), na Cork (1,2 milhão de dólares após múltiplas auditorias por wstETH), na Balancer (mais de 1,2 bilhão de dólares em novembro) e na Aerodrome (não por exploit de contrato, mas por DNS hijack do registrador, com perdas superiores a 100 mil dólares). Reforçando: os contratos não foram comprometidos. Um phishing finalizou o golpe.

Somando tudo, quase 1 bilhão de dólares em perdas. Cada acidente tem causas distintas, mas um padrão está se formando.

Esses exploits migraram para offchain

O risco de contratos inteligentes não desapareceu — Cetus, Cork e Balancer tiveram falhas reais de lógica onchain. Protocolos que ainda consideram testes de invariantes, simulações adversariais e métodos formais como opcionais aprenderão a lição na próxima versão. Mas isso já não é o foco principal.

No universo cripto, a Chainalysis estima que, até 2025, mais de 6,5 bilhões de dólares serão roubados, sendo que os três maiores hacks representam 69% dessas perdas. Como mencionado, as maiores perdas vêm de acessos privilegiados, fluxos de assinatura, engenharia social e infraestrutura de terceiros, e não de bugs isolados em contratos.

Vejo isso como três modos distintos de falha: Camada de Código, Plano de Controle, Composabilidade.

2. Código é a camada na qual o DeFi é mais competente na defesa, mas ainda assim não totalmente resolvida. Temos fuzzing, análise estática e dinâmica, verificação formal, bug bounty, auditorias, testes de invariantes — hoje, qualquer equipe séria sabe como fazer isso.

3. Plano de Controle é a área onde DeFi ainda fica atrás do TradFi em pelo menos uma década. Dispositivos de assinatura, rotação de chaves, revisão de privilégios, proveniência de CI/CD, hardening de DNS, segurança de registradores. A maioria dos protocolos nem possui inventário dessas superfícies, quanto mais controle sobre elas.

4. Composabilidade, embora seja uma das maiores forças do DeFi, traz riscos recentes e subestimados — quando um mercado de empréstimos lista um ativo wrapped, ele transforma o modo de falha do bridge em seu próprio modo de falha. Quando uma posição de dívida colateralizada aceita um token de staking líquido, ela herda a latência de governança do emissor. Aave não escreveu uma linha de código do Kelp, mas sofreu os danos de sua falha — expondo também problemas de governança próprios.

Se um protocolo lista um colateral que não consegue avaliar, congelar, aplicar haircut ou liquidar de forma independente sob pressão, ele está, na prática, assumindo o tail risk desse ativo na sua própria balança, independentemente de a tesouraria ter ou não aprovação.

TradFi já tem playbook

Sobre a discussão de tornar o DeFi “mais parecido com o TradFi”, ela costuma se desviar na mesma direção. No cripto, a intuição é que ficar mais parecido com o TradFi significa mais lento, mais custodial, mais permissioned, mais regulado.

[]

Acredito que isso está errado.

Embora o TradFi não seja perfeito, criou mecanismos muito mais úteis que permissioning. Desenvolveu formas de operar sistemas críticos durante disrupções — esses frameworks já existem. Foram testados em crises bancárias, interrupções de mercado, ataques cibernéticos e acidentes operacionais ao longo de décadas.

Exemplos relevantes:

• NIST Cybersecurity Framework 2.0 eleva o Govern a uma das funções centrais, ao lado de Identify, Protect, Detect, Respond e Recover.

• Basel Committee on Banking Supervision define resiliência operacional como a capacidade de entregar operações críticas durante disrupções.

• FCA (Financial Conduct Authority do Reino Unido) exige que as empresas identifiquem serviços essenciais, estabeleçam tolerâncias de impacto e testem se as disrupções ultrapassam esses limites.

• Institute of Internal Auditors, por meio do modelo Three Lines, separa gestão, desafio de risco e garantia independente.

Tudo isso não requer ativos ou permissões do TradFi. Pode ser transplantado para o DeFi. Segurança no DeFi não significa virar um banco, mas sim manter a abertura e a composabilidade ao mesmo tempo em que se adota disciplina bancária na camada de controle.

Quando Lazarus atacou provedores RPC do LayerZero, usou o mesmo playbook de ataques a SWIFT e supply chain de software corporativo. O TradFi tem trinta anos de experiência nisso. Mas o DeFi parece achar que sua história não serve de lição.

Poder de privilégio é uma utilidade de importância sistêmica

Privilégio deve ser mais difícil de usar do que funções normais do protocolo. Chaves, multisigs ou contas de serviço capazes de listar colaterais, mover reservas, atualizar oráculos, alterar peers do bridge ou modificar lógica de liquidação são utilidades financeiras de importância sistêmica. O mínimo:

• Hardware wallets

• Autenticação anti-phishing

• Máquinas de assinatura independentes

• Decodificação de transações fora de banda

• Separação de quórum

• Timelock para todas as operações não emergenciais

• Rejeição explícita de funcionalidades que possam futuramente ser usadas para signatures ociosas e armadilhadas

A reconstrução pós-acidente da Drift é um bom padrão mínimo.

A pilha offchain também faz parte do protocolo. Gestão de código fonte, CI/CD, IAM na nuvem, repositórios de pacotes, domínios, DNS, surface WalletConnect e front-end entregue via navegador estão na fronteira de ameaças reais. Normas de engenharia incluem acesso com privilégios mínimos, identidade suportada por hardware, deploy sem secrets, builds reprodutíveis com software bill of materials, dependências fixadas. Na fronteira, bloqueios de registrador, hardening de DNS e front-end descentralizado podem garantir continuidade durante acidentes.

O hijack de DNS na Aerodrome nos lembra que a fronteira é maior do que a maioria imagina.

Cada mudança deve ser testada sob cenários hostis. Verificadores cross-chain devem checar provas, não atestações. Bridges canônicos verificam merkle proofs de headers assinados — uma garantia criptográfica: nodes comprometidos podem recusar fornecer dados, mas não falsificá-los. Verificação de provas é mais forte que atestações, mas bridges baseados em provas ainda carregam riscos de consenso, implementação e upgrade. O que essa arquitetura exclui e o que mantém?

Verificadores baseados em atestação não oferecem as mesmas garantias. Eles assinam qualquer dado retornado por endpoints RPC, ampliando a superfície de ataque. Se usar atestação por velocidade ou compatibilidade, o quórum representa independência, não quantidade. Cinco validadores que leem o mesmo RPC envenenado assinam a mesma mentira cinco vezes. Só há segurança real quando os membros do quórum têm fontes de dados verdadeiramente independentes, idealmente combinando nós privados e públicos confiáveis. Kelp é o resultado de atacantes sofisticados explorando essa vulnerabilidade.

Nem todo colateral deve entrar na balança compartilhada. Ativos de bridge, tokens de restaking líquido, shares de vault, dólares sintéticos e tokens wrapped devem ser considerados produtos estruturados. Precisam de um onboarding separado, com riscos detalhados e limites conservadores. Na maioria dos casos, devem operar em mercados isolados, não em pools centrais compartilhados.

Aave já suspendeu rsETH em abril de 2025 por causa de um bug de over-minting na Kelp. Um ano depois, rsETH voltou ao mercado compartilhado — e isso merece uma análise mais rigorosa.

Detecção e resposta devem operar em velocidade de máquina. Quando um protocolo pode ser esvaziado em minutos, a intervenção manual é teatro de governança. Automação limitada é o padrão: monitorar operações administrativas, eventos de mint e burn, uso excessivo, desvios de oráculos e tráfego de bridges, usando limites de taxa, throttling de empréstimos, e triggers pré-definidos com revisão governamental posterior, com escopo restrito e auto-freeze.

Precisamos priorizar a segurança dos fundos dos usuários. Pequenas inconveniências causadas por automações ocasionalmente acionadas são muito menores do que o custo de não tê-las desde o início.

Governança deve definir o que não pode falhar

Para ajudar as equipes a estabelecerem metas de segurança, a governança deve definir o que é absolutamente inaceitável. Conselhos, fundações ou DAOs devem listar claramente seus serviços essenciais: depósitos e retiradas, liquidações, atualizações de oráculos, execução de governança, entradas e saídas de bridges, acesso ao front-end, comunicação de incidentes.

Para cada um, deve-se estabelecer uma tolerância de impacto, incluindo dano máximo ao usuário, perdas de solvência, tempo de inatividade e incerteza de dados, e testar se esses limites permanecem válidos em cenários severos, porém razoáveis.

Isso é o que significa resiliência operacional no setor bancário, e pode ser diretamente transplantado para o DeFi.

DeFi deve adotar um modelo de Three Lines verdadeiro:

• Primeira linha: produto, engenharia, tesouraria e operações são responsáveis pelos riscos que criam e pelos controles de mitigação.

• Segunda linha: funções independentes de risco e segurança têm autoridade clara para desafiar listagens, parâmetros, upgrades e contrapartes, e podem retardar ou bloquear mudanças inseguras.

• Terceira linha: auditoria independente fornece relatórios sobre a efetividade da primeira e segunda linhas.

Independência é a forma de evitar que incentivos de crescimento levem a autoavaliações.

A entrada de ativos deve ser mais parecida com uma análise de crédito do que com desenvolvimento de negócios. O memorando de listing deve cobrir liquidez, concentração, centralização de governança, caminhos de bridge e capacidade de upgrade, mecanismos de resgate, circuit breakers, construção de oráculos e aspectos legais. Se qualquer hipótese for quebrada, o memorando deve ter um procedimento de downgrade claro.

Permissões de emergência devem ser restritas, bem definidas e com sunset programado. Os votos de recuperação de Cetus e Sui mostram dois aspectos dessa questão — intervenções emergenciais podem salvar centenas de milhões de dólares. Mas também levantam uma questão séria: quem pode atuar para cobrir sistemas teoricamente inquebráveis, e com base em quê? A resposta é: antes do lançamento, com condições de gatilho, atores autorizados, critérios de evidência, duração máxima, transparência e planos de retorno à governança normal.

Cada protocolo deve ter um plano de resolução preparado antes da crise. Drift está formando um recovery pool pós-evento. Aave está compensando usuários após o descompasso de oráculos. Resolv reembolsou 1:1 os detentores antes do hack. Essas são respostas razoáveis, mas o padrão mais elevado é uma autorização prévia de waterfall: proteção ao usuário, reserva na tesouraria, seguro ou módulo de segurança, responsabilidade do provedor de serviços, e limites claros para perdas socializadas.

Diferenciar protocolos que levam a sério a governança daqueles que não levam é uma questão de três perguntas: quem pode impedir um lançamento inseguro? quem pode congelar o mercado sob condições predefinidas? e quem paga quando um provedor delegado causa perdas?

Um protocolo que não consegue definir quem, quando e como acionar, não tem uma governança bem estabelecida — apenas espera que o exploit nunca aconteça.

Dados de risco definem o sucesso ou fracasso das medidas de controle

DeFi seguro precisa de um data plane vivo: sinais onchain e offchain que acionam freeze, cap e liquidação. O control plane age, o data plane informa se deve agir.

Padrões de dados e sua qualidade são essenciais. Dados de oráculos, freeze e parâmetros devem ter janela de atualização, proveniência registrada, pontuação de confiança e validação cruzada com feeds independentes. Quando há divergências, comportamentos de fallback devem estar pré-definidos, não decididos na hora.

Aave propôs oráculos gerenciados por risco para USDe, e seu oráculo Slope2 ponderado por tempo aponta na direção certa. O evento do wstETH nos lembra que cada ciclo de controle automatizado precisa de limites para evitar erros de configuração.

A transparência é uma forma de controle. Usuários devem ter páginas de status públicas, listas de endereços de atacantes, logs de incidentes em tempo real, declarações iniciais rápidas e factuais, além de uma análise pós-morte que diferencie fatos de hipóteses, quantifique perdas, liste controles alterados e explique caminhos de compensação. As atualizações de recuperação do Drift, os relatórios pós-morte do Resolv e as explicações do oráculo do Aave são muito melhores do que os comunicados vagos e silenciosos do passado. O padrão da indústria deve ser um playbook de comunicação praticado antes de crises.

Dados de risco existem para impulsionar ações. Limitar empréstimos, reduzir caps, pausar mercados, atualizar manualmente, provar que um mercado pode continuar seguro — esses são exemplos de ações acionáveis. Análises que não alimentam o control, limit ou assurance não merecem o nome de infraestrutura de risco.

Modelo de ameaça de IA já mudou

Em abril de 2026, o modelo de ameaça de IA mudou. Claude Mythos Preview da Anthropic demonstrou ser capaz de identificar e explorar vulnerabilidades zero-day em todos os principais sistemas operacionais e navegadores. Mais de 99% das vulnerabilidades descobertas ainda não foram divulgadas, pois ninguém as corrigiu. Bancos e reguladores do Reino Unido, EUA e Alemanha já consideram capacidades do Mythos como risco cibernético real.

Protocolos DeFi também devem agir assim.

De uma perspectiva prática, spear-phishing fica mais barato, desenvolver exploits é mais rápido, reconhecimento é mais autônomo, e casos de baixa sinalização são detectados mais cedo. As defesas devem incluir:

• Estações de trabalho de desenvolvedores reforçadas como endpoints privilegiados

• Revisões de código com análise adversarial assistida por IA em acesso controlado

• Workflow de assinatura com proteção anti-phishing padrão

• Detecção de anomalias e respostas automáticas limitadas, assumindo que atacantes podem atuar em ritmo mais rápido que equipes humanas

A história do Kelp é uma versão otimista dessa realidade. A mesma capacidade de IA que ameaça protocolos também pode defendê-los. Uma ferramenta de auditoria open source rodando em Claude Code, que identificou riscos exatos do Kelp doze dias antes do ataque, exemplifica isso. A ferramenta não é perfeita: classificou risco como médio, quando deveria ser crítico; não consegue penetrar na configuração sem verificação onchain; e esquece que a configuração DVN pode ser consultada via contratos EndpointV2 do LayerZero.

Porém, ela faz as perguntas certas que outros não fizeram.

Esse deve ser o modelo adotado. IA como camada de segurança independente, qualquer LP, protocolo ou auditor pode agir antes do movimento de fundos.

DeFi seguro não significa DeFi lento

Após o incidente na Kelp, a visão predominante é que DeFi tem problemas de segurança. Acredito que essa visão está equivocada.

DeFi enfrenta problemas na camada de controle, na precificação de composabilidade e na disciplina de governança. Todas essas questões têm soluções conhecidas, muitas delas já descritas em manuais de risco bancário de trinta anos atrás. A única barreira para uma maior segurança é se os fundadores realmente implementarem essas soluções.

DeFi seguro não é sinônimo de lentidão. Slow e safe são atributos diferentes. Acesso aberto ao usuário, composabilidade e liquidação global 24/7; disciplina bancária na camada de controle, challenge independente, velocidade de máquina e garantia contínua — esses podem coexistir.

Ferramentas e playbooks já existem. O capital para um DeFi seguro também.

DeFi está apenas começando. Vamos garantir que ela exista daqui a dez anos.