A broadcast timeout does not prove a swap failed

A request timeout means the client did not receive a timely answer. The node may already have accepted the transaction. Creating another swap immediately can produce a second independent trade.

Persist before and after the boundary

Store the local attempt and reviewed transaction context before broadcasting. If the wallet returns a hash, save it immediately with the chain. If the application signs raw transactions itself, its architecture should retain the transaction identity before network submission. Browser-wallet flows may expose less information, so recovery must use the wallet's supported evidence.

The JSON-RPC reference separates transaction submission from receipt retrieval. Neither a missing response nor a null receipt alone proves permanent rejection.

Reconcile, then decide

1. Check for a known hash and query its transaction and receipt.
2. Inspect the sender's pending and confirmed nonce context when available.
3. Check wallet history or a reliable transaction index if the hash was lost.
4. Keep the result unknown until enough evidence supports pending, replaced, failed or unsubmitted.

A higher account nonce is evidence that some transaction used that sequence position, not proof that this particular swap succeeded. Identify the actual transaction before updating the trade outcome.

Avoid misleading buttons

Offer Check status while outcome is unresolved. If the product offers a fresh attempt, explain that it is a separate action and require a current quote. Do not label it Retry while silently changing nonce, route or amount.

Use a fixture where the mock node accepts the transaction but the response connection drops. The correct behavior is recovery of the first attempt, not a second wallet prompt. This tests the exact failure mode a normal successful submission misses.