Reserve — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Reserve, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 7
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 7 closed, publicly disclosed Reserve reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Access control, Front-running / MEV, Governance attack, Logic error, Reentrancy, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Access control findings disclosed against Reserve
- Front-running / MEV findings disclosed against Reserve
- Governance attack findings disclosed against Reserve
- Logic error findings disclosed against Reserve
- Reentrancy findings disclosed against Reserve
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Reserve: RToken can manipulate distribution to avoid paying DAO fees
Reserve Protocol RTokens distribute revenue between RSR and RToken destinations, taking a percentage DAO fee on the RSR distribution branch. An RToken governance can manipulate distribution settings to systematically avoid paying the full DAO fee. By adding RSR as its own destination address (causing token distribution transfers to revert and force-accumulating RSR revenue) and subsequently shifting the distribution ratio before resetting the target, governance can bypass the fee logic and reduce DAO fees paid from 10% to approximately 1%.
Reserve: Broken assumptions can lead to the inability to seize RSR
A state desynchronization vulnerability in Reserve's StRSR contract allows an actor to break internal rate invariants by front-running `seizeRSR` operations. By executing a sequence of micro-unstakes and micro-stakes, an attacker causes `totalStakes` to hit zero while leaving a non-zero `stakeRSR` balance. When `seizeRSR` subsequently executes, it recalculates `stakeRate` down to zero, causing any future calls to `exchangeRate()` to revert with a division-by-zero panic and rendering RSR seizure unexecutable.
Reserve: The default Governor Anastasius is unable to call `resetStakes`
In Reserve Protocol, executing a proposal through the default Governor Anastasius contract to call `resetStakes` permanently reverts. During execution, `resetStakes` increments the protocol's internal staking `era` variable. However, the governance contract checks that the proposal started in the current era *after* executing the call payload rather than before. As a result, the state change induced by `resetStakes` causes the trailing era validation check to fail, preventing governance from ever executing stake resets.
Reserve: Users can dodge losses due to StRSR era changes with instant operations
In Reserve's StRSR contract, stake rate and draft rate exchange calculations wrap into new eras independently when hitting upper bounds during collateral seizures. Because stake rate and draft rate track active stakes and pending withdrawals separately, users can monitor pending transactions that trigger an era reset for only one rate bucket. By front-running the seizure with an unstake or cancelUnstake call and back-running it immediately after, opportunistic stakers can dodge socialized slashings while leaving other participants to absorb the loss.
Reserve: The time available for a canceled withdrawal should not impact future unstaking processes
In Reserve's StRSR contract, unstaking requests are queued in an array with availability timestamps calculated using the current global `unstakingDelay` and the preceding queue item's `availableAt` time. When users cancel pending unstakes, the contract updates an index tracking active drafts (`firstRemainingDraft`) rather than deleting elements from the underlying array. If an admin reduces the global `unstakingDelay`, any subsequent unstake request by a user who previously canceled a draft will evaluate the stale array entry's `availableAt` timestamp as `lastAvailableAt`. This logic error causes newly created unstake drafts to be locked for the longer duration of the canceled request rather than the updated, shorter protocol delay.
Reserve: Dutch auctions can fail to settle if any other collateral in the basket behaves unexpectedly
In Reserve Protocol's BackingManager, settlement of Dutch auctions attempts to chain directly into collateral rebalancing using a Solidity try-catch block. The implementation assumes that receiving empty error data inside the catch block exclusively signals an out-of-gas condition. However, external operations during rebalancing—such as interactions with upgradeable collateral tokens or calls to empty contract addresses—can also revert with empty error bytes. As a result, unexpected reverts from collateral assets cause auction settlements to fail entirely, preventing trades from clearing at fair market value.