Mento x Good$ Integration — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Mento x Good$ Integration, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 3
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 3 closed, publicly disclosed Mento x Good$ Integration 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, 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
- Logic error findings disclosed against Mento x Good$ Integration
- Integer overflow / underflow findings disclosed against Mento x Good$ Integration
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Mento x Good$ Integration: `TradingLimits::update()` incorrectly only rounds up when `deltaFlowUnits` becomes 0, which will silently increase trading limits
Mento's TradingLimits library reports per-period token flow by truncating raw traded value down to whole token units, dividing by the token decimals. The update function only corrects the rounding when the truncated result is exactly zero, so most swaps under-record the true traded amount. A trader can therefore submit repeated chunks just below the rounding boundary and move up to roughly double the configured trading limit before the aggregate limit register is exhausted, and the same under-recording also happens organically for arbitrary swap sizes. The recommended fix rounds every truncated value up away from zero rather than only the zero case. The protocol has acknowledged the finding.
Mento x Good$ Integration: `GoodDollarExchangeProvider::mintFromExpansion()` will change the price due to a rounding error in the new ratio
Mento's GoodDollarExchangeProvider.mintFromExpansion() mints expansion supply tokens while intending to keep the Bancor price (Reserve/(Supply*reserveRatio)) constant. A fixed-point precision mismatch breaks that invariant: the new ratio is computed at full 1e18 precision and used to size the mint, yet the stored reserveRatio is downscaled to 1e8. The resulting amountToMint exceeds what the stored ratio implies, so the price drifts on every expansion call, violating the documented invariant. Two related precision-loss paths are flagged in mintFromInterest() and updateRatioForReward(). The protocol fixed it by rounding the ratio back to 1e8 precision in PR #548.
Mento x Good$ Integration: Malicious user may frontrun `GoodDollarExpansionController::mintUBIFromReserveBalance()` to make protocol funds stuck
GoodDollar's expansion controller mints G tokens to the distribution helper whenever reserve interest or reserve balance is forwarded, but the underlying mintFromInterest() returns zero when the exchange's token supply has been fully purchased. A front-runner can buy out all G via Bancor swapIn/swapOut to drain tokenSupply to zero, then the expansion function executes its transfer and mint call with amountToMint=0. The reserve receives real funds while no corresponding G is minted, silently misaccounting the expansion and potentially stranding the transferred assets. The protocol acknowledged the issue.