Scoutinternal

LTC, BTC, and XBT Transfer Issues — Troubleshooting Failed, Stuck, and Misdirected Transactions

LTC, BTC, and XBT Transfer Issues — Troubleshooting Failed, Stuck, and Misdirected Transactions

Problem

Customers using BitGo wallets for Litecoin (LTC), Bitcoin (BTC), or XBT report a range of transfer problems including: transactions failing with 500/502/504 server errors, transactions stuck in an unconfirmed/pending state, LTC accidentally sent to a BTC address (cross-chain misdirected funds), invalid address errors when attempting to send or receive LTC, and wallets not broadcasting or receiving transactions. These issues affect both API-driven integrations (e.g., ATM platforms like General Bytes) and the BitGo UI. In some cases the root cause is a platform-side outage; in others it traces back to an incorrect wallet passphrase, insufficient funds, or address-format incompatibility.

Diagnostics

  • Confirm environment and wallet details. Ask for: Environment (Prod/Test), Enterprise Name, Enterprise ID, Wallet ID, Transaction ID, User ID/email, and BitGo Express/SDK Version.
  • Check the exact error message. Distinguish between:
    • HTTP 500 / 502 / 504 → likely a server-side or infrastructure issue requiring engineering escalation.
    • "Insufficient funds" → verify spendable balance vs. total balance (unconfirmed UTXOs may not be spendable yet).
    • "Invalid address" → check whether the destination address format matches the target chain (e.g., LTC vs. BTC address prefix).
    • Wallet passphrase / signing errors → the user may be supplying the wrong wallet password.
  • Inspect the wallet's recent transaction history. In the BitGo dashboard or via the API (GET /api/v2/:coin/wallet/:id/transfer), check whether any transactions are succeeding. If some succeed and others fail, the problem is likely request-specific rather than systemic.
  • Review the full API request and response. Request:
    • Full API endpoint exactly as called including BaseURL
    • Full payload (omitting passwords)
    • Full response with timestamps
    • RequestId / reqId
    • Email address of the API Access Token creator
  • Check BitGo status page. Direct customers and agents to https://status.bitgo.com/ for any ongoing LTC or BTC service incidents.
  • Verify address format. LTC legacy addresses start with L or 3; BTC legacy addresses start with 1 or 3. Because both chains share the 3 prefix for P2SH addresses, cross-chain sends are possible. Native SegWit addresses differ (ltc1 vs. bc1). Confirm the customer is using the correct chain-specific address.
  • Check for unconfirmed parent transactions. A chain of unconfirmed transactions can block subsequent sends. Look at the wallet's pending/unconfirmed transaction count.

Resolution

Scenario: ltc-btc-xbt-transfer#server-errors-502-504

Trigger: LTC (or BTC) transactions fail consistently with HTTP 502 or 504 error codes, and no configuration changes were made on the customer side.

Signals: 502, 504, error code: 500, error code: 504, all transactions failing, LTC transactions failing, server error

Steps:

  1. Collect the standard troubleshooting information: Environment, Enterprise Name, Enterprise ID, Wallet ID, Transaction ID, API endpoint, full payload (omitting passwords), full response with timestamps, reqId, API Access Token creator email, and BitGo Express/SDK version.
  2. Check https://status.bitgo.com/ for any active incidents affecting LTC or BTC infrastructure.
  3. If no public incident is posted, escalate to the engineering team with all collected details and request triage.
  4. Monitor for updates from engineering and relay ETAs to the customer.
  5. Once engineering confirms a fix, ask the customer to retry the transaction and confirm success.

Notes: These server-side errors may resolve on their own after a platform fix. Customers should not repeatedly retry during an outage as this can queue duplicate transactions.

