Skip to content

Solana: Send button blocked for high-frequency accounts due to endless recomposition loop #133

@mocco-hub

Description

@mocco-hub

Your issue will be reviewed by a maintainer and labeled for further action.
To complete your request, follow the bot-actions to report this on the support E-mail box and follow the outlined steps. Alternatively, you can report this issue on the official web page to an agent for assistance.
@guifel


                    Issue Description 

Describe the bug

When using a Solana wallet with high transaction frequency (e.g., a trading bot), the "Review & send" button on the Send form is permanently greyed out and only becomes clickable for ~2 seconds every 30 seconds or so.

Environment

  • OS: macOS
  • Browser: Chrome
  • Wallet: Solana account with high transaction frequency

Steps to reproduce

  1. Connect a Solana wallet that receives frequent transactions (e.g., a bot making trades every few
    seconds)
  2. Navigate to Send form
  3. Fill in a valid recipient address and amount
  4. Observe the "Review & send" button is greyed out
  5. The button occasionally blinks green (enabled) for ~2 seconds before becoming disabled again

Additional symptoms

While investigating, I noticed:

  • Endless stream of getSignaturesForAddress RPC calls in the Network tab
  • 90k+ requests over 20 minutes, transferring 200MB+ of data
  • The app remains mostly usable, tokens display correctly, but sending is blocked

Root cause analysis

The issue stems from the interaction of two mechanisms:

1. Account constantly marked as "outdated"

In suite-common/wallet-utils/src/accountUtils.ts, Solana accounts are marked outdated when:

case 'solana':
return (
freshInfo.history.txids?.[0] !== account.history.txids?.[0] || // Any new tx
// ...
);
For a high-frequency account, there's always a new transaction, so the account is perpetually "outdated".

  1. Send form recomposition blocks the button

In packages/suite/src/hooks/wallet/useSendFormCompose.ts, when account data changes:
useEffect(() => {
// ...
setComposedLevels(undefined); // Kills valid composition
setLoading(true); // Disables button
// ...
}, [account, ...]);

And in ReviewButton.tsx:
isDisabled={isDisabled || isLoading}
The loop:

  1. New transaction arrives → account marked outdated
  2. Full account refetch triggered
  3. Account data updates in Redux
  4. useSendFormCompose detects change → setComposedLevels(undefined) + setLoading(true)
  5. Button disabled
  6. Before recomposition finishes, another transaction arrives
  7. Repeat from step 1

Proposed fix

Don't invalidate the composed transaction during account updates. Keep the last valid composition while recomposing in the background:

  // packages/suite/src/hooks/wallet/useSendFormCompose.ts

  -        // reset precomposed transactions
  -        setComposedLevels(undefined);
  +        // Don't reset composedLevels keep the last valid composition while recomposing
  +        // in the background. This prevents the send button from being blocked during
  +        // account updates (e.g., for high-frequency trading accounts).

           composeRequestID.current++;
           const composeErrors = findComposeErrors(errors);
           if (composeErrors.length > 0) {
               clearErrors(composeErrors);
           }
  -        setLoading(true);
  +        // Only show loading state if we don't have a valid composition yet
  +        if (!composedLevels) {
  +            setLoading(true);
  +        }
           updateContext({ account });

This keeps the button enabled as long as there's a valid composed transaction, while recomposition happens in the background.

Impact

  • Affected users: Anyone with a high-frequency Solana wallet (trading bots, DeFi power users)
  • Severity: High - completely blocks sending for affected users
  • Workaround: None currently, users must wait for a brief window when the button enables

Additional context

The underlying issue of excessive RPC calls (getSignaturesForAddress for all token accounts on every sync) could also be optimized separately, but the proposed fix addresses the immediate UX problem of the blocked send button.

(Issue written by a human along with Claude code)

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingduplicateThis issue or pull request already existsenhancementNew feature or requesthelp wantedExtra attention is needed

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions