Scoutinternal

EVM Cross-Chain Recovery: Funds Sent to BitGo Address on Wrong Network (BSC, Polygon, Arbitrum)

EVM Cross-Chain Recovery: Funds Sent to BitGo Address on Wrong Network (BSC, Polygon, Arbitrum)

Problem

Customers or their end-users accidentally send tokens (USDT, USDC, ETH, BNB, MATIC, DOGE, DAI, WETH, etc.) to a BitGo-managed Ethereum (or other EVM) wallet address but use the wrong EVM-compatible network — most commonly BSC (BEP-20), Polygon, or Arbitrum instead of Ethereum ERC-20 (or vice versa). Because EVM chains share the same address format, the transaction succeeds on-chain but the funds do not appear in the BitGo wallet. The customer provides a transaction hash viewable on the wrong-chain explorer (e.g., bscscan.com, polygonscan.com, arbiscan.io) and requests recovery of the stranded funds to a destination address on that wrong chain.

Diagnostics

  • Verify the transaction on the wrong-chain explorer. Open the TX hash on the appropriate block explorer (bscscan.com for BSC, polygonscan.com for Polygon, arbiscan.io for Arbitrum). Confirm the receiving address, token, amount, and that the transaction is confirmed.
  • Look up the receiving address in BitGo admin tools. Run bga a <receiving_address> to identify the associated wallet, coin type, chain index, and forwarderVersion.
  • Retrieve wallet metadata. Run bga -j w <wallet_id> | grep -ie fee -ie base -ie walletVersion -ie type to obtain:
    • baseAddress
    • feeAddress
    • walletVersion
    • multisigType (onchain vs. tss)
  • Check the wallet version. This is critical for determining recoverability:
    • Wallet version 0, 1, or 2: Recovery is supported (either via engineering manual process or self-serve UI tool).
    • Wallet version 4: May be supported for self-serve recovery depending on forwarderVersion.
    • Wallet version 5 (TSS/MPCv2): Recovery is not supported. Inform the customer accordingly.
  • Estimate fees. Run the fee estimate command on the wrong chain:
    bga coin <wrongChain>
bga admin evmCrossChainRecovery feeEstimate --wrongChainCoin <intendedChain> --wrongChainAddress <receivingAddress> --startNonce 0
    This returns totalBalanceRequired, feeForWalletDeployment, and feeForForwarderDeployment.
  • Check fee address balance. Verify whether the fee address on the wrong chain has sufficient native gas tokens (BNB for BSC, MATIC/POL for Polygon, ETH for Arbitrum) to cover the estimated fees.
  • Confirm the requester is an authorized account holder. If the requester is not a BitGo customer (e.g., an end-user of a BitGo client like BlockFi, Nexo, CoinMetro), they must have the wallet-owning entity contact BitGo on their behalf. BitGo cannot process recovery requests from non-customers directly.
  • Check if self-serve Asset Recovery Tool is enabled. Newer wallets (version 2+) may be eligible for the self-serve EVM recovery feature in the BitGo UI. Verify that the feature is enabled on the customer's Enterprise account.

Resolution

Scenario: ethaddress-bsc-recovery-hash#standard-evm-cross-chain-recovery

Trigger: Funds were sent on a wrong EVM chain (BSC, Polygon, or Arbitrum) to a BitGo ETH/Polygon/other EVM wallet address, and the wallet version is 0, 1, or 2 with onchain multisig.

Signals: wrong network, wrong chain, BSC, BEP-20, Polygon, MATIC, Arbitrum, USDT, USDC, ETH, bscscan, polygonscan, arbiscan, cross-chain recovery, ERC-20 address, forwarderVersion 0, forwarderVersion 1, forwarderVersion 2, walletVersion 0, walletVersion 1, walletVersion 2

