Severity depends on reachable impact and deployment context. Listed tools are review aids; their applicability depends on language, version and configuration.
Insufficient slippage protection lets a market operation execute outside the price range its user or protocol intended. The clearest pattern is an exact-input swap with amountOutMin set to zero. The transaction can then succeed after ordinary market movement, a route change, or deliberate price movement leaves it with almost no output.
The Uniswap V2 router interface makes the relevant controls explicit: exact-input swaps take a minimum output, exact-output swaps take a maximum input, and both take a deadline.
A missing or excessively loose bound becomes exploitable when an attacker can observe or predict the trade, move the execution price, and recover more from the price movement than the attack costs. In a sandwich, the attacker trades before the victim, lets the victim move the pool further, and trades back afterward. Ethereum's MEV documentation describes how this produces worse execution for the sandwiched user.
Not every bad fill is an attack, and a deadline is not a price bound. A deadline limits how long a transaction remains executable; it does not constrain the exchange rate before that time. Likewise, a nonzero minOut is only useful if its source is independent enough from the pool being traded and its tolerance matches the caller's intent.
Trace every swap-like integration, including vault compounding, fee conversion, rebalancing, liquidation, migration, and zap routes. Determine who chooses the bound, when the quote is sampled, which decimals it uses, and whether adapters silently replace a caller's bound with zero.
Test price movement up to and beyond the permitted tolerance. Include shallow liquidity, fee-on-transfer tokens where supported, multi-hop routes, stale transactions, partial fills, and an attacker ordering trades around the operation. Assert final balance deltas rather than trusting a router return value alone.
Firepan can review submitted source for zero, constant, dropped, or effectively disabled bounds and stale-deadline patterns. It cannot decide the correct tolerance for a live market or guarantee transaction ordering.
Is minOut = 1 adequate?
Usually not. A syntactically nonzero bound can still accept nearly total loss.
Should a vault let any caller choose its slippage?
Only within protocol-defined limits. Otherwise a malicious caller may deliberately select a losing bound.
Firepan
Run a free scan — results in minutes, no credit card required.
Run Free Scan →Assess smart contract admin powers, upgrade authority, key custody, delays, caps, and the limits of source-only centralization analysis.
Review smart contract liveness failures caused by gas growth, external-call reverts, griefing, and unrecoverable state.
Understand first-depositor and donation attacks against tokenized vaults, rounding conditions, tests, and mitigation tradeoffs.
Review accounting assumptions for fee-on-transfer, rebasing, and other non-standard ERC-20 tokens, with test and mitigation guidance.
Understand transaction-ordering risk, sandwich attacks, the conditions that make them profitable, and practical review and mitigation techniques.