Scoutinternal

Troubleshooting Transfer and Withdrawal Issues on BitGo

Troubleshooting Transfer and Withdrawal Issues on BitGo

Problem

Customers contact support reporting that they cannot complete transfers or withdrawals from their BitGo wallets. The issues span multiple coins (BTC, SOL, POL, AVAX, DOT, and others) and manifest as error messages during send, missing deposits that don't appear in the wallet UI, zero spendable balance after trading, or funds sent to the wrong chain/wallet type. These problems affect both the BitGo web UI and API-driven workflows, and occur across self-managed wallets, FTX creditor accounts, and custody enterprise accounts.

Diagnostics

  • Confirm the wallet type and coin: Ask the customer for the wallet ID, the coin ticker, and whether they are using a self-managed (hot/warm) wallet, a Go Trading account, or a custody wallet. Verify in the admin console that the wallet exists under the customer's enterprise.
  • Check for error messages: Request a screenshot or exact text of the error. Common errors include incorrect wallet password indicators and insufficient balance messages.
  • Verify spendable balance vs. total balance: In the admin tool, check whether the wallet's spendable balance is 0 while the total balance shows funds. This often indicates funds are still settling after a trade.
  • Check the chain and wallet coin type: Confirm that the deposit address belongs to the correct blockchain. For example, an ETH L1 wallet address will not display native Polygon L2 POL deposits. Compare the coin type on the wallet (e.g., eth vs. polygon) against what the customer intended.
  • Review transfer history and on-chain status: Use a public block explorer to verify whether the transaction was confirmed on-chain. Cross-reference with the transfer list in the BitGo admin tool or via the API endpoint https://developers.bitgo.com/api/v2.enterprise.listtransfers.
  • Confirm Go Account existence: If the customer is querying Go Trading transfer history, verify in the admin console whether their enterprise actually has a Go Account provisioned.
  • Check transfer type/state tagging: For cross-chain bridge transfers (e.g., AVAX C-chain to P-chain), inspect whether the receiving side is incorrectly tagged as a withdrawal instead of a deposit. This is a known display/reconciliation issue.

Resolution

Scenario: transfer-transfers-internal-state#incorrect-wallet-password

Trigger: The customer receives an error indicating the wallet password is incorrect when attempting a withdrawal or transfer.

Signals: incorrect wallet password, wrong password, error on transfer, cannot transfer bitcoins, error on SOL transfer, withdrawal error

Steps:

  1. Confirm with the customer that the error message relates to an incorrect wallet password.
  2. Advise the customer that they must use the correct wallet password to authorize withdrawals. BitGo support cannot reset the wallet password on the customer's behalf.
  3. If the customer has their wallet keycard PDF but is unsure of the password, instruct them to reset it:
    • Navigate to the wallet's Settings page.
    • Click the "Forgot Wallet Password" hyperlink to begin the wallet password reset flow.
  4. If the customer cannot find the reset option in the current UI, instruct them to switch to the classic UI:
    • Click on the profile icon in the top right corner.
    • Click on "Switch to classic".
    • Once in the classic view, navigate to: Trade > Go Account > Settings > Forgot Wallet Password.
  5. Inform the customer that BitGo is unable to regenerate the keycard if it has been lost.

Notes: This is one of the most common transfer failure causes. The wallet password is distinct from the account login password. If the customer has lost both the wallet password and the keycard PDF, a key recovery process may be needed — escalate to the wallet recovery team.

