Beginner FriendlyFoundryNFT
100 EXP
View results
Submission Details
Severity: low
Valid

Block.timestamp on Arbitrum can be off by 24 hours.

[M-1] The Dussehra protocol will be deployed, among others, to the Arbitrum. However, block.timestamp on the Arbitrum nova L2 chain can be off by as much as 24 hours. This has the potential of breaking the intended functionality of the protocol by shifting the dates at which the Dussehra::killRavana function can be called beyond the intended 12 to 13 October 2024 period.

Description: Quoting from Arbitrum's documentation:

Block timestamps on Arbitrum are not linked to the timestamp of the L1 block. They are updated every L2 block based on the sequencer's clock. These timestamps must follow these two rules:

  1. Must be always equal or greater than the previous L2 block timestamp

  2. Must fall within the established boundaries (24 hours earlier than the current time or 1 hour in the future)."

This implies that block.timestamps on Arbitrum can be off by up to 24 hours.

Impact: The time that the Dussehra::killRavana function can be called can potentially shifts beyond the intended 12 to 13 October 2024 period.

Related, but more unlikely, if the organiser calls the ChoosingRam::selectRamIfNotSelected function through a sequencer that is 24 hours to slow, and subsequently is forced to call Dussehra::killRavana through a sequencer that is an hour too fast, the organiser might miss the time window to kill Ravana - breaking the protocol.

Recommended Mitigation: Use an off-chain source (for instance Chainlink's Time Based Upkeeps) to initiate (or limit) functions based on time. This is especially important when deploying to L1 and multiple L2 chains, as timestamps will always differ between chains and sequencers.

Updates

Lead Judging Commences

bube Lead Judge about 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

`block.timestamp` on Arbitrum

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.