# Issue H-1: Incorrect rounding direction in geometric pool `ask_exact_amount_out` allows theft of funds Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/68 ## Found by haxagon, heavyw8t ### Summary Incorrect rounding direction in geometric pool `ask_exact_amount_out` allows theft of funds ### Root Cause There is an incorrect rounding direction in geometric pool `ask_exact_amount_out` which allows theft of funds. https://github.com/left-curve/left-curve/blob/main/dango/dex/src/core/geometric.rs#L185-L206 ```rs fn ask_exact_amount_out( ask_amount_in_quote: Uint128, passive_bids: Box>, ) -> anyhow::Result { let mut remaining_ask_in_quote = ask_amount_in_quote.checked_into_dec::<6>()?; let mut input_amount = Udec128::ZERO; for (price, amount) in passive_bids { let remaining_ask = remaining_ask_in_quote.checked_div_dec_floor(price)?; let matched_amount = cmp::min(amount.checked_into_dec()?, remaining_ask); input_amount.checked_add_assign(matched_amount)?; let matched_amount_in_quote = matched_amount.checked_mul_dec_ceil(price)?; remaining_ask_in_quote.checked_sub_assign(matched_amount_in_quote)?; if remaining_ask_in_quote.is_zero() || remaining_ask.is_zero() || matched_amount_in_quote.is_zero() { return Ok(input_amount.into_int()); } } bail!("not enough liquidity to fulfill the swap! remaining amount: {remaining_ask_in_quote}") } ``` `remaining_ask_in_quote.checked_div_dec_floor` favors the trader, as the `matched_amount` will be lower resulting in a lesser input amount for an exact output. `into_int` which is the bigger issue then also truncates again later, also favoring the trader. Note: the issue also affects the `bid_exact_amount_out` function as it floors the `input_amount` using the same `into_int` function. But the attack path is less strong there but still an issue nevertheless because you can only round down the USDC. ### Internal Pre-conditions - ### External Pre-conditions - ### Attack Path Consider a scenario BTC-USDC pool where 1 sat unit of BTC = 1999 units of USDC. An attacker can execute a swap with exact amount out 1999 units of USDC which translates to 1.999 sat of BTC. Since `remaining_ask_in_quote.checked_div_dec_floor(price)?` operates on `Udec128`, there isn't a big impact here yet as the floor is only occuring at the decimal point value. However once we reach `input_amount.into_int()` the entire decimal value of `input_amount` which is a `Udec128` will get completely truncated, resulting in an `input_amount` of 1 sats of BTC Essentially, the attacker can obtain 1999 units of USDC while paying 1 sats of BTC every swap (actual price: 1000 units of USDC per 1 sat of BTC). Eventually this can accumulate with multiple swaps to drain the BTC pool. ### Impact Loss of funds. ### PoC _No response_ ### Mitigation _No response_ # Issue H-2: Users can swap at the best price by splitting swap into several small swap. Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/291 ## Found by Hurricane, MysteryAuditor, ami, blockace, haxagon, heavyw8t ### Summary In the swap of geometric pair, the protocol matches the passive orders to the user's swap order. However, users can swap at the best price by splitting swap into several small swap. ### Root Cause In the `geometric.swap_exact_amount_in` function, it creates the passive orders and matches them to the user created swap order from [L61](https://github.com/sherlock-audit/2025-09-dango-dex/blob/main/left-curve/dango/dex/src/core/geometric.rs#L61). ```rs L61: if input.denom == *base_denom { ask_exact_amount_in(input.amount, passive_bids) } else if input.denom == *quote_denom { bid_exact_amount_in(input.amount, passive_asks) } ``` The `reflect_curve` function creates the `params.limit` numbers of ask and bid orders. The bid orders' price are decreasing and ask orders' price are increasing. By splitting the swap into several small swaps, users can swap at the best passive order. Let's consider the following scenario: - There is the token1: token2 pair(geometric) - reserve of token1: 1000 - reserve of token2: 10000 - 1 token1 = 10 usd, 1 token2 = 1 usd - swap_fee_rate is 0 for the simplicity - params.spacing: 1 - params.limit: 3 - params.ratio: 10% - Alice is going to swap 300 token1 to token2 in one transaction: - `reflect_curve` function creates 5 passive bids: (price, size): (10, 100), (9, 111.11), (8, 125) - As a result, Alice receives 2712 amount of token2: 100 * 10 + 111.11 * 9 + 89 * 8 = 1000 + 1000 + 712 = 2712 - If Bob swaps 300 token1 using 3 times of swapping of 100 token1 in one transaction: - Bob receives 1000 token2 in one swap of 100 token1 - Totally, Bob receives 3000 token2 As a result, Bob receives more tokens than Alice. ### Internal pre-conditions None ### External pre-conditions 1. None ### Attack Path None ### Impact This causes unfair swapping for users. ### PoC None ### Mitigation Add the cooldown period for swapping or don't allow for users to execute several swap in one transaction. # Issue H-3: Asymmetric liquidity provision to geometric pool can allow attacker to purchase at flat oracle price, irrespective of trade size. Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/299 ## Found by axelot, blockace, haxagon ### Summary Asymmetric liquidity provision to geometric pool can allow attacker to purchase at flat oracle price, irrespective of trade size. ### Root Cause The geometric pool reflects passive orders centered at the oracle price, independent of pool balances. Prices across levels are spaced by a fixed tick spacing and order sizes follow a geometric ratio of remaining inventory. https://github.com/left-curve/left-curve/blob/main/dango/dex/src/core/geometric.rs#L211-L294 ```rs pub fn reflect_curve( oracle_querier: &mut OracleQuerier, base_denom: &Denom, quote_denom: &Denom, base_reserve: Uint128, quote_reserve: Uint128, params: Geometric, swap_fee_rate: Bounded, ) -> anyhow::Result<( Box>, Box>, )> { // Compute the price of the base asset denominated in the quote asset. // We will place orders above and below this price. // // Note that we aren't computing the price in the human units, but in their // base units. In other words, we don't want to know how many BTC is per USDC; // we want to know how many sat (1e-8 BTC) is per 1e-6 USDC. let marginal_price = { const PRECISION: Uint128 = Uint128::new(1_000_000); let base_price: Price = oracle_querier .query_price(base_denom, None)? .value_of_unit_amount(PRECISION)?; let quote_price: Price = oracle_querier .query_price(quote_denom, None)? .value_of_unit_amount(PRECISION)?; base_price.checked_div(quote_price)? }; // Construct bid price iterator with decreasing prices. let bids = { let one_sub_fee_rate = Udec128::ONE.checked_sub(*swap_fee_rate)?; let bid_starting_price = marginal_price.checked_mul(one_sub_fee_rate)?; let mut maybe_price = Some(bid_starting_price); let mut remaining_quote = quote_reserve; iter::from_fn(move || { let price = maybe_price?; if price.is_zero() { return None; } let size_in_quote = remaining_quote.checked_mul_dec(*params.ratio).ok()?; let size = size_in_quote.checked_div_dec_floor(price).ok()?; if size.is_zero() { return None; } maybe_price = price.checked_sub(params.spacing).ok(); remaining_quote.checked_sub_assign(size_in_quote).ok()?; Some((price, size)) }) .take(params.limit) }; // Construct ask price iterator with increasing prices. let asks = { let one_plus_fee_rate = Udec128::ONE.checked_add(*swap_fee_rate)?; let ask_starting_price = marginal_price.checked_mul(one_plus_fee_rate)?; let mut maybe_price = Some(ask_starting_price); let mut remaining_base = base_reserve; iter::from_fn(move || { let price = maybe_price?; let size = remaining_base.checked_mul_dec(*params.ratio).ok()?; if size.is_zero() { return None; } maybe_price = price.checked_add(params.spacing).ok(); remaining_base.checked_sub_assign(size).ok()?; Some((price, size)) }) .take(params.limit) }; Ok((Box::new(bids), Box::new(asks))) } ``` The problem here is that asymmetric liquidity provision allows performing a virtual swap, that is effectively at oracle price, that ignores the spacing and geometric ratio parameters, this allows effectively purchasing the up to the entire liquidity in the pool, bypassing the price increase applied by the geometric pool for increasing liquidity ### Internal Pre-conditions - ### External Pre-conditions - ### Attack Path Suppose we have a geometric pool consisting of 10 ETH and 20000 USDC and 1 ETH = 2000 USDC and a swap fee of 0.1%. An attacker wants to swap 1 ETH for USDC in this pool. They can call `add_liquidity` with 2.222 ETH. They then immediately burn the LP tokens via `withdraw_liquidity` to withdraw some ETH and USDC, realizing their virtual swap performed during the asymmetric deposit. USD value of virtual swap: $$ x = \frac{4444 \cdot 20000}{20000 + 20000 + 4444} = 2000 $$ Fee rate: $$ f = \frac{2000 \cdot 0.001}{4444} = 0.00045 $$ Total ETH withdrawn after LP token burn: $$ ETH = (1-0.00045)(\frac{44444}{40000} - 1)(\frac{44444}{40000})^{-1}(12.2222) = 1.2215 $$ Total USDC withdrawn after LP token burn: $$ USDC = (1-0.00045)(\frac{44444}{40000} - 1)(\frac{44444}{40000})^{-1}(20000) = 1999 $$ Noticeably, we can always obtain a 1 ETH to 2000 USDC trade from the geometric pool _irregardless_ of the `params.spacing` and `params.ratio`. In comparison, suppose our `params.ratio` is 0.05 and the `params.spacing` is 100 USD. We obtain the following relevant price bands > 0.5 ETH @ 1998 USDC > 0.475 ETH @ 1898 USDC > 0.45125 ETH @ 1798 USDC To fill our 1 ETH ask, we execute the orders 0.5 ETH @ 1998 USDC, 0.475 ETH @ 1898 USDC and 0.025 ETH @ 1798 USDC, this yields ~1946 USDC. As seen, performing the asymmetric liquidity provision exploit can allow bypassing the price bands of the geometric pool and allow obtaining a better swap for at the flat oracle price. ### Impact This allows an attacker to execute the virtual swap at the flat oracle price bypassing the price bands of the geometric pool. As a result, the pool earns lesser than intended as it effectively executes large orders without adjusting it's price to measure demand. During periods of high volatility (even if the oracle is accurate), arbitrageurs can exploit this by purchasing large orders at the flat oracle price without the pool price being able to adjust price impact to meet the demand in the intended manner. This result in losses for LP providers. ### PoC _No response_ ### Mitigation _No response_ # Issue M-1: XYK reflect_curve omits swap fee in order sizing, leaking LP fees Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/166 ## Found by blockace, haxagon ### Summary The `reflect_curve` function for the XYK pool sizes passive bid/ask orders without accounting for the swap fee, allowing takers to match those orders effectively fee-free. This under-collects fees that should accrue to liquidity providers, causing direct LP losses in addition to normal impermanent loss. ### Root Cause In [`dango/dex/src/core/xyk.rs`](https://github.com/sherlock-audit/2025-09-dango-dex/blob/main/left-curve/dango/dex/src/core/xyk.rs#L97-L208), the total order size at price `p` is computed from the reserves as if there were no swap fee. For bids, the size uses `quote_reserve / p - base_reserve`; for asks, it uses `base_reserve - quote_reserve / p`. The fee factor `(1 - swap_fee)` is omitted, so passive orders are reflected at sizes that do not accrue the fee when taken. Relevant code (bids): ```rust // dango/dex/src/core/xyk.rs (bids) let quote_reserve_div_price = quote_reserve.checked_div_dec(price).ok()?; let mut size = quote_reserve_div_price.checked_sub(base_reserve).ok()?; ``` Relevant code (asks): ```rust // dango/dex/src/core/xyk.rs (asks) let quote_reserve_div_price = quote_reserve.checked_div_dec(price).ok()?; let size = base_reserve.checked_sub(quote_reserve_div_price).ok()?; ``` Mathematically, for a bid at price `p` with reserves `R_b` and `R_q` and fee `f`, the equality `s * p = (R_q * s)/(R_b + s) * (1 - f)` yields `s = R_q * (1 - f) / p - R_b`. The implementation lacks the `(1 - f)` term. A symmetric adjustment is required for asks as well. Detailed derivation - Bids (pool buys base, taker sells base): - Reserves: `R_b` (base), `R_q` (quote); price `p` (quote per base); fee `f`. - Exact-in (base in) output after fee: `Q_out = (R_q * s)/(R_b + s) * (1 - f)`. - Passive bid at price `p` promises `s * p` quote for `s` base: set `s * p = Q_out`. - Solve: `p = (R_q/(R_b + s)) * (1 - f)` ⇒ `R_b + s = R_q * (1 - f) / p` ⇒ `s = R_q * (1 - f) / p - R_b`. - Therefore total size at price `p` must be `Rq*(1-f)/p - Rb`. - Asks (pool sells base, taker buys base): - Taker pays quote `x = s * p`, wants to receive `s` base. - Exact-in (quote in) output after fee: `B_out = (R_b * x)/(R_q + x) * (1 - f)`. - Set `s = B_out` with `x = s * p`: `s = (R_b * s * p)/(R_q + s * p) * (1 - f)` ⇒ `1 = (R_b * p)/(R_q + s * p) * (1 - f)`. - Hence `R_q + s * p = R_b * p * (1 - f)` ⇒ `s * p = R_b * p * (1 - f) - R_q` ⇒ `s = R_b * (1 - f) - R_q / p`. - Therefore total size at price `p` must be `Rb*(1-f) - Rq/p`. ### Internal Pre-conditions . ### External Pre-conditions . ### Attack Path 1. A trader creates bid/ask orders based on XYK passive pool liquidity. 2. The trader doesn't pay the swap fee when taking the orders. 3. The pool doesn't accrue the swap fee, causing loss for LPs. ### Impact - Liquidity providers lose expected fee revenue on reflected (passive) fills. - Traders bypass the swap fee by taking the orders. ### PoC The following test demonstrates that, after matching the first passive bid, the pool’s invariant `K = X * Y` does not increase, showing that swap fees were not accrued to the pool. ```rust // dango/testing/tests/dex.rs #[test] fn xyk_reflect_curve_incorrect_size_poc() { let (mut suite, mut accounts, _, contracts, _) = setup_test_naive(Default::default()); // Setup, DANGO:USDC = 1:1 let pool_type = PassiveLiquidity::Xyk(Xyk { spacing: Udec128::ONE.checked_div(Udec128::new(100)).unwrap(), reserve_ratio: Bounded::new_unchecked(Udec128::ZERO), limit: 10, }); let lp_denom = Denom::try_from("dex/pool/dango/usdc").unwrap(); let initial_reserves = coins! { dango::DENOM.clone() => 10000, usdc::DENOM.clone() => 10000, }; let swap_fee = Udec128::new_percent(1); // 1% swap fee let oracle_prices = vec![ (dango::DENOM.clone(), Udec128::new(1)), (usdc::DENOM.clone(), Udec128::new(1)), ]; // Add the pair to the DEX suite .execute( &mut accounts.owner, contracts.dex, &dex::ExecuteMsg::Owner(dex::OwnerMsg::BatchUpdatePairs(vec![PairUpdate { base_denom: dango::DENOM.clone(), quote_denom: usdc::DENOM.clone(), params: PairParams { lp_denom: lp_denom.clone(), bucket_sizes: BTreeSet::new(), swap_fee_rate: Bounded::new_unchecked(swap_fee), pool_type, min_order_size: Uint128::ZERO, }, }])), Coins::new(), ) .should_succeed(); // Register the oracle prices for (denom, price) in oracle_prices { suite .execute( &mut accounts.owner, contracts.oracle, &oracle::ExecuteMsg::RegisterPriceSources(btree_map! { denom => PriceSource::Fixed { humanized_price: price, precision: 6, timestamp: Timestamp::from_seconds(1730802926), }, }), Coins::new(), ) .should_succeed(); } // Provide initial liquidity to the Pool suite .execute( &mut accounts.owner, contracts.dex, &dex::ExecuteMsg::ProvideLiquidity { base_denom: dango::DENOM.clone(), quote_denom: usdc::DENOM.clone(), }, initial_reserves.clone(), ) .should_succeed(); // For XYK, first passive bid price should be 0.99 which is (1 - swap_fee) and size will be 101.01010101... // So create an ask order that matches the first passive bid order suite.balances().record(&accounts.user1); let ask_funds = Coins::one(dango::DENOM.clone(), Uint128::new(101)).unwrap(); let msg = Message::execute( contracts.dex, &dex::ExecuteMsg::BatchUpdateOrders { creates: vec![CreateOrderRequest::new_limit( dango::DENOM.clone(), usdc::DENOM.clone(), Direction::Ask, NonZero::new_unchecked(Price::checked_from_ratio(99, 100).unwrap()), // 0.99 NonZero::new_unchecked(Uint128::new(101)), )], cancels: None, }, ask_funds, ) .unwrap(); let tx = accounts .user1 .sign_transaction(NonEmpty::new_unchecked(vec![msg]), &suite.chain_id, 100_000) .unwrap(); suite .make_block(vec![tx]) .block_outcome .tx_outcomes .into_iter() .for_each(|outcome| { outcome.should_succeed(); }); // Check that the user balance has changed, exchanging 101 DANGO for 99 USDC suite.balances().should_change(&accounts.user1, btree_map! { dango::DENOM.clone() => BalanceChange::Decreased(101), usdc::DENOM.clone() => BalanceChange::Increased(99), }); // Now check the reserves and K = X * Y let reserve = suite .query_wasm_smart(contracts.dex, QueryReserveRequest { base_denom: dango::DENOM.clone(), quote_denom: usdc::DENOM.clone(), }) .unwrap(); let dango_reserve = reserve .amount_of(&dango::DENOM.clone()) .unwrap() .into_inner(); let usdc_reserve = reserve .amount_of(&usdc::DENOM.clone()) .unwrap() .into_inner(); println!("DANGO reserve: {}", dango_reserve); println!("USDC reserve: {}", usdc_reserve); // Verifies that swap fee not accrued that means the constant product K is not increased assert!(dango_reserve * usdc_reserve <= 10000 * 10000); } ``` ### Mitigation Adjust the sizing formulas to incorporate the swap fee: - Bids: use `s_total(p) = R_q * (1 - f) / p - R_b`. - Asks: use `s_total(p) = R_b * (1 - f) - R_q / p`. # Issue M-2: The first Liquidity Provider can perform a fee less swap by providing unbalanced liquidity. Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/237 ## Found by Synthrax, Vigilia-Aethereum, d33p ### Summary When users provide unbalanced liquidity, a swap is simulated and a fee is charged. However, this is not done during the initial liquidity provisioning. So the first Liquidity Provider can provide 1000 USDC in an ETH-USDC pool. Could you wait for the second LP to deposit 1000 ETH and 1000 USDC? Once this has been done, they can withdraw their LP tokens and get 500 USD worth of ETH and 500 USDC. This is effectively a feeless swap. ### Root Cause The root cause of this is allowing unbalanced Liquidity provisioning for empty pools and not charging a swap fee. https://github.com/sherlock-audit/2025-09-dango-dex/blob/main/left-curve/dango/dex/src/core/liquidity_pool.rs#L167 ```rs if lp_token_supply.is_zero() { let mint_amount = match &self.pool_type { PassiveLiquidity::Xyk { .. } => xyk::add_initial_liquidity(&deposit)?, PassiveLiquidity::Geometric { .. } => { geometric::add_initial_liquidity(oracle_querier, &deposit)? }, }; reserve.merge(deposit.clone())?; return Ok((reserve, mint_amount)); } ``` ### Internal Pre-conditions The pool should be empty. ### External Pre-conditions None ### Attack Path 1. First LP deposit 1,000,000. USDC in a USDC - ETH POOL. They get 1,000,000 LP tokens for this. 2. Second LP deposits 500,000 USD worth of both assets and gets 1,000,000 LP tokens for this. 3. First LP withdraws their deposit and gets 500,000 USDC and 500,000 USD worth of ETH free of charge. ### Impact The first Liquidity Provider receives a feeless swap. ### PoC ```bash cargo test -p dango-dex geometric_attack_flow_one_sided_then_balanced_then_withdraw_logs -- --nocapture | cat ``` ```rs #[test] fn geometric_attack_flow_one_sided_then_balanced_then_withdraw_logs() { use dango_types::constants::{eth, usdc}; use dango_types::oracle::PrecisionedPrice; // Geometric pool. let pair = PairParams { pool_type: PassiveLiquidity::Geometric(Geometric { ratio: Bounded::new(Udec128::new_percent(50)).unwrap(), spacing: Udec128::new_percent(1), limit: 10, }), bucket_sizes: BTreeSet::new(), swap_fee_rate: Bounded::new(Udec128::new_percent(1)).unwrap(), lp_denom: Denom::new_unchecked(vec!["lp".to_string()]), min_order_size: Uint128::ZERO, }; let now = Timestamp::from_seconds(1_730_802_926); let prices = hash_map! { eth::DENOM.clone() => PrecisionedPrice::new( Udec128::new_percent(300000), // 3000.00 Udec128::new_percent(300000), now, 6, ), usdc::DENOM.clone() => PrecisionedPrice::new( Udec128::new_percent(100), // 1.00 Udec128::new_percent(100), now, 6, ), }; // 83 * 3000 = 249000 + 751688 = 1000688 let mut oracle_querier = OracleQuerier::new_mock(prices); // Start empty. let reserve0 = coin_pair! { eth::DENOM.clone() => 0u128, usdc::DENOM.clone() => 0u128, }; let mut lp_supply = Uint128::ZERO; // Attacker A: one-sided initial deposit (USDC only). let deposit_a1 = coin_pair! { eth::DENOM.clone() => 0u128, usdc::DENOM.clone() => 1_000_000u128, }; let (reserve1, lp_minted_a1) = pair .add_liquidity(&mut oracle_querier, reserve0, lp_supply, deposit_a1) .expect("geometric initial A should succeed"); lp_supply = lp_supply.checked_add(lp_minted_a1).unwrap(); println!( "[geo] A initial: lp_minted={}, lp_supply={}, reserve eth/usdc={}/{}", lp_minted_a1, lp_supply, reserve1.amount_of(ð::DENOM).unwrap(), reserve1.amount_of(&usdc::DENOM).unwrap() ); // Honest B: balanced deposit (adds both). let deposit_b = coin_pair! { eth::DENOM.clone() => 500_000u128 /3000, usdc::DENOM.clone() => 500_000u128, }; let (reserve2, lp_minted_b) = pair .add_liquidity(&mut oracle_querier, reserve1, lp_supply, deposit_b) .expect("geometric subsequent B should succeed"); lp_supply = lp_supply.checked_add(lp_minted_b).unwrap(); println!( "[geo] B subsequent: lp_minted={}, lp_supply={}, reserve eth/usdc={}/{}", lp_minted_b, lp_supply, reserve2.amount_of(ð::DENOM).unwrap(), reserve2.amount_of(&usdc::DENOM).unwrap() ); // Attacker A withdraws all his LP. let (_reserve_after_withdraw, refunds_a) = pair .remove_liquidity(reserve2, lp_supply, lp_minted_a1) .expect("withdraw should succeed"); println!( "[geo] A withdraw: refund eth={}, refund usdc={}", refunds_a.amount_of(ð::DENOM).unwrap(), refunds_a.amount_of(&usdc::DENOM).unwrap() ); } ``` **Output** ```bash Compiling dango-dex v0.0.0 (/Users/mansa/Documents/work-station/smart-contract/contests/2025-09-dango-dex-FeeqLabs/left-curve/dango/dex) Finished `test` profile [unoptimized + debuginfo] target(s) in 2.03s Running unittests src/lib.rs (target/debug/deps/dango_dex-6d651a9dcdad82e0) running 1 test [geo] A initial: lp_minted=1000000, lp_supply=1000000, reserve eth/usdc=0/1000000 [geo] B subsequent: lp_minted=995507, lp_supply=1995507, reserve eth/usdc=166/1500000 [geo] A withdraw: refund eth=83, refund usdc=751688 test core::liquidity_pool::tests::geometric_attack_flow_one_sided_then_balanced_then_withdraw_logs ... ok test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 42 filtered out; finished in 0.00s ``` ### Mitigation 1. Prevent the first liquidity provider from providing unbalanced liquidity. 2. Simulate a swap when the first liquidity provider tries to provide unbalanced liquidity. # Issue M-3: User can pause all auctions by overflow in mid-price average Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/250 ## Found by Ziusz ### Summary Unchecked addition of `best_bid_price` and `best_ask_price` when saving mid price can cause a global auction pause for all traders as an attacker can place one very high-price ask and one small-price bid so both best prices exist; then `mid_price = (bid + ask) / 2` overflows and the auction submessage fails, which sets `PAUSED = true`. ### Root Cause In [cron.rs:630](https://github.com/sherlock-audit/2025-09-dango-dex/blob/main/left-curve/dango/dex/src/cron.rs#L630) the mid price is computed by adding both prices then halving: ```rust fn clear_orders_of_pair(...) -> anyhow::Result<()> { // [...] let mid_price = match (best_bid_price, best_ask_price) { // @audit Can overflow Udec128_24 when ask is near max and bid > 0 (Some(bid), Some(ask)) => Some(bid.checked_add(ask)?.checked_mul(HALF)?), (Some(bid), None) => Some(bid), (None, Some(ask)) => Some(ask), (None, None) => None, }; // [...] } ``` Adding two `Price` (`Udec128_24`) numbers can overflow when ask is near the max and bid is positive. The error bubbles up, the auction submessage fails, and the reply handler pauses trading in [cron.rs:65](https://github.com/sherlock-audit/2025-09-dango-dex/blob/main/left-curve/dango/dex/src/cron.rs#L65): ```rust pub fn reply(ctx: SudoCtx, msg: ReplyMsg, res: SubMsgResult) -> StdResult { match msg { ReplyMsg::AfterAuction {} => { // [...] // @audit Any error sets PAUSED to true globally PAUSED.save(ctx.storage, &true)?; Response::new().add_event(Paused { error: Some(error) }) }, } } ``` ### Internal Pre-conditions 1. The pair has no passive pool reserves yet, so no passive orders cap prices; best bid/ask come only from user orders. ### External Pre-conditions None. ### Attack Path 1. Attacker sends a GTC SELL (`ask`) with extreme price (A) close to `Price` max (`Udec128_24`). 2. Attacker sends a GTC BUY (`bid`) with small price (e.g., 1) and `quote >= min_order_size` (e.g., $10). 3. No match happens (`1 < A`), so at end of block, the contract saves resting book. 4. It computes `mid_price = Some(bid.checked_add(ask)?.checked_mul(HALF)?)`. 5. `bid + ask` overflows `Udec128_24`, so the submessage errors and the reply handler sets `PAUSED = true`. ### Impact The protocol suffers global DoS on auctions across all pairs. Creating a new pair is permanently poisoned because it always carries the risk of pausing all auctions. ### PoC The issue is quite simple, so I think the example on numbers is enough: 1. For simplicity, let's say that `Price` max is 1000. 2. A user provided 1000 as `ask` and 1 as `bid`. 3. Mid price is getting calculated by this formula: `mid_price = Some(bid.checked_add(ask)?.checked_mul(HALF)?)`. 4. So it calculates `bid + ask = 1000 + 1 = 1001`, which overflows over 1000. Transaction reverts before getting to the dividing part. ### Mitigation Never average with `(lo + hi) / 2`; use `lo + (hi − lo) / 2` instead to avoid overflow during the addition. # Issue M-4: Overflow in geometric can dos swap Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/263 ## Found by ExtraCaterpillar ### Summary There are a few places in `geometric` where overflow happens during a swap. If you look at the [`ask_exact_amount_out`](https://github.com/sherlock-audit/2025-09-dango-dex/blob/main/left-curve/dango/dex/src/core/geometric.rs#L185-L206) function, inside the loop of this function, remaining ask amount in quote is converted into base amount. Then this base amount is compared with the available base order size at that price point. The final output of this comparison is saved into `matched_amount`. This `matched_amount` is of type `Dec`. If the base token is 18 decimal token, this `matched_amount` will be 24 decimals since it adds 6 more decimals to it. After that this `matched_amount` is added with `input_amount`- `input_amount.checked_add_assign(matched_amount)?;`. Here the `input_amount` is of type `Dec`. Since both `matched_amount` and `input_amount` are of different types, the `checked_add_assign` function converts `matched_amount` to type `Dec` by multiplying 1e12, and then adds them. As a result the matched amount is now 36 decimals after multiplication by 1e12. We know the max value of `u128` is 340,282,366,920,938,463,463,374,607,431,768,211,455 or 340.282e36. The `matched_amount` already contains 36 decimals. If the `matched_amount` contains anything more than 340 base tokens, this `input_amount` will always overflow. this can happen in pool of base tokens whose price is low and has 18 decimals ### Root Cause Overflow during addition causes swaps to revert. It happens in `ask_exact_amount_out` and `bid_exact_amount_in` where the base asset is used inside `checked_add_assign`. The root cause is type `Dec` is being added to type `Dec` and the token decimal is 18, which leads to 36 decimal after addition ### Internal Pre-conditions _ ### External Pre-conditions _ ### Attack Path _ ### Impact swaps will always revert in `ask_exact_amount_out` and `bid_exact_amount_in` or users will get wrong amount of tokens ### PoC Add this follwing test in `geometric` at the end of the file: ```rust mod tests { use std::ops::Sub; use dango_oracle::OracleQuerier; use grug::{coins, hash_map, Dec, Int, Timestamp, Udec128_24, Udec128_6}; use dango_types::{ constants::{eth, usdc}, oracle::PrecisionedPrice, }; use super::*; #[test] fn test_overflow_ask_amount() { let mut oracle_querier = OracleQuerier::new_mock(hash_map! { eth::DENOM.clone() => PrecisionedPrice::new( // shib 18 decimal, consider eth as shib Udec128::raw(grug::Int(1_17_500_000_000_000)), // .00001175 Udec128::raw(grug::Int(1_17_500_000_000_000)), Timestamp::from_seconds(1730802926), 18, ), usdc::DENOM.clone() => PrecisionedPrice::new( Udec128::new_percent(100), Udec128::new_percent(100), Timestamp::from_seconds(1730802926), 6, ) }); let reserve: CoinPair = coins!( eth::DENOM.clone() => 1000000000_000_000_000_000_000_000, usdc::DENOM.clone() => 11750_000_000, ).try_into().unwrap(); let output = Coin { denom: usdc::DENOM.clone(), amount: Int(150_000_000) }; let geometric_params = Geometric { spacing: Udec128::raw(grug::Int(10_000_000_000_000_000)), // .01 ratio: Bounded::new_unchecked(Udec128::raw(grug::Int(1_000_000_000_000_000))), // .001 limit: 100, }; let fee_rate = Udec128::raw(grug::Int(2_000_000_000_000_000)); // .2% let swap_fee_rate = Bounded::new(fee_rate).unwrap(); let res = swap_exact_amount_out(&mut oracle_querier, reserve.first().denom, reserve.second().denom, &output, &reserve, geometric_params, swap_fee_rate); println!("res: {:?}", res); // overflow error assert!(res.is_err()); // true let _value = res.unwrap(); // panics here } } ``` Run `cargo test --package dango-dex --lib -- core::geometric::tests::test_overflow_ask_amount --exact --show-output`. The test will pannic ### Mitigation In `ask_exact_amount_out`, set the type of `input_amount` as `Dec`. Similarly, in `bid_exact_amount_in`, change the type of `output_amount` to `Dec` # Issue M-5: Taker fees can be bypassed via asymmetric liquidity provision to a pool Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/268 ## Found by cu5t0mPe0, dandan, haxagon ### Summary Taker fees can be bypassed via liquidity provision to a pool ### Root Cause During a swap / order against a XYK or geometric pool, there are two fees charged to the user, 1) the swap / LP fee, the fee paid to liquidity providers of the pool 2) the taker fee, the fee paid to the taxman for swapping against the pool (which is considered a taker order) It is possible to bypass the taker fee, via asymmetric liquidity provision to a pool. During asymmetric liquidity provision, a swap fee is charged based on a virtual swap on the pool using a portion of the liquidity and then adding the rest of the liquidity that is balanced with the pool ratio after the virtual swap is done. https://github.com/left-curve/left-curve/blob/main/dango/dex/src/core/liquidity_pool.rs#L177-L246 ```rs // In case the deposit is asymmetrical, we need to apply a deposit fee. // // This is to prevent an attack where a user deposits asymmetrically, // then immediately withdraw symmetrically, essentially accomplishing a // swap without paying the swap fee. // // We determine the deposit fee rate based oracle price as follows: // // - Suppose the pool's reserve is `A` dollars of the 1st asset and `B` // dollars of the 2nd asset. // - Suppose a user deposits `a` dollars of 1st asset and `b` dollars of // the 2nd asset. // - Note that `A`, `B`, `a`, and `b` here are values in USD, not the // unit amounts. // - Without losing generality, assume a / A > b / B. In this case, the // user is over-supplying the 1st asset and under-supplying the 2nd // asset. To make the deposit symmetrical, the user needs to swap some // 1st asset into some 2nd asset. // - Suppose user swap `x` dollars of the 1st asset into the 2nd asset. // Also suppose our pool does the swap at exactly the oracle price // without slippage. This assumption obviously isn't true, but is good // enough for the purpose of preventing the aforementioned attack. // - We must solve: // (a - x) / (A + x) = (b + x) / (B - x) // The solution is: // x = (a * B - A * b) / (a + A + b + B) // - We charge a fee assuming this swap is to be carried out. The USD // value of the fee is: // x * swap_fee_rate // - To charge the fee, we mint slightly less LP tokens corresponding to // the ratio: // x * swap_fee_rate / (a + b) ... let fee_rate = { let price = oracle_querier.query_price(reserve.first().denom, None)?; let a = price .value_of_unit_amount::<24>(*deposit.first().amount)? .into_next(); let reserve_a = price .value_of_unit_amount::<24>(*reserve.first().amount)? .into_next(); let price = oracle_querier.query_price(reserve.second().denom, None)?; let b = price .value_of_unit_amount::<24>(*deposit.second().amount)? .into_next(); let reserve_b = price .value_of_unit_amount::<24>(*reserve.second().amount)? .into_next(); let deposit_value = a.checked_add(b)?; let reserve_value = reserve_a.checked_add(reserve_b)?; // IMPORTANT! // we have to be sure that abs( a * reserve_b - b * reserve_a ) is not approxed to 0 // because the low precision. // For this reason, it make sense to keep 24 decimal places in value_of_unit_amount // and use into_next() to avoid overflows. // Otherwise the fee rate could be 0 even if very low amount of tokens are deposited even unbalance. // Since we don't have gas price, this can be an attack vector. abs_diff(a.checked_mul(reserve_b)?, b.checked_mul(reserve_a)?) .checked_div(deposit_value.checked_add(reserve_value)?)? .checked_mul(self.swap_fee_rate.into_next())? .checked_div(deposit_value)? .checked_into_prev()? }; ``` The problem is that only the LP / swap fee is charged on the virtual swap. The virtual swap does not charge the taker fee which allows someone to first provide an asymmetric deposit and then burn the received LP tokens and in effect realizing the virtual swap, completely bypassing the taker fee. ### Internal Pre-conditions - ### External Pre-conditions - ### Attack Path Suppose we have a geometric pool consisting of 10 ETH and 20000 USDC and 1 ETH = 2000 USDC and a swap fee of 0.1% and a taker fee of 1%. (We make swap fee negligible to taker fee to emphasise the difference.) An attacker wants to swap 1 ETH for USDC in this pool. They can call `add_liquidity` with 2.222 ETH. They then immediately burn the LP tokens via `withdraw_liquidity` to withdraw some ETH and USDC, realizing their virtual swap performed during the asymmetric deposit without incurring any taker fees. Amount of USDC virtual swap: $$ x = \frac{4444 \cdot 20000}{20000 + 20000 + 4444} = 2000 $$ Fee rate: $$ f = \frac{2000 \cdot 0.001}{4444} = 0.00045 $$ Total ETH withdrawn after LP token burn: $$ ETH = (1-0.00045)(\frac{44444}{40000} - 1)(\frac{44444}{40000})^{-1}(12.2222) = 1.2215 $$ Total USDC withdrawn after LP token burn: $$ USDC = (1-0.00045)(\frac{44444}{40000} - 1)(\frac{44444}{40000})^{-1}(20000) = 1999 $$ Essentially, the 0.1% swap fee is charged from both the USDC and ETH when redeeming the LP tokens, however notice we can completely bypass the taker fee via this path of asymmetric liquidity provision then withdrawal. ### Impact The protocol receives less fees than intended. ### PoC _No response_ ### Mitigation _No response_ # Issue M-6: Any change in bucket size will DOS order cancellation leading to frozen user funds and halts the entire auction Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/307 ## Found by 0xShoonya, blockace, heavyw8t, klaus ### Summary The DEX protocol's order cancellation mechanism fails when bucket sizes for liquidity depth tracking are updated after an order is created. When administrators modify bucket sizes through `BatchUpdatePairs`, existing orders become uncancellable and cannot be matched either because the system attempts to decrease liquidity depths using mismatched bucket configurations. This results in a complete denial of service for order cancellations and the auction system, effectively pausing the entire auction system. The vulnerability has a High severity due to freezing user funds, effectively causing a loss of all funds stuck in orders and breaking a core functionality, as well as causing a loss of yield for LP's and the protocol since no revenue can be earned while the protocol is paused. ### Root Cause The vulnerability stems from asymmetric handling of bucket sizes between order creation and cancellation phases. During order creation, increase_liquidity_depths() uses the current pair.bucket_sizes to create depth entries with specific bucket size keys. However, during cancellation, decrease_liquidity_depths() reloads the current pair.bucket_sizes from storage, which may differ from the bucket sizes used during order creation if administrators have updated them via BatchUpdatePairs. https://github.com/sherlock-audit/2025-09-dango-dex/blob/main/left-curve/dango/dex/src/liquidity_depth.rs#L72-L106 The critical failure occurs in decrease_liquidity_depths() when it calls DEPTHS.modify() on storage keys that were created with different bucket sizes. Unlike may_update(), the modify() method requires the storage key to exist, causing transaction failures when bucket configurations have changed. ### Internal Pre-conditions - Administrators must have updated bucket sizes via BatchUpdatePairs while some orders are still GTC, which is very likely ### External Pre-conditions NA ### Attack Path 1. User creates limit order with TimeInForce::GoodTilCanceled, triggering increase_liquidity_depths() with current bucket sizes 2. Depth entries are created using the bucket sizes active at order creation time 3. Administrator updates bucket sizes via BatchUpdatePairs, replacing the previous configuration 4. User attempts to cancel order through normal cancellation mechanisms 5. System reloads current bucket sizes from PAIRS storage during cancel_order() 6. decrease_liquidity_depths() fails because DEPTHS.modify() cannot find storage keys created with the old bucket sizes 7. Transaction reverts due to missing storage keys, preventing order cancellation 8. User funds remain locked 9. Auction system fails when cron::auction() attempts to clean up passive orders using mismatched bucket sizes 10. Protocol pauses trading as the auction failure triggers the error handling mechanism, setting PAUSED to true and halting all trading activity ### Impact Users lose the ability to cancel their limit orders and reclaim deposited funds when bucket sizes are modified after order creation. The DEPTHS.modify() operation fails because it attempts to access storage keys that were created with different bucket size configurations, causing transaction reversions. This creates a permanent lock on user funds, `ForceCancle`also won't work as this uses the same function to decrease the liquidity depth The vulnerability also affects the auction system in cron::auction(), which uses the same decrease_liquidity_depths() function when cleaning up passive orders. If bucket sizes have changed, the auction process may fail entirely, triggering the protocol's pause mechanism and halting all trading activity, leading to a loss of yield for LP's and the protocol. ### PoC _No response_ ### Mitigation Consider implementing a mechanism to preserve bucket size information at order creation time. One approach could be storing the bucket sizes used during order creation within the Order struct itself, allowing cancellation logic to reference the original configuration. # Issue M-7: Attacker can exploit thin liquidity in xyk pool to save on fees. Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/324 ## Found by dandan ### Summary Because fees on instant swaps with `swap_exact_amount_[in|out]` is calculated from the output of the last pool in the route, an attacker can exploit a `PassiveLiqudity::Xyk` pair with relatively thin liquidity compared to the size of the trade to save on fees. Example: Attacker wants to make a large ETH -> USDC swap and DANGO/USDC pool has relatively thin liquidity compared to the size of the swap. Thus swapping with a route of `[ ETH/USDC, DANGO/USDC ]` (meaning `ETH -> USDC -> DANGO`) would incur large slippage in the last pool, and as the fee is calculated from the output of the last pair, the fee would be too small compared to the size of the trade. If the attacker deposits a large amount of liquidity in the last pool before making the trade, so that they own the majority of the liquidity in this pool, they can retrieve most of the output without paying any fees by simply withdrawing the liquidity after the swap. They can then swap the remaining `DANGO` for `USDC` to reverse the slippage, but despite the output of this swap being relatively large compared to the input, as they have already pulled out most of the funds by withdrawing their liquidity, the total fees will still be less than what they should have paid. Ultimately, this exploit results in a larger amount of `USDC` for the attacker than if they had just swapped `[ ETH/USDC ]` due to avoiding paying part of the fee, causing an equivalent loss for the protocol. This is demonstrated in the PoC below. ### Root Cause Fee is calculated from output of last pool in route: https://github.com/sherlock-audit/2025-09-dango-dex/blob/main/left-curve/dango/dex/src/core/router.rs#L18-L54 ### Internal Pre-conditions A `PassiveLiquidity::Xyk` pool with relatively thin liquidity. ### External Pre-conditions None ### Attack Path Let token A be the token that attacker wants to swap for. Let pool P be a `PassiveLiquidity::Xyk` pool with tokens A/B and relatively thin liquidity. 1. Attacker deposits liquidity in pool P to own a majority of the lp share. 1. Attacker swaps through a route that ends with an output of token B in pool P. 1. Attacker withdraws all of their pool P liquidity. 1. Attacker swaps their remaining amount of token B for token A in pool P. ### Impact Loss of funds for the protocol as it does not get the full amount of fees. ### PoC Paste this in [dango/testing/tests/dex.rs](https://github.com/sherlock-audit/2025-09-dango-dex/blob/main/left-curve/dango/testing/tests/dex.rs) and run with `cargo test --package dango-testing --test dex -- cheat_fees_with_slippage --show-output` ```rust fn cheat_fees_with_slippage(is_cheating: bool, expected_attacker_usdc_gain: Uint128) { let (mut suite, mut accounts, _, contracts, _) = setup_test_naive(Default::default()); suite.balances().record_many(accounts.users()); let attacker_initial_balances = suite.query_balances(&accounts.user1).unwrap(); let eth_usdc_lp_denom = Denom::try_from("dex/pool/eth/usdc").unwrap(); let dango_usdc_lp_denom = Denom::try_from("dex/pool/dango/usdc").unwrap(); let swap_fee = Udec128::new_permille(5); let pool_type = PassiveLiquidity::Xyk(Xyk { spacing: Udec128::ONE, reserve_ratio: Bounded::new_unchecked(Udec128::ZERO), limit: 10, }); // Owner creates ETH/USDC pool suite .query_wasm_smart(contracts.dex, dex::QueryPairRequest { base_denom: eth::DENOM.clone(), quote_denom: usdc::DENOM.clone(), }) .should_succeed_and(|_| { // Update pair params suite .execute( &mut accounts.owner, contracts.dex, &dex::ExecuteMsg::Owner(dex::OwnerMsg::BatchUpdatePairs(vec![PairUpdate { base_denom: eth::DENOM.clone(), quote_denom: usdc::DENOM.clone(), params: PairParams { lp_denom: eth_usdc_lp_denom.clone(), bucket_sizes: BTreeSet::new(), swap_fee_rate: Bounded::new_unchecked(swap_fee), pool_type: pool_type.clone(), min_order_size: Uint128::ZERO, }, }])), Coins::new(), ) .should_succeed(); true }); // Owner creates Dango/USDC pool suite .query_wasm_smart(contracts.dex, dex::QueryPairRequest { base_denom: dango::DENOM.clone(), quote_denom: usdc::DENOM.clone(), }) .should_succeed_and(|_| { // Update pair params suite .execute( &mut accounts.owner, contracts.dex, &dex::ExecuteMsg::Owner(dex::OwnerMsg::BatchUpdatePairs(vec![PairUpdate { base_denom: dango::DENOM.clone(), quote_denom: usdc::DENOM.clone(), params: PairParams { lp_denom: dango_usdc_lp_denom.clone(), bucket_sizes: BTreeSet::new(), swap_fee_rate: Bounded::new_unchecked(swap_fee), pool_type: pool_type.clone(), min_order_size: Uint128::ZERO, }, }])), Coins::new(), ) .should_succeed(); true }); // Register the oracle prices let oracle_prices = vec![ (eth::DENOM.clone(), Udec128::new(4000)), (dango::DENOM.clone(), Udec128::new(1)), (usdc::DENOM.clone(), Udec128::new(1)), ]; for (denom, price) in oracle_prices { suite .execute( &mut accounts.owner, contracts.oracle, &oracle::ExecuteMsg::RegisterPriceSources(btree_map! { denom => PriceSource::Fixed { humanized_price: price, precision: 6, timestamp: Timestamp::from_seconds(1730802926), }, }), Coins::new(), ) .should_succeed(); } // Owner provides some initial liquidity let initial_eth_usdc_liquidity_funds = coins! { eth::DENOM.clone() => 10, usdc::DENOM.clone() => 40_000_000_000, }; suite .execute( &mut accounts.owner, contracts.dex, &dex::ExecuteMsg::ProvideLiquidity { base_denom: eth::DENOM.clone(), quote_denom: usdc::DENOM.clone(), }, initial_eth_usdc_liquidity_funds.clone(), ) .should_succeed(); // Relatively liquidity for DANGO/USDC pool let initial_dango_usdc_liquidity_funds = coins! { dango::DENOM.clone() => 100, usdc::DENOM.clone() => 100, }; suite .execute( &mut accounts.owner, contracts.dex, &dex::ExecuteMsg::ProvideLiquidity { base_denom: dango::DENOM.clone(), quote_denom: usdc::DENOM.clone(), }, initial_dango_usdc_liquidity_funds.clone(), ) .should_succeed(); let eth_swap_amount = Uint128::new(1); let eth_usdc_swap_funds = coins! { eth::DENOM.clone() => eth_swap_amount.clone(), }; if is_cheating { let attacker_dango_usdc_liquidity_funds = coins! { dango::DENOM.clone() => 9900, usdc::DENOM.clone() => 9900, }; suite .execute( &mut accounts.user1, contracts.dex, &dex::ExecuteMsg::ProvideLiquidity { base_denom: dango::DENOM.clone(), quote_denom: usdc::DENOM.clone(), }, attacker_dango_usdc_liquidity_funds.clone(), ) .should_succeed(); let route = vec![PairId { base_denom: eth::DENOM.clone(), quote_denom: usdc::DENOM.clone(), }, PairId { base_denom: dango::DENOM.clone(), quote_denom: usdc::DENOM.clone(), }]; suite .execute( &mut accounts.user1, contracts.dex, &dex::ExecuteMsg::SwapExactAmountIn { route: MaxLength::new_unchecked(UniqueVec::new_unchecked(route.clone())), minimum_output: None, }, eth_usdc_swap_funds.clone(), ) .should_succeed(); suite.balances().record_many(accounts.users()); let attacker_withdrawal_funds = coins! { dango_usdc_lp_denom.clone() => suite.query_balances(&accounts.user1).unwrap().amount_of(&dango_usdc_lp_denom) }; suite .execute( &mut accounts.user1, contracts.dex, &dex::ExecuteMsg::WithdrawLiquidity { base_denom: dango::DENOM.clone(), quote_denom: usdc::DENOM.clone(), }, attacker_withdrawal_funds.clone(), ) .should_succeed(); suite.balances().record_many(accounts.users()); let dango_usdc_swap_funds = coins! { dango::DENOM.clone() => suite .query_balances(&accounts.user1).unwrap().amount_of(&dango::DENOM) .checked_sub(attacker_initial_balances.amount_of(&dango::DENOM)) .unwrap(), }; let route = vec![PairId { base_denom: dango::DENOM.clone(), quote_denom: usdc::DENOM.clone(), }]; suite .execute( &mut accounts.user1, contracts.dex, &dex::ExecuteMsg::SwapExactAmountIn { route: MaxLength::new_unchecked(UniqueVec::new_unchecked(route.clone())), minimum_output: None, }, dango_usdc_swap_funds.clone(), ) .should_succeed(); } else { let route = vec![PairId { base_denom: eth::DENOM.clone(), quote_denom: usdc::DENOM.clone(), }]; suite .execute( &mut accounts.user1, contracts.dex, &dex::ExecuteMsg::SwapExactAmountIn { route: MaxLength::new_unchecked(UniqueVec::new_unchecked(route.clone())), minimum_output: None, }, eth_usdc_swap_funds.clone(), ) .should_succeed(); } suite.balances().record_many(accounts.users()); let balances = suite.query_balances(&accounts.user1).unwrap(); let eth_loss = attacker_initial_balances.amount_of(ð::DENOM) .checked_sub(balances.amount_of(ð::DENOM)) .unwrap(); let usdc_gain = balances .amount_of(&usdc::DENOM) .checked_sub(attacker_initial_balances.amount_of(&usdc::DENOM)) .unwrap(); let dango_delta = balances .amount_of(&dango::DENOM) .checked_sub(attacker_initial_balances.amount_of(&dango::DENOM)) .unwrap(); println!("ETH loss: {}", eth_loss); println!("USDC gain: {}", usdc_gain); println!("DANGO delta: {}", dango_delta); assert_eq!(eth_loss, eth_swap_amount); assert_eq!(dango_delta, Uint128::ZERO); assert_eq!(usdc_gain, expected_attacker_usdc_gain); } ``` ### Mitigation Some options include: - Charge fee from input amount - Charge fee in every step of route # Issue M-8: A newly deployed pool can be DoS Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/363 ## Found by 0x37, 0xAsen, 0xShoonya, 0xc0ffEE, 0xkmr\_, Boy2000, Kirkeelee, LeFy, MissDida, OhmOudits, Synthrax, Yashar, ZeroEx, Ziusz, berndartmueller, calc1f4r, d33p, haxagon, heavyw8t, joicygiore, maigadoh, merlin, vangrim, vivekd, x15 ### Summary A newly deployed pool can be DoS by just providing liquidity with zero amounts ### Root Cause The problem originates from the fact that it does not check if the provided coin amounts are 0, or the LP mint amount is 0 at the first liquidity provision when pool supply is 0. In case the provided amounts are 0, after the first mint, the pool reserves are still 0 (reserves value is 0) but the pool supply is non-zero which causes any further liquidity provisions unable to be executed because of arithmetic error (division by 0) - No zero amounts check at [`execute.rs::provide_liquidity()`](https://github.com/sherlock-audit/2025-09-dango-dex/blob/main/left-curve/dango/dex/src/execute.rs#L187-L262), [`liquidity_pool.rs::add_liquidity()`](https://github.com/sherlock-audit/2025-09-dango-dex/blob/main/left-curve/dango/dex/src/core/liquidity_pool.rs#L142-L175) and also at [`xyk.rs::add_initial_liquidity()`](https://github.com/sherlock-audit/2025-09-dango-dex/blob/main/left-curve/dango/dex/src/core/xyk.rs#L13) and [`geometric.rs::add_initial_liquidity()`](https://github.com/sherlock-audit/2025-09-dango-dex/blob/main/left-curve/dango/dex/src/core/geometric.rs#L16) - After the first provision with zero amounts, the next provisions can not be executed because of the arithmetic error division by 0. As a result, the pool is unable to operate ```rust // xyk.rs pub fn add_subsequent_liquidity( reserve: &mut CoinPair, deposit: CoinPair, ) -> anyhow::Result { let invariant_before = normalized_invariant(reserve)?; // Add the used funds to the pool reserves. reserve.merge(deposit)?; // Compute the proportional increase in the invariant. let invariant_after = normalized_invariant(reserve)?; let invariant_ratio = Price::checked_from_ratio(invariant_after, invariant_before)?; // <<<<<<<<<<<< invariant_before = 0 here // Compute the mint ratio from the invariant ratio based on the curve type. // This ensures that an unbalances provision will be equivalent to a swap // followed by a balancedliquidity provision. Ok(invariant_ratio.checked_sub(Price::ONE)?) } // geometric.rs pub fn add_subsequent_liquidity( oracle_querier: &mut OracleQuerier, reserve: &mut CoinPair, deposit: CoinPair, ) -> anyhow::Result { let deposit_value = oracle_value(oracle_querier, &deposit)?; let reserve_value = oracle_value(oracle_querier, reserve)?; reserve.merge(deposit)?; Ok(deposit_value.checked_div(reserve_value)?) // <<<<<<<<<< reserve_value = 0 here } ``` ### Internal Pre-conditions NA ### External Pre-conditions NA ### Attack Path 1. A pair/pool is initiated 2. The pool is provided with both quote amount = 0 and base amount = 0 (by arbitrary caller) 3. An liquidity provider tries to provide liquidity but it fails ### Impact - Pool is completely DoS and it is unable to function ### PoC Update the test `dango/testing/tests/dex.rs::provide_liquidity()` as below: ```diff fn provide_liquidity( provision: Coins, swap_fee: Udec128, pool_type: PassiveLiquidity, oracle_prices: Vec<(Denom, Udec128)>, expected_lp_balance: Uint128, ) { let (mut suite, mut accounts, _, contracts, _) = setup_test_naive(Default::default()); let lp_denom = Denom::try_from("dex/pool/dango/usdc").unwrap(); // Owner first provides some initial liquidity. let initial_reserves = coins! { - dango::DENOM.clone() => 100, - usdc::DENOM.clone() => 100, + dango::DENOM.clone() => 0, + usdc::DENOM.clone() => 0, }; ``` Run the test with the test cases and it will throw error as below ```bash expected success, got error: contract returned error! address: 0x8dd37b7e12d36bbe1c00ce9f0c341bfe1712e73f, method: execute, msg: division by zero: 200000000000000000000000000000000000000000000000000 / 0 ``` ### Mitigation Explicitly ensure if the first provision amount are not 0 and the first LP mint is not 0 # Issue M-9: Price cannot be represented when a high-value base asset is quoted in a high-decimal asset Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/383 ## Found by 0xShoonya ## Summary A design flaw in the DEX's price representation logic can render certain trading pairs non-functional. The internal price calculation for pairs where a high-value base asset is quoted in a high-decimal asset (e.g., WBTC/DAI) can exceed the maximum value of the `Udec128_24` type used for storage. This causes transactions to fail, effectively creating a denial of service for that market. ## Root Cause We have this information from the README: > The DEX contract is intended to work with tokens with >= 0 and <=18 decimal places (ie, issues related to the token having >=0 and <=18 decimals can be considered valid and in scope) and prices as low as 0.00001 USD (an example of this would be the SHIB token). The internal price is stored as a [Price](https://github.com/sherlock-audit/2025-09-dango-dex/blob/main/left-curve/dango/types/src/dex/price.rs#L35), which is a type alias for `Udec128_24`. This is a 128-bit unsigned number with 24 fixed decimal places. Its maximum representable value is `(2^128 - 1) / 10^24`, which is approximately `3.4e14`. ```js // (2^128 - 1) / 10^24 = 3.4e+14 pub type Price = Udec128_24; ``` The DEX converts human-readable prices into an internal format by scaling them based on the decimal counts of the two tokens involved. This is the formula used: ```js Internal Price = Nominal Price * (Base Unit of Base Token / Base Unit of Quote Token) ``` The issue is that for certain valid pairs under the README's definition, this scaling formula produces a result that overflows the `Udec128_24` limit. A concrete example is the `WBTC/DAI` pair. Let's apply this exact logic to our problematic pair. - __Pair:__ WBTC (base) vs. DAI (quote) - __Nominal Price:__ 1 BTC = $110,000 DAI - __Decimals:__ - WBTC (base_decimals): 8 (Its smallest unit, a satoshi, is 1e-8 WBTC) - DAI (quote_decimals): 18 (Its smallest unit is 1e-18 DAI) Applying the scaling formula: - Internal Price = 110,000 * 1e-8 / 1e-18 - Internal Price = 110,000 * 10^(18 - 8) - Internal Price = 110,000 * 10^10 - Internal Price = 1.1e15 This calculated Internal Price of __1.1e15__ is substantially larger than the maximum representable value of __~3.4e14__. The price itself cannot be stored, leading to an arithmetic overflow. This failure directly contradicts the README's promise to support all tokens with 0 to 18 decimals, as this common and realistic pair is fundamentally incompatible. ## Internal pre-conditions . ## External pre-conditions . ## Attack Scenario . ## Impact The DEX cannot support essential trading pairs like WBTC/DAI which are in-scope as per the README ## Mitigation Consider upgrading Price to a 256-bit fixed-point type # Issue M-10: XYK `reflect_curve` is incorrect and decreases K over time leading to loss of funds for LP providers. Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/384 ## Found by 0xc0ffEE, haxagon ### Summary XYK `reflect_curve` underperforms regular XYK AMM algorithm ### Root Cause The XYK `reflect_curve` algorithm that generates passive orders is unfavorable to the pool, computing more unfavorable prices than what the actual AMM algorithm would give. https://github.com/left-curve/left-curve/blob/cff1bf826bd64ebab16fc7d1947a98e1e1fa4776/dango/dex/src/core/xyk.rs#L97-L167 ```rs pub fn reflect_curve( mut base_reserve: Uint128, mut quote_reserve: Uint128, params: Xyk, swap_fee_rate: Bounded, ) -> anyhow::Result<( Box>, Box>, )> { // Withhold the funds corresponding to the reserve requirement. // These funds will not be used to place orders. let one_sub_reserve_ratio = Udec128::ONE - *params.reserve_ratio; base_reserve.checked_mul_dec_floor_assign(one_sub_reserve_ratio)?; quote_reserve.checked_mul_dec_floor_assign(one_sub_reserve_ratio)?; // If either reserve is zero, return empty iterators as there's no liquidity to reflect if base_reserve.is_zero() || quote_reserve.is_zero() { return Ok(( Box::new(iter::empty()), Box::new(iter::empty()), )); } // Compute the marginal price. We will place orders above and below this price. let marginal_price = Price::checked_from_ratio(quote_reserve, base_reserve)?; // Construct the bid order iterator. // Start from the marginal price minus the swap fee rate. let bids = { let one_sub_fee_rate = Udec128::ONE.checked_sub(*swap_fee_rate)?; let mut maybe_price = marginal_price.checked_mul(one_sub_fee_rate).ok(); let mut prev_size = Uint128::ZERO; let mut prev_size_quote = Uint128::ZERO; iter::from_fn(move || { // Terminate if price is less or equal to zero. let price = match maybe_price { Some(price) if price.is_non_zero() => price, _ => return None, }; // Compute the total order size (in base asset) at this price. let quote_reserve_div_price = quote_reserve.checked_div_dec(price).ok()?; let mut size = quote_reserve_div_price.checked_sub(base_reserve).ok()?; // Compute the order size (in base asset) at this price. // // This is the difference between the total order size at // this price, and that at the previous price. let mut amount = size.checked_sub(prev_size).ok()?; // Compute the total order size (in quote asset) at this price. let mut amount_quote = amount.checked_mul_dec_ceil(price).ok()?; let mut size_quote = prev_size_quote.checked_add(amount_quote).ok()?; // If total order size (in quote asset) is greater than the // reserve, cap it to the reserve size. if size_quote > quote_reserve { size_quote = quote_reserve; amount_quote = size_quote.checked_sub(prev_size_quote).ok()?; amount = amount_quote.checked_div_dec_floor(price).ok()?; size = prev_size.checked_add(amount).ok()?; } // If order size is zero, we have ran out of liquidity. // Terminate the iterator. if amount.is_zero() { return None; } // Update the iterator state. prev_size = size; prev_size_quote = size_quote; maybe_price = price.checked_sub(params.spacing).ok(); Some((price, amount)) }) .take(params.limit) }; // Construct the ask order iterator. let asks = { let one_plus_fee_rate = Udec128::ONE.checked_add(*swap_fee_rate)?; let mut maybe_price = marginal_price.checked_mul(one_plus_fee_rate).ok(); let mut prev_size = Uint128::ZERO; iter::from_fn(move || { let price = maybe_price?; // Compute the total order size (in base asset) at this price. let quote_reserve_div_price = quote_reserve.checked_div_dec(price).ok()?; let size = base_reserve.checked_sub(quote_reserve_div_price).ok()?; // If total order size (in base asset) exceeds the base asset // reserve, cap it to the reserve size. let size = cmp::min(size, base_reserve); // Compute the order size (in base asset) at this price. // // This is the difference between the total order size at // this price, and that at the previous price. let amount = size.checked_sub(prev_size).ok()?; // If order size is zero, we have ran out of liquidity. // Terminate the iterator. if amount.is_zero() { return None; } // Update the iterator state. prev_size = size; maybe_price = price.checked_add(params.spacing).ok(); Some((price, amount)) }) .take(params.limit) }; Ok((Box::new(bids), Box::new(asks))) } ``` The reason for this is that for instance, for bid orders, the function uses the following to determine the order size at step $n$ $$ \Delta b_{n} = \frac{Q_0}{P_n}-{B_{n-1}} $$ The flaw here is that we are using the initial `quote_reserve` value $Q_0$ when dividing by price. This assumes that the quote assets do not change as we move away from our initial point of the AMM but in reality it does change. The only thing that does not change should be the $K = B_0 \cdot Q_0$. Instead, it should be using the formula: $$ \Delta b_{n} = \sqrt{\frac{K}{P_n}}-{B_{n-1}} $$ This works because for a given AMM, at the price $P_n = \frac{Q_n}{B_n} $, we can compute the value of $B_n$ in the AMM using: $$ \sqrt{\frac{K}{P_n}} = \sqrt{\frac{B_n \cdot Q_n}{P_n}} = B_n $$ Similarly for ask orders, the correct function would be: $$ \Delta b_{n} = - \sqrt{\frac{K}{P_n}}+{B_{n-1}} $$ As such, due to the incorrect pricing, the pool is charging lower than what an regular CP-AMM would charge. This causes the K-invariant to decrease, instead of increase over time causing a loss of funds for LP providers. ### Internal Pre-conditions - ### External Pre-conditions - ### Attack Path If we refer to the results pasted at the Python notebook located [here](https://github.com/left-curve/left-curve/blob/main/notebooks/passive_liquidity.ipynb). Let's perform a sample comparison for a bid order when at step `n`. This reflects a SOL-USDC XYK pool with initial liquidity 1 SOL and 200 USDC and a fee of 0.3% ```text ---------------------- Bids ----------------------- p a da b db 0 200.0 0.000000 0.000000 0.000000 0.000000 1 199.4 0.003009 0.003009 0.600000 0.600000 2 198.4 0.008065 0.005055 1.603009 1.003009 3 197.4 0.013171 0.005107 2.611074 1.008065 4 196.4 0.018330 0.005159 3.624245 1.013171 5 195.4 0.023541 0.005212 4.642575 1.018330 6 194.4 0.028807 0.005265 5.666116 1.023541 7 193.4 0.034126 0.005320 6.694923 1.028807 8 192.4 0.039501 0.005375 7.729049 1.034126 9 191.4 0.044932 0.005431 8.768550 1.039501 10 190.4 0.050420 0.005488 9.813482 1.044932 ... ``` At step `n`, interpreting the table, we can observe we can sell 0.050420 SOL to the order book for 9.81 USDC. If we were to perform a regular swap instead, the total USDC received will be (1-0.003)(200-200/(1+0.050420)) = 9.57 USDC. Hence, the pool spends 0.24 USDC more on passive orders than if it were using a regular swap. For the passive order, the pool contents after filling it will be 1.050420 SOL and 190.186518 USDC. Multiplying both will yield K = 199.7757, since the K has decreased, the LP providers are actually losing funds from the XYK pool creating passive orders. If we perform the same analysis using the fixed functions. ```python3 import numpy as np import pandas as pd import matplotlib.pyplot as plt def compute_bids(compute_p_m, compute_a, A, B, dp, half_spread, max_num_orders, **kwargs): # Compute the marginal price. p_m = compute_p_m(A, B, **kwargs) # Set the iterator's starting condition. p = p_m * (1 - half_spread) a = 0 da = 0 b = 0 db = 0 arr_p = [p_m] arr_a = [a] arr_da = [da] arr_b = [b] arr_db = [db] for n in range(1, max_num_orders + 1): # Terminate if price is less or equal to zero. if p <= 0: break # Compute the total order size (in base asset) at this price. a = compute_a(A, B, p, **kwargs) # Compute the order size (in base asset) at this price. da = a - arr_a[n - 1] # Compute the total order size (in quote asset) at this price. db = da * p b = arr_b[n - 1] + db # If total order size (in quote asset) is greater than the reserve, cap it to the reserve size. if b > B: b = B db = b - arr_b[n - 1] da = db * p a = arr_a[n - 1] + da # If order size rounds to zero, we have ran out of liquidity. Terminate the iterator. # Here we assume the base asset has 6 decimals, so < 1e-6 means rounding to zero. if da < 1e-6: break # Update the iterator state. arr_p.append(p) arr_a.append(a) arr_da.append(da) arr_b.append(b) arr_db.append(db) p -= dp return np.array(arr_p), np.array(arr_a), np.array(arr_da), np.array(arr_b), np.array(arr_db) def compute_asks(compute_p_m, compute_a, A, B, dp, half_spread, max_num_orders, **kwargs): # Compute the marginal price. p_m = compute_p_m(A, B, **kwargs) # Set the iterator's starting condition. p = p_m * (1 + half_spread) a = 0 da = 0 b = 0 db = 0 arr_p = [p_m] arr_a = [a] arr_da = [da] arr_b = [b] arr_db = [db] for n in range(1, max_num_orders + 1): # Compute the total order size (in base asset) at this price. a = compute_a(A, B, p, **kwargs) # If total order size (in base asset) exceeds the base asset reserve, cap it to the reserve size. if a >= A: a = A # Compute the order size (in base asset) at this price. da = a - arr_a[n - 1] # If order size rounds to zero, we have ran out of liquidity. Terminate the iterator. # Here we assume the base asset has 6 decimals, so < 1e-6 means rounding to zero. if da < 1e-6: break # Compute the order size (in quote asset) at this price. # This isn't used in the smart contract logic. Just for plotting the graphs. db = da * p # Compute the total order size (in quote asset) at this price. b = arr_b[n - 1] + db # Update the iterator state. arr_p.append(p) arr_a.append(a) arr_da.append(da) arr_b.append(b) arr_db.append(db) p += dp return np.array(arr_p), np.array(arr_a), np.array(arr_da), np.array(arr_b), np.array(arr_db) def plot(compute_bids, compute_asks, A, B, dp, half_spread, max_num_orders=25, filename="", **kwargs): fig, (ax1, ax2) = plt.subplots(2, 1, figsize=(12, 6)) # fig, (ax1, ax2, ax3, ax4) = plt.subplots(4, 1, figsize=(12, 12)) # Compute and plot bids arr_p, arr_a, arr_da, arr_b, arr_db = compute_bids(A, B, dp, half_spread, max_num_orders, **kwargs) ax1.bar(arr_p, arr_da, color="green", width=dp * 0.8) ax2.step(arr_p, arr_a, color="green", where="post") # ax3.bar(arr_p, arr_db, color="green", width=dp * 0.8) # ax4.step(arr_p, arr_b, color="green", where="post") print("---------------------- Bids -----------------------") print(pd.DataFrame(data={"p": arr_p, "a": arr_a, "da": arr_da, "b": arr_b, "db": arr_db})) # Compute and plot asks arr_p, arr_a, arr_da, arr_b, arr_db = compute_asks(A, B, dp, half_spread, max_num_orders, **kwargs) ax1.bar(arr_p, arr_da, color="red", width=dp * 0.8) ax2.step(arr_p, arr_a, color="red", where="post") # ax3.bar(arr_p, arr_db, color="red", width=dp * 0.8) # ax4.step(arr_p, arr_b, color="red", where="post") print("---------------------- Asks -----------------------") print(pd.DataFrame(data={"p": arr_p, "a": arr_a, "da": arr_da, "b": arr_b, "db": arr_db})) ax1.set_ylabel("order size (SOL)") ax2.set_ylabel("order depth (SOL)") # ax3.set_ylabel("order size (USD)") # ax4.set_ylabel("order depth (USD)") ax1.set_ylim(0) ax2.set_ylim(0) # ax3.set_ylim(0) # ax4.set_ylim(0) ax2.set_xlabel("price (USD per SOL)") # ax4.set_xlabel("price (USD per SOL)") plt.tight_layout() if filename != "": plt.savefig(filename) plt.show() def compute_xyk_f(A, B): return A * B def compute_xyk_p_m(A, B): return B / A def compute_xyk_ask_a(A, B, p): return A - B / p def compute_xyk_bid_a(A, B, p): return B / p - A def compute_xyk_ask_a_fixed(A, B, p): return A - (compute_xyk_f(A, B) / p) ** 0.5 def compute_xyk_bid_a_fixed(A, B, p): return (compute_xyk_f(A, B) / p) ** 0.5 - A def compute_xyk_bids(A, B, dp, half_spread, max_num_orders): return compute_bids(compute_xyk_p_m, compute_xyk_bid_a_fixed, A, B, dp, half_spread, max_num_orders) def compute_xyk_asks(A, B, dp, half_spread, max_num_orders): return compute_asks(compute_xyk_p_m, compute_xyk_ask_a_fixed, A, B, dp, half_spread, max_num_orders) plot(compute_xyk_bids, compute_xyk_asks, A=1, B=200, dp=1, half_spread=0.003, # 0.3% max_num_orders=30, filename="") # filename="1-xyk.png") ``` We obtain the following result: ```text ---------------------- Bids ----------------------- p a da b db 0 200.0 0.000000 0.000000 0.000000 0.000000 1 199.4 0.001503 0.001503 0.299775 0.299775 2 198.4 0.004024 0.002521 0.799897 0.500122 3 197.4 0.006564 0.002540 1.301275 0.501378 4 196.4 0.009123 0.002559 1.803918 0.502643 5 195.4 0.011702 0.002579 2.307836 0.503918 6 194.4 0.014301 0.002599 2.813038 0.505202 7 193.4 0.016920 0.002619 3.319535 0.506497 8 192.4 0.019559 0.002639 3.827336 0.507801 9 191.4 0.022219 0.002660 4.336451 0.509115 10 190.4 0.024900 0.002681 4.846891 0.510440 ... ``` Doing a comparative analysis again, Using passive orders, the pool exchanges 4.846891 USDC for 0.024900 SOL, For a swap, the pool exchanges 4.84443 USDC for 0.024900 SOL. The pool still loses a tinier amount if it uses the passive order rather than a regular swap, but this is due to the incorrect application of the fee that is discussed in another submission. However, if we were to calculate the K invariant, K = 1.024900 * 195.153109 = 200.012421, the K-invariant increases instead of decreasing, so at least LP providers are making money instead of losing like earlier. ### Impact K value decreases over time from passive orders, leading to loss of funds for LP providers. ### PoC _No response_ ### Mitigation _No response_ # Issue M-11: Providing and withdrawing liquidity lacks slippage protection Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/412 ## Found by 0x37, 0xDjango, MissDida, berndartmueller, blockace, cu5t0mPe0, dandan, haxagon, holtzzx, merlin, ni8mare ## Summary The `ProvideLiquidity` and `WithdrawLiquidity` messages do not include slippage protection parameters. This omission exposes users to the risk of receiving fewer tokens than expected due to market conditions between the transaction initiation and execution. ## Root Cause The `ProvideLiquidity` and `WithdrawLiquidity` messages calculate the resulting tokens based on pool reserves at the moment of execution, without allowing users to specify a minimum amount of tokens they are willing to accept. This exposes them to slippage caused by market volatility or front-running. **Providing Liquidity** When providing liquidity, the number of LP tokens minted is derived from the ratio of the deposit to the current reserves at execution time (e.g., [XYK pool](https://github.com/left-curve/left-curve/blob/4dd70e17bae94997663c50fa1e0b09ef4fa2d358/dango/dex/src/core/xyk.rs#L28)). Any change in reserves between signing and execution will alter the outcome. **Withdrawing Liquidity** When withdrawing liquidity, the user receives a [pro-rata share of the current reserves](https://github.com/left-curve/left-curve/blob/4dd70e17bae94997663c50fa1e0b09ef4fa2d358/dango/dex/src/core/liquidity_pool.rs#L56): ```rust 56: let refund = reserve.split(lp_burn_amount, lp_token_supply)?; ``` The composition of the withdrawn assets is therefore sensitive to any trades that occur before the withdrawal is processed. This is a deviation from the industry standard for XYK pools, where platforms like Uniswap V2 [allow users to specify minimum amounts](https://github.com/Uniswap/v2-periphery/blob/0335e8f7e1bd1e8d8329fd300aea2ef2f36dd19f/contracts/UniswapV2Router02.sol#L107C14-L107C24) for liquidity provision to protect against slippage. ## Internal Pre-conditions N/A ## External Pre-conditions - The reserves of the targeted liquidity pool change between the time the user signs the transaction and when it is executed. ## Attack Path **Providing Liquidity:** 1. A user intends to provide liquidity to a pool with reserves of **1,000 ETH** and **2,000,000 USDC** (price: 2,000 USDC). They sign a transaction to deposit **10 ETH** and **20,000 USDC**. 2. A large trade is executed, which sells **200 ETH** to the pool. This trade significantly alters the pool's balance. 3. The trade swaps 200 ETH for approximately 333,333 USDC. The new pool reserves become **1,200 ETH** and **~1,666,667 USDC**. The price of ETH drops to ~1,389 USDC. 4. The user's `ProvideLiquidity` transaction is now executed against these reserves. Their deposit of 10 ETH and 20,000 USDC is now highly unbalanced relative to the new pool ratio. 5. As a result, the user receives significantly fewer LP tokens than they would have at the time of signing, and they may incur a substantial asymmetry fee, leading to an immediate loss. **Withdrawing Liquidity** 1. A user holds 1% of the LP tokens for a pool with reserves of **1,000 ETH** and **2,000,000 USDC**. They sign a transaction to withdraw their share, expecting to receive approximately **10 ETH** and **20,000 USDC**. 2. A large purchase of **300 ETH** from the pool is executed, using approximately 857,143 USDC. 3. The trade shifts the pool reserves to **700 ETH** and **~2,857,143 USDC**. The price of ETH rises to ~4,081 USDC. 4. The user's `WithdrawLiquidity` transaction now executes against the new pool state. 5. The user receives 1% of the new reserves: **7 ETH** and **~28,571 USDC**. They receive 30% less ETH than anticipated and are forced to realize their position at a disadvantageous price, effectively crystallizing impermanent loss. ## Impact Liquidity providers can suffer a loss of value due to slippage. When providing liquidity, they may receive fewer LP tokens for their assets than expected. When withdrawing, they may receive an unfavorable mix of assets, potentially forcing them to realize impermanent loss or leaving them with less of a specific asset they require. ## PoC N/A ## Mitigation Consider introducing slippage protection mechanisms by adding parameters to both `ProvideLiquidity` and `WithdrawLiquidity` messages. Additionally, consider adding an optional `deadline` parameter to these messages to prevent them from being held and executed at a much later time under significantly different market conditions. # Issue M-12: `OwnerMsg::ForceCancelOrders` is unusable due to the DEX contract lacking a `receive` function to accept refunds from cancelled passive liquidity orders Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/414 ## Found by berndartmueller, blockace, globalace, haxagon, klaus ## Summary The `OwnerMsg::ForceCancelOrders` message execution will revert if any passive liquidity orders are present, preventing administrators from cancelling all orders in an emergency, because the DEX contract itself cannot receive the order refund due to a missing `receive` function. ## Root Cause In [`dango/dex/src/execute/order_cancellation.rs:18-31`](https://github.com/left-curve/left-curve/blob/4dd70e17bae94997663c50fa1e0b09ef4fa2d358/dango/dex/src/execute/order_cancellation.rs#L18-L31), the `cancel_all_orders` function iterates through all orders to cancel them. For passive liquidity orders, the designated `user` is the DEX contract itself. When `cancel_order` is called for a passive order, it generates a refund transfer to the DEX contract's address. However, the DEX contract lacks a `receive` entry point to accept incoming coin transfers, resulting in the entire transaction failing. ## Internal Pre-conditions 1. At least one passive liquidity order exists in the DEX. 2. An administrator sends the `OwnerMsg::ForceCancelOrders` message to cancel all orders forcefully. ## External Pre-conditions 1. The protocol is in an emergency state where some orders need to be cancelled to protect user funds. ## Attack Path 1. In an emergency situation, an administrator uses `OwnerMsg::ForceCancelOrders` to forcefully cancel all orders. 2. The function begins iterating through orders. When it processes the passive liquidity order, it attempts to execute a transfer of the order's funds back to the `order.user` (the DEX contract). 3. The underlying framework attempts to [call the `receive` function](https://github.com/left-curve/left-curve/blob/4dd70e17bae94997663c50fa1e0b09ef4fa2d358/grug/app/src/execute/transfer.rs#L127-L138) on the DEX contract to deliver the funds. 4. The call fails because the `receive` function is not implemented on the DEX contract. 5. This failure causes the entire `cancel_all_orders` transaction to revert, leaving all orders, including potentially malicious or vulnerable ones, active on the book. ## Impact The `OwnerMsg::ForceCancelOrders` message, a critical safety mechanism, is rendered unusable. ## PoC N/A ## Mitigation Consider implementing a `receive` function on the DEX contract to allow it to accept coin transfers. A more direct mitigation would be to modify `cancel_order` or the loop in `cancel_all_orders` to detect when the refund recipient is the DEX contract itself and skip the transfer logic, as the funds are already in the contract's possession. # Issue M-13: Inconsistent multiplication during order creation and cancellation can lead to panics and Denial of Service during order cancellation Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/415 ## Found by berndartmueller ## Summary A discrepancy in the multiplication logic used between ASK limit order creation and order cancellation allows for the creation of orders that will always cause a panic when cancelled. This will prevent forcefully cancelling orders by the administrator, rendering the `OwnerMsg::ForceCancelOrders` functionality ineffective. ## Root Cause The root cause is the use of two different multiplication methods that have different overflow behaviors. - During order creation in [`order_creation.rs:90`](https://github.com/left-curve/left-curve/blob/4dd70e17bae94997663c50fa1e0b09ef4fa2d358/dango/dex/src/execute/order_creation.rs#L90), the quote amount for an ASK order is calculated using `base.checked_mul_dec_floor(price)`. This is an integer-times-decimal multiplication (`Int * Dec`), which is less susceptible to overflow because it divides by the decimal precision _before_ narrowing the result. - During order cancellation in [`order_cancellation.rs:91`](https://github.com/left-curve/left-curve/blob/4dd70e17bae94997663c50fa1e0b09ef4fa2d358/dango/dex/src/execute/order_cancellation.rs#L91), the remaining quote amount is calculated using `order.remaining.checked_mul(price)`. Here, `order.remaining` is a decimal, resulting in a decimal-times-decimal multiplication (`Dec * Dec`). This method can overflow with large numbers because it multiplies the underlying raw integer values first, which can exceed the maximum representable value before the final division and narrowing. The test case `audit_int_mul_dec_floor_succeeds_while_dec_mul_overflows` below confirms that it is possible for the `Int * Dec` multiplication to succeed while the `Dec * Dec` multiplication with the same economic values overflows. ## Internal Pre-conditions - A user needs to create an order with a relatively small (cheap) `base` amount (using a denom pair where the base has a high number of decimals so that, e.g., `1e18 + 1` tokens is a $ amount the attacker is willing to lose) and a super high price, such that the product of the two values is close to the overflow point for the `Dec * Dec` multiplication but not for the `Int * Dec` multiplication. ## External Pre-conditions None ## Attack Path 1. A malicious user calls the `create_order` function to place a limit ASK order on the book. They choose `base = 1e18 + 1` and `price = Int::::MAX` such that the quote amount calculation succeeds using `checked_mul_dec_floor`. 2. The order is successfully created and the user's base assets are locked. 3. At a later time, any attempt by the contract admin to to cancel this (and all others') order, will fail 4. The `cancel_order` function is called, which in turn calculates `remaining_in_quote` using `order.remaining.checked_mul(price)`. 5. This `Dec * Dec` multiplication overflows and causes the transaction to panic and revert. 6. As the cancellation transaction always fails, the order can never be removed from the book, blocking the admin from cleaning up (potentially malicious) orders. ## Impact This constitutes a Denial of Service vector against the administrative `OwnerMsg::ForceCancelOrders` message to forcefully cancel all orders. The admin will be unable to remove the problematic order from the order book, which could lead to further complications in managing the order book and ensuring its integrity. ## PoC Add the following test case to [`grug/math/src/multiply_fraction.rs`](https://github.com/left-curve/left-curve/blob/4dd70e17bae94997663c50fa1e0b09ef4fa2d358/grug/math/src/multiply_fraction.rs): ```rust #[test] fn audit_int_mul_dec_floor_succeeds_while_dec_mul_overflows() { let amount_base = crate::Int::::new(1_000_000_000_000_000_000u128 + 1); // 1e18 + 1 base tokens let price = crate::Udec128_24::raw(crate::Int::::MAX); // Int × Dec with floor succeeds let amount_quote = amount_base.checked_mul_dec_floor(price).unwrap(); // Cross-check with the underlying ratio computation for determinism let expected = amount_base .checked_multiply_ratio_floor(price.numerator(), crate::Dec::::PRECISION) .unwrap(); assert_eq!(amount_quote, expected); // Convert amount to Dec<_,18> so Dec×Dec narrows a value ~ 2 * u128::MAX let amount_dec = amount_base.checked_into_dec::<6>().unwrap(); // Dec × Dec overflows because the inner exceeds u128 after scaling let dec_mul = amount_dec.checked_mul(price); assert!(matches!(dec_mul, Err(crate::MathError::OverflowMul { .. }))); } ``` It shows that it is possible for the `Int * Dec` multiplication to succeed while the `Dec * Dec` multiplication with the same economic values overflows. ## Mitigation Consider using a consistent method for calculating quote amounts in both order creation and cancellation. The logic in `order_cancellation.rs` should be changed to mirror the safer integer-based multiplication used during creation. For example, the calculation in `dango/dex/src/execute/order_cancellation.rs` could be changed to: ```rust let base_atoms = order.remaining.into_int(); let quote_atoms = base_atoms.checked_mul_dec_floor(price)?; let remaining_in_quote = quote_atoms.checked_into_dec()?; ``` This ensures that any order that can be created can also be safely cancelled without risk of an arithmetic overflow. # Issue M-14: Ineffective minimum order size check for ASK limit orders can lead to Denial of Service Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/416 ## Found by berndartmueller, haxagon ## Summary The minimum order size check for `ASK` orders during order creation is ineffective, allowing the creation of a large number of economically insignificant `ImmediateOrCancel` (IOC) orders. During the cron-based auction, these orders are canceled and refunded, which can consume excessive execution time (and gas, but the cron is using an infinite gas meter, thus no OOG errors), causing block timeouts (e.g., when pairing with Tendermint/CometBFT). Additionally, the owner-callable `OwnerMsg::ForceCancelOrders` message can run out of gas when attempting to forcefully cancel all orders (_not limited to IOC orders!_). ## Root Cause In [`order_creation.rs:103-110`](https://github.com/left-curve/left-curve/blob/4dd70e17bae94997663c50fa1e0b09ef4fa2d358/dango/dex/src/execute/order_creation.rs#L103-L110), the pre-configured `pair.min_order_size` is checked against `amount_in_quote`. For an `ASK` order, `amount_in_quote` is calculated as `base * price`. A malicious user can bypass this check by providing a minimal amount of the `base` asset (e.g., 1 wei) and an arbitrarily high `price` (limit order). This creates a valid limit order that is practically guaranteed not to be filled. ```rust 103: ensure!( 104: amount_in_quote >= pair.min_order_size, 105: "order size ({} {}) is less than the minimum ({} {})", 106: amount_in_quote, 107: order.quote_denom, 108: pair.min_order_size, 109: order.quote_denom 110: ); ``` When the `cron_execute` function runs, [all unfilled IOC orders are collected into memory and then processed for cancellation and refunds](https://github.com/left-curve/left-curve/blob/4dd70e17bae94997663c50fa1e0b09ef4fa2d358/dango/dex/src/cron.rs#L577-L596), potentially causing block timeouts due to the high execution time required to handle a large number of orders. Additionally, a large number of such orders will cause the [owner-callable `OwnerMsg::ForceCancelOrders` message to consume a significant amount of gas](https://github.com/left-curve/left-curve/blob/4dd70e17bae94997663c50fa1e0b09ef4fa2d358/dango/dex/src/execute/order_cancellation.rs#L18-L31), potentially exceeding the block/transaction gas limit and preventing the cancellation of all orders. As this is not limited to IOC orders, the attacker has no rush to create a large number of orders quickly as GTC orders will remain open indefinitely. ## Internal Pre-conditions - An attacker needs to create a large number of ASK limit orders. - The orders must be of type `TimeInForce::ImmediateOrCancel` to affect the cron job or GTC orders to affect the owner-callable force cancel function. - Each order must have a minimal `base` amount and a very high, unrealistic `price` to remain unfilled, while still satisfying the `min_order_size` check in the `quote` currency. ## External Pre-conditions None ## Attack Path 1. An attacker identifies a trading pair and its `min_order_size`. 2. The attacker creates a large number of `ImmediateOrCancel` ASK limit orders. For each order, they provide a minimal amount of the base asset (e.g., 1 wei) and a very high price, such that `1 wei * price` is greater than `min_order_size`. 3. During the cron auction, it requires an excessive amount of time to process and cancel all these IOC orders, potentially leading to block timeouts. 4. The `OwnerMsg::ForceCancelOrders` function may run out of block/transaction gas when attempting to cancel all orders, preventing the owner from managing the order book effectively. ## Impact - Block production can be affected by a malicious actor who creates a large number of ASK IOC limit orders. - The owner may be unable to cancel all orders due to gas limitations when using the `OwnerMsg::ForceCancelOrders` function. ## PoC ## Mitigation For `ASK` orders, consider enforcing a minimum order size on the `base` asset amount in addition to the check on the `quote` asset value # Issue M-15: Users may fail to add liquidity because of overflow Source: https://github.com/sherlock-audit/2025-09-dango-dex-judging/issues/461 ## Found by 0x37, Khan2013, haxagon, heavyw8t, holtzzx ### Summary Users may fail to add liquidity because of overflow ### Root Cause In xyk dex pool, we have one `normalized_invariant`. When we add liquidity, we will calculated the increased `normalized_invariant` to mint shares. The [normalized_invariant's](https://github.com/sherlock-audit/2025-09-dango-dex/blob/main/left-curve/dango/dex/src/core/xyk.rs#L212-L217) formula is like `sqrt(a * b)`. Here we should notice that variable `a` & `b` is in term of `uint128`. So `a.checked_mul(b)` should be in term of `uint128`. `uint128` is around 1e39. If the decimals for base token and quote token are both 18, then it's quite possible to trigger overflow here. For example: 1. DAI as quote token, 18 decimal. 2. WETH as base token, 18 decimal. 3. If we provide 1 ETH and 4000 DAI to mint shares. We will fail. ```rust pub fn normalized_invariant(reserve: &CoinPair) -> MathResult { // amount is uint128. let a = *reserve.first().amount; let b = *reserve.second().amount; a.checked_mul(b)?.checked_sqrt() } ``` ### Internal Pre-conditions N/A ### External Pre-conditions N/A ### Attack Path 1. DAI as quote token, 18 decimal. 2. WETH as base token, 18 decimal. 3. If we provide 1 ETH and 4000 DAI to mint shares. We will fail. ### Impact According to the readme, The DEX contract is intended to work with tokens with >= 0 and <=18 decimal places. However, when base token and quote token's decimal is 18. it's easy to block adding liquidity. ### PoC _No response_ ### Mitigation cast uint128 to uint256 when we multiple a with b.

Dango DEX