Scoutinternal

Solana, Polygon, and Multi-Chain Deposit/Withdrawal Failures and Delays

Solana, Polygon, and Multi-Chain Deposit/Withdrawal Failures and Delays

Problem

Customers report that deposits are not appearing in their BitGo wallets (UI or API), withdrawals are failing before broadcast, or transactions are stuck in a signed/pending state for extended periods. This affects multiple chains — most commonly Solana (SOL/TSOL), Polygon (POLYGON/USDT), but also ETH, BTC, TRX, LTC, EOS, and STX. Symptoms include: confirmed on-chain transactions not reflected in BitGo, withdrawal transactions failing with "Blockhash not found" or "Node is behind" errors, flush forward failures on EVM chains, delayed indexer processing (hours-long gaps), balance/spendable discrepancies, and mislabeled transaction types.

Diagnostics

  • Check the BitGo status page at https://status.bitgo.com/ for any active or recently resolved incidents affecting the relevant chain's indexer or nodes.
  • Use the BitGo admin tool (bga) to look up the transaction hash and check its state:
    • ✓ in block chain vs ✘ not in block chain — confirms whether the transaction is on-chain.
    • in send queue: state=failed or state=attempted or state=abandoned — reveals whether the transaction failed to broadcast or is stuck.
    • wallet transfer records — check if the transfer is confirmed, failed, or signed.
  • Inspect the error message in the send queue output. Key error strings that distinguish root causes:
    • Blockhash not found → SOL blockhash expiry / node lag
    • Node is behind by X slots → SOL node synchronization issue
    • Retry limit of 100 reached without confirmation of success or failure → SOL broadcast timeout
    • NonceTooLowError → EVM nonce conflict from concurrent requests
    • Broadcast result: OK but ✘ not in block chain → EVM gas price too low, transaction pending in mempool
    • IMS service returned error status 400: "Request to the node failed" → SOL node outage
    • Tx outputs does not match with expected txParams recipients → incorrect API payload parameters
    • Wallet pending on-chain initialization → wallet not initialized on-chain
    • Failed to fetch details for address → destination address does not exist on-chain
  • Compare on-chain balance vs. BitGo balance: If spendable balance is higher than confirmed balance, or the total does not match the blockchain explorer, a resync may be needed.
  • Check the wallet's fee address / gas tank activity on the relevant block explorer (e.g., Polygonscan) to see if flush forwards or create-forwarder transactions are failing.
  • For deposits not appearing: Verify the transaction is confirmed on the chain's block explorer. If confirmed on-chain but missing in BitGo, suspect an indexer delay or missed indexing event.
  • For EVM sequence ID issues: Use bga admin getnonce <feeAddress> and compare the internal nonce to the on-chain nonce on the block explorer.

Resolution

Scenario: sol-solana-deposit-deposits#indexer-delay-deposits-not-appearing

Trigger: A deposit is confirmed on the blockchain explorer but does not appear in the BitGo UI, API transfer list, or wallet reports — across any chain (SOL, ETH, BTC, TRX, LTC, EOS, Polygon, STX).

Signals: deposit not reflecting, missing deposit, transaction not appearing, indexer delay, confirmed on-chain but not in BitGo, reindex, flush forward not functioning

Steps:

  1. Verify the transaction is confirmed on the relevant blockchain explorer (Solscan, Etherscan, Polygonscan, Tronscan, etc.).
  2. Use the BitGo admin tool to look up the transaction hash. If it shows ✘ not in send queue, incoming transaction? and zero wallet transfer records, the transaction was missed by the indexer.
  3. Reindex the transaction using the admin tool. After reindexing, verify the transfer record shows as confirmed.
  4. If multiple transactions are affected or the indexer is behind (hours of delay), escalate to the Engineering team via the internal ETH-Alt or relevant chain Slack channel, noting the chain, approximate delay duration, and example transaction hashes.
  5. If Engineering confirms an indexer issue, a fix will typically be deployed server-side. Monitor the status page at https://status.bitgo.com/ for incident updates.
  6. After the indexer issue is resolved, ask the customer to verify the transaction now appears in their wallet. If they are checking via wallet reports, advise them to generate a new report.

