Show quote expiry without promising execution

A quote countdown indicates when the application must stop relying on a particular quote. It does not promise that a transaction submitted before zero will execute successfully.

Use the supplied deadline

When an API returns an expiry, store its value and documented unit with the quote. Do not replace it with a fixed lifetime copied from an example. When no deadline is supplied, an application can impose its own maximum age, but should describe that as a refresh policy rather than a provider guarantee.

PancakeSwap's integration notes distinguish gateway quote expiry from the X order's on-chain deadline. A single countdown cannot stand in for both acceptance and settlement.

Design the transition, not just the timer

At expiry, disable actions that consume the expired payload and request a replacement if the form is still active. Preserve the user's token pair, amount and recipient. Compare the replacement terms with the reviewed terms before reopening a wallet prompt.

Use a fresh server or chain reference where appropriate, and account for local clock error. A browser tab suspended in the background can miss timer ticks; compute remaining time from an absolute deadline each time the page resumes rather than decrementing a counter and trusting it.

Wallet prompts create an awkward boundary

If the user has already submitted a transaction, expiry should not erase its pending record. If the user is still reviewing an unsigned request, the app should avoid presenting an expired payload as current. A signature returned after expiry remains attached to its original message and must not be reused with a replacement quote.

Test background-tab suspension, clock skew, expiry during an approval and expiry while a wallet prompt is open. These cases reveal state errors that a visually correct timer will not catch.