Scoutinternal

Recovery, Co-sign, and Wrong-Chain Tool Issues — Including 'keychain does not have property encryptedPrv' Error

Recovery, Co-sign, and Wrong-Chain Tool Issues — Including "keychain does not have property encryptedPrv" Error

Problem

Customers encounter several categories of recovery-related issues on BitGo: (1) XRP and other coin withdrawals failing with the error "keychain does not have property encryptedPrv," most commonly seen by FTX settlement recipients attempting their first withdrawal; (2) cross-chain (wrong-chain) recovery questions, including confusion about terminology ("Correct Chain" vs. "Incorrect Chain"), flush-forward behavior, and signing requirements in the self-service cross-chain recovery tool; (3) EVM recovery complications where multiple recovery attempts from different forwarders to the same base address cause funds to consolidate unexpectedly; and (4) general recovery tool failures or co-sign requests. These issues span XRP, EVM chains (ETH, POL, BSC), and other supported coins.

Diagnostics

  • For "keychain does not have property encryptedPrv" errors:

    • Confirm the customer is attempting a withdrawal (commonly XRP) and receiving exactly: keychain does not have property encryptedPrv.
    • Check whether the customer is an FTX settlement creditor (recently onboarded account with FTX-sourced funds). These accounts frequently have not set a wallet password.
    • Ask whether the customer is on the new UI or the classic view — the wallet password reset/update option is only accessible in classic view.
    • Navigate to the customer's wallet settings and confirm whether a wallet password (encrypted private key) has been established.

  • For cross-chain / wrong-chain recovery questions:

    • Identify the source chain, destination chain, and asset involved (e.g., POL sent to ETH chain instead of POL chain).
    • Check whether a flush forward has already occurred (funds moved from receive address to base address).
    • Determine whether the recovery status is stuck at "pending" despite on-chain confirmation — this may indicate a backend sync issue that BitGo engineering can resolve.
    • Check whether the asset/chain is supported by the Wallet Recovery Wizard (WRW). BSC tokens, for example, are not supported in WRW and require BitGo to provide half-signed JSON files.

  • For EVM recovery complications:

    • Check whether the customer created multiple recoveries using the same base address but different forwarder addresses.
    • Verify whether funds from multiple forwarders were swept to the base address, causing consolidation into a single recovery's destination.
    • Confirm the recovery ID, wallet ID, forwarder addresses, and destination addresses involved.

  • For general recovery tool errors or co-sign requests:

    • Confirm which recovery tool the customer is using (Wallet Recovery Wizard, self-service cross-chain recovery tool, or API).
    • Gather the recovery ID if one has been generated.
    • Check whether the recovery requires a BitGo co-sign and whether it is pending action from the BitGo side.

Resolution

Scenario: recovery-cosign-wrongchain-tool#encryptedprv-wallet-password

Trigger: Customer receives the error "keychain does not have property encryptedPrv" when attempting a withdrawal, typically XRP, often from an FTX settlement account.

Signals: keychain does not have property encryptedPrv, encryptedPrv, XRP withdrawal failed, FTX refund, wallet password, trading wallet

Steps:

  1. Instruct the customer to switch to classic view first:
    • Click the profile icon in the top right corner.
    • Click "Switch to classic view."
  2. Navigate to Trading Wallet → Settings → Update Wallet Password (or, if the password was never set, use "Forgot wallet password").
  3. The customer enters: a. Their current login password. b. A new wallet password. c. Confirmation of the new wallet password.
  4. After the wallet password is updated, the customer should retry the withdrawal using the new wallet password.
  5. If the customer reports the issue is resolved after switching to classic view and linking the Go account, no further action is needed.

Notes: - This error is extremely common among FTX creditors who received settlement funds and are attempting their first withdrawal.

  • The wallet password update/reset options are only accessible in classic view, not the new UI.
  • Some customers have self-resolved by switching to classic view and linking their Go account without needing to explicitly reset the password.
  • Refer customers to https://www.bitgo.com/ftx-faq for additional FTX-related information.

