search

sherlock-audit / 2023-10-real-wagmi-judging

16 stars 14 forks source link

phenom - Using block.timestamp as the deadline/expiry invites MEV #159

Closed sherlock-admin closed 1 year ago

sherlock-admin commented 1 year ago

phenom

medium

Using block.timestamp as the deadline/expiry invites MEV

Using block.timestamp as the deadline/expiry invites MEV

Impact:

Passing block.timestamp as the expiry/deadline of an operation does not mean 'require immediate execution' - it means 'whatever block this transaction appears in, I'm comfortable with that block's timestamp'. Providing this value means that a malicious miner can hold the transaction for as long as they like (think the flashbots mempool for bundling transactions), which may be until they are able to cause the transaction to incur the maximum amount of slippage allowed by the slippage parameter, or until conditions become unfavorable enough that other orders, e.g. liquidations, are triggered. Timestamps should be chosen off-chain, and should be specified by the caller to avoid unnecessary MEV.

Instances (8):

File: LiqBorrowingMan/LiquidityBorrowingManager.sol

142:         return block.timestamp;

File: LiqBorrowingMan/abstract/DailyRateAndCollateral.sol

47:             uint256 timeWeightedRate = (uint32(block.timestamp) -

54:         holdTokenRateInfo.latestUpTimestamp = uint32(block.timestamp);

79:             uint256 timeWeightedRate = (uint32(block.timestamp) -

86:         holdTokenRateInfo.latestUpTimestamp = uint32(block.timestamp);

File: LiqBorrowingMan/abstract/LiquidityManager.sol

89:         bytes32 salt = keccak256(abi.encode(block.timestamp, address(this)));

358:                 deadline: block.timestamp

405:                 deadline: block.timestamp
sherlock-admin2 commented 1 year ago

1 comment(s) were left on this issue during the judging contest.

tsvetanovv commented:

There is a deadline check in parent function