Steps:

  1. Collect from the customer: (a) transaction hash in text, (b) explorer link on the wrong chain, (c) amount and token, (d) the receiving BitGo address, and (e) a destination address on the wrong chain that the customer controls.
  2. Confirm the destination address must be on the wrong chain (the chain the funds were actually sent on), not on the intended chain. BitGo can only recover funds to an address on the same chain the funds are stranded on.
  3. Run the fee estimate as described in diagnostics. Communicate the totalBalanceRequired in the native gas token of the wrong chain to the customer.
  4. Ask the customer to fund the fee address with the required gas amount on the wrong chain. Provide the fee address and the block explorer link for verification.
  5. Once the customer confirms the fee address is funded, refer the recovery to the Engineering team (or, for wallet version 2+ with the self-serve feature enabled, direct the customer to use the Asset Recovery Tool in the UI).
  6. Engineering performs the recovery, which typically involves three steps: (a) deploy the wallet/forwarder contract on the wrong chain, (b) flush/forward the token from the forwarder to the base address on the wrong chain, (c) create a recovery transaction sending funds from the base address to the customer's destination address.
  7. Share the recovery transaction hash with the customer and confirm completion.

Notes: - For BSC recoveries, the fee is paid in BNB. For Polygon recoveries, the fee is paid in MATIC. For Arbitrum recoveries, the fee is paid in ETH on Arbitrum.

  • Recovery fees vary significantly based on forwarder version and the number of forwarder deployments needed. V0 wallets with high nonces can require substantially more gas (e.g., 40+ BNB or 110+ MATIC for bulk recoveries).
  • If the fee address already has sufficient funds from prior operations, the customer may not need to add more.
  • BTC transactions sent to wrong networks and Fantom (FTM) chain recoveries are not supported.
  • Recovery of unsupported tokens (tokens not listed on BitGo) may require the Wallet Recovery Wizard (WRW) unsupported token recovery feature or the recovertoken API endpoint.

"Yes this can be recovered, just to confirm the destination address is [address] on bsc chain... Yes please, we can only recover the funds to an address on the wrong chain, in this case funds were sent on bsc chain thus we can send them to a destination address only on bsc chain." "To be able to perform this recovery, please fund the fee address with 0.003 BNB. Fee address: https://bscscan.com/address/[address]" "We have checked with our engineering team and this amount can be recovered. Please send 4 matic to the fee address [address] on polygon chain and please provide us with a destination address on polygon chain where to recover the funds."

Scenario: ethaddress-bsc-recovery-hash#self-serve-ui-recovery-tool

Trigger: The customer's wallet is version 2 or higher, and the self-serve EVM Asset Recovery Tool is enabled on their Enterprise account.

Signals: self-serve, asset recovery tool, UI recovery, walletVersion 2, walletVersion 4, recover lost asset, EVM cross chain recovery, recoveries menu

Steps:

  1. Verify the Enterprise has the self-serve Asset Recovery Tool enabled. If not, it can be enabled on the back end.
  2. Direct the customer to log in to the BitGo UI, click the 9-dot grid menu, and select "recoveries."
  3. Customer selects "Recover Asset" → "Recover Lost Asset."
  4. Customer selects the intended chain (the chain the wallet is on), inputs the wallet address, selects the wrong chain (where funds actually went), and specifies the destination address on the wrong chain.
  5. The tool will display any required gas fees. The customer ensures the fee address has sufficient funds.
  6. Customer completes the recovery through the UI.
  7. If the customer encounters errors (e.g., "Balance at the address is 0", timeout errors), collect screenshots and escalate to Engineering.

Notes: - V0 wallets are not supported by the self-serve tool and must go through the manual engineering recovery process.

  • The self-serve tool is not applicable to BASE chain transactions, which still require the Wallet Recovery Wizard (WRW).
  • Some customers may see confusing results if they swap the intended/wrong chain fields. Ensure they input the correct chain for each field.
  • A PDF user guide can be attached to the customer email to walk them through the process.

"We recently added a feature to our UI that allows customers to perform EVM recoveries. This functionality is now enabled on your Enterprise account. Attached is a PDF guide with step-by-step instructions to help you navigate the recovery process." "The EVM recovery feature is now available in the platform UI for your team's use. It can be accessed by logging in and selecting the 'recoveries' option in the 9-dot grid menu."

