Artigo por Eric, Foresight News
Por volta das 10:21 (horário de Pequim) de hoje, a Resolv Labs, que emitiu a stablecoin USR por meio de uma estratégia delta-neutra, sofreu um ataque cibernético. O endereço que começa com 0x04A2 cunhou 50 milhões de USR no protocolo da Resolv Labs utilizando 100.000 USDC.
Com o surgimento do evento, o USR caiu para perto de 0,25 dólares, recuperando-se para cerca de 0,8 dólares até a redação deste artigo. O preço do token RESOLV também registrou uma queda máxima de cerca de 10% por um curto período.
Em seguida, o hacker repetiu o mesmo esquema, cunhando 30 milhões de USR com 100 mil USDC. Com o forte desancoramento do USR, os traders de arbitragem agiram rapidamente; muitos mercados de empréstimo no Morpho que aceitavam USR, wstUSR e outros como garantia foram quase esvaziados, e o Lista DAO na BNB Chain suspendeu novos pedidos de empréstimo.
Esses protocolos de empréstimo não são os únicos afetados. No design do protocolo da Resolv Labs, os usuários também podem cunhar um token RLP, que apresenta maior volatilidade de preço e rendimento mais elevado, mas exige que os detentores assumam responsabilidade por compensações caso o protocolo sofra perdas. Atualmente, a oferta circulante do token RLP é de cerca de 30 milhões de unidades, com o maior detentor, Stream Finance, detendo mais de 13 milhões de RLP, resultando em uma exposição líquida de aproximadamente US$ 17 milhões.
Sim, o Stream Finance, que já sofreu um colapso anteriormente com o xUSD, pode ser novamente atingido.
Até a redação deste artigo, o hacker já converteu o USR em USDC e USDT e continuou comprando Ethereum, adquirindo mais de 10 mil unidades até o momento. Com 200 mil USDC, o hacker retirou mais de 20 milhões de dólares em ativos, encontrando seu "criptomoeda de cem vezes" durante o mercado baixista.
Mais uma vez explorado por causa de "irrelevância"
A forte queda em 11 de outubro do ano passado causou perdas de garantia em muitos stablecoins emitidos com estratégias de delta neutro devido ao ADL (desalavancagem automática). Alguns projetos que utilizaram altcoins como ativos para executar suas estratégias sofreram perdas ainda mais severas e até mesmo desapareceram.
A Resolv Labs, alvo deste ataque, também emitiu o USR por meio de um mecanismo semelhante. O projeto anunciou em abril de 2025 a conclusão de um financiamento semente de 10 milhões de dólares, liderado pela Cyber.Fund e Maven11, com participação da Coinbase Ventures, e lançou o token RESOLV no final de maio e início de junho.
Mas a razão pela qual a Resolv Labs foi atacada não foi a volatilidade extrema, e sim o design do mecanismo de cunhagem do USR ser "insuficientemente rigoroso".
Nenhuma empresa de segurança ou entidade oficial ainda analisou a causa deste incidente de hacking. A comunidade DeFi YAM, por meio de análise preliminar, concluiu que o ataque provavelmente ocorreu porque o SERVICE_ROLE, usado pelo backend do protocolo para fornecer parâmetros ao contrato de cunhagem, foi comprometido pelos hackers.
Segundo a análise do Grok, quando os usuários cunham o USR, eles iniciam uma solicitação na cadeia e chamam a função requestMint do contrato, com os parâmetros:
_depositTokenAddress: endereço do token depositado;
_amount: quantidade depositada;
_minMintAmount: Quantidade mínima esperada de USR a receber (slippage).
Em seguida, o usuário deposita USDC ou USDT no contrato; o backend do projeto, com o SERVICE_ROLE, monitora a solicitação, verifica o valor dos ativos depositados usando o oráculo Pyth e, em seguida, chama as funções completeMint ou completeSwap para determinar a quantidade real de USR a ser cunhada.
O problema está no fato de que o contrato de cunhagem confia completamente no _mintAmount fornecido pelo SERVICE_ROLE, assumindo que esse valor foi verificado off-chain pela Pyth, portanto não definiu um limite superior nem realizou verificação de oráculo on-chain, executando diretamente mint(_mintAmount).
Com base nisso, o YAM suspeita que o hacker tenha controlado o SERVICE_ROLE, que deveria ser controlado pela equipe do projeto (possivelmente devido a falha interna do oráculo, fraude interna ou chave comprometida), definindo diretamente _mintAmount como 50 milhões durante a cunhagem, realizando o ataque que cunhou 50 milhões de USR com apenas 100 mil USDC.
Em última análise, o Grok concluiu que a Resolv não considerou a possibilidade de que o endereço (ou contrato) destinado a receber solicitações de cunhagem de usuários fosse controlado por hackers, não definiu um limite máximo de cunhagem quando as solicitações de cunhagem de USR foram enviadas ao contrato final de cunhagem, nem realizou uma verificação secundária por meio de oráculo on-chain, confiando diretamente em todos os parâmetros fornecidos pelo SERVICE_ROLE.
As prevenções também não estão adequadas
Além de especular sobre as razões do ataque, o YAM também apontou a falta de preparo da equipe do projeto para lidar com a crise.
YAM afirmou no X que a Resolv Labs só pausou o protocolo três horas após a conclusão do primeiro ataque do hacker, com cerca de uma hora de atraso devido à coleta das quatro assinaturas necessárias para a transação de multisig. YAM considera que uma pausa de emergência deveria exigir apenas uma assinatura, e que os privilégios deveriam ser distribuídos o máximo possível entre membros da equipe ou operadores externos confiáveis, aumentando a atenção a anomalias na cadeia, melhorando a probabilidade de pausa rápida e cobrindo melhor diferentes fusos horários.
Embora a sugestão de que apenas uma assinatura seja necessária para pausar o protocolo seja um pouco radical, exigir múltiplas assinaturas de diferentes fusos horários para pausar o protocolo pode realmente atrasar a resposta em situações de emergência. Introduzir um terceiro confiável que monitore continuamente o comportamento na cadeia, ou utilizar ferramentas de monitoramento com permissão para pausar o protocolo em emergência, são lições aprendidas com este evento.
Os ataques de hackers a protocolos DeFi já não se limitam mais a vulnerabilidades de contratos; o evento da Resolv Labs serve como um alerta para os projetos: deve-se assumir que nenhuma etapa no segurança do protocolo pode ser confiada, e todos os componentes envolvendo parâmetros devem passar por pelo menos uma segunda verificação, mesmo que o backend seja operado pelo próprio projeto.