Notes: This is the single most common root cause across all chains. It has been observed for SOL, ETH (including ERC-20 tokens like USDC, SHIB, NU), TRX (including TRC-20 USDT), BTC, LTC, EOS, Polygon, and STX. Root causes on the backend have included socket exception errors on the indexer, node memory increases, and nodes drifting behind chain-head. After reindexing or an Engineering fix, the customer may also need to clear browser cache or regenerate reports.

"We have reindexed the transaction and it is confirmed now." "Yes, we experienced a delay in our SOL indexer but this has since been resolved." "our engineering team advised the delay was caused by a slight delay in our TRX indexer and they confirm that now it's fixed and the indexer is at chain-head."

Scenario: sol-solana-deposit-deposits#sol-blockhash-not-found-withdrawal-failure

Trigger: A Solana withdrawal fails with the error "Transaction simulation failed: Blockhash not found" or "Node is behind by X slots" in the send queue.

Signals: Blockhash not found, SOL withdrawal failed, TSOL failed, Node is behind, broadcast failure, Solana send failed, state=failed

Steps:

  1. Confirm the failure by looking up the transaction hash in the admin tool. Look for state=failed with error containing Blockhash not found or Node is behind.
  2. Advise the customer that "Failed" is a final state for SOL transactions and the transaction cannot be rebroadcasted. The customer must reinitiate the transaction.
  3. If the issue is isolated (one or two failures), it is likely due to a transient node lag where the SOL blockhash expired within its ~1-minute validity window. Ask the customer to retry.
  4. If the issue is persistent (multiple consecutive failures), escalate to Engineering. Known fixes have included:
    • Reverting a Solana node version upgrade.
    • Changing how BitGo builds SOL transactions.
    • Enabling SOL durable nonce for the customer's enterprise (a longer-lived nonce mechanism that avoids blockhash expiry).
  5. For customers who experience recurring SOL broadcast failures, discuss enabling durable nonce with Engineering. Once enabled at the enterprise level, SOL transfers should no longer fail due to blockhash expiry.

Notes: This issue has been seen on both mainnet SOL and testnet TSOL. SOL blockhashes expire within approximately 60 seconds. If the node is even slightly behind, the transaction may fail to simulate. Durable nonce is the long-term fix for enterprises with high SOL transaction volume.

"We were facing intermittent issue with SOL withdrawals since we had upgraded node version. We have reverted the node version now and things seem to be better since then." "We have fixed this issue for SOL and you should no longer encounter transfer failure with this error." "Closing this out as SOL durable nonce has been enabled for your enterprise."

Scenario: sol-solana-deposit-deposits#sol-tss-signing-failure

Trigger: SOL transaction requests enter state TransactionRequestState.FAILED during the TSS signing process, before broadcast.

Signals: TSS transaction request, state FAILED, signing failure, failed while being signed, SOL transfers failing in signing

Steps:

  1. Collect the TSS transaction request IDs from the customer.
  2. Escalate to Engineering, providing the wallet ID, enterprise, and failed transaction request IDs.
  3. Engineering will identify the root cause of the signing failure and deploy a fix.
  4. After the fix is deployed, ask the customer to monitor for further failures and reprocess the failed transactions.
  5. Note: A separate but related issue may cause SOL consolidation requests to get stuck in "SIGNED" state. If reported alongside signing failures, mention both issues to Engineering.

Notes: This is distinct from the blockhash-not-found issue. The transaction fails during the TSS signing step before any broadcast attempt.

"Our engineering team found the root cause of the issue and deployed a fix for the issue, can we trouble you to monitor if you see any further issues? you should not see this issue again."

Scenario: sol-solana-deposit-deposits#sol-node-outage-422-400

Trigger: All SOL withdrawals and consolidations fail simultaneously with HTTP 400 or 422 errors, such as "IMS service returned error status 400: Request to the node failed" or "Response status code does not indicate success: 422 (Unprocessable Entity)".

Signals: SOL down, critical, 422 Unprocessable Entity, IMS service returned error status 400, Request to the node failed, all SOL withdrawals failing

