Scoutinternal

Cancelling or Releasing Stuck Transactions on BitGo

Cancelling or Releasing Stuck Transactions on BitGo

Problem

Customers frequently request cancellation or release of transactions that appear stuck or pending on the BitGo platform. These requests span multiple root causes: transactions held by circuit breaker limits requiring video ID verification, transactions pending internal approval that need to be rescinded or rejected, on-chain transactions already broadcast that cannot be cancelled, transactions stuck due to indexer delays or EVM chain issues, and tokens needing manual flushing in cold wallets. The issue affects multiple coins and chains including BTC, ETH, EVM-compatible tokens (e.g., USDT), and SOL.

Diagnostics

  • Identify the transaction state: Use the BitGo admin tool (admin.bitgo.com) to look up the transfer by its BitGo Transaction ID or wallet ID. Check the "state" field — key values are "held", "pendingApproval", "signed", "pending delivery", "confirmed", or "replaced/removed".
  • Check for circuit breaker trips: Run bga wallet sendq held for the wallet in question. If transactions appear with STATE: held, a circuit breaker has been tripped. Also check the wallet details for Breaker triggered: true and note the Breaker reset time.
  • Check pending approvals: Review the wallet's pending approvals in the admin tool. Note how many approvalsRequired are set and which users have already approved or rejected. Check the "resolvers" array in the pending approval object.
  • Check on-chain status: If the customer provides a transaction hash, verify on-chain via mempool.space (BTC) or etherscan.io (ETH/EVM). If the transaction is visible on-chain with confirmations, it cannot be cancelled.
  • Check for platform-wide issues: Review https://status.bitgo.com/ for any ongoing incidents affecting indexers or EVM-compatible chains.
  • Identify wallet type: Determine if the wallet is hot, cold, or custody. Cold wallets with stuck tokens (e.g., USDT) may need manual flushing by engineering.
  • Check if TSS transaction request: For TSS wallets, look for a txRequestId and check its status (e.g., "pending delivery"). The cancellation path differs from standard transactions.

Resolution

Scenario: cancel-transaction-stuck-cboe#circuit-breaker-held

Trigger: Transaction state is "held" because a circuit breaker (daily velocity/amount limit) was tripped on the wallet.

Signals: held, circuit breaker, tripped, stuck, daily limit, maximum limit, schedule a call, video confirmation, video ID verification

Steps:

  1. Confirm the transaction is in held state by running bga wallet sendq held for the wallet. Note the TXID(s) and value(s).
  2. Inform the customer that a video ID verification call is required to release the held transaction. The customer will need a valid government-issued photo ID.
  3. Ask the customer when they are available to meet. When ready, generate a Google Meet link and share it with the customer via the ticket.
  4. During the video call, verify the customer's identity against the authorized users on the wallet.
  5. After successful verification, release the held transaction(s) using internal tooling.
  6. If the customer wants to cancel a held transaction instead of releasing it, use internal tooling to fail the transaction. Note: if a second transaction is stuck behind the first, you will still need to meet with the customer to clear the second one.
  7. Confirm with the customer that the transaction has been released or failed as requested.
  8. If the customer asks about increasing or removing the transaction limit, loop in the account management team (e.g., their assigned relationship manager) to assist with limit changes.

Notes: Circuit breaker releases are time-sensitive for enterprise customers who may need to meet external deadlines. Multiple transactions may queue behind a single held transaction — all must be addressed. Failing one held transaction does not automatically release subsequent held transactions.