"The error is indicating you are not using the correct wallet password. You will need to use the correct wallet password to withdraw your funds. If you have the wallet keycard pdf and are unsure of the wallet password, you can reset it by navigating to the Settings of the Wallet and using the 'Forgot Wallet Password' hyperlink to being the wallet password reset flow. We are unable to reset the password for you and we are unable to regenerate the keycard if you have lost it." (ticket #232328)

"To update or recover your wallet password, please follow the steps below. Access to these settings is available in the classic (old) UI... Step 1: Click on the profile icon in the top right corner. Step 2: Click on Switch to classic. Once in the classic view, go to your wallet settings where you will find the option to update the wallet password. If you have forgotten your wallet password, you can follow this path: Trade > Go Account > Settings > Forgot Wallet Password" (ticket #263393)

Scenario: transfer-transfers-internal-state#zero-spendable-balance-settlement

Trigger: The customer's wallet shows a total balance but a spendable balance of 0, and they are unable to initiate a withdrawal.

Signals: spendable balance 0, cannot withdraw, balance not available, saldo, settlement, funds not available

Steps:

  1. Explain to the customer that funds are not immediately available for withdrawal after trading due to settlement processing time.
  2. Advise the customer to wait at least 24 hours and try the withdrawal again.
  3. If the issue persists after 24 hours, ask the customer to provide the wallet ID and the exact error details in plaintext for further investigation.
  4. Escalate to the trading/settlement team if the spendable balance remains at 0 beyond the expected settlement window.

Notes: This scenario is particularly common among FTX creditor accounts where funds have recently been distributed or traded.

"Please note that funds are not immediately available for withdrawal after trading due to settlement processing time. This ensures that all transactions are properly recorded and processed. As a result, your spendable balance may show as 0 until the funds are fully settled." (ticket #228838)

Scenario: transfer-transfers-internal-state#wrong-chain-deposit

Trigger: The customer sent tokens to a wallet on the wrong chain (e.g., native L2 POL sent to an ETH L1 wallet address), and the deposit does not appear in the BitGo wallet UI despite confirming on a block explorer.

Signals: missing deposit, POL not showing, wrong chain, polygon, ETH wallet, deposit not appearing, native L2, ERC-20

Steps:

  1. Verify on a public block explorer (e.g., https://polygonscan.com/) that the transaction was confirmed on-chain.
  2. Check the wallet's coin type in the BitGo admin console. Confirm whether the receiving address belongs to an ETH L1 wallet vs. the intended native L2 chain wallet (e.g., Polygon).
  3. Explain to the customer that the address belongs to a different chain wallet. For example, POL exists both natively on its L2 chain and as a native ERC-20 token on the ETH L1 network — depositing native L2 POL to an ETH L1 address will not be recognized.
  4. Instruct the customer to create the correct chain wallet in the BitGo platform (e.g., a "Polygon" wallet for native L2 POL deposits). Note that this will also require funding the chain's gas tank (e.g., native L2 POLYGON in the "Polygon" gas tank).
  5. If the customer asks about recovering the misdirected funds, check with the engineering team whether a wrong-chain recovery is feasible. Note that BitGo typically does not support recoveries on transfers/amounts under $300 due to the heavy transaction fees associated with the recovery.

Notes: This applies to any chain pair where addresses overlap (ETH/Polygon, AVAX C-chain/P-chain, etc.). The cost-benefit of recovery should be evaluated before proceeding.

"POL exists both natively on its L2 chain and similarly as a native ERC-20 token on the ETH L1 network where POL is/can be natively staked. The Address you sent belongs to a native ETH L1 wallet as opposed to a Native POL L2 wallet. You will want to go back into the platform and create a 'Polygon' wallet where you can deposit these native L2 funds into. This will require a deposit of some native L2 POLYGON into the 'Polygon' gas tank as well (Similar to how the native Multi-sig ETH wallets work)." (ticket #233804)

"While we can technically support a recovery here, your team is likely to pay more in POL txn fees for the recovery than have been sent to the wrong chain. We typically do not allow for recoveries of this nature to be done on transfers/ amounts of <$300 given the heavy transaction fees associated with the recovery." (ticket #233804)

Scenario: transfer-transfers-internal-state#avax-bridge-transfer-type-discrepancy

Trigger: AVAX C-chain to P-chain bridge transfers display as withdrawals on both the source (C-chain) and destination (P-chain) wallets, causing reconciliation to show double the withdrawal amount instead of netting to zero.

Signals: AVAX, AVAXC, AVAXP, C to P chain, bridge, transfer type, withdrawal, deposit discrepancy, reconciliation, Cumberland

Steps:

  1. Confirm the transfer details: obtain the C-chain wallet ID, the P-chain wallet ID, and the transaction hashes for both the C-chain withdrawal and the P-chain transfer.
  2. Verify on the AVAX explorer (e.g., https://subnets.avax.network/p-chain/tx/) that the P-chain transaction is indeed an incoming transfer (deposit).
  3. This is a known issue where the P-chain side of a bridge transfer is incorrectly tagged as a withdrawal rather than a deposit in the BitGo transfer list.
  4. Escalate to the engineering team with the wallet IDs and transaction hashes, requesting that the transfer state/type be corrected for the P-chain wallet entry and that the tagging logic be updated for future bridge transfers.

Notes: This affects AVAX C-to-P chain bridging specifically. The on-chain behavior is correct; the issue is in how BitGo labels the transfer direction in the wallet's transfer history.

"Their team is seeing a withdraw from the C-Chain wallet for ~ 97,965 AVAX which makes sense, but then they are also seeing the same withdraw transfer on their P-Chain wallet showing ~ 97,965 AVAX. This netting out to a total withdraw of -195,930 AVAX with accounting vs netting to 0... Their team would expect that this correlating transfer on the P chain wallet would be a deposit vs a withdrawal what it's currently displaying." (ticket #315746)

Scenario: transfer-transfers-internal-state#go-account-transfer-history-api

Trigger: The customer is attempting to query transfer history for a Go Trading account via the API and receives no withdrawal data.

Signals: Go Trading, Go Account, API, list transfers, enterprise listtransfers, no withdrawal data, transfer history

Steps:

  1. Verify in the admin console whether the customer's enterprise actually has a Go Account provisioned.
  2. If no Go Account exists, inform the customer that transfer history cannot exist for a wallet type that is not provisioned on their enterprise.
  3. If a Go Account does exist, confirm the customer is using the correct endpoint and enterprise ID. The endpoint referenced by customers is: https://developers.bitgo.com/api/v2.enterprise.listtransfers.
  4. If the account exists and the endpoint is correct but data is still missing, escalate to the engineering team for investigation.

Notes: The Go Trading account is a distinct wallet type. Not all enterprises have one, and its transfer history may not be surfaced through the same endpoints as standard wallets.

"We are not showing your Enterprise has a Go Account. It should not be possible for there to exist a transfer history for that wallet type." (ticket #247255)

Scenario: transfer-transfers-internal-state#transaction-confirmed-but-not-received

Trigger: The customer reports that a transfer was sent but the recipient claims it was never received, even though the transaction appears confirmed on-chain.

Signals: transfer not received, not arrived, missing transfer, problem with transfer, final destination, confirmed on chain

Steps:

  1. Obtain the transaction hash from the customer.
  2. Look up the transaction on a public block explorer to verify it has been confirmed and that the funds were sent to the correct destination address.
  3. If the transaction is confirmed and the destination address is correct, inform the customer that the transaction has been successfully processed and the funds have been sent from the BitGo account.
  4. Advise the customer to contact the receiving platform/exchange if the funds are not appearing on the recipient side, as the issue may be with the receiving party's deposit detection or crediting process.

Notes: BitGo's responsibility ends once the transaction is confirmed on-chain and sent to the correct address. Delays in crediting on the receiving side are outside BitGo's control.

"We have completed our investigation and confirm that the transaction has been successfully processed, with the funds sent from the BitGo account." (ticket #273703)

Scenario: transfer-transfers-internal-state#insufficient-details-from-customer

Trigger: The customer reports a generic transfer issue (e.g., "I can't transfer," "transfer problem") without providing transaction details, wallet ID, or error messages.

Signals: transfer, unable to transfer, transfer problem, no details, generic issue

Steps:

  1. Request the following details from the customer:
    • Wallet ID
    • Transaction hash (if available)
    • Screenshot of the error message
    • The coin/token being transferred
    • The destination address
  2. Once details are received, triage into the appropriate scenario above.
  3. If no response is received after follow-up, the ticket may be closed with a standard follow-up message.

Notes: A large volume of transfer-related tickets arrive with minimal or no context. Always gather specifics before attempting diagnosis. For FTX creditor inquiries, include the FTX FAQ link: https://www.bitgo.com/ftx-faq

Related

  • keycards-and-private-keys — Wallet password and keycard management, relevant when customers cannot authenticate withdrawals.
  • bitcoin-transactions — Covers Bitcoin deposit and withdrawal workflows, receive address generation, and transaction monitoring.
  • wrong-chain-recovery — Guidance on cross-chain recovery scenarios where funds are sent to an address on an unsupported network.