Scoutinternal

XRP Wallet Withdrawal Issues on BitGo

XRP Wallet Withdrawal Issues on BitGo

Problem

Customers attempting to withdraw XRP from their BitGo wallets encounter a variety of errors including "You have been denied by a policy," "insufficient balance," spendable balance showing as 0, transactions not broadcasting, and the wallet password being rejected. These issues affect both enterprise/custody wallet users and FTX creditor Go Account users. The root causes range from post-trade settlement delays and address whitelisting requirements to enterprise policy conflicts, incorrect wallet passwords, API token unlock limits, and platform-side indexing or broadcast failures.

Diagnostics

  • Identify the account type: Determine whether the customer is using a standard BitGo enterprise/custody wallet or an FTX creditor Go Account (Go Accounts are accessed via ftxcreditors@bitgo.com workflows and have specific trade-settlement constraints).
  • Check the exact error message: Ask the customer to provide the full error text in plaintext, including any ErrorID and evaluation ID values. Key error patterns to distinguish:
    • "You have been denied by a policy" with an evaluation ID → policy denial (enterprise or wallet-level whitelist/velocity policy).
    • "insufficient balance" or "InsufficientBalance" → spendable balance is 0, likely settlement delay or indexer issue.
    • "token unlock limit exceeded" with code 400 → API access token spending limit not unlocked.
    • Incorrect wallet password → wrong password entered during withdrawal signing.
  • Check wallet balance vs. spendable balance: In BitGo Admin tools (bga w <wallet_id>), compare Balance, Confirmed, and Spendable fields. If Spendable is 0 but Balance is non-zero, investigate settlement timing or indexer state.
  • Check enterprise and wallet policies: Use bga CLI or Admin UI to review both enterprise-level and wallet-level policies. Look for coinAddressWhitelist:deny rules on xrp and trustUsdVelocityLimit:getIdVerification rules. Confirm whether the destination address (including destination tag) is whitelisted.
  • Check transaction state in send queue: For stuck/unbroadcast transactions, use bga tooling to check if the transaction is in the send queue (state=failed, state=attempted) and whether it appears confirmed on-chain via an XRP ledger explorer.
  • Check if the customer recently traded: For Go Account users, verify whether the customer recently executed a trade (USD to XRP). Settlement processing may not yet be complete.
  • Check for platform incidents: Review https://status.bitgo.com/ for any active XRP-related incidents or degraded service notices.

Resolution

Scenario: xrp-wallet-withdraw-wallets#settlement-delay-spendable-zero

Trigger: Customer recently traded USD (or another asset) for XRP in a Go Account and the Spendable Balance shows 0 despite a non-zero wallet balance.

Signals: spendable balance 0, insufficient balance, Go Account, FTX creditor, recently traded, settlement, ofcxrp

Steps:

  1. Confirm the customer recently completed a trade (e.g., USD to XRP) within their Go Account.
  2. Explain that funds are not immediately available for withdrawal after trading due to settlement processing time. The spendable balance may show as 0 until the funds are fully settled.
  3. Ask the customer to wait and retry the withdrawal after settlement completes (typically a few hours).
  4. If the issue persists after a reasonable settlement window, check the wallet in Admin tools to verify whether the Spendable balance has updated. If it has not, escalate to engineering for investigation of the settlement or indexer pipeline.

Notes: This was the most common issue among FTX creditor Go Account users in early 2025. Multiple customers reported the same pattern after converting USD to XRP.

"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." "Funds are not immediately available for withdrawal after trading due to settlement processing time. This allows us to ensure all transactions are recorded and processed accurately"

Scenario: xrp-wallet-withdraw-wallets#policy-denial-whitelist

Trigger: Customer receives error "You have been denied by a policy" with an evaluation ID when attempting to withdraw XRP.

Signals: ApiResponseError, denied by a policy, evaluation ID, ErrorID, coinAddressWhitelist, whitelist, destination tag

