Falha de Resolução de USR Não É Um Erro - É Uma Funcionalidade

A exploração do USR pelo Resolv não foi uma “falha” — mas sim um funcionamento correto conforme foi projetado. E exatamente isso é o maior problema.

Quando o “design” se torna uma vulnerabilidade A forma de criar USR é extremamente simples: Usuário envia USDC para o contrato Um serviço off-chain (que possui a chave privada privilegiada) decide quanto USR criar O contrato inteligente apenas verifica o mínimo, não há máximo Não há limite na proporção de garantia Não há limite máximo Em outras palavras: quem controla a chave pode criar quantos USR quiser Você pode enviar 1 USD… e, teoricamente, criar bilhões de USR. Esse design existe desde o início. Não é uma falha. Não é um erro de código. É uma suposição: 👉 “A chave nunca será comprometida.” E então o que era impossível aconteceu A chave foi comprometida. O cenário de ataque foi extremamente “limpo”: Atacante depositou cerca de 200K USDC em duas transações Usou a chave para criar 80 milhões de USR sem garantia Vendeu imediatamente em DEXs Recebeu aproximadamente 23 milhões de USD em ETH Não foi necessário explorar lógica. Não foi preciso burlar o contrato. Bastou… usar o direito correto. Ponto único de falha — o pesadelo familiar Todo o sistema depende de uma única chave privada: Sem multisig Sem timelock Sem limite de criação Sem verificação on-chain da proporção de garantia => Uma vez que a chave é comprometida = uma máquina de imprimir dinheiro infinita é ativada Isso não é mais uma questão técnica. É uma questão de arquitetura do sistema. “Code is law” — mas essa lei é extremamente perigosa O mais assustador não é a perda de 23 milhões de USD. Mas: 👉 O contrato funcionou perfeitamente 👉 Nenhuma linha de código estava “errada” 👉 Não havia bugs para corrigir E mesmo assim, o sistema colapsou. Isso revela uma verdade que o DeFi muitas vezes ignora: Um sistema não precisa de bugs para falhar. Basta um design errado do threat model. Grande lição: Não confie em coisas que não estão on-chain O que aconteceu com o USR é um forte lembrete: Autoridade off-chain = risco não verificável Chave privada ≠ trustless “Vamos manter a chave segura” não é um modelo de segurança Um sistema DeFi de verdade precisa de: Limites claros na cadeia (limite de criação, proporção de garantia) Multisig ou controle distribuído Timelock para ações importantes Mecanismo fail-safe para emergências Conclusão O USR não foi hackeado no sentido tradicional. Ele foi apenas usado exatamente como foi permitido. E aí está o problema: Quando um sistema permite imprimir dinheiro infinito com uma única chave — o ataque não é “se”, mas “quando”. No mundo cripto, às vezes o mais perigoso não são bugs. Mas sim confiar no lugar errado.