Scenario: ethaddress-bsc-recovery-hash#wallet-version-5-tss-not-recoverable

Trigger: The receiving wallet has walletVersion 5 with multisigType "tss" and MPCv2.

Signals: walletVersion 5, tss, MPCv2, not recoverable, not supported, wallet version 5

Steps:

  1. After looking up the wallet and confirming walletVersion is 5 and multisigType is tss, inform the customer that cross-chain recovery is not currently supported for wallet version 5.
  2. Provide a clear, empathetic message: "We do not support the recovery from wallet version 5. This is not currently plausible."
  3. If the customer references prior successful recoveries on a different wallet, clarify that those wallets likely had a different wallet version (e.g., version 2).

Notes: - This is a firm technical limitation. There is no workaround at this time.

"Thanks for reaching out. We do not support the recovery from wallet 5. This is not plausible." "However, all the transactions of the chain provided the wallet version was 2. However, here the wallet version is 5 because of which we are unable to recover this."

Scenario: ethaddress-bsc-recovery-hash#non-customer-requester

Trigger: The person requesting recovery is not a BitGo customer — they are an end-user of a BitGo client (e.g., BlockFi, Nexo, CoinMetro).

Signals: not a customer, no account, BlockFi, Nexo, CoinMetro, end user, wallet owner must contact

Steps:

  1. Inform the requester that BitGo cannot process recovery requests directly from non-customers because the wallet address belongs to the BitGo client's wallet, not the individual.
  2. Instruct the requester to have the wallet-owning entity (e.g., their exchange or platform) open a support ticket with BitGo on their behalf.
  3. The wallet-owning entity must provide: the transaction hash, the receiving address, and a destination address for the recovered funds.
  4. Close the ticket if the non-customer cannot arrange for the wallet owner to contact BitGo.

Notes: - If the wallet-owning entity is a former BitGo client (e.g., Nexo) that is under legal proceedings, there may be legal and compliance complications that prevent or delay recovery. Inform the requester to continue their grievance with the former client.

  • BitGo will never process a recovery at the direction of someone who does not own the wallet.

"We are able to perform recoveries of ETH on BNB chain. We will need Blockfi to create a support ticket on your behalf. They will need to include the transaction id for the transaction sent incorrectly as well as provide a destination address where the coins should be recovered to." "This recovery is possible, but you need CoinMetro to contact us and open a ticket on your behalf for the recovery. This is needed because you are not a customer of ours and the address you send funds to, while on the wrong network, belongs to a wallet CoinMetro owns."

Scenario: ethaddress-bsc-recovery-hash#weth-or-unsupported-token-recovery

Trigger: The stranded funds are a token not supported by BitGo (e.g., WETH on Polygon, XSGD on Arbitrum, or a fraudulent/unknown ERC-20 token).

Signals: unsupported token, WETH, wrapped ether, unknown token, not supported, recovertoken, WRW, wallet recovery wizard

Steps:

  1. Confirm whether the token is listed on BitGo's supported token list. Check via https://app.bitgo.com/api/v1/client/constants or internal tooling.
  2. If the token is unsupported but the cross-chain recovery infrastructure applies, the EVM cross-chain recovery process may still work. Escalate to Engineering for assessment.
  3. For unsupported tokens on the correct chain (not a cross-chain issue), direct the customer to the Wallet Recovery Wizard (WRW) unsupported token recovery feature or the recovertoken API endpoint: https://developers.bitgo.com/api/express.wallet.recovertoken.
  4. Download the latest WRW from: https://github.com/BitGo/wallet-recovery-wizard/releases. The "EVM cross chain recovery" option in WRW may be applicable for some cross-chain scenarios.
  5. If Engineering confirms recovery is not possible (e.g., for WETH on Polygon), inform the customer clearly.

Notes: - WETH recovery from Polygon was flagged as uncertain — BitGo does not support WETH natively and recovery is not guaranteed.

  • The recovertoken API may not yet function for all chains (e.g., Arbitrum unsupported token recovery was escalated to Engineering as of early 2025).
  • For tokens that are outright fraudulent or scam tokens, BitGo cannot recover them but the WRW unsupported token recovery flow may work.

