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.
File: contracts/governance/twTAP.sol
307
308 // Mint twTAP position
309 tokenId = ++mintedTWTap;
310 _safeMint(_participant, tokenId);
311
312 uint256 expiry = block.timestamp + _duration;
313 require(expiry < type(uint56).max, "twTAP: too long");
314 // Eligibility starts NEXT week, and lasts until the week that the lock
315: // expires. This is guaranteed to be at least one week later by the
Lines of code
307
Vulnerability details
Passing
block.timestampas 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.Assessed type
other