"If you are running into this (keychain does not have property encryptedPrv) error, you may need to reset the trading wallet password. To reset the password, please follow below steps: 1. Login 2. Navigate to Trading Wallet 3. Go to Settings 4. Update Wallet Password 5. Enter Password Details a. User inputs their current login password. b. User enters a new wallet password. c. User confirms the new wallet password. 6. Complete the Upgrade. Please switch to classic view first and then follow the steps suggested." (ticket #227120)

"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" (ticket #263996)

"Never Mind. I resolved the issue by switching to classic view and linking the go account." (ticket #223357)

Scenario: recovery-cosign-wrongchain-tool#crosschain-terminology-and-signing

Trigger: Customer has questions about cross-chain recovery tool behavior, including flush-forward purpose, "Correct Chain" vs. "Incorrect Chain" labels, pending status after on-chain confirmation, or BSC token recovery workflow.

Signals: cross chain, wrong chain, incorrect chain, correct chain, flush forward, WRW, BSC tokens, half-signed JSON, pending status, recovery signing

Steps:

  1. Flush forward vs. signing: Explain that the flush forward moves assets from the receive address to the base address of the wallet. A separate signature is still required to complete the actual recovery (withdrawal from base address to destination). This is by design.
  2. Pending status after on-chain confirmation: If the recovery shows as "pending" despite being confirmed on-chain, this is a backend sync issue. Escalate to the BitGo product/engineering team (specifically the team overseeing the cross-chain recovery tool) to manually resolve the stuck status.
  3. "Correct Chain" vs. "Incorrect Chain" terminology: In BitGo's cross-chain recovery tool, the chain where the funds currently reside is referred to as the "correct" chain, and the chain where the customer intended to send is the "incorrect" chain. Example: if POL was sent to the ETH chain instead of the POL chain, ETH is labeled "Correct Chain" (because funds are there) and POL is labeled "Incorrect Chain."
  4. BSC tokens and WRW: The Wallet Recovery Wizard (WRW) does not support BSC tokens. For unsupported chains/tokens, the correct process is for the BitGo team to provide half-signed JSON files individually for the customer to complete signing.
  5. After a flush forward completes, the recovery process should be re-initiated if needed — confirm with the customer whether new unsigned transactions are available in the tool.

Notes: - The "Correct Chain" / "Incorrect Chain" terminology can be counterintuitive. BitGo has acknowledged this feedback and may update labels based on customer input.

  • For enterprise clients with complex recovery needs, loop in the Product Manager overseeing the cross-chain recovery tool for direct assistance.

"The flush forward represents flushing of assets from the receive address to the base address of the wallet. For completing recovery, which is akin to a withdrawal from base address we need a signature to complete the transaction." (ticket #249268)

"In the example, where POL was sent to ETH chain instead of POL chain. Since the funds are currently lying on ETH chain hence, we refer to it correct chain and the POL chain as incorrect chain. However, the purpose of collecting customer feedback is to understand if they have a difference in understanding and we can make changes accordingly." (ticket #249268)

Scenario: recovery-cosign-wrongchain-tool#evm-multiple-forwarder-consolidation

Trigger: Customer created multiple EVM recoveries using the same base address but different forwarder addresses, resulting in funds consolidating to a single destination address unexpectedly.

Signals: EVM recovery, multiple forwarders, same base address, funds consolidated, sweep, unsigned transaction, destination address mismatch

Steps:

  1. Identify the forwarder addresses and destination addresses involved in each recovery.
  2. Confirm that when the second recovery was created, its funds were also moved to the shared base address, combining with the first recovery's funds.
  3. Explain to the customer: because the unsigned transaction is a sweep of all funds at the base address (it does not specify an amount), it sent the total consolidated amount to the first recovery's destination address.
  4. Verify on-chain that the recovered funds have arrived at the expected destination address.
  5. Confirm the recovery ID and wallet ID for the customer's records.
  6. Advise the customer that the issue is resolved and they can proceed with signing future EVM recoveries as needed.

Notes: - This behavior is inherent to how EVM sweeps work — the unsigned transaction sweeps the entire base address balance regardless of which forwarder contributed the funds.

  • Customers should be advised to use different base addresses or complete one recovery before initiating another to avoid this consolidation.

"Your team created two recoveries where the base address is same but using different forwarders. When the second recovery was created, its funds also moved to the base address, making the total $645 in value. Since the unsigned transaction didn't specify an amount and is a sweep of all funds, it fetched the full amount i.e $645 and sent it to the first recovery's destination address." (ticket #242002)

Scenario: recovery-cosign-wrongchain-tool#pending-cosign-request

Trigger: Customer has submitted a recovery and is waiting for BitGo to process or co-sign the recovery transaction.

Signals: recovery ID, co-sign request, cosign, pending recovery, recovery processing

Steps:

  1. Obtain the recovery ID from the customer.
  2. Check the status of the recovery in internal tooling.
  3. If the recovery is queued and no further action is needed from the customer, reassure them that it will be processed shortly.
  4. If the recovery requires additional input or has encountered an error, provide specific guidance based on the error.
  5. Follow up if no response is received — if the customer does not reply, the ticket may be closed as resolved.

Notes: - Many recovery-related tickets in this cluster contain only a title (e.g., "Recovery," "Recovery tool not working," "Co-sign request for wrong-chain recovery") with no further problem detail or resolution detail available. If a customer references one of these older cases, gather fresh information about the current state of the recovery before proceeding.

Related