Scoutinternal

WBTC Mint/Burn Requests, Policy Unlocks, and Related Custody Operations

WBTC Mint/Burn Requests, Policy Unlocks, and Related Custody Operations

Problem

Customers and internal teams submit requests for WBTC mint and burn operations, WDOGE mint/burn operations, custody withdrawal requests (e.g., Ledn, Bitstamp, Coinlist), enterprise policy unlocks (e.g., Nonco/Metatech), and occasionally encounter stuck or failed transactions across multiple chains (BTC, ERC-20, ALGO, CSPR). These requests arrive as emails to support@bitgo.com and follow distinct operational workflows depending on request type. The majority of tickets in this cluster are templated WBTC mint/burn requests with minimal detail, but a subset involve policy unlock procedures requiring video verification, transaction troubleshooting, or withdrawal issues involving address whitelisting and liveness checks.

Diagnostics

  • Identify the request type from the subject line: Look for patterns such as "New wbtc mint request," "New wbtc burn request," "New wdoge mint request," "New wdoge burn request," "Ledn - Withdraw Request," "Bitstamp - Withdraw Request," "Coinlist - Stuck Transaction," or "Policy Unlock."
  • For WBTC/WDOGE mint or burn requests: Confirm the request details (amount, merchant, destination addresses) are present. These are typically processed via an internal operational workflow. Many of these tickets contain only a subject line and no body — verify whether required details were submitted via a separate channel or form.
  • For policy unlock requests: Check the policy ID provided by the customer. Verify the requesting user is an authorized admin on the enterprise. Confirm whether video ID verification has already been completed for this user.
  • For stuck/failed transactions: Use the BitGo admin tool (bga) to inspect the wallet:
    • Check wallet balance alignment (balance vs. confirmed vs. spendable).
    • Check if the circuit breaker (Breaker triggered) is true or false and the reset time.
    • Review the wallet webhook status — look for "state": "suspended" and successiveFailedAttempts.
    • Review the transaction send queue state (e.g., state=done, state=pending).
    • Check transfer state history for anomalies (e.g., created → signed → failed → confirmed).
    • Look for indexer issues or broadcast errors in the transaction diagnostic output.
  • For withdrawal policy blocks: Check whether the transaction was declined due to an unverified address policy. Look for policy triggers related to address whitelisting and liveness check requirements.

Resolution

Scenario: mint-wbtc-request-new#wbtc-wdoge-mint-burn

Trigger: Customer or merchant submits a new WBTC mint, WBTC burn, WDOGE mint, or WDOGE burn request via email to support.

Signals: wbtc, mint, burn, wdoge, new wbtc mint request, new wbtc burn request, new wdoge mint request, new wdoge burn request

Steps:

  1. Confirm the ticket subject matches a known mint/burn request pattern (e.g., "New wbtc mint request," "New wbtc burn request," "New wdoge mint request," "New wdoge burn request").
  2. Verify the request contains required details (amount, merchant identity, relevant addresses). If the ticket body is empty (as is common with these templated requests), check whether a structured form submission or internal channel provided the details.
  3. Process the mint or burn request through the established internal operational workflow for wrapped asset operations.
  4. Acknowledge receipt to the requester and provide status updates as the operation progresses.

Notes: The vast majority of these tickets (over 30 in the sample set) have only a subject line with no body content. This suggests they are auto-generated or submitted through a standardized intake process. Treat them as routine operational requests unless additional context indicates otherwise.

Scenario: mint-wbtc-request-new#policy-unlock-video-verification

Trigger: Customer requests an enterprise or wallet policy unlock (e.g., to modify policy rules), requiring identity verification before BitGo can proceed.

Signals: policy unlock, unlock policy, modify policy, Nonco, Metatech, video verification, Calendly, videoid

Steps:

  1. Confirm the policy ID provided by the customer (e.g., the customer will provide a UUID-format policy ID).
  2. Send the customer the video verification scheduling link: https://calendly.com/bitgo-client-delivery/videoid
  3. Instruct the customer to have government-issued photo ID ready and to reference their ticket number when scheduling the call.
  4. Include this note: "If you are not initially verified by BitGo, please bring the person on the call who has already verified and can authorise your identity."
  5. Once video verification is completed successfully, proceed with unlocking the policy.
  6. Confirm to the customer that the policy unlock is complete.

Notes: Repeat requests from the same customer for the same policy ID (as seen in follow-up tickets) should still go through the video verification process each time for security purposes. If the customer was recently verified on a prior ticket, the agent conducting the call can confirm identity more quickly.

