Scoutinternal

Transactions Stuck in Signed, Pending, or Unconfirmed State

Transactions Stuck in Signed, Pending, or Unconfirmed State

Problem

Customers report that outgoing transactions remain stuck in "signed," "pending," or "unconfirmed" status in the BitGo UI or API, despite time passing or the transaction already being confirmed on-chain. This affects multiple chains including ETH, ARB, SOL, NEAR, STX, HBAR, BTC, LTC, MATIC/Polygon, and OP. The issue manifests as transactions not progressing to "confirmed" in BitGo's system, funds appearing locked, and subsequent transactions being blocked. Common root causes include nonce holes on EVM chains, insufficient gas/fees, indexer lag, circuit breaker triggers, and broadcast failures. In some cases, a transaction reaches the chain but fails on-chain with a "Failed - Transaction Revert" error, which also requires Engineering investigation.

Diagnostics

  • Get the wallet ID and transaction details. Always request the wallet ID and transaction details (transfer ID and/or on-chain transaction hash) from the customer before investigating. Do not attempt to diagnose or resolve the issue without these identifiers.
  • Check transaction state in admin tooling: Use bga wallet sendq commands to see the send queue state (e.g., state=failed, state=held, state=attempted, state=done). Check the error field for specifics.
  • Verify on-chain status: Compare the transaction hash against the relevant block explorer (Etherscan, mempool.space, Arbiscan, etc.). If confirmed on-chain but showing "signed" in BitGo, the issue is an indexer/reindexing problem.
  • Check for on-chain revert: If the block explorer shows the transaction as "Failed" or "Transaction Revert" (i.e., the transaction was broadcast and reached the chain but was reverted by the smart contract or network), this is a distinct failure mode — see the "On-Chain Transaction Revert" scenario below. Do not treat this as a standard stuck/pending issue; escalate to Engineering.
  • Check for nonce holes: Look for the error message "cause": "nonce hole" and message "Ethereum transactions confirm sequentially. There is a missing nonce that is preventing this transaction from confirming." Use bga admin getnonce <address> to compare the on-chain nonce vs. expected nonce.
  • Check fee address balance: Verify the fee address has sufficient native currency (ETH, MATIC, etc.) to cover gas costs. Look for error "insufficient funds in fee address".
  • Check for broadcast errors: Look for errors like "intrinsic gas too low", "Operation failed after multiple attempts and will never succeed", or "Operation failed but may succeed later".
  • Check for circuit breaker: Look for "Breaker triggered: true" on the wallet. Check if the send queue shows state=held.
  • Check velocity/policy limits: Look for velocity limit violations (e.g., "The velocity calculation reached X USD with this transaction, exceeding the enterprise limit").
  • Check wallet whitelist: Look for "The destination address was not whitelisted on the wallet whitelist" in the evaluation details.
  • Check the BitGo status page: Visit https://status.bitgo.com/ for any active incidents affecting the coin's network or BitGo indexers.

Resolution

Scenario: transaction-stuck-transactions-pending#nonce-hole-evm

Trigger: EVM transaction (ETH, ARB, MATIC, OP) is stuck in "signed" status with a nonce hole error indicating a missing sequential nonce.

Signals: nonce hole, Ethereum transactions confirm sequentially, missing nonce, signed state, ETH, ARBETH, POLYGON, OPETH, userActionDisabled

