Use of block.timestamp for deadline in every swap can lead to loss
Summary
Since block.timestamp is always relative, using it in any way is equivalent to using no deadline at all. Needs to use a user defined input to effectively enforce any deadline.
Without a deadline, the transaction might be left hanging in the mempool and be executed way later than the user wanted.
That could lead to user loss. Eventhough in some fucntions minAnountout is mentioned , but user will get that that token which is given minimum , but the out token which is to be used for staking , price of that can go lower , or not able to get yeild , which he will get if txn is execute before proper deadline , because a validator can just hold onto the transaction. And when it does get around to putting the transaction in a block, it'll be block.timestamp, so they've got no protection there.
Vulnerability Detail
Lets consider one function.
In baseStakingvault.sol , when _depositFromNotionol is called, _staketokens() if called . In which Trade object is made and in that deadline is set to block.timestamp . Which is not useful at all. As this is called internally, still deadline parramter should be added. And not be hardcoded as block.timestamp
Impact
Transaction can be left hangning in the mempool , and situation can occur in which from swap not deserved tokens in output will be obtained
this same issue is present in _redeemFromNotionol and many other fuctions present in scope too.
I will be adding just one code snippet
sa9933
Medium
Use of block.timestamp for deadline in every swap can lead to loss
Summary
Since block.timestamp is always relative, using it in any way is equivalent to using no deadline at all. Needs to use a user defined input to effectively enforce any deadline. Without a deadline, the transaction might be left hanging in the mempool and be executed way later than the user wanted.
That could lead to user loss. Eventhough in some fucntions minAnountout is mentioned , but user will get that that token which is given minimum , but the out token which is to be used for staking , price of that can go lower , or not able to get yeild , which he will get if txn is execute before proper deadline , because a validator can just hold onto the transaction. And when it does get around to putting the transaction in a block, it'll be block.timestamp, so they've got no protection there.
Vulnerability Detail
Lets consider one function.
In baseStakingvault.sol , when _depositFromNotionol is called, _staketokens() if called . In which Trade object is made and in that deadline is set to block.timestamp . Which is not useful at all. As this is called internally, still deadline parramter should be added. And not be hardcoded as block.timestamp
Impact
Transaction can be left hangning in the mempool , and situation can occur in which from swap not deserved tokens in output will be obtained
this same issue is present in _redeemFromNotionol and many other fuctions present in scope too. I will be adding just one code snippet
Code Snippet
https://github.com/sherlock-audit/2024-06-leveraged-vaults/blob/main/leveraged-vaults-private/contracts/vaults/staking/EthenaVault.sol#L45C4-L77C6
Tool used
Manual Review
Recommendation
Used deadline parameter like they have used in Uniswap. should execute within 15min or 30min like that.
Duplicate of #79