Contexto da Resolv e do design da stablecoin USR
O cenário atual das stablecoins DeFi pode ser segmentado em três grandes categorias: reservas lastreadas em moeda fiduciária, como USDC; modelos supercolateralizados, como MakerDAO; e o surgimento mais recente das chamadas “stablecoins estruturadas”. O USR da Resolv se enquadra nesta terceira categoria, buscando aprimorar a eficiência de capital sem abrir mão da estabilidade de preço.
O USR não adota um modelo de colateral único. Em vez disso, combina estratégias de hedge com mecanismos de segmentação de risco. Por exemplo, o protocolo normalmente mantém a estabilidade do valor patrimonial líquido realizando hedge de ETH ou outros ativos voláteis e implementa estruturas de “pool de risco”, nas quais participantes específicos absorvem as perdas primeiro em eventos extremos. Em teoria, essa abordagem eleva o aproveitamento do capital, mas também faz com que o sistema deixe de ser um ciclo totalmente autônomo on-chain, passando a depender da operação coordenada de múltiplos componentes.
Essa combinação de “estrutura multinível e dependências externas” torna o sistema mais eficiente em condições normais de mercado, mas também aumenta sua exposição a riscos sistêmicos em situações adversas.
Revisão completa do ataque: do mint ao resgate
A análise das atividades on-chain mostra que o ataque ao Resolv foi altamente estruturado, seguindo um padrão clássico: “mint sem colateral → extração de liquidez → transferência de valor”.
Fonte: Arkham
O invasor entrou no sistema com aproximadamente 100.000 USDC como capital inicial, burlou mecanismos críticos de verificação e cunhou diretamente cerca de 50 milhões de USR. Esse foi o núcleo do ataque, já que o sistema permitiu erroneamente a emissão em larga escala de stablecoins sem colateral suficiente, criando artificialmente uma enorme “liquidez não lastreada”.
Após o mint inicial, o invasor não liquidou todos os ativos de imediato. Em vez disso, cerca de 35 milhões de USR foram convertidos em wstUSR. Essa etapa alterou o formato do ativo, facilitando sua entrada em diferentes cenários de liquidez ou a superação de determinadas restrições, além de aumentar a eficiência dos resgates subsequentes.
Na sequência, o invasor trocou sistematicamente wstUSR por USDC e USDT, retirando gradualmente ativos reais dos pools de liquidez de stablecoins. Durante essa fase, o criador de mercado automatizado (AMM) absorveu passivamente a pressão de venda, esgotando os ativos de qualidade do pool e provocando uma queda acentuada no preço do USR—um exemplo clássico de corrida de liquidez.
Após converter os stablecoins em dinheiro, o invasor ainda trocou parte do USDT por ETH, acumulando cerca de US$ 4,55 milhões em ETH. Essa movimentação transferiu os ativos para tokens mainstream mais líquidos e menos sujeitos a congelamentos, preservando o valor e isolando o risco.
Análise da vulnerabilidade central: dissecando o mecanismo de confiança do sistema
Esse incidente difere dos exploits DeFi tradicionais, que geralmente exploram vulnerabilidades de código em contratos inteligentes. Em vez disso, trata-se de uma violação no ponto de entrada de confiança do sistema.
Muitos protocolos DeFi modernos dependem de mais do que apenas lógica on-chain para operações críticas como mint, liquidação ou ajustes de parâmetros. São introduzidas camadas adicionais de verificação—autorização por assinatura, serviços de backend ou dados de oráculos. Esses componentes formam um “modelo de confiança estendido”. Se qualquer elo for comprometido, mesmo a lógica on-chain rigorosa pode produzir resultados incorretos.
Com base na natureza desse ataque, é razoável supor que o problema tenha ocorrido por um dos seguintes motivos: bypass de controles de assinatura ou permissão, falha da lógica de verificação em determinadas condições ou manipulação de fontes de dados off-chain. Em todos os casos, o erro comum foi o sistema reconhecer erroneamente um “estado sem colateral” como “estado legítimo”.
Esse tipo de vulnerabilidade é particularmente perigoso porque dificilmente é detectado em auditorias de código. Depende, na verdade, do rigor da arquitetura geral do sistema.
O processo de perda do peg: como a liquidez foi rapidamente drenada
Em sistemas de stablecoin, a manutenção do peg depende não apenas de mecanismos teóricos, mas da estrutura real do mercado. Quando um grande volume de ativos sem valor entra no sistema, normalmente é a liquidez—e não a lógica do protocolo—que colapsa primeiro.
O processo de descolamento do USR seguiu esse padrão. Quando 80 milhões de tokens sem colateral entraram no pool de liquidez, o mercado rapidamente se desequilibrou: arbitradores e atacantes venderam USR continuamente enquanto USDC e USDT eram retirados do pool. Como os AMMs utilizam precificação baseada na razão de ativos, a venda unilateral rapidamente derrubou o preço do USR.
Vários fenômenos clássicos foram observados: o preço caiu de quase US$ 1 para níveis extremamente baixos em pouco tempo, os ativos de qualidade do pool foram rapidamente esgotados e o slippage das negociações aumentou significativamente. Em conjunto, esses fatores tornaram ineficazes quaisquer mecanismos de correção por arbitragem, levando o preço ao colapso.
Assim, o chamado “peg estável” fracassou, pois a condição essencial para sua manutenção—liquidez ampla e saudável—já havia sido destruída.
Estrutura das perdas: como o risco se propagou pelo sistema
Uma característica marcante desse evento é que as perdas não ficaram concentradas em um único agente, mas se espalharam camada por camada pela estrutura DeFi. Os provedores de liquidez foram os primeiros atingidos, pois seus USDC e USDT foram retirados dos pools em troca de USR em rápida depreciação. Detentores de stablecoin também sofreram diretamente com a queda de preço, reduzindo o valor de seus portfólios.
Ao mesmo tempo, usuários de mercados de empréstimo foram impactados. Quando USR foi utilizado como colateral ou em pares de negociação, a volatilidade de preço acionou mecanismos de liquidação, forçando alguns usuários a fechar posições. Em algumas arquiteturas, pools de risco ou mecanismos de seguro são projetados para absorver choques, mas sob estresse extremo, essas estruturas geralmente não conseguem cobrir todas as perdas.
No geral, a transmissão de risco apresentou uma clara “reação em cadeia”: uma falha em um elo rapidamente escalou para um problema sistêmico.
Repensando mecanismos de stablecoin: equilibrando eficiência e segurança
O incidente do USR da Resolv evidencia um dilema recorrente: o equilíbrio entre eficiência e segurança no design de stablecoins. Para aumentar a eficiência de capital, mais projetos têm reduzido índices de colateral, introduzido estratégias de hedge ou adotado estruturas sofisticadas. Contudo, tais otimizações elevam a complexidade do sistema.
Maior complexidade amplia as superfícies potenciais de ataque, incluindo gestão de permissões, fontes de dados e caminhos de execução. Sem redundância e proteção suficientes, o sistema se torna vulnerável a eventos extremos. Designs que dependem fortemente de liquidez tornam a confiança do mercado um fator crítico. Quando a confiança vacila, mecanismos de estabilização de preço têm dificuldade de atuar de forma autônoma.
Nesse contexto, confiar apenas em “modelos avançados” não resolve esses desafios e pode, inclusive, introduzir novos riscos caso não sejam devidamente validados.
Conclusão: stablecoins DeFi entram em uma fase de risco de alta complexidade
Em suma, o ataque ao USR não é um caso isolado, mas um marco na evolução das stablecoins DeFi. O setor está migrando do “risco de modelo simples” para o “risco de sistema complexo”, com vetores de ataque passando de vulnerabilidades individuais em contratos para brechas estruturais multinível. Os atacantes exploraram o mecanismo de confiança do sistema para cunhar tokens sem colateral e extrair valor pelos mercados de liquidez. Esse processo resultou tanto em perdas econômicas diretas quanto em um abalo significativo na confiança do mercado.
Para o desenvolvimento futuro de stablecoins, esse episódio serve como alerta: na busca por eficiência e inovação, é fundamental reavaliar os limites do sistema e as premissas de confiança. Apenas com redundâncias robustas de segurança e mecanismos de isolamento em nível arquitetural será possível garantir estabilidade real em ambientes complexos.
