RFQ expiry needs a different retry decision from HTTP failure

A transport retry can recover a lost response. It cannot extend the validity of an expired maker quote. RFQ expiry therefore needs a separate recovery path from a temporary HTTP error.

The 0x FAQ identifies short-lived RFQ quotes as one possible cause of reverts. Do not turn an illustrative validity interval into a universal timer for every provider, chain or route.

Track the relevant validity information

Retain quote creation and expiry data when the provider exposes them, together with the account and request identity. If the deadline is encoded and not directly available, follow the provider's documented freshness policy instead of inventing one from the current browser clock.

Leave time for wallet review and network inclusion. A quote that is still valid when a button is clicked may expire before it executes.

Choose the right retry

If a read request failed before returning a quote, a bounded retry may be appropriate. If a known quote expired, request a new quote and rebuild the transaction. Review changed economic terms before submission.

If submission timed out after a transaction may have been broadcast, first reconcile its hash or account nonce. Creating a replacement quote without checking the earlier transaction can result in two trades.

Do not diagnose from one internal failure

A routed transaction can contain multiple execution attempts. The 0x FAQ notes that internal orders may fail while the overall transaction succeeds through another path. Inspect the receipt and actual outcome before classifying a swap as failed solely from an internal trace.

Test expiry before signing, expiry during wallet review and a lost broadcast acknowledgement. These scenarios should lead respectively to refresh, refreshed review, and transaction reconciliation rather than the same automatic resend loop.