Assessment reports>Singularity>Informational findings>Uniswap liquidity provision has unnecessary deadline
Category: Coding Mistakes

Uniswap liquidity provision has unnecessary deadline

Informational Severity
Informational Impact
N/A Likelihood

Description

The UniswapLiquidityAssetManager contract's uniswapLiquidityProvision function first calls the _releaseFundsAndPrepareLiquidityProvisionArgs to prepare arguments for liquidity provision, and then it calls _executeLPMint, which calls the Uniswap NonfungiblePositionManager's mint function to execute the mint. The arguments for this prepared by _releaseFundsAndPrepareLiquidityProvisionArgs include the following deadline:

mintParams.deadline = block.timestamp + 2 minutes;

As the call to nonfungiblePositionManager.mint happens in the same transaction, the time of execution of the mint will always be the value of block.timestamp at the moment mintParams.deadline is set. As long as mintParams.deadline is set to a value of at least block.timestamp, the deadline will always be respected, and the 2 minutes is unnecessary.

The purpose of the deadline argument is for transactions that have been prepared off chain, which may be delayed from the moment the user sets the parameters (for example in the mempool or due to using a hardware device to sign the transaction) until they land on-chain. If such usage of the deadline functionality was intended, then the deadline should be set by the user (or their client/front-end), included as a public value in the circuit, and be part of the signed data in the circuit. For example, the user's client could set the deadline to the timestamp that is two minutes in the future at the time that the user generates the proof.

Impact

The addition of 2 minutes is unnecessary but has no negative impact in itself. The deadline functionality is not used to protect against slippage, however.

Recommendations

If the Uniswap deadline functionality is intended to be used to protect against slippage, then the value of deadline should be obtained from a public value in the circuit, and that value should be part of the signed data in the circuit.

Remediation

This issue has been acknowledged by Singularity, and a fix was implemented in commit 4df0140f.

Zellic © 2024Back to top ↑