MorpheusAI

Summary

In the Morpheus setup, the L2TokenReceiver contract is designed to interact with
Uniswap V3 on Arbitrum for performing token swaps. This contract utilizes the swap function,
which relies on block.timestamp to enforce deadlines for these swaps. The function parameters
include the amount of tokens to swap amountIn, the minimum amount of tokens to receive amountOutMinimum for slippage protection, and a deadline for when the swap must be completed.

The swap aims to exchange tokens at a specified rate, within a defined slippage tolerance, and before a certain deadline to ensure the trade's execution aligns with the user's expectations and market conditions.

Vulnerability Details

The primary vulnerability arises from the reliance on block.timestamp for setting the swap deadline.
block.timestamp reflects the current time but is susceptible to blockchain reorganizations (reorgs).

In a cross-chain context, especially involving chains like Arbitrum where occasional reorgs can occur,
the actual execution time of a swap can significantly deviate from the intended timestamp.

Impact

The reliance on block.timestamp introduces a risk where, in the event of a chain reorg,
the swap transaction could be included in a different block with a new timestamp.

This discrepancy can lead to several adverse outcomes:

Slippage Protection Failure, where the market conditions change unfavorably during the delay caused by the reorg,
the swap might execute at a rate that does not meet the user's slippage protection requirements, resulting in a suboptimal trade.

Deadline Miss, where the transaction may fail to execute if the new block.timestamp exceeds the specified deadline, resulting in lost opportunities or the need for re-initiation by the owner.

Tools Used

manual review

Recommendations

To address these vulnerabilities and minimize their impact, several mitigation strategies can be employed:

Implement mechanisms to dynamically adjust deadlines based on observed network conditions,
including the average time for cross-chain message delivery and processing, and potential delays caused by reorgs.

Establish robust monitoring systems to quickly detect reorgs and assess their impact on ongoing
and pending transactions, enabling swift response to re-execute transactions as necessary.

Develop fallback mechanisms or retry logic for the swap function that can automatically adjust to changing conditions, such as re-executing a transaction with updated parameters if it fails due to timing issues.