search

hats-finance / HATs-Arbitration-Contracts-0x79a618f675857b45934ca1c413fd5f409cf89735

MIT License
0 stars 0 forks source link

wrapping of timestamp in uint32 #52

Open hats-bug-reporter[bot] opened 8 months ago

hats-bug-reporter[bot] commented 8 months ago

Github username: -- Submission hash (on-chain): 0x8c87f3c9cea38884a3bba80eccb64354584f319812e828f957dacf133fc18cc3 Severity: low

Description: Description\ block.timestamp is a uint256, but it is wrapped in a uint32. This means that the timestamp will overflow in the year 2106 and after that the protocol will break.

Attack Scenario\ In the contract HATClaimsManager.sol block.timestamp is wrapped in uint32 so at some point on 6 Feb, 2106 the protocol will break and the functions like setPendingMaxBounty and challengeClaim will stop working.

https://github.com/hats-finance/hats-contracts/blob/0d6ebbde912bc272d9b310140d434ee2aacd36d3/contracts/HATClaimsManager.sol#L177

https://github.com/hats-finance/hats-contracts/blob/0d6ebbde912bc272d9b310140d434ee2aacd36d3/contracts/HATClaimsManager.sol#L210

https://github.com/hats-finance/hats-contracts/blob/0d6ebbde912bc272d9b310140d434ee2aacd36d3/contracts/HATClaimsManager.sol#L384

Revised Code File

Consider changing the size of the cast from uint32 to a larger number, like uint64. This should be more than enough to not encounter limits within a reasonably distant future.

bahurum commented 8 months ago

That date is well beyond the life cycle of this version of the protocol

Nabeel-javaid commented 8 months ago

That date is well beyond the life cycle of this version of the protocol

That's the reason why this was marked as Low

jellegerbrandy commented 8 months ago

I do not think there is any real risk that these contracts will be used in the current form in 2106. The casting is done by design to save (some) gas