"Our team had shared that you should be able to recover funds with our Wallet Recovery Wizard (WRW). The EVM cross chain recovery option should be what you are looking for... Please download the latest version of our WRW here - https://github.com/BitGo/wallet-recovery-wizard/releases" "Unfortunately we cannot recover the tokens that we don't support but you can use WRW to recover unsupported tokens."

Scenario: ethaddress-bsc-recovery-hash#high-forwarder-deployment-cost

Trigger: The fee estimate returns an unusually high totalBalanceRequired due to many forwarder deployments needed (e.g., V0 wallet with high nonce, or bulk recovery across many addresses).

Signals: high fee, expensive, forwarder deployment, nonce, 40 BNB, 110 MATIC, 780 MATIC, bulk recovery, multiple addresses

Steps:

  1. Present the fee breakdown to the customer, distinguishing between feeForWalletDeployment and feeForForwarderDeployment.
  2. If there are multiple transactions at different addresses, provide per-transaction fee estimates so the customer can choose which to recover.
  3. Advise the customer to add slightly more than the estimated amount to account for gas price fluctuations: "Please add the funds accordingly and always include extra, as there will always be fluctuations in the fees."
  4. Clarify that these are network fees only — BitGo does not charge a separate recovery fee on top of gas costs.
  5. If the cost of recovery exceeds the value of the stranded funds, inform the customer so they can make an informed decision on whether to proceed.

Notes: - V0 wallets can require dramatically more gas because the forwarder must be deployed from a specific nonce. For example, one recovery required deploying ~154,000 forwarders at ~0.000262179 BNB each, totaling ~40.4 BNB.

  • Individual transactions below $500 in value may not be supported for manual engineering recovery, though the self-serve tool has no minimum threshold.
  • The fee estimate link https://coinmarketcap.com/converter/ can be shared for the customer to verify current conversion rates.

"1 forwarder deployment costs ~ 0.000262179 bnb as per current fees... For this, we need to do 171526 - 17425 forwarders deployments which is 154101 * 0.000262179 = 40.402046079" "Total fee required to recover funds: {'totalBalanceRequired':'781.775268588116952064', 'feeForWalletDeployment':'3.944461938833248064', 'feeForForwarderDeployment':'777.830806649283704'}"

Scenario: ethaddress-bsc-recovery-hash#recovery-tool-api-failure

Trigger: The customer or the self-serve recovery tool encounters an error such as "Response timeout of 5000ms exceeded" or "Failed" status during the recovery process.

Signals: failed, timeout, Response timeout of 5000ms exceeded, BscScan API, recovery tool error, nonce holes, COIN-4412

Steps:

  1. Collect the Recovery ID (even if truncated), error screenshots, the wallet address, intended chain, wrong chain, and the original transaction hash.
  2. Escalate to Engineering with all collected details. Reference JIRA ticket COIN-4412 if the issue involves BscScan API timeouts.
  3. Engineering may need to address issues such as: (a) BscScan public API service timeout when fetching token balances, (b) nonce holes in the forwarder address that need to be filled before recovery can proceed.
  4. Once Engineering resolves the underlying issue, ask the customer to retry the recovery via the self-serve tool.
  5. If the recovery failed during the "Flush Forward" step (before broadcast), there will be no on-chain transaction hash — clarify this to the customer.

Notes: - Nonce holes may occur if prior transactions were partially processed. Engineering can fill these before the customer retries.

  • If the issue is with a public block explorer API (e.g., BscScan), it may be resolved by Engineering deploying a fix or waiting for the external service to stabilize.

"Upon further investigation our Engineering team are working to fix an issue with the BscScan public API service to fetch token balance api. This api is giving the error Response timeout of 5000ms exceeded" "The issue was due to nonce holes which has since been filled. The funds are now with the base address. Can you please create a new recovery request and use the base address, [address] in the wallet address field?"

Related