Scoutinternal

Transactions Stuck in 'Signed' State — Not Broadcasting to the Blockchain

Transactions Stuck in "Signed" State — Not Broadcasting to the Blockchain

Problem

Customers report that transactions appear with a status of "signed" in the BitGo UI or API but are never broadcast to the blockchain network. The transaction hash may be returned successfully, yet the transaction does not appear on-chain (e.g., on Etherscan, Solscan, or other block explorers). This issue has been observed across multiple chains including BTC, ETH, ERC-20 tokens (such as USDC), GTETH, XLM, SOL, TRON (TRX), and Polygon. In some cases the status eventually resolves on its own after a delay; in others, manual intervention or an engineering fix is required.

Diagnostics

  • Identify the coin/chain: Ask the customer which coin or token is affected. The root cause and resolution path differ by chain (e.g., ETH nonce issues vs. BTC send-queue delays vs. XLM indexer problems).
  • Collect transaction details: Request the wallet ID, BitGo transfer ID, and the on-chain transaction hash (if one was returned).
  • Check the internal admin tool (bga t <txhash>): Run the transaction lookup to determine:
    • Whether the transaction is in block chain or not in block chain.
    • The send queue state (e.g., state=done, state=attempted, state=pending).
    • The number of broadcast attempts and any error messages (e.g., insufficient funds for gas, SIGERROR, Broadcast result: OK but still not confirmed).
    • Whether wallet transfer records show status signed, confirmed, or failed.
  • Check the fee/gas address balance: For ETH and ERC-20 wallets, verify whether the fee address (gas tank) has sufficient ETH. An empty or underfunded fee address is a common cause.
  • Check for nonce holes (ETH/EVM chains): Look in the BitGo UI under the Pending Transactions tab for any nonce hole notifications. A stuck lower-nonce transaction will block all subsequent transactions.
  • Check the BitGo status page: Visit https://status.bitgo.com/ for any active incidents affecting transaction broadcasting or indexer delays on the relevant chain.
  • Check if the transaction actually confirmed on-chain: Sometimes the on-chain state is confirmed but the BitGo internal state has not been updated (indexer lag). Compare the hash on the relevant block explorer (e.g., Etherscan, Solscan) against the BitGo transfer status.
  • Check for on-chain revert: If the block explorer shows the transaction as "Failed" or "Transaction Revert", the transaction reached the chain but was reverted. This is distinct from a broadcast failure — do not attempt to rebroadcast. Escalate to Engineering with the wallet ID, transaction hash, and the full error string.
  • Check broadcast error details: In the bga t output, look for specific error strings such as insufficient funds for gas * price + value, SIGERROR Validate signature error, or expecting array of recipients of size 1.

Resolution

Scenario: signed-stuck-transactions-state#platform-side-broadcast-delay

Trigger: Transactions are stuck in "signed" state for 10–20+ minutes but eventually confirm, or multiple customers on the same chain report simultaneous delays, and/or there is an active incident on status.bitgo.com.

Signals: signed, stuck, delayed, multiple customers affected, status page incident, send queue state=attempted, BTC, ETH, indexer delay

