Inappropriate slippage parameter settings.

[c4-bot-10]

Lines of code

https://github.com/code-423n4/2024-01-salty/blob/main/src/staking/Liquidity.sol#L62
https://github.com/code-423n4/2024-01-salty/blob/main/src/staking/Liquidity.sol#L72

Vulnerability details

Impact

Using inappropriate slippage parameters when calculating zapAmount.
The provided minAmountOut is set to 0.
the slippage control the user can receive the least optimal amount of the token they want to trade.
Users may incur losses of assets when adding liquidity.

// Deposit an arbitrary amount of one or both tokens into the pool and receive liquidity corresponding the the value of both of them.
	// As the ratio of tokens added to the pool has to be the same as the existing ratio of reserves, some of the excess token will be swapped to the other.
	// Due to precision reduction during zapping calculation, the minimum possible reserves and quantity possible to zap is .000101,
	function _dualZapInLiquidity(IERC20 tokenA, IERC20 tokenB, uint256 zapAmountA, uint256 zapAmountB ) internal returns (uint256 amountForLiquidityA, uint256 amountForLiquidityB  )
		{
		(uint256 reserveA, uint256 reserveB) = pools.getPoolReserves(tokenA, tokenB);
		(uint256 swapAmountA, uint256 swapAmountB ) = PoolMath._determineZapSwapAmount( reserveA, reserveB, zapAmountA, zapAmountB );

		// tokenA is in excess so swap some of it to tokenB?
		if ( swapAmountA > 0)
			{
			tokenA.approve( address(pools), swapAmountA );

			// Swap from tokenA to tokenB and adjust the zapAmounts
			zapAmountA -= swapAmountA;
			zapAmountB += pools.depositSwapWithdraw( tokenA, tokenB, swapAmountA, 0, block.timestamp );
			}

		// tokenB is in excess so swap some of it to tokenA?
		else if ( swapAmountB > 0)
			{
			tokenB.approve( address(pools), swapAmountB );

			// Swap from tokenB to tokenA and adjust the zapAmounts
			zapAmountB -= swapAmountB;
			zapAmountA += pools.depositSwapWithdraw( tokenB, tokenA, swapAmountB, 0, block.timestamp );
			}

		return (zapAmountA, zapAmountB);
		}

And the deadline is set to block.timestamp.
code-423n4/2022-11-paraspace-findings#429 as a validator can hold the transaction and the block it is eventually put into will be block.timestamp, so this offers no protection.
This could result in users executing transactions at unfavorable prices.

Proof of Concept

https://github.com/code-423n4/2024-01-salty/blob/main/src/staking/Liquidity.sol#L62
https://github.com/code-423n4/2024-01-salty/blob/main/src/staking/Liquidity.sol#L72

Tools Used

Recommended Mitigation Steps

Implement proper slippage control.

Assessed type

MEV

[c4-judge]

Picodes marked the issue as duplicate of #805

[c4-judge]

Picodes marked the issue as unsatisfactory:
Invalid