Dango DEX — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Dango DEX, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 11
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 11 closed, publicly disclosed Dango DEX reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Integer overflow / underflow, Logic error, across Cosmos-SDK, EVM-Solidity, Solana-Rust. 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
- Integer overflow / underflow findings disclosed against Dango DEX
- Logic error findings disclosed against Dango DEX
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Dango DEX: Inconsistent multiplication during order creation and cancellation can lead to panics and Denial of Service during order cancellation
Dango DEX, a Rust-based order-book DEX built on the LeftCurve/Grug framework, uses inconsistent multiplication paths when computing ASK quote amounts at order creation versus cancellation. Creation employs an integer-times-decimal multiplication that narrows after dividing by precision, while cancellation multiplies two decimal values whose raw product can exceed u128. An attacker can place an ASK order at a maximum price such that creation succeeds but cancellation always overflows and panics, permanently blocking the administrator's ForceCancelOrders cleanup and creating a persistent administration-level denial-of-service, with no direct loss of funds.
Dango DEX: Ineffective minimum order size check for ASK limit orders can lead to Denial of Service
Dango DEX's ASK-limit-order creation validates order size against the user-supplied quote value, computing amount_in_quote as base times the order's limit price. An attacker can defeat this by posting a 1-wei base quantity with an arbitrarily high price, generating a large volume of economically trivial ImmediateOrCancel orders that never fill. When the cron-driven auction sweeps and refunds all pending IOC orders in a single pass, the excessive order count can blow past block execution time and stall block production on the Tendermint/CometBFT chain. The same flood also exhausts gas in the owner-only ForceCancelOrders path, which cancels every order type, effectively blocking emergency order-book management.
Dango DEX: Attacker can exploit thin liquidity in xyk pool to save on fees.
Dango DEX computes the swap fee for multi-hop instant swaps from the output of the final pool in the route. An attacker who supplies a majority of the liquidity to a thin XYK pool at the end of the route can route a large trade through that pool, withdraw most of the resulting output via their LP position before it is fee-charged, and then swap the residual back to reverse slippage. The net effect is that the attacker receives more of the desired token than a direct single-pool swap would give and the protocol collects less fee revenue than it should, as demonstrated by a Rust integration test that asserts the exact USDC gain.
Dango DEX: A newly deployed pool can be DoS
A freshly deployed Dango DEX pool can be permanently bricked (DoS) by any caller supplying exactly zero of both base and quote assets as the very first liquidity provision. Because the code never validates that the initial deposit amounts or the first LP token mint are non-zero, the pool ends up in a state where reserves are still zero but LP supply is non-zero. Every subsequent liquidity provision then invokes add_subsequent_liquidity, which divides by the zero invariant/reserve value and reverts with an arithmetic error, leaving the pool unable to ever operate.
Dango DEX: User can pause all auctions by overflow in mid-price average
Dango DEX's on-chain cron job clears and re-saves resting orders for each trading pair each block, computing a mid-price from the best bid and best ask. Because these prices are stored as Udec128_24 fixed-point values, computing mid_price = (bid + ask) / 2 can overflow at the addition step when the ask is near the type maximum and the bid is a positive value. A user can intentionally place one extreme GTC sell and one small GTC buy on a fresh pair with no passive reserves, so no match occurs and the unchecked checked_add overflows when the resting book is saved. The resulting error bubbles out of the auction submessage into a reply handler that unconditionally sets a global PAUSED=true flag, causing a denial of service on auctions across every pair. The fix is to compute the mid price with the subtraction-safe form lo + (hi - lo) / 2 so the two extremes are never added.
Dango DEX: Any change in bucket size will DOS order cancellation leading to frozen user funds and halts the entire auction
Dango's auction-based DEX tracks liquidity depth per bucket, keyed by the bucket sizes configured when an order is created. When an administrator later updates pair bucket sizes via a batch update, order cancellation and auction cleanup both call decrease_liquidity_depths(), which reloads the new bucket sizes and fails because DEPTHS.modify() requires the old storage keys to still exist. Every cancellation attempt reverts, permanently freezing user funds, and the same failure in cron::auction() cleanup trips the protocol's pause mechanism, halting all trading and cutting off LP and protocol revenue.
All reports in this group
- Dango DEX: XYK reflect_curve omits swap fee in order sizing, leaking LP feesLogic error$0
- Dango DEX: The first Liquidity Provider can perform a fee less swap by providing unbalanced liquidity.Logic error$0
- Dango DEX: `OwnerMsg::ForceCancelOrders` is unusable due to the DEX contract lacking a `receive` function to accept refunds from cancelled passive liquidity ordersLogic error$0
- Dango DEX: Overflow in geometric can dos swapLogic error$0
- Dango DEX: Users may fail to add liquidity because of overflowInteger overflow/underflow$0