Trocar 200.000 por quase 100 milhões, os stablecoins DeFi sofrem novo ataque

撰文：Eric，Foresight News

Por volta das 10:21 (hora de Pequim) de hoje, a Resolv Labs, que emitiu stablecoins USR através de uma estratégia Delta neutra, foi alvo de um ataque informático. O endereço com início em 0x04A2 cunhou 50 milhões de USR a partir do protocolo Resolv Labs, utilizando 100.000 USDC.

Após a divulgação do incidente, o USR caiu de imediato para perto de 0,25 dólares e, no momento em que foi escrito, recuperou para cerca de 0,8 dólares. A maior queda intradiária do preço do token RESOLV também chegou a aproximar-se de 10%.

Mais tarde, o hacker repetiu a operação: voltou a cunhar 30 milhões de USR usando 100.000 USDC. Com o grande desancoramento do USR, os arbitragistas agiram rapidamente; muitos mercados de empréstimo no Morpho que suportam USR, wstUSR e outros como colateral já foram praticamente esvaziados, e a Lista DAO na BNB Chain também suspendeu os novos pedidos de empréstimo.

O impacto não se limitou a esses protocolos de empréstimo. Na conceção do protocolo Resolv Labs, os utilizadores também podem cunhar um token RLP com maior volatilidade de preço e retornos mais elevados, mas que exige assumir responsabilidade por compensação quando o protocolo recebe perdas. Atualmente, a oferta em circulação do token RLP é de perto de 30 milhões de unidades; o maior detentor, a Stream Finance, possui mais de 13 milhões de RLP, com uma exposição líquida ao risco de aproximadamente 17 milhões de dólares.

Sim, a Stream Finance, que já tinha sido atingida uma vez devido ao xUSD, pode estar novamente prestes a ser atacada.

No momento em que foi escrito, o hacker converteu o USR em USDC e USDT e tem continuado a comprar Ethereum; até agora já comprou mais de 10.000 unidades. Com 200.000 unidades de USDC, conseguiu fazer a correspondência de ativos no valor de mais de 20 milhões de dólares; durante o mercado em baixa, o hacker encontrou a “moeda de cem vezes” do tipo que lhe pertence.

Mais uma vez, por “falta de rigor”, abriram uma brecha

A grande queda de 11 de outubro do ano passado fez com que muitas stablecoins emitidas através de estratégias Delta neutra sofressem perdas de colateral devido a ADL (automated deleveraging, redução automática de alavancagem). Parte dos projetos cujos ativos utilizam altcoins como base para executar as estratégias sofreu perdas ainda mais severas, chegando mesmo a fugir diretamente.

A Resolv Labs, que desta vez foi atacada, também emite USR com um mecanismo semelhante. O projeto tinha anunciado em abril de 2025 a conclusão de uma ronda semente de 10 milhões de dólares, com a Cyber.Fund e a Maven11 como líderes, e com a Coinbase Ventures a participar, tendo, no final de maio e início de junho, lançado o token RESOLV.

Mas a razão pela qual a Resolv Labs foi atacada não foi por causa de condições de mercado extremas; foi sim porque o desenho do mecanismo de emissão de USR “não era suficientemente rigoroso”.

Até ao momento, nenhuma empresa de segurança ou entidade oficial publicou uma análise sobre as causas do ataque informático. A comunidade DeFi YAM, através de análise preliminar, chegou à conclusão de que o mais provável é que o ataque tenha resultado do facto de o hacker ter controlado o SERVICE_ROLE do back-end do protocolo, que é utilizado para fornecer parâmetros ao contrato de cunhagem.

De acordo com a análise do Grok, quando o utilizador cunha USR, inicia um pedido on-chain e chama a função requestMint do contrato, sendo os parâmetros:

_depositTokenAddress：o endereço do token depositado;

_amount：a quantidade depositada;

_minMintAmount：a quantidade mínima esperada de USR recebida (para proteção contra slippage).

Depois, o utilizador deposita USDC ou USDT no contrato. O back-end do projeto, através do SERVICE_ROLE, monitoriza o pedido, usa o oráculo Pyth para verificar o valor do ativo depositado e, em seguida, chama as funções completeMint ou completeSwap para decidir a quantidade real de USR a cunhar.

O problema está no facto de o contrato de cunhagem confiar completamente no _mintAmount fornecido pelo SERVICE_ROLE, assumindo que esse número foi validado offline pelo Pyth. Por isso, não definiu limites superiores, nem verificou com oráculos on-chain, e executou diretamente o mint(_mintAmount).

Com base nisso, a YAM suspeita que o hacker controlou o SERVICE_ROLE que deveria estar sob controlo do próprio projeto (possivelmente devido a um oráculo interno fora de controlo, apropriação indevida por parte de quem guardava, ou roubo de chaves). Na cunhagem, o _mintAmount foi definido diretamente para 50 milhões, realizando assim o ataque em que 100.000 USDC foram convertidos em 50 milhões de USR.

Em última instância, a conclusão apresentada pelo Grok é que a Resolv não considerou, ao desenhar o protocolo, a possibilidade de o endereço (ou contrato) utilizado para receber pedidos de cunhagem dos utilizadores ser controlado por um hacker. Quando os pedidos de cunhagem de USR foram submetidos ao contrato final para cunhar USR, não foi definida uma quantidade máxima de cunhagem, nem foi pedido ao contrato de cunhagem para realizar uma validação secundária com oráculos on-chain; em vez disso, confiou em todos os parâmetros fornecidos pelo SERVICE_ROLE.

A prevenção também ficou aquém

Além de especular as causas do roubo, a YAM também apontou que o projeto não se preparou adequadamente para lidar com a crise.

A YAM afirmou no X que a Resolv Labs apenas suspendeu o protocolo 3 horas após ter sido concluído o primeiro ataque do hacker. Cerca de 1 hora desse atraso deveu-se à recolha das transações multi-assinatura necessárias, exigindo 4 assinaturas. A YAM considera que a suspensão de emergência deveria exigir apenas uma assinatura, e as permissões deveriam ser atribuídas o máximo possível a membros da equipa, ou a operadores externos de confiança; assim, seria possível aumentar a atenção a situações anómalas na cadeia, melhorar a probabilidade de uma suspensão rápida e cobrir melhor diferentes fusos horários.

Embora a recomendação de que a suspensão do protocolo exija apenas uma assinatura seja um pouco agressiva, é verdade que precisar de múltiplas assinaturas através de fusos horários diferentes para suspender o protocolo pode mesmo atrasar coisas importantes quando ocorre uma emergência. A introdução de um terceiro de confiança que monitore continuamente ações on-chain, ou a utilização de ferramentas de monitorização com permissões de pausa de emergência, são precisamente os “mestres do pós-incidente” trazidos por este evento.

Os ataques a protocolos DeFi não se limitam há muito tempo a vulnerabilidades de contratos. O caso da Resolv Labs serve como aviso para os projetos: as suposições sobre segurança do protocolo não podem confiar em nenhum dos seus elos; todos os pontos que envolvem parâmetros devem, no mínimo, passar por uma validação secundária, e isso também não é exceção mesmo para o back-end operado pelo próprio projeto.