QuantAMM

Summary

The block.number value is used in AfterUpdate function for storing timestamp of fee deposit of tokens. On Ethereum, this can be affected by blockchain reorganization (reorg), leading to potential inconsistencies or unintended behavior. Furthermore, on Layer 2 rollups like Optimism and Arbitrum, where block numbers may not increment synchronously with Ethereum's mainnet, this can result in desynchronization and protocol misbehavior.

Vulnerability Details

According to Arbitrum Docs block.number returns the most recently synced L1 block number. Once per minute the block number in the Sequencer is synced to the actual L1 block number. This period could be abused to completely bypass this protection. The user would open their position 1 Arbitrum block before the sync happens, the close it the very next block. It would appear that there has been 5 block (60 / 12) since the last transaction but in reality it has only been 1 Arbitrum block. Given that Arbitrum has 2 seconds blocks I would be impossible to block this behavior through parameter changes.

It also presents an issue for Optimism because each transaction is it's own block. No matter what value is used for the block delay, this can affect the mapping values precision

Impact

The inaccuracy of block.number will affect the mapping

Tools Used

Manual Audit

Recommendations

Use block.timestamp