Steps:

  1. Confirm the nonce hole by checking the wallet's pending transactions or using bga admin getnonce <fee_address> to compare on-chain nonce with expected nonce.
  2. If the UI "resolve" buttons are enabled, instruct the customer to fill the nonce hole from the UI by resolving from the bottom of the pending transactions list upward.
  3. If UI resolve buttons are disabled (e.g., multisig wallets), escalate to the engineering team to manually reset the nonce for the fee address to match the chain.
  4. If the nonce hole was caused by a low/zero fee transaction that never confirmed, use the change fee API endpoint (https://api.bitgo.com/docs/#operation/v2.wallet.changefee) to bump the fee on the stuck transaction. Advise the customer to use the current network fee estimate.
  5. Once the nonce-filling transaction confirms, subsequent queued transactions should automatically proceed.
  6. Confirm with the customer that transactions are flowing again. If recurring, inform customer that engineering has implementations in progress to reduce nonce hole occurrences on TSS v2 wallets.

Notes: Nonce holes can be caused by low fees (transaction never gets mined), dropped transactions, or platform issues. Customers should avoid submitting 0 fee transactions. The nonce must be sequential — it cannot be set to an arbitrary higher number. This issue affects all EVM-compatible chains including ETH, ARB, Polygon, and OP.

"the nonce should be sequential so each outgoing withdrawal should have the same sequence of numbers. It seems a nonce issue was created here 487 because of low fees, we raised the fees and the transaction got confirmed, confirming all the transactions stuck after that" "Transactions are getting stuck again, it seems you are initiating 0 transaction fees, these will remain stuck until the fee gets raised, this is the API endpoint to raise the fee https://api.bitgo.com/docs/#operation/v2.wallet.changefee" "Our engineering does have some implementations in the works, that are one of our high priorities, that would resolve most of the issues that the clients are facing due to nonce holes."

Scenario: transaction-stuck-transactions-pending#intrinsic-gas-too-low

Trigger: Transactions stuck in "signed" state with send queue showing error "intrinsic gas too low" and multiple failed broadcast attempts.

Signals: intrinsic gas too low, Operation failed after multiple attempts and will never succeed, arbeth, signed, failed, sendQueue, gas limit

Steps:

  1. Verify the error in the send queue shows "Broadcast result: Operation failed after multiple attempts and will never succeed -- intrinsic gas too low".
  2. Escalate to the engineering team via the #notify-eth-alt-team Slack channel or JIRA to increase the gas limit as a short-term fix.
  3. Engineering will deploy a hotfix to increase the gas limit.
  4. Engineering will mark all affected transfers as failed and reset the nonce for the fee address to match with the chain.
  5. Confirm with the customer that subsequent transactions are going through successfully.

Notes: This was observed specifically on ARB (ARBETH) but could apply to other EVM chains. Root cause is the gas limit reaching 99+% causing the indexer to mark the sendQueue as failed.

"We found that transactions were failing with the error - intrinsic gas too low. Upon debugging, we found that the gas limit was reaching 99+% and our indexer were marking the sendQueue as failed. We deployed a hotfix to increase the gas limit as a short-term measure. We marked all the transfers as failed and reset the nonce for the fee address to match with the chain."

Scenario: transaction-stuck-transactions-pending#indexer-lag-reindex

Trigger: Transaction is confirmed on the blockchain (visible in block explorer) but BitGo UI/API still shows "signed," "pending," or "unconfirmed" status.

Signals: confirmed on chain, unconfirmed in BitGo, zero confirmation, indexer behind, reindex, balance mismatch, STX, LTC, BTC, HBAR, NEAR, SOL

Steps:

  1. Verify the transaction is confirmed on the relevant block explorer.
  2. Use admin tooling to reindex the specific transaction: bga indexer execute INDEX_TRANSACTION <txid>.
  3. Alternatively, resend the indexer broadcast notification to correct the end status to confirmed under the BitGo wallet.
  4. Confirm the transaction now shows as "confirmed" in the BitGo system and that wallet balances match on-chain balances.
  5. If a balance discrepancy persists after reindexing, escalate to engineering to reconcile address balances (they may need to fetch all addresses along with balances and fix the confirmed balance accordingly). For ETH and ALT coin chains, escalate via the #notify-eth-alt-team Slack channel.

Notes: This issue commonly affects STX, HBAR, NEAR, SOL, LTC, and BTC. It can be caused by indexer processing delays, full node connectivity issues, or recent platform maintenance. For BTC, notification indexers may process slowly during security improvements. For HBAR, the indexer may fall behind causing a diff in balance reported via BitGo vs on-chain.

"This transaction was confirmed but we needed to resend the indexer broadcast notification to correct the end status to confirmed under the bitgo wallet." "I was able to reindex it successfully, now it should show as confirmed." "Balance should be matching now with chain."

Scenario: transaction-stuck-transactions-pending#circuit-breaker-triggered

Trigger: A large BTC transaction is stuck with send queue state "held" and a circuit breaker notification has been received.

Signals: circuit breaker, held, stuck transaction, video ID verification, large amount, BTC

Steps:

  1. Check if the wallet shows "Breaker triggered: true" and the send queue shows state=held.
  2. Inform the customer that a circuit breaker was tripped due to the transaction size, and a video ID verification call is required to release it.
  3. The customer will need a valid government-issued photo ID for the call.
  4. Schedule or initiate a video call with the customer (Google Meet or similar).
  5. After successful identity verification, release the transaction by updating the send queue: bga wallet sendqupdate held pending.
  6. Reset the circuit breaker: bga wallet update triggeredCircuitBreaker false.
  7. Confirm with the customer that the transaction has been broadcast to the blockchain.

Notes: This applies to custody wallets with large outgoing transactions that exceed internal thresholds. The customer typically already knows about this process and may proactively request the video KYC call.

"It appears you have a stuck transaction on your account. We will need to meet with you over a video ID verification call in order to release it. You will need a valid government issued photo ID for this call."

Scenario: transaction-stuck-transactions-pending#low-fee-btc-unconfirmed

Trigger: BTC transactions remain unconfirmed/pending on-chain due to low fee rates during periods of high network congestion.

Signals: stuck, pending, unconfirmed, BTC, low fees, mempool, accelerate, fee too high, no descendent unspent found

Steps:

  1. Check the current Bitcoin mempool fee rates at https://mempool.space/ to confirm fees are elevated.
  2. Advise the customer to accelerate the transaction via the BitGo UI: navigate to the wallet, then under "stuck transactions" click the accelerate button.
  3. If the customer encounters "fee too high" errors when accelerating, check if a hotfix has been deployed and ask them to retry.
  4. If the customer encounters "no descendent unspent found that belongs to this wallet" error, advise them to try accelerating the oldest stuck transaction first.
  5. If acceleration via UI fails, the customer can use the API endpoint: POST /api/v2/btc/wallet/{walletId}/acceleratetx with cpfpTxIds (transaction hash, not transfer ID), cpfpFeeRate, and walletPassphrase.
  6. If all acceleration attempts fail, escalate to engineering.

Notes: The accelerate endpoint requires the transaction hash (not the BitGo transfer ID). Consolidation transactions may have specific limitations with acceleration. During prolonged high-fee periods, customers should ensure appropriate fee estimation when initiating transactions.

"2- error from API: IMS service returned error status 400: "no unconfirmed transaction 654447cc8059bb0007e6973c53925738", requestId=cloo0nncvjtxo07zq0odn6zah You need to specify the transaction hash which this one not the transfer id" "Transactions are unconfirmed due to low fees, the fees are quite high at the moment https://mempool.space/ You are able to accelerate them if needed via UI, by going into the wallet, then under 'stuck transactions' you can accelerate them."

Scenario: transaction-stuck-transactions-pending#near-sol-broadcast-timeout

Trigger: NEAR or SOL transactions are stuck in "signed" status due to broadcast failures or full node connectivity timeouts.

Signals: NEAR, SOL, signed, timed out, expired, broadcast, full node

Steps:

  1. Check the send queue for broadcast errors or timeout messages.
  2. Escalate to the engineering team to determine if the transaction can be pushed to the network or needs to be marked as failed.
  3. Engineering will either reindex confirmed transactions or mark expired/unreachable transactions as failed.
  4. Inform the customer which transactions were confirmed vs. which failed due to expiry so they can re-initiate the failed ones.
  5. If recurring, check for known indexer issues on the status page at https://status.bitgo.com/.

Notes: NEAR transactions can expire if not broadcast within a certain time window. SOL transactions can also expire. Some transactions may succeed on-chain but need reindexing to update BitGo status. If the issue is a platform-wide indexer problem, there may be a known incident on the status page.

"I see these transactions timed out trying to connect to our full node, since we had issues with Near indexer in the last few days." "the OP transactions are confirmed and SOL transaction has expired. There was uncategorised error during broadcasting which has been fixed by the team to avoid this persisting in future."

Scenario: transaction-stuck-transactions-pending#whitelist-velocity-policy-block

Trigger: Transaction fails immediately with a policy violation error such as destination not whitelisted or velocity limit exceeded.

Signals: not whitelisted, velocity limit, enterprise limit, policy violation, denied, ErrorID

Steps:

  1. Look up the Evaluation ID in the admin tooling to identify which policy was triggered.
  2. If the destination address is not whitelisted: Instruct the customer to add the receiving address to their wallet whitelist. Provide the exact address that needs whitelisting.
  3. If a velocity limit was exceeded: Inform the customer that their transaction exceeded the configured enterprise or wallet velocity limit (e.g., USD amount over a time window). They may need to wait for the velocity window to reset, or an enterprise admin can adjust the policy.
  4. If the customer has a whitelist policy but no second admin to approve non-whitelisted sends: Advise them to either add the address to the whitelist or add a second admin to approve the transaction.

Notes: The requirement for admin approvals is effective only when combined with spending limits, whitelist policies, and/or approval for all outgoing transactions. A wallet with only an admin policy but no spending/whitelist policy will not trigger approvals.

"The destination address was not whitelisted on the wallet whitelist." "The requirement for multiple admin approvals is effective only when combined with spending limits, whitelist policies, and/or approval for all outgoing transactions. Since your wallet currently lacks any policy except the admin policy, this condition is not applicable."

Scenario: transaction-stuck-transactions-pending#utxo-insufficient-funds

Trigger: BTC wallet shows "Insufficient Funds" error immediately after a prior transaction, even though the overall balance appears sufficient.

Signals: insufficient funds, 0 balance, UTXO, unspents, BTC, spendable, unconfirmed

Steps:

  1. Explain to the customer that this is caused by UTXO (Unspent Transaction Output) mechanics — their unspents are currently tied up in unconfirmed transactions.
  2. Advise the customer to use the List Wallet Unspents endpoint (https://developers.bitgo.com/api/v2.wallet.unspents) to view available unspents.
  3. To prevent this in the future, suggest:
    • Use the Fanout endpoint (https://developers.bitgo.com/api/express.wallet.fanoutunspents) to split larger unspents into smaller ones for higher transaction volume.
    • Use the Send Many endpoint (https://developers.bitgo.com/api/express.wallet.sendmany) to batch multiple recipients into a single transaction.
  4. If the customer needs to send immediately, they must wait for the previous transaction to confirm (typically ~10 minutes for BTC) so the change output becomes spendable.

Notes: A transaction can only consume a maximum of 200 unspents. If a wallet has many tiny unspents, the sum of the top 200 may not cover the desired send amount. Conversely, very few large unspents mean the change is locked until confirmed.

"You are encountering this issue because of the unspents on your wallet and how they behave with regards to confirmed versus spendable balance and confirmed vs unconfirmed transactions."

Scenario: transaction-stuck-transactions-pending#liveness-check-platform-delay

Trigger: Transaction stuck in pending approval state due to a liveness verification issue or platform-wide transaction processing delay.

Signals: liveness verification, pending approval, platform delay, status page, pendingApproval

Steps:

  1. Check the transaction state — if it shows pendingApproval, verify if a liveness check is blocking it.
  2. Check https://status.bitgo.com/ for any active platform-wide incidents affecting transaction processing.
  3. If the liveness check feature has a known bug, escalate to engineering (via Slack to the ProdOps team).
  4. Offer the customer the option to wait for an engineering fix, or to re-initiate the transaction (in which case the stuck one will be rejected).
  5. Once the platform issue is resolved, advise the customer to re-trigger transactions. Confirm resolution.

Notes: Platform-wide delays may affect multiple customers simultaneously. Always check the status page first. For custody/trust wallets, the Trust team may need to be involved in releasing transactions. Do NOT tell customers their transaction is "waiting for trust signing" — this is not a standard transaction state. If a transaction is genuinely held pending trust review, the Trust team will communicate directly with the customer; support agents should not characterize the hold this way without explicit confirmation from the Trust team.

"It seems that it is an issue with our liveness check feature. Your options are, wait for a resolution from our engineering team or reinitiate your test transaction and we will reject the stuck one."

Scenario: transaction-stuck-transactions-pending#on-chain-transaction-revert

Trigger: A transaction was broadcast to the blockchain but failed on-chain with a "Failed - Transaction Revert" error (visible on the block explorer as a failed/reverted transaction).

Signals: Failed - Transaction Revert, transaction revert, reverted on chain, failed on chain, on-chain failure, txn failing on chain

Steps:

  1. Confirm the on-chain failure by looking up the transaction hash on the relevant block explorer (e.g., Etherscan, Polygonscan, Tronscan). The transaction will show as "Failed" with a revert reason.
  2. Note the revert reason if displayed on the block explorer (e.g., out of gas, smart contract assertion, insufficient allowance). This helps Engineering diagnose the root cause.
  3. Do NOT attempt to reindex or rebroadcast a reverted transaction — it has already been processed by the chain and will not change state.
  4. Escalate to the Engineering team immediately, providing:
    • The wallet ID
    • The on-chain transaction hash
    • The full error string (e.g., "Failed - Transaction Revert") as shown on the block explorer
    • The coin/chain affected
  5. Inform the customer that the transaction failed on-chain due to a revert and that Engineering is investigating. The customer should not retry until Engineering confirms the root cause and provides guidance.
  6. Once Engineering identifies the cause (e.g., a contract interaction issue, gas estimation error, or platform bug), they will advise whether the transaction can be retried and whether any platform-side fix is needed.

Notes: A "Transaction Revert" is an on-chain failure — the transaction was included in a block but the EVM (or equivalent) rolled back its state changes. This is distinct from a transaction that never reached the chain (broadcast failure) or one that is simply unconfirmed. Gas fees are still consumed in a revert. This error requires Engineering investigation; support agents should not attempt to resolve it independently.

"txn on chain is failing with this error Failed -Transaction Revert> [escalated to engineering]"

Related