"All of our LTC transactions have been failing. The last successful transaction was on Sept 16 3:49PM MDT. No changes have been made to our platform." (ticket #245103)

"We have received different error messages when sending LTC transactions, specifically: 502 error code: 500, 504 error code: 504" (ticket #245103)

"We believe the previously reported issues with 504 and 502 errors on LTC transactions have been resolved." (ticket #245103)

Scenario: ltc-btc-xbt-transfer#incorrect-wallet-passphrase

Trigger: Transaction signing fails after server errors are resolved, and the error points to an incorrect wallet passphrase.

Signals: incorrect wallet passphrase, wrong password, signing error, wallet passphrase, cannot send, unable to sign

Steps:

  1. Inform the customer that the error indicates the wallet passphrase used for signing is incorrect.
  2. Ask the customer to verify that the user attempting to sign the transaction has the necessary permissions on the wallet.
  3. Confirm the user is entering the correct wallet password (not the account login password — these are different).
  4. If the customer believes the password is correct and errors persist, collect the Wallet ID(s) associated with the issue and escalate to engineering for further investigation.

Notes: This scenario often surfaces after a platform outage is resolved — the underlying server errors mask the passphrase issue until the infrastructure is healthy again.

"Our investigation indicates that it was caused by an incorrect wallet passphrase being used. The primary reason for this error is likely that the password entered for signing the transaction was incorrect. Please verify that the user attempting to sign the transaction has the necessary permissions and is using the correct password for the wallet." (ticket #245103)

Scenario: ltc-btc-xbt-transfer#insufficient-funds-unconfirmed

Trigger: Transaction fails with an "insufficient funds" error despite the wallet appearing to have a balance, or the wallet has a large number of unconfirmed transactions.

Signals: insufficient funds, spendable balance, unconfirmed, pending, balance mismatch, available balance

Steps:

  1. Check the wallet's spendable balance versus total balance. Unconfirmed incoming deposits are not spendable until they receive the required number of confirmations.
  2. If there is a chain of unconfirmed outgoing transactions, the change outputs are also locked, reducing the spendable balance.
  3. Advise the customer to wait for pending transactions to confirm before retrying.
  4. If the customer confirms sufficient confirmed balance and the error persists, collect full request/response details and escalate to engineering.

Notes: Customers sometimes deposit additional funds expecting them to be immediately spendable. Remind them that deposits require on-chain confirmations before they become available for spending.

"Our engineering team has identified that the last transaction attempt for your wallet failed due to insufficient funds." (ticket #245103)

Scenario: ltc-btc-xbt-transfer#ltc-sent-to-btc-address

Trigger: Customer reports they accidentally sent LTC to a BTC address (or vice versa), and the funds are not visible in the intended destination wallet.

Signals: LTC sent to BTC, BTC address, wrong network, cross-chain, sent to bitcoin wallet, misdirected funds

Steps:

  1. Confirm the exact transaction ID and the destination address the funds were sent to.
  2. Determine whether the destination address is controlled by BitGo (i.e., it is a BitGo wallet address on the other chain). If so, recovery may be possible because BitGo holds the corresponding keys on both chains for certain address formats.
  3. If the destination is a BitGo-controlled wallet, escalate to the engineering team with the transaction ID, source wallet ID, destination address, and both the source chain (LTC) and destination chain (BTC) clearly identified.
  4. If the destination address is not controlled by BitGo (e.g., an external exchange or personal wallet), advise the customer that BitGo cannot recover the funds. They will need to contact the owner/operator of the destination address and request recovery using the private keys for that address on the LTC network.
  5. Educate the customer on address format differences: LTC native SegWit addresses begin with ltc1, while BTC native SegWit addresses begin with bc1. Legacy P2SH addresses (starting with 3) can appear valid on both networks, which is a common source of cross-chain errors.

Notes: This is one of the most frequently reported issues in this cluster, with many tickets titled "LTC sent to BTC address" or "LTC to BTC." Recovery feasibility depends entirely on whether BitGo controls the destination address on both chains. There is no guaranteed recovery for funds sent to external addresses.

Scenario: ltc-btc-xbt-transfer#invalid-ltc-address

Trigger: Customer receives an "invalid address" error when trying to send to or receive at an LTC address, often when sending from an external platform (e.g., Coinbase) to a BitGo LTC wallet.

Signals: invalid address, LTC invalid address, cannot send to address, address error, incorrect LTC address, Coinbase

Steps:

  1. Check the format of the LTC address being used. BitGo may generate addresses in newer formats (e.g., M-prefix P2SH or ltc1 bech32) that some external platforms do not yet support.
  2. If the external platform rejects the address, advise the customer to generate a new receive address in the BitGo UI or via API and check whether an older-format address (e.g., legacy L-prefix or 3-prefix) is available.
  3. If the address format is correct and the error persists on the BitGo side, collect the full address, wallet ID, and error response and escalate to engineering.

Notes: Address compatibility is a known issue between platforms. Some exchanges have not updated to support all LTC address formats.

Scenario: ltc-btc-xbt-transfer#third-party-integration-general-bytes

Trigger: Customer using a third-party integration (e.g., General Bytes ATM software) reports that their LTC wallet will not send funds, but the API credentials and wallet configuration appear correct.

Signals: General Bytes, ATM, third-party integration, will not send, API correct, wallet password correct

Steps:

  1. Verify that transactions are actually being submitted by checking the wallet's transaction history in the BitGo dashboard. In at least one case, transactions were successfully being sent despite the customer's report.
  2. Collect: Error Message, reqId, full API endpoint, full payload (omitting passwords), full response, API Access Token creator email, and BitGo Express/SDK version.
  3. If transactions show as submitted on BitGo's side, the issue likely lies in the third-party integration's error handling or status polling. Advise the customer to work with their integration vendor (e.g., General Bytes) to verify how transaction status is being read.
  4. If no transactions appear on BitGo's side, troubleshoot the API call itself — verify the endpoint URL, authentication token, wallet ID, and passphrase being used by the integration.
  5. If the issue cannot be resolved with the above steps, escalate to engineering with the collected details.

"We are seeing transactions being sent from this wallet with several being submitted today." (ticket #266885)

Scenario: ltc-btc-xbt-transfer#stuck-pending-transactions

Trigger: LTC or BTC transaction has been submitted but remains unconfirmed/pending for an extended period.

Signals: pending, unconfirmed, stuck, not confirmed, transaction not confirmed, stuck LTC transaction

Steps:

  1. Look up the transaction on a public block explorer (e.g., blockchair.com or litecoinblockexplorer.net for LTC, mempool.space for BTC) using the transaction ID.
  2. Check whether the transaction is visible in the mempool. If it is, the fee rate may be too low for current network conditions.
  3. For BTC: If BitGo supports fee bumping (CPFP or RBF) for the wallet type, consider initiating a fee bump. Refer to BitGo documentation on accelerating transactions.
  4. For LTC: Network congestion is less common, but if the fee is too low, the transaction may eventually drop from mempools. Monitor and advise the customer to wait or, if the transaction drops, retry with a higher fee.
  5. If the transaction is not visible on any block explorer but shows as pending in BitGo, escalate to engineering — the transaction may not have been broadcast successfully.

Notes: Customers should avoid sending additional transactions from the same wallet while a parent transaction is unconfirmed, as child transactions depend on the parent's confirmation. Review BitGo's dynamic fee support to avoid underpaying fees.

Related

  • bitcoin-special-call-outs — Covers best practices for BTC fee calculation, dynamic fee support, and managing unconfirmed transaction backlogs.
  • bitcoin-transactions — Describes deposit/withdrawal flows in the BitGo UI for BTC wallets; the same general workflow applies to LTC.
  • warm-wallet-vs-hot-wallet — Relevant when whitelist policies or wallet configuration may be restricting outbound sends.