shealtielanz
medium
Without a deadline parameter
, the transaction may sit in the mempool
and be executed at a much later time potentially resulting in an unfavorable/Worst price
.
This issue is in the USSD
contract at the UniV3SwapInput
function.
function UniV3SwapInput(
bytes memory _path,
uint256 _sellAmount
) public override onlyBalancer {
IV3SwapRouter.ExactInputParams memory params = IV3SwapRouter
.ExactInputParams({
path: _path,
recipient: address(this),
//deadline: block.timestamp, // @audit block.timestamp is set to zero by default making the transaction be executed later at more unfavorable time
amountIn: _sellAmount,
@audit the slippage is set to zero, meaning users can
accrue a loss by getting zero amount of tokens from the swap
amountOutMinimum: 0 //@audit no slippage, can receive 0 output tokens
});
uniRouter.exactInput(params);
}
In the UniV3SwapInput
function, the params struct is created with the deadline
parameter commented out
. When a rebalancing is called for, the rebalance
function implements it logic and then calls the UniV3SwapInput
function, which performs swaps
in other to enable the rebalancing of stablecoin
, however with no expiration deadline
, this transaction can sit in the mempool
due to volatile market and high gas-prices
where miners
would not include the transaction right away due to low gas incentives
, and when this is noticed by MEV
searchers, these searchers
(via frontrunning & Flashloans) can manipulate the reserves
of the Pool
it intends to perform this swap
on, thereby making the contract get less than what is required for rebalancing
and also lead to the dis-stability of stablecoin
, the impact is worst especially where there is also no slippage parameter
.
This could deeply affect the rebalancing of the USSD
contract.
Manual Review
The most common solution is to include a reasonable deadline
and timestamp
as an argument (instead of commenting it out).
and also don't use the block.timestamp
as the deadline
as it doesn't prevent this issue,.