"We were able to fail it, but we would still need to meet to clear the second transaction that got stuck because of it. Please let me know when you are available to meet." (ticket #321310)

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

Scenario: cancel-transaction-stuck-cboe#pending-approval-rescind

Trigger: Transaction is in "pendingApproval" state and requires one or more enterprise approvers to approve or reject before it proceeds.

Signals: pendingApproval, pending approval, rescind, reject, cancel, approver, approvalsRequired, transaction requests

Steps:

  1. Confirm the transaction is in "state": "pendingApproval" via admin tooling.
  2. Identify the required number of approvals ("approvalsRequired") and which users have already approved.
  3. Advise the customer that the transaction can be cancelled by having an approver who has not yet approved the transaction use the Reject option in the UI under the wallet's Transaction Requests section.
  4. If the initiator has not yet approved, they can also Rescind the request from the UI. However, once the initiator has approved, only another approver who has not yet approved can reject.
  5. If the customer encounters UI errors when trying to rescind or reject, escalate to engineering via JIRA. In the interim, support can attempt to fail the pending transfer using internal tooling after confirming with engineering.
  6. Pending approvals are automatically cancelled after 30 days due to inactivity if no action is taken.

Notes: An approver can still reject a withdrawal even after having previously approved it, as long as the required number of approvals has not been fully met and the transaction has not been broadcast. If video verification is also required as a step, the transaction will expire after 30 days if the video is never completed.

"The initiator can actually cancel as well but for this withdrawal, 2 approvals is required and you have already approved it (first approval), so the Rescind option is no longer available for you, and only the 2nd approver (Harrison in this case) can reject." (ticket #266161)

"Pending approvals are automatically cancelled after 30 days due to inactivity." (ticket #266161)

"I see that Thiago submitted this transaction. Are they not able to rescind it from the UI? This transaction should show up in the Transaction Requests under the wallet." (ticket #316864)

Scenario: cancel-transaction-stuck-cboe#already-confirmed-on-chain

Trigger: The transaction has already been broadcast to the blockchain and has confirmations, or has completed successfully.

Signals: confirmed, completed, successfully, on-chain, cannot be cancelled, broadcast, confirmations

Steps:

  1. Verify the transaction status on-chain using the appropriate block explorer (e.g., mempool.space for BTC, etherscan.io for ETH).
  2. If the transaction shows confirmations or is confirmed, inform the customer that the transaction cannot be cancelled once it has been broadcast and confirmed on-chain.
  3. If the transaction is on-chain but unconfirmed (0 confirmations, pending in mempool), advise the customer that BitGo is unable to cancel transactions once they are being seen on-chain pending confirmation, as this can result in a double-spend. Suggest the customer look to accelerate the transaction within the BitGo UI.
  4. For FTX creditor withdrawal transactions that have completed, confirm via admin tool (e.g., TAT — Transfer Admin Tool) that the transaction was successful and inform the customer it cannot be reversed.

Notes: This is the most common scenario. Blockchain transactions are irreversible once confirmed. Even unconfirmed transactions visible in the mempool cannot be safely cancelled by BitGo due to double-spend risk.

"We are unable to cancel transactions once they are being seen on-chain pending confirmation. This can result in a double-spend as we have no way to guarantee the transaction we cancel on our platform will not still be confirmed. You can look to accelerate the transaction within our UI." (ticket #223922)

"Once the transaction is initiated, it cannot be canceled later." (ticket #221973)

Scenario: cancel-transaction-stuck-cboe#indexer-delay

Trigger: Transaction is stuck due to a BitGo-side indexer delay, not a blockchain issue. The transaction has been signed but not broadcast.

Signals: indexer delay, stuck, not broadcast, signed, pending, EVM, EVM-compatible chains

Steps:

  1. Check https://status.bitgo.com/ for any ongoing incidents related to indexer delays or EVM-compatible chain issues.
  2. Inform the customer that the stuck transaction is a result of an indexer delay on the BitGo side.
  3. Advise the customer that cancelling this transaction will not help — a new transaction will experience the same issue.
  4. Escalate to engineering if the issue is not already being tracked. Monitor the status page for resolution.
  5. Once engineering resolves the indexer issue, the transaction should be broadcast automatically. Confirm with the customer by sharing the on-chain transaction link.

Notes: This scenario was observed for both BTC and EVM-compatible chains. Do not cancel and re-create transactions during indexer delays as the replacement will also be stuck.

"This issue is a result of an indexer delay we are experiencing. As a result, cancelling this transaction will not allow you to build and send a new withdrawal request. That new transaction will also experience the same issue as this one." (ticket #247600)

"The stuck transaction is due to the ongoing issue with EVM- compatible chains. Our engineering team is currently working to resolve this issue." (ticket #268801)

Scenario: cancel-transaction-stuck-cboe#bulk-pending-approval-cancellation

Trigger: Customer has a large number of pending approval transactions that need to be cancelled in bulk, which is impractical to do one-by-one in the dashboard.

Signals: bulk, cancel all, too many, pending approval, one by one, internal incident

Steps:

  1. Confirm the wallet ID and ask the customer to verify they want all pending approval transactions cancelled (including any older ones).
  2. Once confirmed, escalate to engineering or use internal tooling to bulk-cancel all pending approval transactions on the wallet.
  3. Verify via spoofing/admin tooling that no pending approval transactions remain.
  4. Inform the customer and ask them to verify on their end.

Notes: Customers cannot bulk-cancel pending approvals from the UI — they must do them one by one. Support or engineering intervention is needed for bulk operations.

Scenario: cancel-transaction-stuck-cboe#cold-wallet-token-flush

Trigger: Tokens (e.g., USDT) appear stuck in a cold wallet and the spendable balance is not synced, typically requiring a manual token flush.

Signals: stuck, cold wallet, USDT, token, flush, spendable, flushing, ETH cold

Steps:

  1. Look up the wallet in admin tooling and confirm it is a cold wallet. Check the base address on etherscan.io or the relevant block explorer.
  2. Verify the token balance vs. spendable balance. If the spendable amount is not reflecting the full token balance, a manual flush is likely needed.
  3. Perform a manual token flushing on the BitGo backend.
  4. After flushing is complete, verify that the spendable balance is synced and inform the customer.

Notes: This scenario applies to ERC-20 tokens (and similar) on cold wallets. The customer may describe the situation as a "stuck transaction" when it is actually a balance sync / flush issue.

"We have completed the flushing. Spendable amount should be synced." (ticket #230028)

Scenario: cancel-transaction-stuck-cboe#tss-pending-delivery

Trigger: A TSS transaction request is in "pending delivery" state — signing did not complete — and the customer wants it cancelled.

Signals: TSS, txRequestId, pending delivery, signing, cancel, transaction request

Steps:

  1. Ask the customer for the txRequestId and walletId. Locate the transaction request in the admin tool or UI (it may appear under a cancelled/rejected tab once actioned).
  2. Advise the customer to use the API endpoint to cancel the request: https://developers.bitgo.com/api/v2.wallet.txrequest.update
  3. If the API endpoint is returning errors, escalate to engineering — a fix may need to be deployed. Track via JIRA.
  4. Once the request is cancelled, confirm with the customer that it shows as cancelled in both the UI and via API (ensure they are retrieving the latest result with latest: true).

Notes: TSS transaction requests that fail during signing remain in "pending delivery" state. The standard pending approval reject/rescind flow does not apply — the customer must use the txRequest update API.

"We see the status of this tx request is - pending delivery. If you wish to cancel this, please use this API endpoint - https://developers.bitgo.com/api/v2.wallet.txrequest.update" (ticket #318682)

Scenario: cancel-transaction-stuck-cboe#low-fee-stuck-unconfirmed

Trigger: Customer submitted a transaction with a very low or zero fee, and it is stuck unconfirmed in the mempool.

Signals: low fee, zero fee, 0 fee, unconfirmed, mempool, stuck, accelerate, bump fee, sats/vB

Steps:

  1. Verify the transaction on mempool.space (BTC) or the relevant block explorer. Confirm it is unconfirmed with 0 confirmations.
  2. BitGo cannot cancel transactions once they are visible on-chain in the mempool due to double-spend risk.
  3. Advise the customer to use the accelerate transaction feature within the BitGo UI to bump the fee (RBF / Replace-by-Fee for BTC).
  4. If the transaction eventually gets replaced or dropped from the mempool, it may show as replaced/removed in BitGo's system. Confirm this status with the customer.
  5. For ETH/EVM transactions stuck pending, the customer can attempt acceleration via the UI. A pending approval state may appear for the acceleration — the customer should approve it.

Notes: Some low-fee transactions may eventually confirm on their own if the mempool clears. The transaction in ticket #231129 with 0 fee ultimately confirmed without intervention. If the transaction is replaced/removed by the network, BitGo will reflect that state automatically.

"We see the reported transaction is in replaced/removed state." (ticket #251444)

"We see the accelerated transaction is in a Pending approval state currently." (ticket #256446)

Scenario: cancel-transaction-stuck-cboe#engineering-fail-pending-transfer

Trigger: A transfer is stuck in "pendingApproval" state for an extended period (weeks/months) and cannot be resolved via the UI — engineering must manually fail it.

Signals: pendingApproval, long pending, months, fail, engineering, manual

Steps:

  1. Confirm the transfer ID and wallet ID with the customer.
  2. Verify via admin tooling that the transfer is in "state": "pendingApproval" with "confirmations": 0 and "height": 999999999 (indicating it was never broadcast).
  3. Confirm with the customer that the transaction should be failed (not executed).
  4. Refer the request to the engineering team to manually fail the pending transfer.
  5. Once engineering confirms the transfer has been failed, ask the customer to verify the status shows as "failed" in both the UI and via API.

Notes: This is a last-resort path for transfers that are stuck in pendingApproval and cannot be actioned through normal approval/rejection workflows. Always confirm with the customer that they want the transfer to be cancelled/failed and not executed.

"We failed the pending transfer. Can you please check again and let us know if you see it as failed on your end as well?" (ticket #220215)

Related