Futures
Access hundreds of perpetual contracts
TradFi
Gold
One platform for global traditional assets
Options
Hot
Trade European-style vanilla options
Unified Account
Maximize your capital efficiency
Demo Trading
Introduction to Futures Trading
Learn the basics of futures trading
Futures Events
Join events to earn rewards
Demo Trading
Use virtual funds to practice risk-free trading
Launch
CandyDrop
Collect candies to earn airdrops
Launchpool
Quick staking, earn potential new tokens
HODLer Airdrop
Hold GT and get massive airdrops for free
Launchpad
Be early to the next big token project
Alpha Points
Trade on-chain assets and earn airdrops
Futures Points
Earn futures points and claim airdrop rewards
Exchange 200,000 for nearly 100 million, DeFi stablecoin attacked again
Article by: Eric, Foresight News
Around 10:21 AM Beijing time today, Resolv Labs, which issued the stablecoin USR using Delta neutral strategies, was hacked. An address starting with 0x04A2 minted 50 million USR tokens using 100,000 USDC from the Resolv Labs protocol.
As the incident came to light, USR’s price plummeted to around $0.25, then recovered to about $0.8 by the time of writing. The RESOLV token price also briefly dropped nearly 10%.
Subsequently, the hacker repeated the process, again using 100,000 USDC to mint 30 million USR tokens. With USR’s significant depegging, arbitrage traders quickly acted. Many lending markets on Morpho that support USR, wstUSR, and other collateral types have been almost drained, and Lista DAO on BNB Chain has paused new borrowing requests.
The impact extends beyond these lending protocols. In Resolv Labs’ design, users can also mint an RLP token, which is more volatile and offers higher yields but requires the user to bear compensation responsibilities if the protocol suffers losses. Currently, the circulating supply of RLP is nearly 30 million, with the largest holder, Stream Finance, holding over 13 million RLP, exposing a net risk of about $17 million.
Indeed, Stream Finance, which previously suffered a major loss due to xUSD’s collapse, may face another blow.
As of now, the hacker has converted USR into USDC and USDT and continues to buy Ethereum, having purchased over 10,000 ETH. They have turned 200,000 USDC into assets worth over $20 million, finding a “hundredfold coin” during the bear market that belongs to TA.
Once Again, a Lack of Rigor Leads to Exploitation
The sharp decline on October 11 last year caused many stablecoins issued via Delta strategies to suffer collateral losses due to automatic deleveraging (ADL). Projects using altcoins as collateral faced even heavier losses or outright exit scams.
The attacked Resolv Labs also issued USR using a similar mechanism. The project announced in April 2025 that it completed a $10 million seed round led by Cyber.Fund and Maven11, with Coinbase Ventures participating. It launched its token RESOLV in late May or early June.
However, the reason for the attack was not extreme market conditions but rather a flaw in the USR minting mechanism’s design.
No security firm or official has yet analyzed the cause of this hack. The DeFi community YAM, through initial analysis, concluded that the attack likely resulted from the hacker gaining control of the SERVICE_ROLE used by the protocol backend to provide parameters for minting.
According to Grok’s analysis, when users mint USR, they initiate a request on-chain and call the contract’s requestMint function, with parameters including:
_depositTokenAddress: the address of the token deposited;
_amount: the deposit amount;
_minMintAmount: the minimum expected USR to receive (slippage protection).
Then, users deposit USDC or USDT into the contract. The project’s backend, with the SERVICE_ROLE, monitors the request, uses the Pyth oracle to verify the asset value, and then calls completeMint or completeSwap to determine the actual USR minted.
The problem lies in the fact that the minting contract fully trusts the _mintAmount provided by SERVICE_ROLE, assuming this number has been verified off-chain by Pyth. There are no upper limits set, nor on-chain oracle validation, so it directly executes mint(_mintAmount).
Based on this, YAM suspects the hacker gained control of the SERVICE_ROLE, which should be controlled by the project team—possibly due to an internal oracle malfunction, insider theft, or key compromise—and set _mintAmount to 50 million, enabling the attack to mint 50 million USR with just 100,000 USDC.
Ultimately, Grok’s conclusion is that Resolv’s protocol design failed to consider the possibility that the address (or contract) receiving user mint requests could be controlled by a hacker. When the mint request was submitted to the final minting contract, no maximum mint limit was set, nor was there secondary verification via on-chain oracles; it blindly trusted all parameters provided by SERVICE_ROLE.
Prevention Measures Also Lacked Adequacy
Besides hypothesizing the cause of the breach, YAM pointed out that the project’s crisis response preparedness was insufficient.
YAM stated on X that Resolv Labs only paused the protocol three hours after the initial attack, with about an hour of delay due to collecting signatures from four signers for multi-sig transactions. YAM believes emergency pauses should require only one signature, and permissions should be distributed to team members or trusted external operators to increase responsiveness to on-chain anomalies, enabling faster halts and better coverage across different time zones.
While the suggestion to allow a single signature to pause the protocol is somewhat aggressive, requiring multiple signatures across time zones could delay critical responses during emergencies. Introducing trusted third parties that continuously monitor on-chain activity or using emergency pause tools with monitoring capabilities are lessons from this incident.
The hacker’s attack on DeFi protocols is no longer limited to contract vulnerabilities. The Resolv Labs incident serves as a warning: in protocol security, assumptions should be that no component can be fully trusted. All parameter-related steps must undergo at least secondary verification, even for backend operations managed by the project itself.