Scoutinternal

Recovering Coins Sent to the Wrong Chain (BTC / BCH / LTC Cross-Chain Recovery)

Recovering Coins Sent to the Wrong Chain (BTC / BCH / LTC Cross-Chain Recovery)

Problem

Customers accidentally send coins to a BitGo wallet address generated for a different chain — most commonly BTC sent to a BCH wallet address, or BCH sent to a BTC wallet address. Because BTC and BCH (and LTC) share similar address formats, funds land on the wrong chain and do not appear in the intended wallet. The customer needs to recover these funds using the BitGo Wallet Recovery Wizard (WRW), with BitGo co-signing the recovery transaction in some cases. This issue also applies to other UTXO-based cross-chain mistakes such as LTC ↔ BCH.

Diagnostics

  • Confirm the cross-chain scenario. Ask the customer for:
    • The Wallet ID of the wallet that received the funds (the "wrong" wallet).
    • The Transaction ID of the misdirected transaction.
    • The receiving address and which coin type that address belongs to on the BitGo platform.
    • The coin that was actually sent (the source coin).
  • Verify the address belongs to BitGo. Look up the receiving address in the BitGo Admin tool (BGA). Confirm the address is owned by the customer's wallet. If the address is not found in BGA, the WRW cannot recover funds from it — WRW can only recover from BitGo-controlled addresses.
  • Check whether the address is a legacy or SegWit address. If BCH was sent to a SegWit BTC address, the recovery process is different and more sensitive (see the SegWit BCH recovery scenario below).
  • Confirm the customer has the necessary wallet permissions. At least spender permission on the wallet is required to perform the recovery through WRW.
  • Check the WRW version. The "Wrong Chain Recoveries" function is available in older WRW versions (e.g., v3.1.3) and newer versions. Some customers may need to use a specific version if they encounter errors on the latest release.
  • Confirm the customer has a Blockchair API key. Newer WRW versions require an API key from Blockchair (https://blockchair.com/api/docs#link_M05) to query for unspent outputs.
  • For multi-output transactions, verify which output(s) correspond to BitGo-controlled addresses. WRW can only recover from outputs that went to BitGo addresses.

Resolution

Scenario: bch-btc-recover-recovery#standard-cross-chain-wrw

Trigger: Customer sent BTC to a BCH address (or BCH to a BTC/LTC address, or LTC to a BCH address) and the receiving address is a legacy (non-SegWit) BitGo wallet address.

Signals: BTC sent to BCH, BCH sent to BTC, wrong chain, cross-chain recovery, WRW, Wallet Recovery Wizard, legacy address

Steps:

  1. Direct the customer to download the BitGo Wallet Recovery Wizard from its GitHub releases page: https://github.com/BitGo/wallet-recovery-wizard/releases
  2. Provide installation instructions based on their platform:
    • macOS: Double-click the .dmg file, drag 'BitGoWalletRecoveryWizard' into 'Applications', then right-click and select 'Open'. If a publisher-unknown warning appears, click 'Open' in the notification box.
    • Windows: Right-click the .zip file, select 'Extract All...', choose an install folder, then double-click 'BitGoWalletRecoveryWizard.exe'.
  3. Instruct the customer to log into the WRW using 'Mainnet' (production environment at https://www.app.bitgo.com/) or 'Testnet' (https://app.bitgo-test.com/) as appropriate.
  4. The customer must select "Wrong Chain Recoveries" and fill in the form:
    • Source Coin: The coin that was sent (e.g., BTC).
    • Destination Coin: The coin type of the wallet that received it (e.g., BCH).
    • Wallet ID: The wallet ID of the wallet that received the source coin.
    • Transaction ID: The transaction ID of the misdirected transaction.
    • Destination Address: The address where recovered funds should be sent (should be a valid address for the source coin).
    • API Key: A Blockchair API key (obtainable at https://blockchair.com/api/docs#link_M05).
    • Wallet Passphrase: The wallet passphrase of the wallet that received the source coin.
  5. The customer should tick the box to Sign Transaction and click Recover. This generates a half-signed JSON file.
  6. The customer sends the half-signed JSON file to support@bitgo.com.
  7. BitGo engineering co-signs the transaction and returns a fully-signed recovery file containing:
    • halfSignedTx (the half-signed transaction hex)
    • completeTx (the complete transaction hex)
    • completeTxHash (the transaction ID of the complete transaction)
  8. Instruct the customer to verify the transaction by decoding it on a public blockchain explorer such as https://www.blockchain.com/explorer/assets/btc/decode-transaction and confirming destination addresses and amounts.
  9. Once verified, the customer can broadcast using https://www.blockchain.com/explorer/assets/btc/broadcast-transaction (for BTC recoveries) or the equivalent for the relevant chain.

Notes: - The customer must have at least spender permission on the wallet for the recovery to succeed. Without spender permission, the WRW will return errors such as "No encrypted keychains on this wallet."

  • If a non-wallet-creator admin is logged in, they should use their BitGo login password as the wallet passphrase — not the original wallet creation passphrase. Only when the wallet creator is logged in should the actual wallet password be used. This mirrors how withdrawals work via the web UI.
  • The error ccm: tag doesn't match typically indicates an incorrect passphrase was entered.
  • For multi-output transactions, WRW can only recover from outputs that correspond to BitGo-controlled addresses. If only one of multiple outputs went to a BitGo address, only that portion is recoverable.
  • If the customer encounters errors on the latest WRW version, ask them to try version 3.1.3 as the "Wrong Chain Recoveries" feature is confirmed to work in that version.

"After installed, choose the Wrong Chain Recoveries function and fill up the form and ticked the box to Sign Transaction. You will also need an API key from Blockchair to complete this - https://blockchair.com/api/docs#link_M05" (ticket #239915)

"So the admin signed in should uses his/her BitGo login password for the wallet passphrase here. Only when the wallet creator logged in should the actual wallet password be used. This works the same way when withdrawing via the web UI." (ticket #239915)

"WRW can only recover from BitGo addresses. So ~0.28525 BCH was expectedly recover from the BitGo address in this transaction." (ticket #239915)

Scenario: bch-btc-recover-recovery#segwit-bch-recovery-trusted-miner

Trigger: BCH was sent to a SegWit BTC address. BitGo provides a recovery transaction hex but warns that it must NOT be broadcast to the public mempool.

Signals: SegWit, segwit BCH recovery, trusted miner, mempool, replayable, do not broadcast, transaction hex, steal funds, destination address swap

Steps:

  1. When the customer submits the half-signed JSON for a BCH-to-SegWit-BTC recovery, escalate to engineering to produce the recovery transaction hex.
  2. Engineering returns the raw transaction hex along with a critical warning.
  3. Relay the transaction hex to the customer with the following mandatory warning:

    "Do not attempt to broadcast this transaction yourself! Due to the specific nature of this recovery, if this transaction hits the mempool at all, then anybody can swap out the destination address and steal the funds."

  4. Instruct the customer: they must contact a trusted miner directly and request the miner mine the transaction without it entering the public mempool.
  5. Recommend miners available at https://blockchair.com/broadcast as one avenue. Note that the previously suggested miner (https://www.smartbit.com.au/txs/pushtx) is no longer operational.
  6. If the miner requires a specific mining fee encoded in the transaction, ask the customer to relay that information back to BitGo so engineering can recreate the transaction with the requested fee.
  7. If the customer or miner encounters the error "Invalid transaction. Error: non-mandatory-script-verify-flag (Extra items left on stack after execution) (code 64)", escalate back to engineering for further analysis.

Notes: - The reason this recovery is sensitive is that SegWit BCH transactions are replayable — untrusted miners could intercept and redirect the funds.

  • This is inherent to how the blockchain operates; BitGo cannot streamline or eliminate this requirement.
  • The customer should NOT use Blockchair's standard broadcast feature or any public broadcast tool for this specific transaction type. Only direct miner engagement is safe.

"Regarding your query about why BitGo is unable to broadcast this transaction directly, the main reason is that set with BCH transactions are replayable. This means that untrusted miners could potentially intercept and steal the funds. For this reason, the transaction needs to be broadcast by a trusted miner to ensure security." (ticket #274044)

"IMPORTANT: Do not attempt to broadcast this transaction yourself! Due to the specific nature of this recovery, if this transaction hits the mempool at all, then anybody can swap out the destination address and steal the funds. Instead, you should contact a miner that you trust and request that they mine the transaction for you." (ticket #25986)

"the previously suggested miner, https://www.smartbit.com.au/txs/pushtx, is no longer operational." (ticket #274044)

Scenario: bch-btc-recover-recovery#wrw-errors-troubleshooting

Trigger: Customer encounters errors during the WRW cross-chain recovery process such as "No encrypted keychains on this wallet," "ccm: tag doesn't match," or address lookup failures.

Signals: No encrypted keychains, ccm tag doesn't match, WRW error, wallet passphrase, spender permission, address not found, copy paste issue

Steps:

  1. "No encrypted keychains on this wallet": Confirm the logged-in user has at least spender permission on the wallet. If not, an admin with spender privileges must log in and perform the recovery.
  2. "ccm: tag doesn't match": This indicates an incorrect wallet passphrase. If a non-wallet-creator is logged in, they should use their BitGo login password as the wallet passphrase, not the original wallet creation passphrase.
  3. Address not found / lookup failures: Copy-paste operations can introduce invisible formatting characters. Ask the customer to copy the address directly from a block explorer link or from the BitGo Admin API response rather than from email text. Verify the address resolves correctly in BGA.
  4. Blockchair API key errors or "token expired": Ask the customer to delete the expired API token in their Blockchair account and create a new one with the same permissions, then retry.
  5. Version-specific errors: If the customer is on the latest WRW version and encounters unexplained failures, ask them to try WRW version 3.1.3 which has confirmed compatibility with the Wrong Chain Recoveries function.
  6. If errors persist after troubleshooting, collect screenshots of all fields filled in the WRW form and escalate to engineering.

Notes: - The Blockchair API key is required in newer WRW versions for querying unspent outputs. It can be obtained at https://blockchair.com/api.

"Yes, definitely at least spender permission on the wallet is required for the recovery to go through." (ticket #239915)

"Upon checking the screenshot, we could see the token on the wallet has expired. Could you please delete the expired token and recreate a new one with the same permissions and try again?" (ticket #26200)

"I found when copying/paste the address from your comments, my system could not find it. When I copied the address from blockexplorer link, I was suddenly able to find it." (ticket #20524)

Related