Why swaps and signed orders have deadlines

A deadline limits when an execution remains valid. It does not schedule the transaction, reserve block space or guarantee completion before that time. A deadline is an upper bound on authorization, not an inclusion promise.

Two uses of time limits

Transaction-based routers can reject a call whose deadline has passed. Signed orders can include an expiry that a settlement contract checks when someone attempts to fill them. Uniswap documents transaction deadlines, while 0x's versioned order specification includes an expiry field.

These constraints concern validity at execution. The exact comparison and time source belong to the contract's rules. A countdown on a website is a presentation of those rules, not a separate authority capable of extending them.

A hypothetical timeline

An order is signed at 12:00 with an expiry at 12:10. A solver may try to fill it at 12:03 or 12:09 if all other conditions hold. Nothing requires a solver to do so. After the relevant expiry boundary, the old authorization cannot produce a valid fill under those rules.

For an already submitted transaction, passing the deadline does not necessarily remove the transaction from every node's pending pool. It can still be included and fail its contract check. Expiry of a signed trading instruction and disappearance of a pending network message are different events.

Deadline and price boundary work together

A short validity window does not replace minimum-output or maximum-input protection. Prices can move within the window. Conversely, a price bound does not express how long you want the authorization to remain available.

When reading a swap or order, keep both dimensions explicit: acceptable exchange terms and acceptable time. For intent systems, also distinguish quote validity from order expiry. A provider's short-lived quote can expire before a longer order lifetime, and the interface may need a new quote even though no onchain trade has yet happened.