Security Audit Report

An attacker deposits 1 wei of any token, then calls emergencyWithdraw with an amount exceeding their balance (e.g., 1M tokens). Due to unchecked arithmetic at line 315, balances[attacker][token] underflows to a very large number (2^128 - (1M - 1)). The safeTransfer then sends 1M real tokens to the attacker. The attacker repeats this for different token addresses or uses multiple accounts, progressively draining all liquidity from the DEX. Each call extracts real ERC20 tokens while corrupting the accounting so no legitimate withdrawal can succeed.

An attacker places an order selling 1B tokens at price 1.5e18. When a taker fills this order: (1) the division-before-multiplication causes quoteAmount to lose precision, (2) the uint256->uint128 cast then truncates the already-reduced quoteAmount further if it exceeds 2^128. The order maker receives far less than they should. By repeating with many orders across different prices and amounts, the attacker systematically drains all maker funds.

The contract defines MAX_PRICE_DEVIATION (1% from 1:1 parity) but never validates it. An attacker places orders at extreme prices (e.g., 1e14 or 1e20). Users confused by the orderbook see these 'bargain' prices and fill them, losing massive value. Even users who don't fill the orders have their liquidity locked in these junk orders if the attacker front-runs position management.

An attacker places a self-swap order where baseToken == quoteToken (no validation prevents this). They lock 1M tokens. When filled, tokens move from balance to balance (net zero). When canceled, they receive a refund of the remaining amount. The attacker can abuse this to extract tokens by: (1) placing the self-swap, (2) partially filling it, (3) canceling to get refund, (4) repeating to extract more than deposited.

The contract prices all orders in fixed 18-decimal units without validating or normalizing for actual token decimals. An attacker observes that mUSD (6 decimals) and another 6-decimal stablecoin are available. They place an order selling 1B mUSD at a price of 1e15 (effectively 0.001 quote tokens per mUSD in 18-decimal space). Due to the mismatch between price format (18 decimals) and actual token behavior (6 decimals), the implied exchange rate is drastically wrong, allowing the attacker to extract massive arbitrage value.

An attacker exploits the unchecked arithmetic in emergencyWithdraw (Finding 6) combined with the reentrancy vulnerability in withdraw (Finding 14) to drain all liquidity. Step 1: Attacker calls emergencyWithdraw(token, balance+1), causing unchecked underflow where balances[attacker][token] becomes 2^128-1. Step 2: safeTransfer sends balance+1 tokens to attacker, draining pool. Step 3: Attacker's corrupted balance allows them to call emergencyWithdraw again, repeating the drain. Step 4: Meanwhile, legitimate users calling withdraw during a malicious ERC20 reentrancy trigger double-decrements of totalDeposits (Finding 14), further corrupting accounting. Result: All protocol liquidity is drained, totalDeposits and balances diverge, other users cannot withdraw.

An attacker exploits Finding 1 (division-before-multiplication in quoteAmount) combined with Finding 10 (missing token decimal validation). Step 1: Attacker identifies a baseToken with 6 decimals and quoteToken with 18 decimals. Step 2: Attacker places order: sell 1e6 baseToken at price=1e12 (0.000001 in 18-decimal notation). Step 3: A taker calls fillOrder: quoteAmount = (1e6 * 1e12) / 1e18 = 1e18 / 1e18 = 1 (truncates correctly). But if attacker sets price=1e11 instead: quoteAmount = (1e6 * 1e11) / 1e18 = 1e17 / 1e18 = 0 (truncates to zero). Step 4: Taker receives 1e6 baseToken for 0 quoteToken, draining 1e6 from maker. Step 5: Attacker repeats with multiple orders, systematically draining all maker liquidity via precision loss exploitation. With 1000 orders, attacker extracts 1000 * 1e6 tokens for zero payment.

