Redação: Eric, Foresight News

Hoje, por volta das 10:21, horário de Pequim, a Resolv Labs, que emite a stablecoin USR utilizando a estratégia Delta neutra, foi alvo de um ataque hacker. Um endereço começando com 0x04A2 usou 100.000 USDC para cunhar 50.000.000 USR a partir do protocolo Resolv Labs.

Com a exposição do evento, o USR caiu para cerca de 0,25 dólares, e, no momento da redação, voltou a subir para cerca de 0,8 dólares. O preço do token RESOLV teve um declínio máximo próximo de 10%.

Depois, os hackers repetiram a operação e novamente usaram 100.000 USDC para cunhar 30.000.000 USR. Com a grande desvinculação do USR, os traders de arbitragem também agiram rapidamente, e muitos mercados de empréstimo no Morpho, que suportam USR, wstUSR, entre outros como colateral, foram quase esvaziados. A Lista DAO na BNB Chain também interrompeu novos pedidos de empréstimo.

Os protocolos de empréstimo afetados não se limitam apenas a estes. No design do protocolo Resolv Labs, os usuários também podem cunhar um token RLP que apresenta maior volatilidade de preço e maior rendimento, mas que precisa assumir a responsabilidade de compensação quando o protocolo sofre perdas. Atualmente, a circulação do token RLP é de quase 30 milhões, com o maior detentor, Stream Finance, possuindo mais de 13 milhões de RLP, com um risco líquido de aproximadamente 17 milhões de dólares.

Exatamente, a Stream Finance, que já havia sido atingida por problemas com o xUSD, pode ser golpeada novamente.

Até o momento da redação, os hackers converteram USR em USDC e USDT, e continuam comprando Ethereum, já tendo adquirido mais de 10 mil. Com 200 mil USDC, conseguiram obter mais de 20 milhões de dólares em ativos; os hackers encontraram seu 'token de 100 vezes' durante o mercado em baixa.

Mais uma vez foi explorado devido à 'falta de rigor'

A grande queda de 11 de outubro do ano passado fez com que muitos stablecoins emitidos usando a estratégia Delta neutra sofressem perdas de colaterais devido ao ADL (desalavancagem automática). Alguns projetos que utilizavam criptomoedas alternativas como estratégia de execução sofreram perdas ainda mais severas ou até mesmo saíram correndo.

Desta vez, o Resolv Labs, que foi atacado, também emitiu USR utilizando um mecanismo semelhante. O projeto anunciou em abril de 2025 que havia completado uma rodada de financiamento semente de 10 milhões de dólares liderada pela Cyber.Fund e Maven11, com a 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 o Resolv Labs foi atacado não foi devido a condições extremas, mas sim ao design do mecanismo de cunhagem de USR que 'não é rigoroso o suficiente'.

Atualmente, ainda não há empresas de segurança ou autoridades que tenham analisado as causas do ataque hacker. A comunidade DeFi YAM chegou a uma conclusão preliminar através da análise: o ataque provavelmente foi causado pelo fato de o SERVICE_ROLE, usado pelo backend do protocolo para fornecer parâmetros ao contrato de cunhagem, ter sido controlado pelo hacker.

De acordo com a análise da Grok, os usuários que cunham USR iniciam uma solicitação na blockchain e invocam a função requestMint do contrato, com parâmetros incluindo:

_depositTokenAddress: endereço do token depositado;

_amount: quantidade a ser depositada;

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

Depois, os usuários depositam USDC ou USDT no contrato, o SERVICE_ROLE do backend da equipe monitora a solicitação, usando o oráculo Pyth para verificar o valor dos ativos depositados, e então chama as funções completeMint ou completeSwap, decidindo a quantidade real de USR a ser cunhada.

O problema reside no fato de que o contrato de cunhagem confia completamente no _mintAmount fornecido pelo SERVICE_ROLE, acreditando que esse número foi verificado fora da blockchain pela Pyth, portanto, não definiu um limite máximo e não teve validação do oráculo na blockchain, executando diretamente mint(_mintAmount).

Com base nisso, YAM suspeita que o hacker controlou o SERVICE_ROLE que deveria ser controlado pela equipe do projeto (possivelmente devido a um oráculo interno fora de controle, roubo interno ou chave comprometida), e ao cunhar, definiu diretamente o _mintAmount para 50 milhões, realizando o ataque que permitiu cunhar 50 milhões de USR com 100 mil USDC.

Em última análise, a conclusão dada pela Grok é que a Resolv não considerou no design do protocolo a possibilidade de que o endereço (ou contrato) usado para receber solicitações de cunhagem de usuários poderia ser controlado por hackers. Quando a solicitação para cunhar USR foi enviada ao contrato que finalmente cunharia o USR, não foi definido um limite máximo de cunhagem, nem foi solicitado que o contrato de cunhagem realizasse uma verificação secundária com um oráculo na blockchain, confiando diretamente em todos os parâmetros fornecidos pelo SERVICE_ROLE.

A prevenção também não foi adequada.

Além de especular sobre as razões do hack, YAM também apontou a falta de preparo da equipe do projeto em lidar com a crise.

YAM comentou no X que o Resolv Labs só suspendeu o protocolo 3 horas após o primeiro ataque do hacker, sendo que cerca de 1 hora de atraso se deveu à coleta de 4 assinaturas necessárias para a transação multi-assinatura. YAM acredita que a suspensão de emergência deveria requerer apenas uma assinatura e que a autoridade deveria ser distribuída entre os membros da equipe ou operadores externos confiáveis, aumentando assim a atenção a anomalias na blockchain e melhorando a possibilidade de uma rápida suspensão, cobrindo melhor diferentes fusos horários.

Embora a sugestão de que uma única assinatura possa suspender o protocolo seja um pouco radical, a exigência de múltiplas assinaturas de diferentes fusos horários para suspender o protocolo pode, de fato, atrasar decisões importantes em situações de emergência. A introdução de um terceiro confiável que monitore continuamente o comportamento na blockchain, ou o uso de ferramentas de monitoramento com autoridade de suspensão de emergência do protocolo, são lições aprendidas deste evento.

Os ataques de hackers a protocolos DeFi já não se limitam a vulnerabilidades de contrato. O evento do Resolv Labs serve de alerta para os projetos: as suposições sobre a segurança do protocolo não devem confiar em nenhuma parte, e todos os aspectos que envolvem parâmetros devem ser verificados pelo menos duas vezes, incluindo o backend operado pela própria equipe do projeto.