Handle User Rejection (Error 4001) gracefully during wallet signing

[Lakes41]

Difficulty: Intermediate
Type: UI/UX, bug

Background

When a user initiates a transaction (e.g., staking tokens), their wallet prompts them to sign the payload. If the user clicks "Reject" in their wallet extension, an error is thrown.

Problem

Currently, when a user rejects a transaction, the UI surfaces a generic, red "Transaction Failed: internal JSON-RPC error" toast notification. This is jarring and inaccurately portrays a normal user action as a catastrophic system failure.

Expected outcome

The application correctly intercepts the standard EIP-1193 user rejection code (4001) and handles it silently or displays a benign "Transaction cancelled by user" information toast.

Suggested implementation

1. Locate the generic catch blocks wrapping transaction logic.
2. Inspect the thrown error object for code === 4001 or specific string identifiers (e.g., user rejected transaction).
3. Route the UI state accordingly (e.g., reset the loading button) without triggering the global error boundary or scary error toasts.

Acceptance criteria

• Rejecting a transaction in Metamask/Rabby does not trigger a red error toast.
• The loading state on the originating button reverts to normal immediately.
• Real transaction failures (e.g., out of gas) still correctly show error toasts.

Likely affected files/directories

• src/hooks/useTransaction.ts
• src/components/TransactionModal.tsx

Requirements

• Must account for slight variations in error objects across different wallet providers.

[DingiDinigi]

Hi I've handled EIP-1193 error normalization across wallet providers before — MetaMask, Rabby, and others don't always shape rejection errors identically, so catching code === 4001 alone isn't enough; you need to also check nested error shapes and message strings some providers fall back to. This is a familiar, well-defined fix.
I'll intercept user rejections at the transaction-handling layer so they reset the UI state cleanly (no red error toast, no scary global error boundary trigger) while making sure genuine failures like out-of-gas still surface properly. I will like to take this on, I can complete the task within a very short time and draft a good PR