Review `uint32` in Time Delays library for sub-second chains

[gonzaotc]

🧐 Motivation

uint32‐based timestamps work for ~136 years at 1 s block emission, but that shrinks fast when you need sub‑second block times.

Block‑time	uint32 (2³² − 1)	uint40 (2⁴⁰ − 1)	uint48 (2⁴⁸ − 1)
10 s	1 361 years	348 414 years	89 194 038 years
1 s	136 years	34 841 years	8 919 404 years
0.1 s (100 ms)	13.6 years	3 484 years	891 940 years
0.001 s (1 ms)	0.136 years (≈50 days)	34.8 years	8 919 years

📝 Details

uint32 is fine for blockchains with ≥1 s block times, but for networks experimenting with sub‑second production we should consider bumping to uint40 or uint48 (or higher).

[ernestognw]

Thanks for documenting!

An immediate action we can take would be to note the limit assumptions of the contract. Perhaps 34 years is cool for the majority of the teams and I don't think block time will go lower (will it? 👀)

[arr00]

What does block.timestamp return on sub-second blockchains? Milliseconds?

[ernestognw]

Miliseconds according to MegaETH:

https://docs.megaeth.com/realtime-api

That leaves a maximum delay of 49.7 days in those networks (2**32/1000/60/60/24). Another question is whether there's demand for delays in subsecond networks

[arr00]

I don't think we should be changing the existing contracts for this... but we should support it. Maybe we should have contracts involving timestamps be generated from templates?