Scoutinternal

Unable to Send — Troubleshooting Send / Withdrawal Failures

Unable to Send — Troubleshooting Send / Withdrawal Failures

Problem

Customers report being unable to send or withdraw cryptocurrency from their BitGo wallets. Reported symptoms vary widely: the send button may be missing or unresponsive, transactions may fail after submission (e.g., "fee rate too low"), sends may appear to process as duplicates ("double send"), or the send process may not complete at all. This cluster spans multiple coins and affects both the web UI and CLI/API workflows.

Diagnostics

Before attempting any fix, the support agent should gather the following:

  • Confirm the product context: Determine whether the customer is using the BitGo web UI (app.bitgo.com), the BitGo CLI, or the SDK/API. Several tickets reference UI-specific issues (e.g., missing "Send" button) while at least one references a CLI sendtoaddress command error.
  • Identify the coin/chain: Ask the customer which coin they are trying to send (BTC, ETH, CSPR, etc.). Some chains have specific initialization or minimum-balance requirements (e.g., CSPR requires 2.5 CSPR minimum for wallet initialization).
  • Check wallet status in the admin tool: Verify the wallet exists, is fully initialized on-chain, and has a confirmed balance. For newer wallets on chains like Casper, confirm the initialization transaction has been confirmed before the customer attempts to send.
  • Review wallet policies: In the BitGo admin console, check whether the wallet has spending limits, whitelist policies (warm wallet), or approval requirements that could block the send.
  • Check for pending transactions: Look for any stuck or pending transactions on the wallet. Unconfirmed prior transactions can block subsequent sends, especially on UTXO-based chains (BTC).
  • Inspect fee settings: If the customer reports sendouts are failing, check whether the fee rate used is sufficient for the current network conditions. Ticket #7803 specifically references "fee rate too low" as a failure reason.
  • Look for duplicate send attempts: If the customer mentions a "double send" (Tickets #7089, #8268), review the transaction history for duplicate entries and confirm whether one or both transactions were broadcast to the network.
  • Browser/client health: If the issue is UI-related (missing button, form not working), ask the customer to clear their browser cache, try a different supported browser, or check for JavaScript errors in the console.

Resolution

Scenario: send-sending-sendouts-unable#fee-rate-too-low

Trigger: Sendouts are failing with an indication that the fee rate is too low for current network conditions.

Signals: sendouts failing, fee rate too low, transaction not confirming, stuck transaction, BTC send failure

Steps:

  1. Confirm with the customer that the error or failure message references the fee rate.
  2. In the BitGo web UI, navigate to the wallet and initiate a new send. On the send form, check or adjust the fee rate to match current network conditions (use a mempool explorer to determine an appropriate fee).
  3. For API/SDK users, advise increasing the feeRate or maxFeeRate parameter in the send call.
  4. If prior transactions are stuck due to low fees, evaluate whether a Replace-By-Fee (RBF) or Child-Pays-For-Parent (CPFP) strategy is appropriate and guide the customer or escalate to engineering if needed.
  5. Re-attempt the send with the corrected fee rate.

Notes: This primarily affects UTXO-based chains such as BTC. During periods of high network congestion, the default fee estimate may be insufficient.

Scenario: send-sending-sendouts-unable#send-button-missing-or-unresponsive

Trigger: Customer reports the "Send" button is missing from the wallet form, or the send form does not function as expected in the web UI.

Signals: no send button, button missing, cant send, send not working, normal send removed, bug no send button

Steps:

  1. Ask the customer which browser and version they are using. Recommend a supported, up-to-date browser (Chrome or Firefox).
  2. Have the customer clear their browser cache and cookies, then log in again at https://app.bitgo.com.
  3. Verify in the admin tool that the wallet is fully initialized and that the coin type supports sends from the UI.
  4. Check whether the wallet type (cold, warm, hot) affects the availability of the send button — cold wallets, for example, require offline signing and may not expose a simple "Send" button in the same way.
  5. For ETH wallets, confirm the customer is navigating to their wallet and clicking the "Withdrawal" button (the ETH send flow uses "Withdrawal" as the action label, per BitGo documentation).
  6. If the issue persists, collect browser console logs and escalate to the engineering team with reproduction details.

Notes: Ticket #4367 specifically reports "Bug: no 'send' button on this form." Ticket #4182 asks whether "Normal send" was removed. These may indicate a UI regression or a wallet-type mismatch.

Scenario: send-sending-sendouts-unable#cannot-send-funds-general

Trigger: Customer states they cannot send funds ("i cannot send founds," "i can't send") without a specific error message or further detail.

Signals: cannot send, cant send, unable to send, send founds, i can't send, sending issues

Steps:

  1. Ask the customer to provide the exact error message (if any), the coin type, the wallet name or ID, and a screenshot of what they see.
  2. Verify in the admin tool that:
    • The wallet has sufficient balance (including enough for network fees).
    • The wallet is not locked or frozen by a policy or compliance hold.
    • There are no pending approval requests blocking the transaction.
  3. For wallets on chains requiring initialization (e.g., CSPR), confirm the wallet has been fully initialized on-chain before attempting a send.
  4. If the customer is using the API or CLI, ask them to share the exact command or request payload and the full error response. Ticket #5312 references a "weird CLI error using sendtoaddress command" — request the verbatim error output.
  5. If no blocking condition is found and the issue cannot be reproduced, escalate to engineering with the wallet details, timestamps, and any error output.

Notes: Many tickets in this cluster contain minimal detail. Gathering specifics from the customer is the critical first step. Do not assume a single root cause without evidence.

Scenario: send-sending-sendouts-unable#double-send

Trigger: Customer reports that a transaction was sent twice (duplicate/double send) or that funds were deducted more than expected.

Signals: double send, sent twice, duplicate transaction, duplicate send

Steps:

  1. Pull the wallet's transaction history in the admin tool and identify whether two distinct transactions were broadcast to the network for the same intended send.
  2. Check the blockchain explorer for both transaction IDs to confirm whether both were confirmed on-chain.
  3. If only one transaction confirmed, reassure the customer that the duplicate will not result in additional fund loss.
  4. If both transactions confirmed, investigate whether the customer clicked "Send" multiple times, or whether an API integration submitted the request more than once (e.g., retry logic without idempotency).
  5. Advise API users to implement idempotency keys or sequenceId in their send requests to prevent duplicate submissions.
  6. If the double send was caused by a platform-side issue, escalate to engineering with both transaction IDs and timestamps.

Notes: Tickets #7089 and #8268 both reference "Double Send." This can occur when users click the send button multiple times during slow UI responses, or when API integrations retry without proper safeguards.

Scenario: send-sending-sendouts-unable#wallet-not-initialized

Trigger: Customer is attempting to send from a newly created wallet that has not yet been fully initialized on the blockchain.

Signals: new wallet, cannot send, wallet initialization, CSPR, minimum balance, wallet not ready

Steps:

  1. Check in the admin tool whether the wallet's on-chain initialization transaction has been confirmed.
  2. For CSPR wallets specifically, confirm that the minimum balance of 2.5 CSPR has been funded and that the initialization transaction (which sets up signers and home domain) has completed.
  3. Advise the customer not to attempt sends until the initialization is fully confirmed.
  4. Once confirmed, the wallet should be ready for normal send operations.

Notes: Per BitGo documentation: "Do not use a CSPR wallet while it is being initialized or you may lose funds." This applies to any chain that requires on-chain account activation.

Scenario: send-sending-sendouts-unable#send-not-received-by-recipient

Trigger: Customer reports that the send appeared to process but the recipient has not received the funds.

Signals: send process did not reach, not received, funds missing, transaction pending

Steps:

  1. Obtain the transaction ID from the customer's wallet transaction history.
  2. Look up the transaction on the appropriate blockchain explorer to check its confirmation status.
  3. If the transaction is confirmed but the recipient hasn't credited it, advise the customer that the issue is on the recipient's side (e.g., the receiving exchange may require additional confirmations).
  4. If the transaction is unconfirmed/pending, check whether the fee was sufficient for the current network conditions and advise accordingly (see the fee-rate-too-low scenario).
  5. If no transaction ID exists in the wallet history, the send may not have been submitted successfully — re-attempt with the customer while monitoring for errors.

Notes: Ticket #9220 references "Send process did not reach." Always verify on-chain status before concluding the transaction failed.

Related