Summary

In several instances in the protocol certain timestamp checks are made, in order to ensure intended time window for entering as a player, predictions, etc.

As per the Arbitrum docs, in Arbitrum, clients submit transactions by posting messages to the Ethereum chain, either through the sequencer or via the chain's delayed inbox and some time will elapse between when a message is put into the inbox (and timestamped) and when the contract processes the message and carries out the transaction requested by the message. 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.

Vulnerability Details

Deploying a protocol on the Arbitrum chain does bring certain nuances regarding timestamp handling, given the nature of Layer 2 solutions and their reliance on Layer 1 for finality. Possible issues are:

• Timestamp Manipulation: Miners/validators can manipulate block timestamps within a certain range. This is true on Ethereum and can be more pronounced on Layer 2 solutions like Arbitrum.

• Delayed Finality: Transactions on Arbitrum might appear to be confirmed quickly, but true finality depends on the Layer 1 settlement. Timestamps could be affected by this delay.

Impact

it's possible that timestamp inconsistencies or manipulation could for example allow a malicious user to set a prediction after the match has finished if the current checks are solely based on block.timestamp. This can be particularly problematic on Arbitrum or any other Layer 2 solution where timestamp manipulation is more feasible.

Tools Used

Arbitrum docs

Recommendations

• Adding Time Buffer: Ensure there's a buffer period around the prediction cut-off time.

• Oracle Integration: Use an oracle to verify the match start time.