# The deposit / withdraw / trade transaction lack of expiration timestamp check and slippage control

Ajna pool deposit/withdraw/trade functions lack deadline and slippage checks, letting stale mempool transactions execute at unfavorable prices or lock lender funds.

- Payout: Contest reward
- Severity: high
- Program: Ajna
- Credited: ctf_sec
- Disclosed: 2022-12-21
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-01-ajna-judging/issues/39
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-01-ajna%3AH-11
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:business-logic

**Target:** Pool.sol deposit/withdraw/trade functions (removeQuoteToken, addQuoteToken)
**Root cause:** Pool actions accept no deadline and no min/max received amount, so transactions can execute long after submission at arbitrarily worse prices.
**Steps:**
1. Submit `removeQuoteToken(maxAmount_, index_)` with no minReceived parameter
2. Transaction sits in mempool while other lenders/borrowers change bucket state and LUP
3. On late execution, `removedAmount_` can be far below `maxAmount_` with no revert
4. Similarly `addQuoteToken` can land in a bucket whose price moved, locking funds since withdrawal would push LUP below liquidation threshold
**How found:** Compared Ajna's forked Uniswap V2 router pattern (which has `ensure(deadline)` and amountMin checks) against Ajna's Pool functions and noticed both safeguards were dropped.
**Exploitation:** Attacker or MEV searcher observes pending deposit/withdraw tx, manipulates bucket state or LUP via borrows/withdrawals so the victim's stale tx executes at a much worse rate or becomes unwithdrawable.
**Insight:** When a protocol forks a known router/AMM, diff the fork against upstream for removed safety modifiers (deadline, min-out) — missing ones are often judged valid high-severity findings.