Summary
A whitehat security researcher GregoAI (@therealgregoAI) / X recently uncovered a vulnerability in the backup auction infrastructure used by Reserve Yield Protocol DTFs. The bug affected the Gnosis EasyAuction contract — a third-party, non-upgradeable contract that the Reserve Yield Protocol used as a fallback trading mechanism, and that had not been used in over two years. If exploited under very specific edge circumstances, it could have permanently locked funds that were actively inside an auction, with no recovery path. However, an attacker would merely have been able to lock funds, not extract them, which made the incentive to attack low.
The relevant trading functions in affected DTFs have already been paused prior to making this announcement, so no meaningful funds are at risk, and the process to deprecate this fallback trading mechanism is underway. The bug was never exploited, merely uncovered by a whitehat security researcher, responsibly disclosed, and addressed. This is a report to share the info for community awareness.
How Reserve Protocol Auctions Worked
When a yield DTF needs to rebalance its collateral or process revenue, it opens a trade. There are two paths for this: Dutch Auctions (the default, recommended method) and Batch Auctions via the Gnosis EasyAuction contract.
Critically, the rebalance() function is public, and anyone can choose which auction type to use. This meant an attacker would have been able to force the protocol down the Batch Auction path at will.
The Bug
The vulnerability was a division-by-zero that could be triggered during auction settlement. Here was how it worked in plain terms:
- Force the vulnerable path. An attacker calls
rebalance()and specified Batch Auction mode, sending up to $1M (currentmaxTradeVolumeon yield DTFs) of DTF into the EasyAuction contract. - Place a tiny bid. During the auction window, the attacker places a minimal bid — as little as a fraction of a cent. In order to realize the bug, the full lot on auction CANNOT be filled. If the full lot has been bid, then the bug can not surface in step 3. This means that if other auction participants fills the bid, no funds would be at risk — only remaining inventory that was not sold.
- Poison the settlement state. After the auction ends, the attacker needs to call a public helper function called
precalculateSellAmountSum(). This function was designed to pre-process bids to make settlement cheaper, but when called with carefully chosen parameters, it advances the auction's internal cursor to the very end of the bid list. - Settlement permanently reverted. When anyone then tries to settle the auction, the settlement logic picks up where the pre-calculation left off — but there are no more bids to process. Key variables remain at zero, and the code would hit a
0 ÷ 0operation, which causes an irreversible revert.
Because the EasyAuction contract is non-upgradeable and had no admin rescue function, this is not a temporary freeze. If exploited, the funds would be permanently locked in a contract that could never release them.
What Would Have Been at Stake
The impact is twofold:
- Protocol collateral (up to $1M per auction) can be permanently frozen.
- All third-party bids placed during the auction would also be frozen, since bidders can only reclaim funds after settlement (which could never complete). In a well-attended (but unfilled) auction, this could have meant losses of nearly double the
maxTradeVolumeof $1M.
Beyond the immediate loss, the protocol's internal trade counter would have been stuck, blocking all future trades until governance intervened through a multi-day process.
Why This Was Serious
Several factors compounded the severity:
- No access control: Anyone could trigger the vulnerable auction path.
- Low cost to attack: The attacker only needed a negligible bid amount.
- No recovery: The EasyAuction contract could not be upgraded or admin-rescued.
- Collateral damage: Innocent bidders would have lost their deposits too.
- Protocol disruption: All rebalancing would have halted until governance acted.
Why This Was Low Risk
There was no direct incentive to cause this bug to surface, since the funds ended up locked in the auction contract, not in the attacker's possession.
Additionally, a critical requirement to realizing the bug was for the full lot on auction to not be filled. Batch auctions were priced in a way to incentivize bidders to make money, and bidding was fully permissionless. It is reasonable to assume that every auctioned lot would be filled.
Finally, dutch auctions are the main yield DTF auction method. Batch auctions have not been used in over 2 years. An attacker would have needed to front-run the launch of a dutch auction in order to launch a batch auction, and even then, ABC Labs could have participated in said batch auction, filling the lot and nullifying the attack.
Mitigation
While we considered the execution of this attack to be low risk, ABC Labs treated this bug with the utmost urgency and care.
- Every yield DTF has a Trade Pauser role that could act in times of emergency. Because there were user funds at risk while batch auctions were still enabled, ABC Labs worked to ensure trading was paused across all active yield DTFs. As of this post, trading for over >99% of TVL in yield DTFs had been paused.
- Governance proposals have been made to set the
batchAuctionLengthto 0, disabling the use of batch auctions in any form. stRSR governance takes 8 days to complete, so in just over 1 week batch auctions will be disabled, and trading will be unpaused.
NOTE: Pausing trading did not affect any other DTF functionality. Minting & redeeming are still enabled. stRSR functions are still enabled.
Conclusion
A bug was recently found in a 3rd party contract used by Yield DTFs. It was never exploited, the risk has been mitigated, and funds are safe.
We appreciate the hard work of the whitehat GregoAI (@therealgregoAI) / X for submitting their bug report to our Immunefi bug bounty program.
We encourage stRSR holders of any yield DTF to go vote on the pending proposals to disable batch auctions.