This function is used if there is a logic that includes token contributions and so on, case however is that when attempting to add liquidity the execution does not provide all necessary protection, in this instance the protocol uses a hardcoded type(uint256).max
as the deadline parameter for this attempt at adding the liquidity via the well, which allows the trnasaction to linger in the mempool for long and cause it to get finalized in a worse condition.
A simple POC of the issue with not having deadline checks, is when, say an attempt is made to swap ABC for XYZ, where the min acceptable XYZ is 100, now if deadline is not provided, this transaction can linger for long where when the trasnaction eveuntually gets fialized, auser could have encountered loss in USD
value of XYZ.
Now pertaining to the attached snippet this would also be applicable to the value of the barnRaiseToken
that is sent, i.e tokenAmountIn
, cause dependent on the current USD value of the token, different decisions would be made on how much tokens to get sent and used to add liquidity.
Adding liquidity is done without deadline protection could cause for the transaction to be unfairly executed.
As a general rule, whenever adding/removing liquidity, always attach both slippage & deadline protection.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.