Part 2

Zaros
PerpetualsDEXFoundrySolidity
70,000 USDC
View results
Submission Details
Severity: low
Invalid

Global Swap Deadline State Enables MEV Timing Manipulation in UniswapV3Adapter

Summary

A security vulnerability has been identified in the UniswapV3Adapter contract where a global stored deadline is used for all swap transactions instead of requiring per-transaction deadlines.

The current implementation uses a stored deadline state variable that is set via setDeadline() and applies this single deadline across all swap transactions. This architectural decision introduces temporal consistency issues and transaction timing vulnerabilities.

The contract maintains a global deadline state that, once set, governs all subsequent swap operations. This poses security concerns as transaction execution timing becomes predictable and potentially manipulatable. Malicious actors monitoring the mempool can observe the fixed deadline and optimize their transaction ordering to exploit this predictability.

Moreover, the global deadline state fails to account for varying latency requirements across different trading scenarios and market conditions. During high volatility periods, users might require stricter deadline controls, while more relaxed timeframes might be acceptable in stable market conditions. The current implementation prevents this kind of dynamic adaptation.

Impact

The vulnerability manifests in the contract's core swap execution logic where the stored deadline is used without transaction-specific validation. In the executeSwapExactInputSingle function, transactions rely on this global deadline state, creating a uniform time window that could be significantly different from when the transaction was actually submitted.

A particularly concerning scenario arises in MEV contexts, where specialized bots can monitor transactions and manipulate their execution timing. These bots can hold transactions until just before the global deadline expires, potentially executing them under significantly different market conditions than when they were submitted.

Proof of Concept

contract UniswapV3Adapter {
uint256 deadline; // Stored globally
function setDeadline(uint256 _deadline) public onlyOwner {
if (_deadline < block.timestamp) revert Errors.SwapDeadlineInThePast();
deadline = _deadline;
emit LogSetDeadline(_deadline);
}
function executeSwapExactInputSingle(SwapExactInputSinglePayload calldata swapPayload)
external
returns (uint256 amountOut)
{
// Uses stored deadline for all swaps
// ...
}
}

Recommended Fix

The vulnerability can be remediated by implementing transaction-specific deadlines:

function executeSwapExactInputSingle(
SwapExactInputSinglePayload calldata swapPayload,
uint256 swapDeadline
) external returns (uint256 amountOut) {
if (swapDeadline < block.timestamp) revert Errors.SwapDeadlineInThePast();
return swapRouter.exactInputSingle(
IUniswapV3RouterInterface.ExactInputSingleParams({
// ... other params ...
deadline: swapDeadline,
// ... other params ...
})
);
}

The contract should be refactored to remove the global deadline state and associated setter function. All swap-related functions should be updated to include deadline parameters in their signatures. This change ensures that each transaction carries its own timing constraints, allowing for more granular control over execution windows and reducing the attack surface for timing-based manipulations.

Updates

Lead Judging Commences

inallhonesty Lead Judge 4 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.