Ao trocar 200 mil por quase 100 milhões, as stablecoins da DeFi enfrentam mais um ataque

Escrito por: Eric, Foresight News

Por volta das 10h21, horário de Pequim, de hoje, a Resolv Labs, que emite a stablecoin USR utilizando uma estratégia delta neutra, foi vítima de um ataque cibernético. Um endereço que começa com 0x04A2 cunhou 50 milhões de USR a partir do protocolo Resolv Labs utilizando 100.000 USDC.

Assim que o incidente veio à tona, o preço das ações da USR despencou para cerca de US$ 0,25 e, até o momento da redação deste artigo, já havia se recuperado para cerca de US$ 0,8. O preço do token RESOLV também sofreu uma queda temporária de quase 10%.

Posteriormente, o hacker repetiu o procedimento e cunhou novamente 30 milhões de USR utilizando 100.000 USDC. Com a significativa desvinculação do USR, os operadores de arbitragem agiram rapidamente, e muitos mercados de empréstimos na Morpho que aceitam USR, wstUSR e outros tipos de garantias ficaram praticamente esvaziados, enquanto a Lista DAO na BNB Chain também suspendeu novos pedidos de empréstimo.

O impacto não se limita a esses protocolos de empréstimo. Na estrutura do protocolo da Resolv Labs, os usuários também podem cunhar um token RLP mais volátil e com maior rendimento, mas precisam assumir responsabilidades de compensação caso o protocolo venha a incorrer em prejuízos. Atualmente, a circulação de tokens RLP é de quase 30 milhões, sendo que o maior detentor, a Stream Finance, possui mais de 13 milhões de RLP, o que resulta em uma exposição líquida ao risco de cerca de US$ 17 milhões.

De fato, a Stream Finance, que já havia sofrido com o incidente do xUSD, pode ser afetada novamente.

Até o momento da redação deste artigo, o hacker converteu USR em USDC e USDT e continua comprando Ethereum, tendo já adquirido mais de 10.000. Com 200.000 USDC, eles conseguiram obter mais de 20 milhões de dólares em ativos, encontrando sua “moeda que rendeu cem vezes mais” durante o mercado em baixa.

Mais um caso de exploração devido à “falta de rigor”

A forte queda ocorrida em 11 de outubro do ano passado fez com que muitas stablecoins emitidas por meio de estratégias delta-neutras sofressem perdas de garantia devido ao ADL (desalavancagem automática). Alguns projetos que adotaram estratégias envolvendo altcoins sofreram perdas ainda maiores ou entraram diretamente em falência.

A Resolv Labs, que foi alvo do ataque, também emitiu USR utilizando um mecanismo semelhante. O projeto anunciou, em abril de 2025, que havia concluído uma rodada de financiamento inicial de US$ 10 milhões liderada pela Cyber.Fund e pela Maven11, com a participação da Coinbase Ventures, e lançou o token RESOLV entre o final de maio e o início de junho.

No entanto, o motivo pelo qual a Resolv Labs foi atacada não se deveu a condições extremas de mercado, mas sim à “falta de rigor” no projeto do mecanismo de cunhagem de USR.

Até o momento, nenhuma empresa de segurança ou autoridade analisou as causas desse incidente de hacking. A comunidade DeFi YAM concluiu preliminarmente, por meio de análises, que o ataque provavelmente foi causado pelo hacker que controlava o SERVICE_ROLE utilizado pelo backend do protocolo para fornecer parâmetros ao contrato de cunhagem.

De acordo com a análise da Grok, quando os usuários cunham USR, eles iniciam uma solicitação na cadeia de blocos e chamam a função requestMint do contrato, com parâmetros que incluem:

_depositTokenAddress: o endereço do token depositado;

_valor: o valor depositado;

_minMintAmount: a quantidade mínima esperada de USR a ser recebida (para evitar deslizamento).

Em seguida, os usuários depositam USDC ou USDT no contrato, e o SERVICE_ROLE do backend do projeto monitora a solicitação, utilizando o oráculo Pyth para verificar o valor dos ativos depositados e, em seguida, chama a função completeMint ou completeSwap para determinar a quantidade real de USR cunhada.

O problema reside no fato de que o contrato de cunhagem confia totalmente no valor _mintAmount fornecido pela função SERVICE_ROLE, acreditando que esse número foi verificado fora da cadeia pelo Pyth; assim, não foi definido nenhum limite máximo, nem houve qualquer verificação por oráculo na cadeia, executando-se diretamente a função mint(_mintAmount).

Com base nisso, a YAM suspeita que o hacker tenha assumido o controle do SERVICE_ROLE, que deveria estar sob o controle da equipe do projeto (possivelmente devido a uma falha interna do Oracle, conluio ou roubo de chaves), definindo diretamente o _mintAmount para 50 milhões durante a cunhagem, realizando assim o ataque que resultou na cunhagem de 50 milhões de USR com 100.000 USDC.

Por fim, Grok concluiu que a Resolv não levou em conta, ao projetar o protocolo, a possibilidade de que o endereço (ou contrato) usado para receber as solicitações de cunhagem dos usuários pudesse ser controlado por hackers. Quando a solicitação para cunhar USR foi enviada ao contrato responsável pela cunhagem final de USR, não foi definido um limite máximo de cunhagem, nem houve uma verificação secundária por meio de um oráculo na cadeia, confiando-se diretamente em todos os parâmetros fornecidos pela SERVICE_ROLE.

As medidas de prevenção também foram inadequadas

Além de especular sobre os motivos do ataque, a YAM também destacou a preparação inadequada do projeto para lidar com situações de crise.

A YAM declarou no X que a Resolv Labs só suspendeu o protocolo três horas após o primeiro ataque do hacker, sendo que cerca de uma hora desse atraso se deveu à necessidade de coletar quatro assinaturas para a transação com múltiplas assinaturas. A YAM acredita que uma pausa de emergência deve exigir apenas uma assinatura e que essa autoridade deve ser distribuída, na medida do possível, entre os membros da equipe ou operadores externos de confiança, o que aumentaria a percepção de anomalias na cadeia, melhoraria a probabilidade de uma pausa rápida e daria uma cobertura mais ampla aos diferentes fusos horários.

Embora a sugestão de que uma única assinatura possa suspender o protocolo seja um tanto radical, exigir várias assinaturas em diferentes fusos horários para suspender o protocolo poderia, de fato, atrasar questões importantes em uma emergência. A introdução de terceiros de confiança que monitorem continuamente o comportamento na cadeia de blocos ou o uso de ferramentas de monitoramento com autoridade para acionar o protocolo de pausa de emergência são lições aprendidas com este incidente.

Os ataques de hackers a protocolos DeFi já não se limitam às vulnerabilidades dos contratos. O incidente envolvendo a Resolv Labs serve de alerta para as equipes de projeto: as suposições sobre a segurança do protocolo não devem basear-se em nenhum único elo, e todos os processos relacionados a parâmetros devem passar por, no mínimo, uma verificação secundária, incluindo aqueles operados pela própria equipe de projeto.