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
- 4
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 4 closed, publicly disclosed Sentiment V2 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 Oracle manipulation, 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
- Oracle manipulation findings disclosed against Sentiment V2
- Logic error 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: Red Stone Oracle Can Time Travel
Sentiment V2's RedstoneCoreOracle caches the asset and ETH/USD prices whenever any user calls updatePrice(), but imposes no replay protection: as long as newly submitted observations fall within the three-minute validity window, the same or different observations can be swapped back and forth arbitrarily, even within a single transaction. An attacker holding two valid Redstone payloads can flip the cached price between a minimum and a maximum on demand, trading against the favorable reading and enabling atomic liquidations or arbitrage. Sherlock's final adjudication upgraded the issue to High severity with duplicates after the escalation was accepted, and the team fixed it by requiring the three-minute period to elapse before each new update.
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: Base pools can get bricked if depositors pull out
In Sentiment V2's Pool contract, rounding in the asset-to-share conversion during withdrawals can leave a pool with non-zero deposit assets but zero deposit shares. Because convertToShares rounds down to zero in this state, every subsequent deposit reverts with Pool_ZeroSharesDeposit, permanently bricking the pool. An attacker can trigger this on a freshly initialized empty pool (no other depositors) and, because pool IDs are deterministic per owner/asset/rate-model key, can front-run and brick all pools for a targeted owner, causing a denial-of-service. No funds are lost since the condition only arises when the pool has no remaining depositors or borrowers.
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().