Monolith Stablecoin Factory — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Monolith Stablecoin Factory, 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 Monolith Stablecoin Factory 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, 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 Monolith Stablecoin Factory
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Monolith Stablecoin Factory: Inconsistency in position health checks will lead to the incorrect user liquidations
Monolith Stablecoin Factory's Lender contract contains an inconsistency between two solvency checks. The adjust() function validates a position as healthy when debtBalance is less than or equal to borrowingPower, while the liquidation path in getLiquidatableDebt() only skips liquidation when borrowingPower is strictly greater than debt. At the exact boundary where borrowingPower equals debt, a user's position is considered solvent by the deposit/borrow path yet still qualifies as liquidatable, allowing an otherwise-healthy account to have its collateral seized. The finding was reported by a large group of independent contest researchers and the proposed fix aligns both comparisons to use the non-strict inequality.
Monolith Stablecoin Factory: User can abuse rounding issue in order to borrow unbacked tokens
The Monolith Lender's free-debt share accounting is vulnerable to a rounding-based inflation attack. By repeatedly borrowing and redeeming all but one wei of debt, an attacker can drive totalFreeDebtShares to ~1e32 while each account's personal debt rounds up to just 1, because the debasement step that normally resets the ratio can be defeated with debts larger than 1e18. After repaying the last wei on one wallet, totalFreeDebt reaches 0 while the share count stays enormous, so the next borrow mints shares 1:1 against the inflated denominator. This lets a wallet borrow ~1e27 tokens (~$1b) in face value while only receiving ~1e22 in actual debt liability, effectively minting unbacked tokens and draining the protocol.
Monolith Stablecoin Factory: EIP violation for `totalAssets()` in the `Vault`
The Monolith Stablecoin Factory Vault implements EIP-4626's totalAssets() view function, which the standard mandates MUST NOT revert. In this implementation totalAssets() calls getPendingInterest() on the Lender, which invokes calculateInterest() inside a try/catch block. If that internal call throws (e.g. division by zero), the catch branch enforces require(gasBefore >= INTEREST_CALCULATION_GAS_REQUIREMENT, ...) with a 40000-gas threshold that is evaluated only after a revert occurs. Callers who do not forward the extra gas their RPC estimated will therefore see totalAssets() revert instead of returning a value, breaking off-chain pricing and downstream integrations that assume the view function never reverts. The Sherlock judges ruled this a valid Medium under the contest rule that EIP MUST-statement violations in view functions count even with low impact; the team acknowledged the issue but declined to fix it.