Steps:

  1. Confirm the customer has whitelisted the destination XRP address in the "Whitelist" tab of their wallet or Go Account.
  2. Verify that the destination tag (if required) is included in the whitelisted address using the correct format: address?dt=tag. For example, if the XRP address is r3ZDszz2ieaVjCPxGjMjJWrjVaxQxHgf1o and the destination tag is 123, the full address to whitelist is: r3ZDszz2ieaVjCPxGjMjJWrjVaxQxHgf1o?dt=123
  3. If the address is whitelisted at the wallet level but the enterprise policy also has a coinAddressWhitelist:deny rule for XRP, the enterprise policy may be blocking the transaction. Check enterprise policies using bga CLI.
  4. If the enterprise policy needs to be updated (e.g., adding a new whitelisted address), the enterprise admin must approve the change. If the policy is locked, support can temporarily unlock it using bga policy setmutablev2 -t 48 (unlocks for 48 hours) to allow the admin to make changes.
  5. Advise the customer to retry the withdrawal after the address is properly whitelisted at both the wallet and enterprise level.

Notes: For Go Account / FTX creditor users, the policy denial often resolves once the address is whitelisted correctly with the destination tag. Enterprise customers may need repeated policy unlocks if the admin does not complete changes within the mutable window.

"To withdraw XRP from your Go account, you will first need to whitelist the XRP address you want to send to at the whitelist tab of the Go account. If the XRP address has a destination tag, please be sure to include this in the whitelisted address: etc: If the XRP address is r3ZDszz2ieaVjCPxGjMjJWrjVaxQxHgf1o and the destination tag is 123, the full address to whitelist is: r3ZDszz2ieaVjCPxGjMjJWrjVaxQxHgf1o?dt=123" "The enterprise policy has been unlocked as per your request for the following 48 hours."

Scenario: xrp-wallet-withdraw-wallets#incorrect-wallet-password

Trigger: Customer receives an error indicating the wallet password is incorrect when attempting to sign an XRP withdrawal.

Signals: wallet password, incorrect password, wrong password, classic view, Forgot wallet password

Steps:

  1. Some withdrawal features may require switching to the old UI. Instruct the customer to click on the profile icon in the top right corner, then click on "Switch to classic view".
  2. Advise the customer to retry the withdrawal using the correct wallet password.
  3. If the customer has forgotten their wallet password, instruct them to navigate to: Trade > Wallet Details > Settings > Forgot Wallet Password.
  4. The customer can then reset and retry.

Notes: This scenario applies to self-managed BitGo wallets, not Go Account / FTX creditor wallets which use a different withdrawal flow.

"The error message indicates that the wallet password used during the withdrawal request is incorrect. Please try again and make sure to use the correct wallet password. If you happened to forgot the wallet password you may goto Trade > Wallet Details > Settings > Forgot Wallet Password" "Please be informed that access to the specified options requires the switch to the old UI. ... Step 2:- Click on Switch to classic view"

Scenario: xrp-wallet-withdraw-wallets#video-id-verification-required

Trigger: Customer sees a message about video ID verification being required for the first withdrawal to a newly whitelisted address, or for withdrawals exceeding $250k in a rolling 24-hour period.

Signals: video verification, video ID verification, whitelisted recipient, first withdrawal, $250k, schedule a video call, Liveness Check

Steps:

  1. Explain the thresholds for video verification:
    • A.) A transaction of any amount going to a newly whitelisted address for the first time, and/or
    • B.) Over $250k withdrawn in a rolling 24-hour period.
  2. Instruct the customer that once they initiate the transaction, they will see an option to schedule a video call or perform a self-verify (Liveness Check) to verify the request.
  3. The customer should whitelist the address first, then initiate the withdrawal. The verification prompt will appear as part of the withdrawal flow — the withdrawal will show as pending verification with options to self-verify or schedule a call.
  4. If the customer does not see the verification option, confirm the address is properly whitelisted and have them retry the withdrawal.

Notes: Some customers may complete a small test withdrawal without being prompted for verification depending on policy configuration. This applies primarily to Go Account / FTX creditor withdrawals.

"Our thresholds for video verification are A.) a transaction of any amount going to a newly whitelisted address for the first time and/or B.) Over $250k withdrawn in a rolling 24hour period. Once you initiate the transaction you will see an option to schedule a video call with us to verify the request." "Please note that you only need to verify a whitelisted address after a withdrawal is initiated to the address. You will then see the withdrawal pending verification with options to verify the self-verify (Liveness Check) or meeting us in a call to do so."

Scenario: xrp-wallet-withdraw-wallets#token-unlock-limit-exceeded

Trigger: API user receives error "token unlock limit exceeded" (HTTP 400) when attempting to build or send an XRP transaction via the API.

Signals: token unlock limit exceeded, code 400, API, access token, spending limit, unlock, sensitive API calls

