sherlock-audit / 2024-09-predict-fun-judging

0 stars 0 forks source link

Stable Midnight Canary - Protocol highly depends on correct block.timestamp values which is not the case in Arbitrum #298

Open sherlock-admin3 opened 2 days ago

sherlock-admin3 commented 2 days ago

Stable Midnight Canary

Medium

Protocol highly depends on correct block.timestamp values which is not the case in Arbitrum

Summary

It is said in the contest README that the protocol can be deployed on any EVM compatible chain. Arbitrum is one of them. From Arbitrum docs:

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.

The current reliance on block.timestamp is incompatible with the protocol's design, as accurate timestamps are crucial for core functionalities. It's uncertain whether the CTF can be deployed on Arbitrum, so this issue might not be applicable. However, if deployment is possible, I think that it should be reported.

Root Cause

Potential deployment on Arbitrum where block.timestamp behaves different than mainnet and other EVM compatible chains. https://github.com/sherlock-audit/2024-09-predict-fun/blob/41e70f9eed3f00dd29aba4038544150f5b35dccb/predict-dot-loan/contracts/PredictDotLoan.sol#L30

Internal pre-conditions

N/A

External pre-conditions

Protocol deployed on Arbitrum.

Attack Path

N/A

Impact

Loan start time can be set in past (24 hours back) thus making the real duration of the loan uncertain. Call time of loan can be set in past and result in no auction. All functionalities which depend on block.timestamp can be set in the past and lead to unexpected result for users.

PoC

No response

Mitigation

No response