Sentiment V2 — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Sentiment V2, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 20
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 20 closed, publicly disclosed Sentiment V2 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 Oracle manipulation, Logic error, Integer overflow / underflow, 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
- Oracle manipulation findings disclosed against Sentiment V2
- Logic error findings disclosed against Sentiment V2
- Integer overflow / underflow findings disclosed against Sentiment V2
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Sentiment V2: RedStone oracle is vulnerable because ```updatePrice``` is not called during the ```getEthValue``` function.
Sentiment V2's RedstoneOracle keeps stale pricing because its getValueInEth view function reads cached assetUsdPrice/ethUsdPrice state values, while the updatePrice function that refreshes them is never invoked from within the price read path. Because updatePrice is callable by anyone and grants only three minutes of price liveness, a borrower can call it when collateral is expensive and omit it when collateral drops, sustaining an artificially inflated collateral valuation. This lets positions be opened or sustained at wrong ETH values, letting a user borrow against an overstated asset while repaying at a fairer, higher price. Sherlock judged the root cause valid at Medium severity after escalation.
Sentiment V2: Lack of slippage protection during withdrawal in SuperPool and Pool contracts.
Sentiment V2's Pool.withdraw() and SuperPool withdraw/redeem functions compute share/exchange rates at execution time without any min-amount-out or max-shares-in slippage guard. If a bad-debt liquidation lands in the same block interval as a user's pending withdrawal, the pool's totalDepositAssets shrinks and the share-to-asset exchange rate worsens, so the withdrawing user burns more shares (or receives fewer assets) than they expected. The finding was upheld as Medium after escalation, with the protocol acknowledging the issue; the recommended fix is to add minimum-amount-out to redeem() and maximum-shares-in to withdraw().
Sentiment V2: Liquidation fee is incorrectly calculated, leading to unprofitable liquidations
Sentiment V2's PositionManager.liquidate() computes the liquidation fee on the full collateral amount transferred to the liquidator rather than on the liquidator's net profit (collateral reward minus debt repaid). With a 30% fee this makes liquidations economically irrational in most cases: a liquidator repaying $90 of a debt-backed position with $98 of collateral receives only ~$68.6. Since no rational actor liquidates at a loss, underwater positions remain open and the protocol accrues bad debt, risking insolvency. The finding was acknowledged and the fee was repriced off liquidator profit via the linked fix PR.
Sentiment V2: None of the functions in SuperPool checks pause state
Sentiment V2's SuperPool contract inherits OpenZeppelin's Pausable and exposes an owner-only togglePause() function, but none of its user-facing functions apply the whenNotPaused modifier. As a result, toggling the pause state succeeds yet has no operational effect, so governance cannot halt deposits, mints, withdrawals or redemptions during an incident. The sponsor confirmed the finding and fixed it by adding whenNotPaused to deposit() and mint() in protocol-v2 PR #305. This is a governance/emergency-control defect rather than a direct attacker exploit, but it defeats the protocol's first line of defense during a crisis.
Sentiment V2: Not removing a token from the position assets upon an owner removing a token from the known assets will cause huge issues
Sentiment V2 lets the owner mark assets as supported collateral, and users add such assets to their positionAssets list for valuation. When the owner later un-marks an asset, that token is not removed from existing positions' positionAssets sets, so it keeps being counted toward collateral value. The owner-side workaround of deleting the asset's oracle is counterproductive because the RiskEngine reverts on a zero oracle address, blocking liquidations for those positions. The only sane remedy is removing the token from positionAssets with a time-delay to avoid instantly liquidating affected users, and the finding was adjudicated as Medium with several duplicates.
Sentiment V2: Protocol's interestFees + Interest in a pool can be lost because of precision loss when using low-decimal assets like USDT/USDC.
Sentiment V2's pool interest-accrual loses protocol fee income when pools use low-decimal assets such as USDT/USDC. Because interest and the interest fee are computed from asset amounts with 6 decimals, small interest accruals over short elapsed windows round feeAssets down to zero via mulDiv, yet pool.lastUpdated still advances — permanently checkpointing past the skipped fee. A borrower or lender can deliberately trigger accrue() on short intervals to suppress all or part of the protocol's interest fee, with the researcher demonstrating a ~9% fee loss on a realistic 1.5%-APY, 2000-USDC pool with 40-minute gaps, at trivial maintenance cost on low-gas chains. This is an accounting/precision defect rather than an oracle manipulation, and Sherlock adjudicated it as a Medium, Unique finding, acknowledging the issue.
All reports in this group
- Sentiment V2: User's can seize more assets during liquidation by using type(uint).maxLogic error$0
- Sentiment V2: `ChainlinkOracle` doesn't validate for minAnswer/maxAnswerOracle manipulation$0
- Sentiment V2: Base pools can get bricked if depositors pull outLogic error$0
- Sentiment V2: Super Pool shares can be inflated by bad debt leading to overflowsLogic error$0
- Sentiment V2: Under certain circumstances bad debt will cause first depositor to lose fundsLogic error$0
- Sentiment V2: Liquidations will revert if a position has been blacklisted for USDCLogic error$0
- Sentiment V2: Red Stone Oracle Can Time TravelOracle manipulation$0
- Sentiment V2: `SuperPool` fails to correctly deposit into poolsLogic error$0
- Sentiment V2: Liquidators may repay a position's debt to pools that are within their risk tolerance, breaking the concept of isolated risk in base poolsLogic error$0
- Sentiment V2: Exploiter can force user into unhealthy condition and liquidate himLogic error$0
- Sentiment V2: rounding error due to internal accounting and can steal some portion of the first depositors fundsInteger overflow/underflow$0
- Sentiment V2: LTV of 98% would be extremely dangerousLogic error$0
- Sentiment V2: Attacker Can Manipulate Interest Distribution by Exploiting Asset Transfers and Fee Accrual MechanismLogic error$0
- Sentiment V2: Super pool uses `ERC20.approve` instead of safe approvals, causing it to always revert on some ERC20sLogic error$0