Trocar 200 mil por quase 100 milhões, a stablecoin DeFi sofre novo ataque

Artigo de: Eric, Foresight News

Por volta das 10h21, horário de Pequim, a Resolv Labs, que utiliza a estratégia neutra Delta para emitir stablecoins USR, foi alvo de um ataque hacker. Um endereço começado por 0x04A2 usou 100.000 USDC para cunhar 50 milhões de USR através do protocolo Resolv Labs.

Com a exposição do incidente, o preço do USR caiu para perto de 0,25 dólares e, até o momento da redação, recuperou-se para cerca de 0,8 dólares. O preço do token RESOLV também sofreu uma queda de quase 10% em um curto período.

Depois, os hackers repetiram a operação, usando novamente 100.000 USDC para cunhar 30 milhões de USR. Com a grande desvalorização do USR, traders de arbitragem agiram rapidamente. Muitos mercados de empréstimo na Morpho, que suportam USR, wstUSR e outros como garantias, foram quase esvaziados. A Lista DAO na BNB Chain também suspendeu novas solicitações de empréstimo.

Não foram apenas esses protocolos de empréstimo que sofreram impacto. Na estrutura do protocolo Resolv Labs, os usuários podem cunhar um token chamado RLP, que tem maior volatilidade de preço e potencial de retorno, mas exige que o usuário assuma responsabilidade por perdas caso o protocolo sofra prejuízos. Atualmente, há cerca de 30 milhões de RLP em circulação, com o maior detentor, a Stream Finance, possuindo mais de 13 milhões de RLP, representando uma exposição de risco de aproximadamente 17 milhões de dólares.

Sim, a Stream Finance, que já enfrentou uma crise com o xUSD, pode estar prestes a sofrer outro golpe.

Até o momento da redação, os hackers converteram USR em USDC e USDT, além de continuarem comprando Ethereum, tendo adquirido mais de 10.000 ETH. Com 200.000 USDC, conseguiram obter ativos no valor superior a 20 milhões de dólares. Durante o mercado em baixa, os hackers encontraram uma “moeda de 100x” que pertence ao seu perfil.

Mais uma vez, uma brecha por falta de rigor

A grande queda de 11 de outubro do ano passado fez com que muitas stablecoins emitidas com estratégias neutras Delta sofressem perdas de garantia devido ao mecanismo de ADL (auto-desleverage). Algumas plataformas que utilizavam altcoins como ativos de execução tiveram perdas severas e até saíram do mercado.

A Resolv Labs, que também utilizou um mecanismo semelhante para emitir USR, anunciou em abril de 2025 que havia recebido um investimento seed de 10 milhões de dólares liderado pela Cyber.Fund e Maven11, com participação da Coinbase Ventures. A token RESOLV foi lançada no final de maio ou início de junho.

No entanto, o ataque à Resolv Labs não foi causado por condições extremas de mercado, mas sim por uma falha no design do mecanismo de cunhagem de USR, que não era suficientemente rigoroso.

Até o momento, nenhuma empresa de segurança ou autoridade oficial analisou as causas do ataque. A comunidade DeFi, por meio da YAM, concluiu preliminarmente que o ataque provavelmente ocorreu porque o ROLE de serviço (SERVICE_ROLE), que fornece parâmetros para o contrato de cunhagem, foi controlado pelos hackers.

Segundo a análise do Grok, ao cunhar USR, o usuário faz uma solicitação na blockchain e chama a função requestMint do contrato, com parâmetros incluindo:

_depositTokenAddress：endereço do token depositado;

_amount：quantidade depositada;

_minMintAmount：quantidade mínima de USR esperada (para evitar slippage).

Depois, o usuário deposita USDC ou USDT no contrato, o backend do projeto, com o ROLE de serviço monitorando a solicitação, usa a oracle Pyth para verificar o valor do ativo depositado, e então 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 totalmente no _mintAmount fornecido pelo ROLE de serviço, assumindo que esse valor foi verificado pelo Pyth fora da cadeia, sem estabelecer limites máximos ou realizar uma segunda verificação com uma oracle na cadeia. Assim, ao executar mint(_mintAmount), o contrato simplesmente aceita o valor.

Com isso, a YAM suspeita que os hackers controlaram o ROLE de serviço, que deveria estar sob controle do projeto (possivelmente devido a uma falha na oracle interna, roubo de chaves ou insider), e durante a cunhagem, definiram _mintAmount como 50 milhões, permitindo a cunhagem de 50 milhões de USR com apenas 100.000 USDC.

Em resumo, o Grok conclui que o projeto Resolv não considerou a possibilidade de que o endereço (ou contrato) responsável por receber as solicitações de cunhagem pudesse ser controlado por hackers. Quando a solicitação de cunhagem de USR foi enviada ao contrato final, não foi estabelecido um limite máximo de cunhagem, nem foi realizada uma segunda verificação com uma oracle na cadeia, confiando cegamente em todos os parâmetros fornecidos pelo ROLE de serviço.

Medidas de prevenção insuficientes

Além de especular sobre as causas do ataque, a YAM também apontou que o projeto não estava suficientemente preparado para lidar com a crise.

No X, a YAM afirmou que a Resolv Labs só pausou o protocolo três horas após o primeiro ataque, sendo que cerca de uma hora desse tempo foi gasto na coleta de quatro assinaturas necessárias para uma transação multiassinatura. A YAM sugeriu que uma pausa de emergência deveria exigir apenas uma assinatura, e essa permissão deveria ser atribuída a membros da equipe ou operadores externos confiáveis, aumentando a atenção a atividades anormais na cadeia e possibilitando uma resposta rápida. Assim, a pausa poderia ser mais eficiente, especialmente considerando diferentes fusos horários.

Embora a sugestão de que uma única assinatura seja suficiente para pausar o protocolo seja bastante radical, a necessidade de múltiplas assinaturas de diferentes fusos horários para interromper o sistema pode atrasar ações em situações de emergência. A introdução de terceiros confiáveis, que monitorem continuamente as atividades na cadeia, ou o uso de ferramentas de monitoramento com privilégios de pausa de emergência, são lições que este incidente deixou.

Ataques a protocolos DeFi não se limitam a vulnerabilidades em contratos inteligentes. O incidente da Resolv Labs serve como um alerta: na segurança de protocolos, não se deve confiar em nenhuma parte do sistema. Todos os componentes que envolvem parâmetros devem passar por pelo menos uma verificação secundária, inclusive os backends operados pelo próprio projeto.