Rova — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Rova, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 2
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 2 closed, publicly disclosed Rova reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, 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
- Logic error findings disclosed against Rova
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Rova: `maxTokenAmountPerUser` limit can be bypassed when currency token has less decimals than the launch token.
Rova's Launch.sol lets participants adjust their token allocation via updateParticipation. The function's cap check mixes raw token units with currency units (additionalCurrencyAmount/refundCurrencyAmount) before normalizing for decimal differences, so when the payment currency has fewer decimals than the launch token (e.g. 6-decimal USDC vs an 18-decimal token) the comparison is skewed. An attacker can first join with a small allocation and then raise it past the maxTokenAmountPerUser cap while the flawed check still passes. This produces oversized allocations, an unfair token distribution, and financial disadvantage for other participants. The finding was adjudicated as Medium in the Sherlock contest with no bounty.
Rova: `userTokens` accounting in `Launch.sol::updateParticipation` is updated incorrectly and can lead to loss of user funds, DOS and a broken invariant
In Rova's Launch contract, the updateParticipation function, when a user lowers their requested token amount in a launch group sale, incorrectly updates the _userTokensByLaunchGroup accounting by subtracting the refund currency amount from the stored token total instead of subtracting the actual reduction in requested tokens. Because token amount and currency amount differ in magnitude (and only cohere if the sale token shares the payment token's decimals), the stored per-user total is left inflated relative to what the user actually holds. Any subsequent cancelParticipation or processRefund then subtracts the user's true token amount from this corrupted, smaller balance, causing an arithmetic underflow that reverts the call. The result is that users cannot cancel their participation or claim issued refunds, permanently locking their contributed funds and effectively DoSing those operations.