Steps:

  1. Check https://status.bitgo.com/ for any active or recent incidents related to the affected chain (e.g., BTC transaction signing delays, ETH indexer issues).
  2. If an incident is active, inform the customer and share the status page link so they can subscribe for updates.
  3. If no incident is posted but multiple customers report the same issue on the same chain, escalate to the engineering team for the affected chain via the appropriate internal Slack channel (e.g., #notify-eth-alt-team for ETH and ALT coin chains) or JIRA.
  4. Once engineering confirms the fix, notify the customer and ask them to verify their transactions now show the correct on-chain status.

Notes: This scenario covers platform-wide issues such as indexer delays where the transaction is confirmed on-chain but BitGo's internal state has not updated. It also covers send-queue processing backlogs. The customer does not need to take action — this is resolved server-side by engineering.

"Both transactions should be confirmed now. We are currently experiencing a delay in updating the transaction to the final state to match on chain. Please follow our status page updates here https://status.bitgo.com/incidents/dbj6m9528nhx" "Our engineering team resolved the issue, can you monitor the transactions now and let us know if you are still seeing any issues?" "We have fixed the issue and all transactions should be on the chain now."

Scenario: signed-stuck-transactions-state#insufficient-gas-fee-address

Trigger: The ETH or ERC-20 transaction is stuck in "signed" and the broadcast error indicates insufficient funds for gas, or the fee address balance is zero/near-zero.

Signals: signed, not broadcasted, ETH, ERC-20, insufficient funds for gas, gas tank, fee address, empty fee address, insufficient balance

Steps:

  1. Use bga t <txhash> to confirm the broadcast error. Look for: Operation failed but may succeed later -- insufficient funds for gas * price + value.
  2. Look up the wallet's fee address on Etherscan (the fee address can be found in the wallet details in the admin tool under feeAddress).
  3. Inform the customer that their fee address (gas tank) does not have sufficient ETH to cover gas costs.
  4. Ask the customer to deposit ETH into the fee address. Provide the specific amount needed if visible from the error (e.g., "please deposit at least 1.15 ETH").
  5. Once the fee address is funded, the pending transactions should begin broadcasting automatically. Ask the customer to confirm.
  6. Optionally, share ETH fee management resources:

Notes: For ETH, gas fees are highest between 2 and 6 PM UTC. Best times for lower fees are early morning (1:00–2:00 UTC) or late night (9:00–11:00 UTC). This applies to both manual withdrawals and automated flushing operations.

"It seems you don't have funds in your gas tank https://etherscan.io/address/[ETH_ADDRESS] Can you please add some funds to your fee address, once the address is funded, transactions should start flowing again." "The pending transactions are currently stuck due to insufficient ETH to cover both the transaction amount and the associated gas fees. To proceed, please deposit at least 1.15 ETH into the wallet."

Scenario: signed-stuck-transactions-state#eth-nonce-hole

Trigger: An ETH/EVM transaction is stuck in "signed" or "attempted" state, and the Pending Transactions tab in the BitGo UI shows a nonce hole notification or an earlier pending transaction is blocking newer ones.

Signals: nonce hole, nonce issue, pending transactions, ETH, Polygon, EVM, signed, attempted, resolve button, sequential nonce

Steps:

  1. Instruct the customer to navigate to their wallet in the BitGo UI and open the Pending Transactions tab.
  2. Look for a nonce hole entry — this indicates a prior transaction at a lower nonce that must be resolved before subsequent transactions can process.
  3. Ask the customer to click the Resolve button next to the nonce hole entry in the Pending Transactions tab.
  4. If the customer receives an InsufficientBalance error when attempting to resolve, confirm that the wallet has enough ETH to cover the original transaction amount plus gas. If the original transaction amount is no longer available (e.g., funds were moved), engineering intervention may be required to clear the stuck nonce.
  5. If the customer cannot resolve via the UI, escalate to engineering with the wallet ID, transfer ID, and the nonce hole details.
  6. Once the nonce hole is resolved, all subsequent queued transactions should begin processing.

Notes: In Ethereum and EVM-compatible chains, transactions must be processed in strict sequential order based on their nonce. If a transaction with a lower nonce is still pending, any newer transactions — even if valid and fully funded — cannot be processed until the earlier one is confirmed, replaced, or dropped.

"Reviewing your account, we see that the transaction is currently stuck due to a nonce issue. Could you please review the Pending Transactions section in your BitGo UI and resolve the nonce." "The reason your USDC transaction is not being broadcast is due to a nonce issue caused by an earlier pending transaction from the same wallet... In Eth, transactions must be processed in strict sequential order based on their nonce."

Scenario: signed-stuck-transactions-state#chain-specific-indexer-fix

Trigger: Transactions on a specific chain (e.g., XLM, GTETH, SOL) are stuck in "signed" but may have already been broadcast or confirmed on-chain, and the BitGo indexer for that chain is not updating status correctly.

Signals: XLM, GTETH, SOL, indexer, signed, confirmed on chain but showing signed, failed transfers marked as signed, state mismatch

Steps:

  1. Verify the on-chain status of the transaction using the appropriate block explorer (e.g., Solscan for SOL, Etherscan for ETH/GTETH, Stellar expert for XLM).
  2. If the transaction is confirmed on-chain but BitGo still shows "signed," this is an indexer synchronization issue.
  3. Escalate to the engineering team for the affected chain, providing the wallet ID, transfer ID, and on-chain hash. For ETH and ALT coin chains, use the #notify-eth-alt-team Slack channel.
  4. For SOL specifically, check whether the on-chain transaction actually failed — some SOL transfers that failed on-chain may still show as "signed" in BitGo rather than "failed." Engineering must correct these records.
  5. Notify the customer once engineering confirms the indexer has been fixed and states are updated.

Notes: This scenario also applies when on-chain transactions failed but BitGo still shows them as "signed." The SOL chain has shown this behavior where failed on-chain transactions are not updated to "failed" in BitGo's records.

"We have fixed an issue with our XLM indexer and all XLM transactions should be confirmed now." "We are seeing some transfers marked as SIGNED but have actually failed on chain... Can this be please correctly marked on your end to reflect the correct state?"

Scenario: signed-stuck-transactions-state#btc-unspent-send-low-fee

Trigger: A BTC transaction sent from the "Unspents" menu with a custom fee is applying an unexpectedly low fee and not being broadcast.

Signals: BTC, unspents, custom fee, low fee, not broadcasted, signed, processed

Steps:

  1. Confirm the customer is sending BTC via the Unspents menu in the BitGo UI with a custom fee.
  2. Explain that the Unspents send feature is primarily intended for spending or freezing specific unspents, not for general withdrawals.
  3. Recommend the customer use the standard Withdraw option instead, which leverages BitGo's unspent selection algorithm and applies appropriate fees automatically.
  4. If the transaction is already stuck in "signed" state, escalate to engineering with the wallet ID and transfer ID for manual resolution.
  5. Follow up with the customer once engineering confirms the issue is resolved.

Notes: Engineering has noted that the Unspents send method may not correctly apply custom fees in all cases. The standard withdraw flow is the recommended approach for BTC sends.

"Their recommendation is to not withdraw in this manner unless they have a reason and to instead leverage our withdraw option, letting our unspent selection algorithm choose what unspents to use."

Scenario: signed-stuck-transactions-state#tron-signature-error

Trigger: A TRON (TRX) transaction is stuck in "attempted" state with a broadcast error containing "SIGERROR Validate signature error."

Signals: TRON, TRX, SIGERROR, Validate signature error, signature count, permission, broadcast failed, attempted

Steps:

  1. Use bga t <txhash> to confirm the error. Look for: SIGERROR Validate signature error: Signature count is 2 more than key counts of permission : 1.
  2. This indicates a mismatch between the number of signatures applied and the permission configuration on the TRON address.
  3. Escalate to engineering immediately with the wallet ID, transaction hash, and the full error string.
  4. Engineering will need to investigate the wallet's on-chain permission settings and the signing logic.
  5. Inform the customer that the issue has been escalated and provide updates as they become available.

Notes: This error has been observed on TRON wallets and requires engineering investigation. The customer cannot resolve this themselves.

"Broadcast result: Operation failed but may succeed later -- SIGERROR Validate signature error: Signature count is 2 more than key counts of permission : 1"

Scenario: signed-stuck-transactions-state#half-signed-api-recipients-required

Trigger: An API call to send a half-signed transaction on Polygon or other EVM chain returns the error "expecting array of recipients of size 1".

Signals: half-signed, halfSigned, txHex, recipients, expecting array of recipients, polygon, tpolygon, API error, send endpoint

Steps:

  1. Confirm the customer is using the /api/v2/{coin}/wallet/{walletId}/tx/send endpoint with a halfSigned payload containing only txHex.
  2. The fix is to include a recipients array in the halfSigned payload alongside txHex. The recipients array should be taken from the response of the /api/v2/{coin}/signtx (sign transaction) endpoint.
  3. Provide the corrected payload structure:
    {
  "halfSigned": {
    "txHex": "<signed_tx_hex>",
    "recipients": [
      {
        "address": "<destination_address>",
        "amount": "<amount>"
      }
    ]
  }
}
  4. If the customer reports this started happening suddenly without a code change on their side, note that BitGo changed the recipients field from optional to required. This change was not communicated through the standard breaking-change notification process.
  5. If the customer needs further assistance with payload construction, engage the Solutions Architect team.

Notes: This was caused by an API change where the recipients field went from optional to required in the half-signed send payload. The documentation was not updated at the time of the change. The workaround is to include the recipients list from the signtx endpoint response in the send payload.

"This particular change did not go through the communication process as it only changed one field from optional to required and was not flagged as a breaking change. The effect, however, was much more than that, and to your note, the documentation was not updated appropriately." "Sending the transaction with the recipients list from the signtx endpoint response worked, so I managed to send a few transactions from our sandbox environment."

Related