Skip to content
Financial Context Wiki

Swap deadlines, slippage, and calldata: what to verify before signing

Learn how to decode a DEX swap call and verify its router, function, amount bounds, route, recipient, and deadline before signing.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

Before signing a DEX swap, verify the chain, destination contract, decoded function, token addresses, input or output bound, route, recipient, and any deadline. The percentage shown as “slippage” in a front end is not itself an on-chain instruction. It is commonly used to calculate a bound such as amountOutMin or amountOutMinimum for an exact-input swap, or amountInMax or amountInMaximum for an exact-output swap.

A deadline is a time guard, not a price guarantee. If the router checks a deadline and the transaction executes after it, the call should revert. A transaction can still execute before that deadline at any price permitted by its amount bound. A long deadline leaves that authorization usable for longer; a very short deadline increases the chance of expiry before inclusion.

Calldata is not self-describing. Decode it with the verified ABI for the exact contract on the selected chain, including any nested multicall or Universal Router commands. If the wallet cannot show trustworthy decoded fields, do not infer their meaning from byte positions or a function-name database alone.

How it works

Decode the actual call

Under the Solidity ABI, the first 4 bytes of calldata are the function selector and the encoded arguments begin at the fifth byte. The selector can collide or be mislabeled, so match it against the ABI of the verified destination contract. A proxy, aggregator, or router may wrap the swap in multicall, execute, or another function; decode every nested payload that can transfer tokens or change the final recipient.

For an exact-input swap, the input is fixed and the protective field sets the minimum acceptable output. For an exact-output swap, the desired output is fixed and the protective field caps the input. A zero or unexpectedly loose bound may remove meaningful price protection. Token decimals matter: compare raw integer amounts only after mapping each token address to the correct decimals and symbol.

Check route, recipient, and value

Confirm that the route begins with the token being spent and ends with the token expected. Inspect intermediate tokens, pool fees, and any commands that wrap, unwrap, sweep, or transfer balances. The recipient should be the intended wallet or a contract whose behavior is understood. Also check the transaction’s native value; it can be separate from ERC-20 amounts encoded in calldata.

Locate the deadline

Deadline placement depends on the router version. Uniswap V2-style router functions include a deadline argument, and the original Uniswap V3 ISwapRouter structs include one. Universal Router exposes both execute(commands, inputs, deadline) and an overload without a deadline. Therefore, never assume every swap has a deadline or that it appears inside the same nested swap parameters.

The deadline is normally compared with the block timestamp used during execution. It does not cancel a pending transaction, guarantee prompt inclusion, or protect against an adverse price that remains inside the amount bound. If cancellation is needed, the sender must use the chain and wallet’s transaction-replacement mechanism, and replacement is not guaranteed once the original is included.

Worked example

A quote expects 10,000 USDC from an exact-input swap, and the user selects 1% slippage. Ignoring fees already included in the quote, the expected minimum is 9,900 USDC. With USDC’s 6 decimals, that bound is the raw integer 9900000000.

The decoded call instead contains amountOutMinimum = 9000000000, or 9,000 USDC. That permits up to 10% less than the quote, not 1%. The recipient is also an unfamiliar address and the deadline is many hours away. Any one of those mismatches is enough to reject the request and rebuild it through a trusted interface. After rebuilding, simulate the exact unsigned transaction against recent state and re-check the decoded payload before signing.

Verification checklist and risks

  • Verify the selected chain and the router or proxy address against the protocol’s official deployment records.
  • Decode with the verified contract ABI; expand nested calls and router commands rather than reviewing only the outer function.
  • Match token addresses, direction, decimals, fixed amount, protective amount bound, route, fee tiers, recipient, and native value.
  • Convert the deadline to an absolute time and decide whether its remaining window is intentional. Treat a missing deadline as a design choice that needs separate review.
  • Simulate the exact transaction from the signing address against recent state. A successful simulation is evidence for that state, not a guarantee of inclusion or final execution.
  • Review approvals or Permit2 permissions separately. Good swap bounds do not make an unlimited or malicious token authorization safe.
  • Tight bounds can revert during ordinary price movement; loose bounds increase execution-price and sandwich risk. A reverted on-chain transaction can still consume gas.

Common misconceptions

Myth: The displayed slippage percentage is signed

Usually the signed payload contains amount bounds derived from that setting. Verify the actual integers and token decimals; a correct-looking interface label does not prove that the calldata uses the same tolerance.

Myth: Every swap uses amountOutMin and deadline

Names and locations vary by router and function. Exact-output swaps protect the input side, and some entry points omit the deadline or place it on an outer call.

Myth: A deadline prevents a bad price

It only limits when execution is allowed if the called code enforces it. Price protection comes from the amount bound, and even that permits every execution inside the bound.

Myth: Decoding the outer function is enough

Aggregators and universal routers can contain several calls, token permits, transfers, and cleanup commands. The security-relevant recipient or amount may be inside a nested payload.

Sources

Navigation

Search the wiki...