HydraDX — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for HydraDX, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 9
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 9 closed, publicly disclosed HydraDX 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, Oracle manipulation, Price manipulation, 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 HydraDX
- Oracle manipulation findings disclosed against HydraDX
- Price manipulation findings disclosed against HydraDX
- Front-running / MEV findings disclosed against HydraDX
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
HydraDX: complete liquidity removal will result in permanent disable of the liquidity addition and prevent minting shares for the liquidity providers.
HydraDX's Omnipool pallet allowed a position owner whose stake constituted the entire liquidity of a token pool to remove all of it, driving both asset reserve and total shares to zero. Because add_liquidity mints new shares proportionally via shares*amount/reserve, any subsequent addition either reverts on a division by zero or, if the reserve was restored by a donation, mints zero shares to the depositor, permanently disabling liquidity provision and trading for that asset. This dead state could be reached by a single actor withdrawing the initial listing position or by all LPs withdrawing normally, economically bricking the token's pool. The judge upheld it as a Medium after correcting an erroneous duplicate association, while the sponsor disputes it as intended design requiring a fresh add_token flow.
HydraDX: Users can MAKE EMA-Oracle price outdated with direct transfers to StableSwap
HydraDX's EMA oracle refreshes exchange rates only when StableSwap/Omnipool hooks fire on swaps, deposits, or withdrawals. Direct token transfers into a StableSwap account change pool balances and prices but trigger no oracle hook, so the oracle keeps serving a stale exchange rate. The runtime transfer filter only blocks transfers to the Omnipool protocol account, leaving StableSwap destinations unguarded. An attacker can exploit this staleness to tilt arbitrage in their favor or, under network congestion, keep rates distorted long enough to unjustly block liquidations in lending protocols that consume the oracle data.
HydraDX: An attacker possesses the capability to exhaust the entirety of liquidity within the stable swap pools by manipulating the buy function, specifically by setting the `asset_in` parameter equal to the `asset_out` parameter
HydraDX's Stableswap pallet `buy()` extrinsic accepted identical `asset_in` and `asset_out` values without validation. When both are equal, the underlying `calculate_in_given_out` math derives a new reserve identical to the old one, so the computed input amount collapses to zero (normalized upward to 1, ~1.001 after fees) while the requested full output is paid out. An unauthenticated attacker can therefore withdraw arbitrarily large pool liquidity for roughly one token unit by repeatedly calling `buy()`, draining the stable pools and causing losses to the protocol and liquidity providers. The reported fix adds an `ensure!(asset_out != asset_in)` guard at the start of the extrinsic. The finding was filed against the code4rena 2024-02-hydradx contest by castle_chain and independently by bin2chen.
HydraDX: Complete liquidity removals fail from stableswap pools
HydraDX's stableswap pallet only offers single-asset liquidity removal, omitting the multi-token withdrawal counterpart present in Curve's design. When a liquidity provider tries to redeem their entire LP balance, the curve math that must convert the composing tokens into a single asset fails because the underlying liquidity no longer exists, producing an arithmetic overflow that reverts the call. The included Rust PoC reproduces the failure by having ALICE redeem all 23786876415280195891619 shares from a three-asset pool. The net effect is that an LP holding the full share supply cannot fully exit the pool, economically locking their funds.
HydraDX: Malicious liquidity provider can put pool into highly manipulatable state
HydraDX's StableSwap AMM enforces a minimum-liquidity invariant so that pools cannot be reduced to easily manipulable dust: total pool issuance must stay at or above MinPoolLiquidity or be exactly zero. The remove_liquidity_one_asset() withdrawal enforces this with two checks, but withdraw_asset_amount() only validates the caller's own share balance and never inspects the pool's total issuance. Because LP shares are transferable, a malicious provider can deposit the minimum, move a single share to another address they control, then withdraw everything via withdraw_asset_amount(), leaving a pool with only dust liquidity. This breaks the stated invariant, making the degraded pool easier to price-manipulate and temporarily preventing other LPs (such as fixed smart contracts) from exiting through remove_liquidity_one_asset(). HydraDX confirmed the missing check but disputed severity, and the judge ruled Medium on the grounds of a rare edge-case temporary availability impact.
HydraDX: No `safe_withdrawal` option in `withdraw_protocol_liquidity` function in omnipool can be abused by frontrunners to cause losses to the admin when removing liquidity
HydraDX's omnipool exposes a `withdraw_protocol_liquidity` call for removing protocol-held LP positions that, unlike the parallel `remove_liquidity` path, has no `safe_withdrawal` option and therefore no `ensure_price` barrier. When an admin invokes it with a price parameter, a frontrunner can trade against the pool to move the spot price, so the withdrawal executes at adverse terms and the admin absorbs slippage losses that are not bounded to the ~2% cap enforced in the guarded path. The write-up ties the missing guard to a concrete, exploitable MEV path and recommends restoring the price barrier.
All reports in this group
- HydraDX: Re-adding assets to the omnipool can cause a problem with the oracleLogic error$0
- HydraDX: Storage can be bloated with low value liquidity positionsLogic error$0
- HydraDX: A huge loss of funds for all the users who try to remove liquidity after swapping got disabled at manipulated price.Logic error$0