Sparkn

Summary

Miners can manipulate block.timestamp to disadvantage protocol/project usage

Vulnerability Details

Miners can manipulate block.timestamp as this is under their control within a certain leeway of past timestamps. For example last block.timestamp can be within say 13-15 seconds of thee next so miner can choose a timestamp that makes it so that resulting logic is different from if it was one value block.timestamp vs another but differ by seconds

Consider the following example when it comes to the various deploy and distribute functions e.g

If block.timestamp < closeTime as set in saltToCloseTime[salt] the deployment reverts. If owner or organizer had anticipated that earliest they would distribute was after a given time e.g 1000 seconds as timestamp say closeTime == 1000 so saltToCloseTime[salt] = 1000. Miner can make block.timestamp expected to be 1000 seconds as 999(allowed as they have leeway to set this and difference 1 second is allowable) so that 999< 1000 and function reverts. This whereas owner or organizer had informed stakeholders distribution occurring

Impact

This can led to potential reverts in many functions relying on block.timestamp as in the example above. It can also harm reputation if expectation and communication distributions happening at particular time but is manipulated to occur in as next block by miner as opposed to expected block

Additionally miners can ignore transaction calls for functions relying on

whenever transaction is finally mined block.timestamp will be greater than saltToCloseTime[salt] so valid at a later stage. This is akin to a DOS like attack by miners to prevent distributions from happening earlier so they happen way later than expected

Tools Used

Manual Analysis

Recommendations

It is recommended to understand these issues so as to know that there is a block.timestamp window that may affect transactions and call the relevant functions only when sure block.timestamp will be greater than saltToCloseTime[salt] as opposed to the boundary edge points.

It may be ideal to work with block.number which cant be manipulated by miners, and use blocks as estimates of times however this has challenge as it may result in faulty expectations times as yo may work with each block 13 seconds in your timeline calculations when in fact other blocks may be 17 seconds etc