"We have received your request to unlock policy. For security purposes, we will need to schedule a video conference to verify your Identification. Please use the following link to schedule a time to meet with us and verify the request: https://calendly.com/bitgo-client-delivery/videoid" (ticket #271103)

"Note: If you are not initially verified by BitGo, please bring the person on the call who has already verified and can authorise your identity." (ticket #271103)

Scenario: mint-wbtc-request-new#stuck-transactions-webhook-suspended

Trigger: Customer reports withdrawals stuck in the UI across one or more assets; investigation reveals a suspended webhook and/or no actual transaction-level issue.

Signals: stuck, withdrawals stuck, webhook, suspended, successiveFailedAttempts, BTC, ERC-20, ALGO, Coinlist

Steps:

  1. Use the BitGo admin tool (bga) to inspect the wallet by ID.
  2. Verify balance alignment: compare Balance, Confirmed, Spendable, and TRS Balance fields. If all are aligned and recent transactions show as confirmed, there is no on-chain issue.
  3. Check Breaker triggered — if false, the circuit breaker is not the cause.
  4. Inspect wallet webhooks: look for "state": "suspended" and a high successiveFailedAttempts count. A suspended webhook will not cause transactions to be stuck on-chain, but may prevent the customer's system from receiving transfer notifications, making transactions appear stuck in their UI.
  5. Inform the customer that the wallet itself is functioning normally and that the suspended webhook may be causing notification delivery failures on their side.
  6. If the webhook has been suspended for a long time (e.g., years), advise the customer to review and update or re-create their webhook endpoint.
  7. Request additional details (specific transaction IDs, error messages) if the customer insists transactions are genuinely stuck.

Notes: A suspended webhook does not block on-chain transactions. The customer may perceive transactions as "stuck" because their internal systems rely on webhook callbacks to update withdrawal status. Confirm this distinction clearly.

"Not seeing anything wrong with the noted wallet other than the failing webhook which is now suspended. Seems like its been this way a while." (ticket #210274)

"Reviewing that wallet, I see nothing wrong. Balance is aligned, CB isn't tripped, all transactions are confirmed with new transactions as of today. The only issue I see is a suspended wallet webhook, but its been that way a while, almost 3 years." (ticket #210274)

Scenario: mint-wbtc-request-new#cspr-failed-then-confirmed-indexer

Trigger: CSPR transactions show a state history of created → signed → failed → confirmed, with both confirmedTime and failedTime present on the same transfer.

Signals: CSPR, Casper, failed, confirmed, indexer, double-spend, failedTime, confirmedTime, broadcast, settlement window

Steps:

  1. Verify the transaction on-chain using the transaction hash — confirm it exists in a block (e.g., check block height and block hash).
  2. Check the send queue state for the transaction (e.g., state=done).
  3. Review the transfer record for the wallet — if the transfer shows status confirmed and the on-chain record also confirms it, the transaction did succeed.
  4. Look for an error message in the transaction details such as: "Broadcast result: Operation failed after multiple attempts and will never succeed -- Invalid Deploy" — this indicates the indexer attempted to re-broadcast an already-confirmed transaction.
  5. Escalate to the engineering team for confirmation of indexer issues during the affected time window.
  6. Communicate to the customer that the indexer was down at the time of the transaction, causing delayed catch-up. While the indexer was catching up, it repeatedly attempted to broadcast the transaction. Once the indexer caught up, the transaction was correctly marked as confirmed.
  7. If the customer reports a large batch of affected transactions (e.g., ~52 transactions), request the full list and escalate to engineering for a bulk review.

Notes: This scenario creates a settlement risk for the customer: transactions appear failed (potentially allowing duplicate withdrawal attempts) but were actually confirmed on-chain. Treat this with urgency and ensure the customer understands which transactions actually settled.

"Our engineering team have reviewed and found the indexer was down at the time of the transaction and it took a while for the indexer to catch up. While this was occurring, our indexer was also repeatedly attempting to broadcast the transaction. Once the indexer was able to catch back up, the transaction became marked as confirmed." (ticket #317473)

"we've identified an issue with CSPR withdrawals starting June 4th where ~52 transactions are being marked as both 'confirmed' and 'failed' in your system, creating a settlement window problem." (ticket #317473)

Scenario: mint-wbtc-request-new#withdrawal-unverified-address-policy

Trigger: Customer attempts a withdrawal that is declined due to a policy requiring address verification via liveness check.

Signals: unverified address, policy, liveness check, whitelist, declined, WBTC, swap, withdrawal

Steps:

  1. Confirm the transaction was declined because of a policy that triggers when it involves an unverified address.
  2. Instruct the customer to finalize their initial video ID by clicking the bell icon in the BitGo UI.
  3. After adding their video ID, instruct the customer to navigate to the wallet from which they wish to withdraw and select the whitelist section.
  4. Have the customer enter the withdrawal address in the whitelist.
  5. The first time the customer withdraws to this address, they will be prompted for a liveness check. They must complete it.
  6. Once the liveness check is complete, the withdrawal should proceed successfully.

Notes: This applies when a customer has not yet verified their identity or has not whitelisted the destination address. The liveness check is a one-time requirement per new withdrawal address.

"The transaction was declined because of a policy that triggers when it involves an unverified address. The address must be verified through a liveness check." (ticket #360175)

"Firstly, you must finalize your initial video ID by clicking the bell icon. After adding your video ID, please go to the wallet ID from which you wish to withdraw and select the whitelist section. Enter the withdrawal address. The first time you withdraw to this address, you will be prompted for a liveness check." (ticket #360175)

Scenario: mint-wbtc-request-new#ledn-bitstamp-withdraw-request

Trigger: A custody withdrawal request is submitted on behalf of Ledn or Bitstamp via an email with a templated subject line.

Signals: Ledn, Bitstamp, withdraw request, custody withdrawal

Steps:

  1. Confirm the ticket subject matches a known custody withdrawal pattern (e.g., "Ledn - Withdraw Request," "Bitstamp - Withdraw Request").
  2. Verify the withdrawal details are present (amount, destination address, asset).
  3. Process the withdrawal through the established internal custody operations workflow.
  4. Acknowledge receipt and provide status updates as the withdrawal is completed.

Notes: Like WBTC mint/burn requests, many of these tickets are templated with minimal body content. Follow standard custody withdrawal procedures.

Related