Stablecoin vulnerabilities in disclosed bug bounty reports
Peg maintenance, collateral accounting and redemption paths — where a small accounting error becomes a supply error.
- Reports indexed
- 29
- Total paid
- $300k
- Critical
- 0
- Largest payout
- $300k
Stablecoins fail at the seams between minting, collateral accounting and redemption. A mint path that credits more than it collects, a redemption that values collateral differently than the mint did, or a peg mechanism whose stabilising action becomes destabilising under stress.
The disclosed findings also cover the operational surface: blocklist and pause functionality, upgrade authority, and the reserve attestation path — the parts that are administrative rather than algorithmic but carry the same supply risk.
Because stablecoins are used as collateral everywhere else, findings here frequently reference lending and DEX integrations as the amplification path.
What reviewers look for
- Mint and redeem paths valuing collateral by different methods
- Peg mechanisms with a destabilising region under stress
- Blocklist or pause functions with over-broad authority
- Reserve accounting divergent from circulating supply
- Redemption queues exploitable through ordering
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Stablecoin redemption path uses stale Chainlink round data
An algorithmic stablecoin's redemption module fetched Chainlink price data via latestRoundData without checking the update timestamp or round completeness status. During market volatility and L2 sequencer outages, oracle updates lagged, leaving stale collateral valuation in place on-chain. Attackers leveraged this discrepancy by buying discounted stablecoins on secondary markets and immediately redeeming them for full-value backing assets through 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.
Usual ETH0: Lack of on-chain deviation check for LST can lead to loss of assets
Usual ETH0's DaoCollateral prices liquid staking tokens such as wstETH using Lido's exchange-rate oracle (stEthPerToken), but the protocol cannot enable the depeg check for LST collateral because LST is not pegged 1:1 to ETH. With no on-chain threshold or deviation guard on that price path, a black-swan event such as a mass slashing of Lido validators can make the market price collapse while the slower exchange-rate oracle still reports a stale higher value, letting an attacker buy discounted wstETH, mint overvalued ETH0 against it, and redeem ETH0 for another LST at par to extract the difference. The team's reliance on an off-chain monitoring bot to pause the contract is ineffective because a transaction can be front-run, so the protocol becomes exit liquidity for depegged LSTs. The finding was acknowledged by the Usual team but deferred, and is rated Medium on the Sherlock contest.
Aegis.im YUSD: Insolvency as `YUSD` will depeg overtime as the redemption fees are disbursed with no collaterals backing them.
In AegisMinting.approveRedeemRequest, the protocol computes the collateral to return to a redeeming user from the full requested yusdAmount, then separately strips an insurance-fund fee from that yusd amount before burning. The fee-denominated portion of the YUSD is left outstanding as a liability with no collateral backing it, so every approved redemption converts fully-backed YUSD into unbacked YUSD. Over time, as redemption fees accumulate (configurable up to 50%), the contract's collateral pool drains relative to outstanding YUSD, driving a depeg and eventual insolvency. The team acknowledged the issue but declined to fix it at this time.
Aegis.im YUSD: A whale adversary can grief the redeem functionality through redeem limit consumption
Aegis.im's YUSD minting contract enforces a per-period redeem cap by incrementing a cumulative counter each time a user creates a redeem request, but it never decrements that counter when a request is withdrawn or rejected. A whale holding a large YUSD balance can therefore consume the entire period's redeem allowance with signed redeem requests and then withdraw them after expiry without the counter resetting. This denies legitimate users the ability to request redemptions until the period rolls over, a griefing DoS that costs the attacker only temporary fund lockup plus gas. The issue was acknowledged by the team but not fixed at the time of disclosure.
LoopFi: Unclaimed rewards handling issue in `AuraVault` contract functions (`AuraVault::deposit`, `AuraVault::mint`, `AuraVault::withdraw` and `AuraVault::redeem`)
LoopFi's AuraVault is an ERC-4626 vault that prices shares and assets through totalAssets(), which is implemented to return only the vault's underlying token balance held in an Aura RewardsPool. Because it omits earned-but-unclaimed rewards obtainable via IPool(rewardPool).earned(address(this)), every deposit, mint, withdraw and redeem is priced against an understated vault value, so users transacting while rewards have accrued receive a slightly incorrect number of shares or assets. This is an accounting/mispricing weakness rather than a direct theft primitive, and the effect is best measured in fractions of a percent alongside the reward cycle. The LoopFi sponsor acknowledged the report and stated the AuraVault will be removed and no longer used, neutralising the issue rather than shipping the proposed patch that adds earned rewards back into totalAssets().
All reports in this group
- Rubicon: An attacker can steal all tokens of users that use `FeeWrapper`Logic error$0
- Autonomint Colored Dollar V1: Lack of lastEthPrice sync between different chainsLogic error$0
- Ethena Labs: Non-whitelisted users can burn UStb and redeem collateral during WHITELIST_ENABLED stateLogic error$0
- Ethena Labs: Blacklisted user can burn tokens during WHITELIST_ENABLED stateAccess control$0
- Mento x Good$ Integration: `GoodDollarExchangeProvider::mintFromExpansion()` will change the price due to a rounding error in the new ratioInteger overflow/underflow$0
- Mento x Good$ Integration: Malicious user may frontrun `GoodDollarExpansionController::mintUBIFromReserveBalance()` to make protocol funds stuckLogic error$0
- SeeR PM: Users of protocol will be exposed to high slippage due to no callre-specified minimum output & deadline paramLogic error$0
- Perennial V2 Update #3: Emptyset reserve strategies may revert when aave/compound supply limit is reached or pool owner pause/froze the poolLogic error$0
- Midas - Instant Minter/Redeemer: Standard redemption in `RedemptionVault` does not update token allowance.Logic error$0
- DittoETH: Attacker can profit from discount feesLogic error$0
- DittoETH: A successfully disputed redemption proposal has still increased the redemption fee base rate; exploit to depeg dUSDLogic error$0
- DittoETH: The `shortOrder` verification bug on the `RedemptionFacet::proposeRedemption()` allows an attacker to leave a small `shortOrder` on the order book, leading to the protocol's bad debtLogic error$0
- DYAD: No incentive to liquidate when `CR <= 1` as asset received `<` dyad burnedLogic error$0
- Zivoe: ITO can be manipulatedLogic error$0
- PoolTogether: Lack of Slippage Protection in `withdraw`/`redeem` Functions of the VaultLogic error$0
- M^0: Malicious minters can repeatedly penalize their undercollateralized accounts in a short peroid of time, which can result in disfunctioning of critical protocol functions, such as `mintM`.Logic error$0
- M^0: Validator threshold can be bypassed: a single compromised validator can update minter's state to historical stateLogic error$0
- M^0: An earner can still continue earning even after being removed from the approved list.Access control$0
- Tapioca: Not properly tracking debt accrual leads mintOpenInterestDebt() to lose twTap rewardsLogic error$0
- Ubiquity: LibUbiquityPool::mintDollar/redeemDollar reliance on outdated TWAP oracle may be inefficient for preventing depegOracle manipulation$0
- Ubiquity: LibTWAPOracle::update Providing large liquidity will manipulate TWAP, DOSing redeem of uADsOracle manipulation$0
- Asymmetry Finance: In de-peg scenario, forcing full exit from every derivative & immediately re-entering can cause big losses for depositorsGovernance attack$0
- Asymmetry Finance: No slippage protection on `stake()` in SafEth.solLogic error$0