Resolv Labs Atacada, Projetos DeFi Novamente Explorados em Ataque em Cascata

Resolv Labs, a entidade emissora da stablecoin USR que utiliza uma estratégia Delta neutra, foi alvo de um ataque. Um endereço começando por 0x04A2 criou 50 milhões de USR a partir do protocolo Resolv Labs com 100.000 USDC.
Após a revelação do incidente, o preço do USR caiu imediatamente para cerca de 0,25 dólares, recuperando-se posteriormente para aproximadamente 0,80 dólares no momento da redação. O preço do token RESOLV também caiu quase 10% em um curto período.

Depois, os hackers usaram um método semelhante para criar 30 milhões de USR com 100.000 USDC. Quando o valor do USR despencou, os especuladores de arbitragem agiram rapidamente, e muitos mercados de empréstimo na Morpho, que suportam USR, wstUSR e outros ativos colaterais, ficaram quase esgotados. A Lista DAO na cadeia BNB também suspendeu temporariamente novas solicitações de empréstimo.

Esses protocolos de empréstimo não são os únicos afetados. O protocolo Resolv Labs também permite aos usuários criar tokens RLP, o que aumenta a volatilidade de preços e potencial de lucro, mas também os torna responsáveis legalmente por perdas decorrentes do protocolo. Atualmente, há cerca de 30 milhões de tokens RLP em circulação, sendo que a Stream Finance detém mais de 13 milhões, representando um risco líquido de aproximadamente 17 milhões de dólares.
Sim, a Stream Finance, que sofreu grandes perdas com o xUSD, pode estar prestes a enfrentar mais um choque.
Até o momento da redação, os hackers converteram USR em USDC e USDT e continuam comprando Ethereum, adquirindo mais de 10.000 unidades. Com 200.000 USDC, recuperaram mais de 20 milhões de dólares em ativos, encontrando seu “token de lucro 100 vezes maior” no mercado de baixa.
Mais uma vez, uma vulnerabilidade foi explorada devido à “falta de rigor”.

A forte queda de 11 de outubro do ano passado causou perdas de ativos colaterais em muitas stablecoins emitidas com estratégia Delta-neutra, devido ao ADL (Auto Deleveraging). Alguns projetos que usam altcoins como ativos colaterais sofreram perdas ainda maiores, e alguns até desapareceram completamente.

O Resolv Labs, projeto atacado desta vez, também utiliza um mecanismo semelhante para emitir USR. Em abril de 2025, o projeto anunciou que havia concluído uma rodada de financiamento seed de 10 milhões de dólares liderada 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.

No entanto, o motivo do ataque ao Resolv Labs não foi devido às condições de mercado adversas, mas sim porque o mecanismo de criação do USR “não era suficientemente rigoroso”.

Até o momento, nenhuma empresa de segurança ou órgão oficial analisou as causas do ataque. Uma análise preliminar do membro da comunidade DeFi YAM sugere que o ataque provavelmente ocorreu porque hackers assumiram o controle da função SERVICE_ROLE, usada na parte auxiliar do protocolo para fornecer parâmetros ao contrato de criação de tokens.

Segundo a análise do Grok, ao criar USR, o usuário inicia uma requisição na cadeia e chama a função requestMint do contrato, com parâmetros incluindo:
_depositTokenAddress: endereço onde o token é enviado;
_amount: quantidade a ser depositada;
_minMintAmount: quantidade mínima de USR esperada (ponto de slippage).

Depois, o usuário envia USDC ou USDT para o contrato. A parte auxiliar SERVICE_ROLE do projeto monitora a requisição, usando o oracle Pyth para verificar o valor do ativo enviado, e então chama as funções completeMint ou completeSwap para determinar a quantidade real de USR criada.

O problema está no fato de que o contrato de emissão confia totalmente no valor de mintAmount fornecido pelo SERVICE_ROLE, assumindo que esse valor foi verificado pelo Pyth fora da cadeia. Assim, ele não impõe limites ou validações adicionais com um oracle on-chain, e simplesmente executa mint(_mintAmount).

Com base nisso, YAM suspeita que o hacker tenha assumido o controle do SERVICE_ROLE, que deveria ser controlado pela equipe do projeto (possivelmente devido a uma falha no sistema oracle interno, roubo interno ou comprometimento de chaves), e tenha definido diretamente _mintAmount para 50 milhões durante a criação fraudulenta, realizando assim o ataque que gerou 50 milhões de USR com 100.000 USDC.

Por fim, Grok conclui que o Resolv não considerou a possibilidade de que o endereço (ou contrato) usado para receber a requisição de criação de USR pudesse estar sob controle de hackers ao projetar o protocolo. Quando a requisição de criação de USR é enviada ao contrato que realmente gera o token, não há limite máximo de quantidade definido, e o contrato de emissão não usa um oracle on-chain para validação secundária. Em vez disso, ele confia totalmente nos parâmetros fornecidos pelo SERVICE_ROLE.

A prevenção também é insuficiente.

Além de especular sobre as causas do ataque, YAM também aponta a falta de preparação da equipe do projeto para lidar com crises.

YAM declarou no X que o Resolv Labs apenas suspendeu temporariamente o protocolo por três horas após o ataque inicial, sendo que cerca de uma hora foi necessária para coletar as quatro assinaturas necessárias para transações multiassinatura. YAM acredita que a suspensão de emergência deveria exigir apenas uma assinatura, e essa autoridade deveria ser delegada a membros da equipe ou operadores confiáveis externos sempre que possível. Isso aumentaria a conscientização sobre atividades anormais na cadeia, melhoraria a capacidade de pausa rápida e cobriria diferentes fusos horários de forma mais eficaz.

Embora a proposta de suspender um protocolo com uma única assinatura pareça extrema, exigir múltiplas assinaturas de diferentes fusos horários para pausar um protocolo pode causar atrasos significativos em situações de emergência. A introdução de uma terceira parte confiável para monitorar continuamente o comportamento na cadeia ou o uso de ferramentas de monitoramento com poder de pausa de emergência são lições importantes deste incidente.

Ataques de hackers a protocolos DeFi há muito se limitam a vulnerabilidades de contratos inteligentes. O incidente do Resolv Labs serve como um alerta para os times de projetos: a segurança do protocolo não deve confiar em nenhuma parte do sistema, e todos os parâmetros relacionados devem passar por pelo menos duas verificações, incluindo até mesmo os servidores operados pela própria equipe do projeto.