Opus — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Opus, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 13
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 13 closed, publicly disclosed Opus 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 Logic error, Front-running / MEV, across EVM-Solidity, Other. 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 Opus
- Front-running / MEV findings disclosed against Opus
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Opus: Attacker can lock every trove withdrawals
Opus is a Starknet/Cairo collateralized-debt protocol (trove-based, Liquity-style) where the Sentinel contract enforces a per-gate maximum asset amount when converting asset amounts to Yang. The Abbot's withdraw path incorrectly reuses the deposit-oriented convert_to_yang, so the cap check applies an addition (current_total + enter_amt) even though the caller is withdrawing. An attacker who deposits until current_total equals max_amt can thereby cause every subsequent withdrawal from that gate to revert with 'SE: Exceeds max amount allowed', locking withdrawals for all trove owners until an admin reconfigures the limit. The judge downgraded severity from High to Medium because funds are recoverable via reconfiguration and the attacker sacrifices their own funds, and Opus confirmed they mitigated the issue based on this report.
Opus: Multiplier is incorrectly calculated in `Controller`
Opus's Cairo `Controller` miscomputes the proportional-integral multiplier that drives the yin borrowing rate: the `i_gain` factor is applied to the entire accumulated integral term instead of only to the freshly-computed nonlinear delta. Because `get_i_term_internal` already returns `old_i_term + nonlinear_transform(...) * time_since_last_update_scaled`, the caller's `multiplier += i_gain * new_i_term` re-multiplies the historical component on every update, compounding the gain repeatedly rather than once per increment. This distorts the multiplier and thereby the borrowing/interest pricing over time. The code4rena judge upheld the finding because the implementation contradicts the documented formula, and the Opus team confirmed.
Opus: Neglect of exceptional redistribution amounts in `withdraw_helper` function
Opus's Shrine `withdraw_helper` computes a trove's post-withdrawal yang balance before calling `charge`, the function that also applies interest and any exceptional yang redistribution into the trove during the same transaction. The storage write that follows overwrites the deposit with the earlier pre-charge value, so any redistribution credited by `charge` is silently discarded. A user withdrawing even a small amount in a transaction where an exceptional redistribution occurs permanently forfeits that credited yang, a direct financial loss. The recommended fix reorders the function so `charge` runs before the new balance and total are derived.
Opus: A user can steal from the shrine by forcing redistribution of their trove; due to incorrect logic trove debt will be reset but yangs kept
Opus's shrine redistribution helper contains an array-desynchronization bug. When iterating a trove's yangs, it appends the trove's updated balance to `updated_trove_yang_balances` and continues, but only records the matching total in `new_yang_totals` in the non-zero branch, so the two arrays advance at different rates and per-trove entries are silently skipped. After a 100% redistribution, a trove can be left with its debt zeroed while its collateral (yang) balance is untouched. An attacker who can force redistribution of their own trove, for example by draining the absorption/stability pool and letting a small price move push LTV over threshold, ends up debt-free yet can withdraw the full collateral, effectively stealing value from the shrine and breaking its total-yang invariant. The finding includes a Cairo test reproduction and specifies that the parallel arrays must be kept in lockstep as the fix.
Opus: `convert_to_yang_helper()` loss precision
Opus's Cairo gate contract computes user deposit shares in `convert_to_yang_helper()` by multiplying the raw (non-18-decimal) asset amount by `total_yang` inside an 18-decimal Wad normalization before the final division by total assets. For assets with fewer than 18 decimals, such as BTC with 8 decimals, the intermediate truncation can round a legitimate deposit down to zero shares, causing the depositor to forfeit the full deposited value. The report quantifies the loss with a fresh-pool BTC example (a ~36 USD deposit becoming 0 shares) and demonstrates the same numeric path in a failing regression test before and after the fix. The recommended correction moves the intermediate math into u256 so the division happens after the full multiplication rather than after an early Wad truncation.
Opus: An attacker could manipulate debt exceptional redistribution because it is allowed to deposit into any trove
Opus is a Liquity-style trove system where a liquidated trove's debt and collateral are redistributed among other troves in proportion to their collateral composition, with an exceptional-redistribution fallback that spreads an asset's value across all remaining assets when no other trove holds it. Because abbot.deposit() does not require the caller to be the trove's owner, an attacker can unilaterally deposit a small amount of a redistributed asset into a victim's trove. This converts what would have been a system-wide shared loss into a concentrated bad-debt transfer onto the victim trove. The judge upheld the finding as Medium, noting the attack's validity despite the low likelihood of a liquidating trove holding an asset no other trove holds.
All reports in this group
- Opus: The `provide()` function does not reset withdrawal requests, allowing an attacker to bypass risk-free yield tactics protectionLogic error$0
- Opus: after shut, no pulled redistribution yang will be lockedLogic error$0
- Opus: ERC4626 inflate issue mitigation is not sufficientFront-running / MEV$0
- Opus: Shrine's recovery mode can be weaponized as leverage to liquidate healthy trovesLogic error$0
- Opus: Unhealthy troves with LTV > 90% cannot always be absorbed as intendedLogic error$0
- Opus: Collateral cannot be withdrawn from trove once yang is suspendedLogic error$0
- Opus: Loss of liquidation compensation assets in absorbLogic error$0