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
3
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.

highPrice manipulationEVM-Solidity$300k

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.

Algorithmic StablecoinsherlockOct 17, 2023Open
mediumLogic errorEVM-Solidity$0

Asymmetry Finance: No slippage protection on `stake()` in SafEth.sol

Asymmetry Finance's `SafEth.sol` smart contract lacked slippage protection in its `stake()` function when minting `safETH` tokens to users. The amount of `safETH` minted depends on the real-time valuation of the contract's underlying liquid staking derivative tokens relative to total supply. Without a user-defined minimum output parameter, transactions could be subjected to adverse price movements, front-running, or sandwich attacks, resulting in users receiving fewer minted tokens than expected.

Asymmetry Financecode4renaJul 28, 2023Open
mediumGovernance attackEVM-Solidity$0

Asymmetry Finance: In de-peg scenario, forcing full exit from every derivative & immediately re-entering can cause big losses for depositors

Asymmetry Finance's rebalancing logic in `rebalanceToWeights` unwinds and fully liquidates all underlying liquid staking derivative (LSD) positions into ETH before re-allocating according to target weights. During market volatility or token de-pegging, this full-exit and full-re-entry strategy subjects the protocol to massive unnecessary slippage, DEX pool fees, and price impact across non-de-pegged assets. A marginal rebalancing design would instead adjust only the necessary deltas, avoiding severe capital losses for depositors.

Asymmetry Financecode4renaJul 28, 2023Open

Vulnerability classes seen in this protocol type

Related protocol type pages