Description

Here is the current timestamp validation at minter.move, line 186:

assert!(now <= timestamp + DELAY_MAX, ...);

This check ensures that the current time is not after timestamp + DELAY_MAX, rejecting stale requests. However, it allows any future timestamp, meaning users can submit requests with timestamps significantly ahead of the current block time.

Impact

Permitting forward-dated timestamps may lead to inconsistencies if off-chain systems (e.g., price feeds or processors) assume timestamps reflect actual request time. In some cases, this could cause confusion in server-side time-sensitive processing

Recommendations

Consider enforcing a bounded timestamp range on both sides:

assert!(now >= timestamp && now <= timestamp + DELAY_MAX, ...);

This ensures that requests are neither stale nor prematurely timestamped. If future timestamps are expected, document this behavior for downstream systems.

Remediation

This issue has been acknowledged by MatrixDock, and they have provided the following response:

The backend performs further validation on the timestamp and thus not necessary here.