Timestamp dependence

A block timestamp is a protocol input with boundary assumptions.

LET’S PICTURE IT

A deadline based on a shared clock still needs clear rules at the cutoff.

SEE IT FOR YOURSELF

Link blocks, then see what an edit breaksStep 1 / 4

The first toy block records Maya sending Leo three units. A1 is an illustrative fingerprint label, not a real cryptographic digest.

Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.

Name the intended use

Time windows, vesting and auctions may rely on block timestamps. State what precision and ordering the application actually requires.

Avoid perfect-clock assumptions

Block timestamps follow consensus constraints and are not a user’s exact wall clock. Short-window designs need to account for transaction inclusion and permitted producer choices.

Test the boundary

Check the instant before, at and after the deadline under the contract’s comparison rule. Frontend countdowns do not replace the on-chain condition.

Keep randomness separate

A publicly observable timestamp is not an unpredictable secret. Combining it with other known values does not automatically create secure randomness.

Reason about the scenario

deadline rule: timestamp < end
end - 1 → accepted
end → rejected

This boundary differs from a <= rule.

Pseudocode or a simplified scenario for local reasoning. This is not a production contract or a completed security review.

QUICK CHECK · NO PRESSURE

Is a block timestamp a suitable secret random seed by itself?

Your progress stays in this browser.

Keep exploring the original referenceSolidity documentation ↗

Original explanations by EtherTools. Examples are educational and source-linked; this site is independent of the Ethereum Foundation. Our approach.