Treat wallet error 4001 as a user decision

When a wallet request returns error 4001, the application should stop that request's flow and return control to the user. Automatically reopening the same prompt turns a deliberate refusal into a loop.

EIP-1193 defines 4001 as user rejection. Interpret the code in the context of the operation that produced it: connection, permission, typed-data signing and transaction sending are different actions.

Clean up only the cancelled stage

Clear the pending wallet-request state, re-enable appropriate controls and provide a concise message such as “Signature cancelled.” Keep the user's form values if they remain valid.

If an approval was confirmed before the user rejected the swap transaction, retain that approval receipt. Do not label the entire process as a reverted swap or pretend the permission was undone.

Require a fresh user action

A retry should begin from an explicit click. Recheck quote freshness, account and chain before reopening the wallet. The old transaction may no longer match current market conditions even though the only visible event was rejection.

Distinguish a documented rejection response from a transport timeout with unknown outcome. A timeout after possible broadcasting requires reconciliation; it should not be converted to 4001 merely to simplify the interface.

Use useful telemetry

Record the cancelled stage without treating every refusal as an infrastructure incident. Aggregate counts can reveal confusing prompts, but logs should not include signed payloads or unnecessary account history.

Test rejection at each wallet boundary. A rejection before approval should leave no confirmed approval record; rejection after approval should preserve one. Also test a late rejection arriving after an account change so it cannot overwrite the new account's state.

The application's job is to describe the request outcome accurately and preserve recoverable progress. It should not guess why the user declined.