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

`block.timestamp` works differently on `arbitrum` than `L1 (Ethereum)`, User may have to wait more than actual time required to update metadata

Summary

Due to different handling of block.timestamp on arbitrum. User may have to stake more than the actual time in order to update metadata.

Vulnerability Details

The project is meant to be deployed on arbitrum and ethereum. In streets smartcontract stake and unstake relies on block.timestamp. The more time user stake, more stats of staked nft are updated.
But block.timestamp is handled differently on arbitrum. As per official docs from arbitrum -

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:
- Must be always equal or greater than the previous L2 block timestamp
- Must fall within the established boundaries (24 hours earlier than the current time or 1 hour in the future). More on this below.
Furthermore, for transactions that are force-included from L1 (bypassing the sequencer), the block timestamp will be equal to either the L1 timestamp when the transaction was put in the delayed inbox on L1 (not when it was force-included), or the L2 timestamp of the previous L2 block, whichever of the two timestamps is greater.

To illustrate from an example - Alice stake his Rapper nft on 25th Feb 01:00, She just want to update his first stat by staking for 1 day. So she came back after 28 hours at 26th Feb 5:00 , But block.timestamp at time on arbitrum is showing 25th Feb 10:00 (due to it's ability to adjust time to max 24 hours earlier than actual time if required). So in this case her staked period is counted as only 9 hours(while actual staked period is 28 hours), so neither her nft metadata is updated nor she get 1 cred token as reward.

On ethereum she would have got 1 cred token + metadata could have updated.

Impact

Staking nft for same time period can yield different results based on the network used by the participant.

Tools Used

Manual Review

Recommendations

Team must assure that use of block.timestamp is reliable on the chains contracts will be deployed to.

Updates

Lead Judging Commences

inallhonesty Lead Judge over 1 year ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

arbitrum timestamp

Support

FAQs

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