Steps:

  1. Check https://status.bitgo.com/ for an active SOL incident. If one exists, share the status page link with the customer.
  2. If no incident is posted, escalate immediately to Engineering as a critical SOL outage.
  3. Engineering will diagnose the node/indexer issue. Known causes have included indexer failures and node outages.
  4. Once the fix is applied, confirm with the customer that SOL transactions are processing again.

Notes: These outages tend to be brief (hours) and affect all SOL wallets platform-wide, not just a single customer.

"We had a brief issue with our indexer which has been addressed. We are monitoring and will provide further update as soon as possible." "we updated the status page, please check here for updates https://status.bitgo.com/incidents/rykgy335x799"

Scenario: sol-solana-deposit-deposits#polygon-deposit-withdrawal-delay-node-drift

Trigger: Polygon deposits take 1-2+ hours to appear in BitGo despite being fully confirmed on-chain, and/or Polygon withdrawals are stuck in "SIGNED" state for extended periods.

Signals: Polygon delay, USDT:POLYGON, deposits not detected, withdrawals stuck signed, flush forward not functioning, node drift, Polygon network down

Steps:

  1. Check the BitGo status page at https://status.bitgo.com/ for Polygon-specific incidents.
  2. Verify the transaction on Polygonscan. If confirmed on-chain but not in BitGo, it is an indexer/node drift issue.
  3. Escalate to Engineering, noting that Polygon nodes are drifting and providing example transaction hashes and approximate delay duration.
  4. Engineering will address the node synchronization issue. Known root causes have included node memory increases and drifting nodes.
  5. Once resolved, confirm with the customer that deposits are now reflecting and withdrawals are no longer stuck.

Notes: This issue has been observed specifically with USDT:POLYGON deposits as well as native POLYGON transactions. The flush forward and create-forwarder mechanisms may also be impacted during node drift, causing a cascade of stalled deposit processing.

"Our engineering team is working on this, and the nodes are drifting." "This has been resolved. The issue was due to one of our nodes having had an increase in memory."

Scenario: sol-solana-deposit-deposits#polygon-flush-forward-create-forwarder-failure

Trigger: Flush forward transactions on Polygon fail with "Reverted" errors, or the forwarder address is not deployed before the flush is attempted.

Signals: flush forward failing, Polygon, Reverted, create forwarder failed, forwarder not deployed, gas tank

Steps:

  1. Ask the customer for the wallet ID and failed transaction hashes from the gas tank address on Polygonscan.
  2. Check whether the "Create Forwarder" transaction executed successfully before the flush attempt. If the forwarder was not deployed in time (e.g., due to concurrent deposits triggering multiple deploy attempts), the flush will fail.
  3. Escalate to Engineering with the wallet ID, gas tank address, and failed transaction hashes.
  4. Engineering may confirm that a successful deploy transaction exists for the same forwarder address — the failure was a duplicate attempt caused by near-simultaneous deposits. In this case, no action is needed; the funds are safe and will be flushed on the next cycle.
  5. If the forwarder was genuinely not deployed, Engineering will investigate and resolve.

Notes: A "Reverted" error during flush does not mean funds were moved or lost. The wallet rolls back to its previous state. The customer can retry, and the transaction should succeed. Multiple near-simultaneous deposits to the same new address can trigger duplicate create-forwarder attempts; one succeeds and the others revert.

"there was no problem with forwarder address creation and the address was deployed successfully. The forwarder gets deployed when funds are deposited to it, for a transaction that you have shared, there is a successful deploy transaction is already present and the failed one was created due to multiple funds were deposited almost at the same time which resulted in multiple deploy forwarder transactions."

Scenario: sol-solana-deposit-deposits#polygon-nonce-too-low-withdrawal-failure

Trigger: Polygon USDT withdrawals fail with "NonceTooLowError" and the wallet's spendable balance is higher than the confirmed balance.

Signals: NonceTooLowError, Polygon USDT, spendable higher than confirmed, withdrawal failure, concurrent requests, nonce conflict

Steps:

  1. Confirm the error by looking up the failed transaction hash in the admin tool. The error will contain NonceTooLowError.
  2. Escalate to Engineering. The NonceTooLowError occurs because concurrent withdrawal requests cause lower-nonce transactions to be broadcast on-chain even after they have already failed.
  3. For the spendable balance discrepancy, Engineering will resync the affected receive addresses and the wallet's token balance. After resyncing, verify that the spendable balance matches the on-chain balance.
  4. After the fix, ask the customer to retry the withdrawal.