An attacker exploits Finding 4 (no price validation against MAX_PRICE_DEVIATION) combined with Finding 3 (cross-decimal arithmetic without normalization). Step 1: Attacker places order: baseToken=USDC (6 decimals), quoteToken=mUSD (6 decimals), amount=1e9, price=1e14 (0.0001% of parity). Step 2: Attacker locks 1e9 USDC, offering to sell at 1e-4 price. Step 3: Taker calls fillOrder: quoteAmount = (1e9 * 1e14) / 1e18 = 1e23 / 1e18 = 1e5 mUSD (0.0001 mUSD for 1 USDC). Step 4: If an automated market-making bot fills this order, taker pays only 1e5 mUSD for 1e9 USDC worth ~1e9 mUSD, extracting ~999,900 mUSD of value. Attacker can repeat with multiple extreme prices to drain all quoteToken liquidity. Additionally, if attacker sets price=type(uint128).max (10^38), the calculation overflows and truncates (Finding 2), resulting in zero payment for large fills.

An attacker exploits Finding 5 (reentrancy in fillOrder via cancel) combined with Finding 7 (linked list head corruption) and Finding 12 (incomplete order deletion). Step 1: Attacker places order A (orderId=10) in the list: HEAD -> 10 -> 20 -> 30. Step 2: Attacker places order B (orderId=20). Step 3: Taker calls fillOrder(10, halfAmount), which triggers _removeFilledOrder if order becomes fully filled. Step 4: During _removeFilledOrder execution, order.maker is set to address(0) but order.remaining is NOT deleted (Finding 12). Step 5: Before _removeFilledOrder completes, attacker calls cancel(10) in a reentrant callback, which checks order.maker != address(0). Step 6: If cancellation races with removal, the linked list pointers become inconsistent: orders[20].prev may still point to 10, but orders[10].next was updated. Step 7: Subsequent getOrders calls read the corrupted list and skip valid orders (Finding 7) or enter infinite loops (Finding 30). Step 8: The attacker places a new order C (orderId=35) but due to list corruption, it inserts at the wrong position, potentially being filled before its price is reached.

An attacker exploits Finding 13 (missing baseToken != quoteToken validation) combined with Finding 1 (division-before-multiplication precision loss). Step 1: Attacker places order: baseToken=USDC, quoteToken=USDC, amount=1e6, price=1e18 (1:1 self-swap). Step 2: balances[attacker][USDC] -= 1e6 (locked). Step 3: Taker calls fillOrder(orderId, 5e5): quoteAmount = (5e5 * 1e18) / 1e18 = 5e5 (correct). Step 4: balances[taker][USDC] -= 5e5, balances[taker][USDC] += 5e5 (net zero), balances[attacker][USDC] += 5e5. Step 5: attacker now has 5e5 from fill. Step 6: Attacker calls cancel to refund remaining 5e5. Step 7: attacker receives 5e5 from cancel, total gain = 5e5 + 5e5 = 1e6 net gain from the fill + cancel without real trading. Repeated 100x: attacker steals 100e6 USDC by exploiting self-swap accounting.

An attacker exploits Finding 3 (cross-decimal arithmetic without normalization) combined with Finding 4 (no MAX_PRICE_DEVIATION enforcement). Step 1: Protocol has two 6-decimal stablecoins: USDC and mUSD. Step 2: Attacker places order: baseToken=mUSD (6 decimals), quoteToken=USDC (6 decimals), amount=1e8, price=1e15 (0.001 in 18-decimal representation). Step 3: The price formula is: quoteAmount = (1e8 * 1e15) / 1e18 = 1e23 / 1e18 = 1e5 USDC (0.0001 USDC). Step 4: Taker fills: receives 1e8 mUSD (100 actual tokens at 6 decimals) for 1e5 USDC (0.0001 actual tokens). This is a 1,000,000x arbitrage. Step 5: Attacker drains all mUSD liquidity by placing multiple such orders, extracting orders at massive discounts by exploiting the lack of decimal scaling.