Steps:

  1. Confirm the error message contains token unlock limit exceeded.
  2. Explain to the customer that this error occurs because they have either exceeded the spending limits set on their access tokens or have never set spending limits, requiring an unlock before sensitive API calls.
  3. Direct the customer to unlock their session using the BitGo API unlock endpoint: https://developers.bitgo.com/api/user.unlock
  4. After unlocking, the customer should retry the transaction.
  5. If the issue persists after unlocking, check for any active platform incidents (e.g., an internal service issue may compound the problem).

Notes: This scenario affects API-integrated customers, not UI-only users. The error may also surface alongside other transient platform issues.

"You are receiving this message because you have either exceeded the spending limits designated on your access tokens and need to do an unlock to proceed with any sensitive API calls. Alternatively, you may have never set any spending limits on your access token. Thus you would need to unlock your session to complete any withdrawal or sensitive API calls: https://developers.bitgo.com/api/user.unlock"

Scenario: xrp-wallet-withdraw-wallets#transaction-stuck-not-broadcasting

Trigger: XRP transaction has been submitted but is not broadcasting to the network or remains stuck in the send queue for an extended period.

Signals: not broadcasting, stuck, send queue, attempted, failed, tefPAST_SEQ, rebroadcast, engineering

Steps:

  1. Use BitGo admin tools to check the transaction's state in the send queue. Look for states such as state=failed or state=attempted.
  2. Verify whether the transaction is confirmed on-chain using an XRP ledger explorer despite showing as failed in the BitGo system.
  3. If the transaction is stuck in the attempted queue and not on-chain, escalate to engineering for investigation. The engineering team may need to resolve a broadcast pipeline issue.
  4. If the transaction shows as confirmed on-chain but as failed in the BitGo system (e.g., error tefPAST_SEQ), this is a known issue where transactions are initially marked as "Failed" but later confirmed. This can lead to double-spending if the customer's system retries based on the failed status. Escalate to engineering for a patch fix and coordinate with the customer success manager for any reimbursement if applicable.
  5. For deposit transactions not appearing in the wallet, support can attempt a rebroadcast or run indexer consolidation commands (CONSOLIDATE_WALLET_STATE, CONSOLIDATE_ADDRESS_STATE) via the bga indexer execute tool.
  6. Direct the customer to monitor https://status.bitgo.com/ for any active incidents.

Notes: The double-spending issue (transactions marked "Failed" then later "Confirmed") was identified as a platform bug. Engineering deployed a patch fix. Affected customers may require reimbursement coordination through their Customer Success Manager.

"We had an issue that was causing the transaction not to be broadcasted on chain and stay stuck in the attempted queue. Our engineering team fixed the issue and the transaction got confirmed." "We have 10 transactions that resulted in double-spending because of the BitGo API Response - all transactions were first marked as 'Failed' (which, as agreed, is a final status), and later on, the transactions were marked as 'Confirmed' in BitGo System." "We have rebroadcast the transaction and are now showing it confirmed."

Scenario: xrp-wallet-withdraw-wallets#xrp-inactive-destination-account

Trigger: Customer receives an error from the BitGo API when attempting to send XRP to an inactive (unfunded) XRP Ledger account.

Signals: inactive account, unfunded address, XRP destination, destination tag optional, non-BitGo address

Steps:

  1. Confirm the destination XRP address is inactive (has not been funded with the minimum XRP reserve on the XRP Ledger).
  2. Note that BitGo may return an error when sending to inactive XRP accounts. This is a known limitation.
  3. Advise the customer that the destination tag is optional for non-BitGo addresses. If an address does not have a destination tag, the customer should not add one. Only for BitGo addresses must the destination tag be included.
  4. If the customer was using a random or placeholder destination tag (e.g., "test"), advise them to remove it and retry without a destination tag.
  5. If the error persists for a legitimately inactive address, escalate to engineering to determine if the restriction can be relaxed for the customer's use case.

Notes: Other wallet providers (e.g., Coinbase, Crypto.com) may allow sends to inactive XRP accounts. BitGo's API-level validation may reject these by default.

"Destination tag is optional for non bitgo addresses. If an address doesn't have a destination tag then you don't need to add it to the address. Only in case of bitgo addresses, the dt must be added."

Scenario: xrp-wallet-withdraw-wallets#new-ui-balance-not-visible

Trigger: Customer logs in and sees the new UI but wallet balances are not displayed, or the XRP wallet option is greyed out when attempting to withdraw.

Signals: new UI, missing balances, wallets not showing, greyed out, classic view, old interface