Notes: This is primarily seen with Polygon:USDT but could affect any EVM-based token wallet with high-concurrency send operations.

"There were two errors: NonceTooLowError issue — This is happening because of concurrent requests where we are broadcasting lower nonce value transactions on-chain even though they have failed on-chain. Spendable balance issue — There were a couple of receive addresses with spendable balance issue. Resynced the address and the wallet balance to fix the issue."

Scenario: sol-solana-deposit-deposits#polygon-evm-gas-price-too-low

Trigger: A Polygon transaction shows state=attempted in the send queue with Broadcast result: OK but remains ✘ not in block chain for an extended period. The on-chain nonce has not advanced.

Signals: Polygon transaction stuck, attempted, not in block chain, gas price, pending, signed state

Steps:

  1. Use the admin tool to check the transaction's gasPrice value.
  2. Compare it with the average gas price on Polygonscan for the same time period.
  3. If the transaction's gas price is significantly below the network average, the transaction is simply waiting in the mempool for gas prices to decrease.
  4. Inform the customer that the transaction will eventually process when gas prices drop, or Engineering can manually intervene to accelerate with a higher gas price if urgent.

Notes: This is not a BitGo bug — it is expected EVM behavior when the gas price tier used is below network congestion levels.

"The gas price for this transaction was 75.844661208 Gwei, significantly lower than the average gas price of 166.16390 Gwei during the same period. This discrepancy explains why the transaction was not immediately processed and had to wait until the gas price decreased."

Scenario: sol-solana-deposit-deposits#polygon-evm-sequence-id-out-of-sync

Trigger: Polygon or other EVM withdrawals fail due to high sequence ID / nonce mismatch, often caused by scripts repeatedly calling the build endpoint without completing the send.

Signals: high sequence id, nonce out of sync, Polygon testnet withdrawal fail, sequence ID, build call, programmatic, script

Steps:

  1. Ask the customer if they have any scripts or automation that programmatically call the BitGo build or send endpoints. A build call every few seconds will increment the sequence ID without completing transactions.
  2. Ask the customer to stop the script causing the repeated build calls.
  3. Once the script is stopped, request Engineering to reset the sequence ID for the affected wallet.
  4. After the reset, ask the customer to retry the withdrawal.

Notes: This is the leading cause of sequence IDs falling out of sync. The reset is only effective if the offending script is stopped first; otherwise the problem will recur.

"We are seeing a build call every few seconds which is causing the sequenceID to increment. We are able to reset the sequence ID to unblock you, but if there is a script and it continues to run as it is, this problem will keep occurring."

Scenario: sol-solana-deposit-deposits#sol-sendcoins-tx-outputs-mismatch

Trigger: A call to /api/v2/sol/wallet/{walletId}/sendcoins or /api/v2/sol:usdt/wallet/{walletId}/sendcoins returns the error "Tx outputs does not match with expected txParams recipients".

Signals: Tx outputs does not match with expected txParams recipients, sendcoins, sol, sol:usdt, tokenName, type transfer

Steps:

  1. Review the customer's API request payload.
  2. If the customer is sending native SOL (not an SPL token), advise them to remove the tokenName parameter. SOL is a base coin and not considered a token.
  3. If the customer is sending an SPL token (e.g., sol:usdt), advise them to:
    • Use "type": "transfer" (not "transferToken" — the intent type transferToken is not supported).
    • Pass the USDT Token Account Address for the recipient, not the native SOL account address.
  4. Ask the customer to retry the transaction with the corrected payload.

Notes: The "type": "transfer" value works for both native SOL and SPL token sends. The tokenName parameter should only be used when applicable and should not be set to "sol" for native SOL sends.

"Can you please use the USDT be sure to pass the USDT Token Account Address for recipient instead of the native account address? Additionally, this should work with "type": "transfer" instead of the previous recommendation for 'tokenTransfer'." "Can you please retry this request, but remove the 'tokenName' parameter? SOL is a base coin and not considered a token."

