plamentsv/dex-integration-security

Injectable Skill: DEX Integration Security

Protocol Type Trigger: dex_integration (detected when recon finds: swap|addLiquidity|removeLiquidity|IUniswapV2Router|ISwapRouter|amountOutMin|amountOutMinimum|slippage - AND the protocol is NOT itself a DEX implementation) Inject Into: Breadth agents, depth-external, depth-edge-case Language: Primarily EVM; applicable to Sui PTB-based DEX interactions and Soroban DEX integrations (SoroSwap, Phoenix Protocol) Finding prefix: [DEX-N]

Orchestrator Decomposition Guide

When decomposing this skill into depth agent investigation questions, map sections to domains:

• Sections 1, 2: depth-external (external DEX call safety, return value handling)
• Sections 3, 4: depth-edge-case (boundary conditions, fee tier assumptions)
• Section 5: depth-state-trace (approval state management)

When This Skill Activates

Recon detects DEX integration patterns: swap, addLiquidity, removeLiquidity, IUniswapV2Router, ISwapRouter, amountOutMin, amountOutMinimum, slippage, exactInputSingle, exactInput, swapExactTokensForTokens - but the protocol itself is NOT a DEX/AMM implementation. This skill analyzes the CALLER's integration with an external DEX, not the DEX internals.

---

1. Slippage Parameter Analysis

For each function that calls a DEX swap:

1a. Parameter Origin

• Is amountOutMin (or equivalent) user-provided or computed on-chain?
• If computed: what oracle or price source feeds the computation? (cross-reference ORACLE_ANALYSIS if applicable)
• Can the parameter be set to 0? If yes: trace all callers - does ANY code path pass 0 as slippage tolerance?

1b. Parameter Forwarding

• Is the slippage parameter forwarded through intermediate functions? At each hop: is it modified, scaled, or silently dropped?
• For protocols that apply their own fee before swapping: is amountOutMin adjusted to account for the fee deduction from the input amount?

1c. Multi-Hop and Multi-Swap

• For multi-hop swaps (encoded path): is slippage checked on intermediate amounts or only the final output?
• For operations requiring multiple sequential swaps: is slippage enforced per-swap or only on aggregate output?

Tag: [TRACE:swap_call → amountOutMin_source={user/computed/hardcoded} → value_can_be_zero={YES/NO} → forwarded_through={functions}]

---

2. Deadline Enforcement

For each function that calls a DEX router:

2a. Deadline Value

• Is a deadline parameter passed to the DEX router?
• Is block.timestamp used as the deadline? (provides no MEV protection - always passes)
• Is the deadline hardcoded to type(uint256).max or equivalent? (same issue - no protection)

2b. Queued or Delayed Swaps

• For protocols that queue swaps for later execution: is the deadline relative to queue time or execution time?
• If relative to queue time: a long queue delay can cause the swap to execute at a stale price with an expired market context

2c. L2 Considerations

• For L2 deployments: does the deadline account for sequencer delay or batch submission lag?
• Can the sequencer hold a transaction to execute it at a favorable time within the deadline window?

Tag: [TRACE:router_call → deadline={value_or_source} → block.timestamp_used={YES/NO} → queue_delay_considered={YES/NO}]

---

3. Return Value Handling

For each DEX call that returns swap output amounts:

3a. Actual vs Expected

• Does the protocol check the actual amount received vs the expected output?
• For fee-on-transfer tokens: does the protocol use the router return value (pre-fee) or re-check balance (post-fee)?
• If the protocol uses balanceOf delta: is the delta computed correctly (post-balance minus pre-balance in the same transaction)?

3b. Multi-Output Validation

• For removeLiquidity calls: are BOTH output token amounts validated?
• For swaps returning multiple values: are all return values consumed, or are some silently ignored?

3c. Failure Handling

• If the DEX call reverts: does the protocol handle the revert gracefully, or does it propagate and brick a larger operation (e.g., batch liquidation blocked by one failed swap)?
• For try/catch wrapped swaps: does the catch path leave state consistent?

Tag: [TRACE:swap_return → checked={YES/NO} → fee_on_transfer_aware={YES/NO} → revert_handling={propagate/catch/ignore}]

---

4. Fee Tier and Pool Assumptions

4a. Hardcoded Pool or Fee Tier

• Are pool addresses or fee tiers (e.g., Uniswap V3 fee tiers: 100, 500, 3000, 10000) hardcoded?
• If hardcoded: can the optimal pool change over time due to liquidity migration or new pool deployment?
• Does the protocol verify the pool contract is genuine (not a malicious contract deployed at an expected address)?

4b. Pool Liquidity Assumptions

• Does the protocol assume sufficient liquidity exists in the target pool?
• For large swap amounts: can the swap fail or produce extreme slippage if pool liquidity drops?
• For protocols specifying pools by fee tier: what happens if multiple pools exist for the same pair with different fee tiers?

Tag: [TRACE:pool_selection → hardcoded={YES/NO} → fee_tier={value} → pool_verified={YES/NO} → liquidity_assumption={documented/implicit}]

---

5. Router Approval Safety

5a. Approval Scope

• Does the protocol grant unlimited (type(uint256).max) approval to the router?
• Is the approval granted once in initialization or per-transaction?
• If per-transaction with exact amounts: is a race condition possible between approval and swap execution?

5b. Router Mutability

• Is the router address upgradeable or replaceable (via admin setter)?
• After a router migration: are stale approvals to the old router revoked?
• Can the old router still spend tokens if approvals remain?

5c. Permit Usage

• For protocols using permit (EIP-2612) instead of approve: is the permit deadline scoped tightly?
• Is the permit nonce managed correctly to prevent replay?
• Can a permit intended for one router be used by a different contract?

Tag: [TRACE:approval → scope={unlimited/exact} → router_upgradeable={YES/NO} → stale_revoked={YES/NO}]

---

Common False Positives

• amountOutMin = 0 in atomic flash loan context: If the entire operation reverts on net loss within the same transaction, zero slippage tolerance is acceptable (atomic protection guarantees revert on unfavorable outcome)
• Hardcoded pool address for canonical immutable pair: Stable pairs on immutable DEX deployments (e.g., WETH/USDC on Uniswap V3 mainnet) carry low migration risk
• Unlimited approval to verified immutable router: If the router contract is non-upgradeable and its code is verified, unlimited approval is low risk
• block.timestamp deadline on private/protected functions: If the swap function is only callable by a trusted keeper within a controlled execution flow, MEV deadline protection may be enforced upstream

Step Execution Checklist (MANDATORY)

| Section | Required | Completed? | Notes | |---------|----------|------------|-------| | 1. Slippage Parameter Analysis | YES | | Origin, forwarding, multi-hop | | 2. Deadline Enforcement | YES | | Value, queue delay, L2 | | 3. Return Value Handling | YES | | Actual vs expected, fee-on-transfer | | 4. Fee Tier and Pool Assumptions | IF hardcoded pool/fee tier | | Pool verification, liquidity | | 5. Router Approval Safety | IF protocol approves router | | Scope, mutability, stale approvals |