Steps:

  1. Instruct the customer to switch to the classic/old UI:
    • Click on the profile icon in the top right corner.
    • Click on "Switch to classic view".
  2. After switching, verify that balances appear correctly and that withdrawal functionality is accessible.
  3. Advise the customer to clear all browser cache and update Google Chrome to the latest version, then retry in the new UI to see if the issue resolves.
  4. If the issue persists in the new UI after cache clearing, document the wallet details and report to engineering as a UI display bug.

Notes: This scenario was reported by users who had not logged in for an extended period and encountered the redesigned UI. The classic view workaround restores full functionality.

"Fortunately, I was able to use the 'Revert back to the old interface' option, and was able to find the request and approve it, though it wasn't under 'Pending approvals and requests' on the main wallet screen. I had to find it under 'Transfers', then 'Pending'." "Step 1 :- Click on the profile icon in the top right corner Step 2:- Click on Switch to classic view"

Scenario: xrp-wallet-withdraw-wallets#xrp-deposit-not-appearing

Trigger: An XRP deposit is confirmed on-chain but does not appear in the BitGo wallet balance or shows as unspendable.

Signals: deposit not showing, confirmed on-chain, not in wallet, unspendable, rebroadcast, InsufficientBalance after deposit, insufficient funds

Steps:

  1. Verify the transaction is confirmed on-chain using an XRP Ledger explorer with the provided TXID.
  2. Use BitGo admin tools to check if the transaction exists in the wallet's transfer records.
  3. If the transaction is confirmed on-chain but not reflected in the wallet, attempt a rebroadcast of the transaction or run indexer consolidation:
    • bga indexer execute CONSOLIDATE_WALLET_STATE <root_address>
    • bga indexer execute CONSOLIDATE_ADDRESS_STATE <root_address>
  4. If the deposit shows in the balance but not in spendable balance, check https://status.bitgo.com/ for any active XRP platform incidents. If an incident is active, inform the customer that engineering is working on the issue and they will be notified when resolved.
  5. If no incident is active and the above steps do not resolve the issue, escalate to engineering.

Notes: In one observed case, an XRP deposit showed in the overall balance summary but the spendable balance was much lower, and the API returned "error": "insufficient funds". This was resolved by engineering after a platform-level fix.

"We have rebroadcast the transaction and are now showing it confirmed. ... ✓ 1 wallet transfer records: ✓ wallet:[WALLET_ID] transfer:[WALLET_ID] 366.066 confirmed" "Our engineering team is aware of this issue and are working diligently to resolve. You can stay up to date here for more info: https://status.bitgo.com/"

Scenario: xrp-wallet-withdraw-wallets#xrp-wallet-limit-increase

Trigger: Enterprise customer requests an increase to the number of XRP wallets allowed for their enterprise.

Signals: wallet limit, wallet limit increase, setwalletlimit, enterprise

Steps:

  1. Confirm the enterprise ID and the desired new wallet limit for XRP.
  2. Use the BitGo admin CLI to increase the wallet limit:
    • bga e <enterprise_id>
    • bga ent setwalletlimit xrp <new_limit>
  3. Confirm to the customer that the wallet limit has been updated.

Notes: This is an administrative action requiring support-level access to the bga CLI. Only applicable to enterprise customers.

Scenario: xrp-wallet-withdraw-wallets#no-bitgo-account-found

Trigger: Customer contacts support about an XRP withdrawal error but no BitGo account is found associated with their email address.

Signals: user not found, 404, no account, different email, scam, phishing

Steps:

  1. Search for the customer's email in the BitGo admin tools. If no account is found, inform the customer.
  2. Ask whether they may have an account under a different email address.
  3. Confirm the customer is logging in at the official BitGo domain: https://app.bitgo.com/web/auth/login
  4. Warn that BitGo does not have a mobile app, does not offer phone support or online chat, and that any other access point may not be the legitimate platform.
  5. Ask the customer to reach out from their BitGo-associated email address for security purposes.

Notes: This may indicate the customer is a victim of a phishing or impersonation scam targeting crypto users. Handle with care.

"We are unable to locate an account associated with us with email 'useremail'. ... Could you also confirm the URL where you are trying to log in? Our official domain is https://www.bitgo.com/, and the main login portal can be accessed from this domain at https://app.bitgo.com/web/auth/login. ... Please note that we currently provide support exclusively via email. We do not have a phone support line or online chat support. We do not have a mobile app."

Related