Scenario: sol-solana-deposit-deposits#sol-wallet-no-addresses-initialization-required

Trigger: A Solana wallet shows no receive addresses on the Addresses page in the BitGo UI, and the wallet has a zero balance.

Signals: no addresses, SOL wallet, no address at Solana wallet, initialize, wallet initialization, 0 balance

Steps:

  1. Confirm the wallet has a zero balance.
  2. Advise the customer: Before receive addresses can be created, the SOL wallet must be initialized. They should click "Deposit" on the right-hand side of the wallet page to see the amount needed and the address to send it to.
  3. Once the wallet is funded with the initialization amount, the wallet will be initialized on-chain and the customer can create additional receive addresses.

Notes: This is standard Solana wallet behavior on BitGo, not a bug. The same initialization requirement applies to TRX wallets (which require 100 TRX to initialize on-chain).

"Before you are able to create receive addresses you need to first initialize the wallet. You can do that by clicking on deposit on the right hand-side. You will see there, the amount needed to be sent and the address where you should send it to initialize the wallet."

Scenario: sol-solana-deposit-deposits#sol-failed-to-fetch-details-for-address

Trigger: A SOL withdrawal attempt returns HTTP 400 with error "Failed to fetch details for address : {address}".

Signals: Failed to fetch details for address, SOL, 400, invalid address, account does not exist

Steps:

  1. Check the destination address on the Solana explorer at https://explorer.solana.com/address/{address}.
  2. If the explorer shows "Account does not exist" with no prior transaction activity, inform the customer that BitGo validates destination addresses and prevents transfers to non-existent accounts.
  3. Advise the customer to double-check the destination address with the intended recipient. The address may be a program-owned account or otherwise invalid.

Notes: BitGo performs validations to prevent transfers to non-valid Solana addresses. If the account has never received any SOL and does not exist on-chain, the transfer will be blocked.

"BitGo performs a set of validations to prevent transfers to a non valid address from happening. As we checked on-chain also, it looks like this account does not exist."

Scenario: sol-solana-deposit-deposits#eth-transaction-mislabeled

Trigger: A transaction is labeled as a "deposit" in the BitGo UI or API when it was actually a withdrawal, or vice versa.

Signals: mislabeled, mislabelled, incorrect label, deposit instead of withdrawal, transaction type wrong

Steps:

  1. Collect the transaction hash and wallet ID from the customer.
  2. Escalate to Engineering to manually correct the mislabeled transaction.
  3. Engineering will fix the specific transaction label and investigate the root cause.
  4. A code fix will be deployed to prevent future mislabeling. Ask the customer to monitor and report any further mislabeled transactions.

Notes: This was observed on ETH transactions and was caused by a bug that was fixed and deployed to production.

"We have fixed the mislabel of this transaction and will follow up on an ETA for the root cause by EOD tomorrow."

Scenario: sol-solana-deposit-deposits#deposit-not-on-expected-network

Trigger: A customer reports a missing deposit but the transaction hash cannot be found on the expected blockchain explorer (e.g., Etherscan).

Signals: missing deposit, transaction not found, wrong network, cannot locate on etherscan, which network

Steps:

  1. Attempt to look up the transaction hash on the block explorer for the expected chain.
  2. If the transaction is not found, ask the customer to confirm which network the deposit was sent on (e.g., Ethereum mainnet, Polygon, Tron, BSC, etc.).
  3. If the deposit was sent on a different network than the BitGo wallet supports, advise accordingly — recovery may or may not be possible depending on the chain and address type.

Notes: This is a common miscommunication issue. Always confirm the chain/network before initiating any Engineering investigation.

Scenario: sol-solana-deposit-deposits#deposit-visible-in-ui-not-in-new-ui-view

Trigger: A customer reports that a deposit (e.g., ETH on Optimism) shows as deposited but does not appear in the asset list or balance in the BitGo UI.

Signals: deposit not visible, asset not showing, balance zero, Optimism, classic view, new UI

Steps:

  1. Ask the customer to switch to the "classic view" of the BitGo UI:
    • Step 1: Click on the profile icon in the top right corner.
    • Step 2: Click on "Switch to classic view".
  2. Once in the classic view, check if the asset and balance are visible.
  3. If the asset appears in the classic view, this is a known UI display issue with the newer interface. Report to the product team if not already known.

"Please try accessing the BitGo UI through the Classic view and review if you are able to see the balance... Step 1 :- Click on the profile icon in the top right corner Step 2:- Click on Switch to classic view"

Scenario: sol-solana-deposit-deposits#sol-tsol-testnet-devnet-only

Trigger: A customer asks about creating or using a Solana wallet on testnet (as opposed to devnet).

Signals: TSOL, testnet, devnet, Solana testnet, Ramp.Network

Steps:

  1. Inform the customer that BitGo currently only supports DEVNET for the SOL TestNet environment.
  2. If the customer needs to operate on Solana testnet (e.g., for integration with third-party services that use testnet), advise that this is not currently supported.

Notes: Third-party services such as Ramp.Network may operate on Solana testnet, but BitGo's TSOL environment uses devnet. There is no workaround for testnet on BitGo at this time.

"Unfortunately we only currently support DEVNET for our SOL TestNet Environment."

Scenario: sol-solana-deposit-deposits#wallet-not-in-enterprise

Trigger: A customer reports they cannot see a wallet or deposit on their BitGo dashboard, and the wallet was created outside the enterprise scope.

Signals: wallet not visible, cannot find wallet, deposit not showing, wallet not in enterprise, moved wallet

Steps:

  1. Use the admin tool to check which enterprise the wallet belongs to.
  2. If the wallet is under the user's personal account rather than the enterprise, move it to the correct enterprise.
  3. After moving, advise the customer to search for the wallet in the wallets search bar.

Notes: Wallets created via API without specifying the enterprise may default to the user's personal space and not be visible in the enterprise dashboard.

Scenario: sol-solana-deposit-deposits#sol-pyusd-spl-token-consolidation-failure

Trigger: A customer cannot withdraw or consolidate an SPL token (e.g., SOL:PYUSD) despite having a balance, and consolidation fails.

Signals: PYUSD, SPL token, unable to withdraw, consolidation failed, spendable 0, token not enabled, needsConsolidation

Steps:

  1. Check if the token is enabled on the wallet. Go to the wallet settings page → Tokens → ensure the token is enabled for the root address.
  2. If the token is enabled but spendable balance shows 0, check the needsConsolidation flag on the relevant address using the admin tool. If it is false, set it to true.
  3. Ask the customer to retry the consolidation after the flag is updated.
  4. If consolidation still fails, escalate to Engineering. The issue may relate to unsupported token standards (e.g., Solana Token 2022) that require platform-level support to be built.

Notes: SOL:PYUSD specifically required Solana Token 2022 standard support, which was not initially available. Engineering had to build support for this standard and correct the ATA (Associated Token Account) address before the token could be withdrawn.

"To withdraw the amounts, you first need to enable the token on the wallet by going to the settings page under the wallet, then under tokens, and enable the tokens for the root address."

Scenario: sol-solana-deposit-deposits#btc-ltc-utxo-deposit-missing-entries

Trigger: A BTC or LTC transaction with multiple outputs to addresses in the same wallet shows only some outputs in the transfer entries field when queried via the API, while all outputs appear in the UTXO outputs list.

Signals: missing entries, BTC deposit, LTC deposit, multiple outputs, entries field, UTXO outputs, get transfer endpoint

Steps:

  1. Look up the transfer using the admin tool and verify the entries section. If entries are missing compared to the UTXO outputs, this is a known indexing bug.
  2. Escalate to Engineering with the wallet ID and transaction hash.
  3. Engineering will fix the underlying bug. After the fix, the customer should make a new API call for the transfer, and the missing entries should now appear.

Notes: This was caused by a bug introduced in a platform update that resulted in missing data in the entries section of the transfer response. The UTXO outputs were always correct; only the entries summary was incomplete.

"We experienced an issue due to a bug introduced which resulted in the missing data."

Related

  • wallet-reports — Wallet reports may not show transactions affected by indexer delays until the transaction is reindexed and a new report is generated.
  • keycards-and-private-keys — Wallet initialization steps reference the deposit flow described in the SOL wallet initialization scenario.
  • none identified for Polygon-specific flush forward documentation.