Scoutinternal

WBTC Burn Requests — Intake and Processing

WBTC Burn Requests — Intake and Processing

Problem

Customers submit WBTC (Wrapped Bitcoin) burn requests, which arrive as support tickets titled "New wbtc burn request." These are high-volume, routine operational requests tied to the WBTC mint/burn lifecycle. The tickets are generated in bulk and require internal processing by the appropriate BitGo team. Based on the source tickets, the problem/resolution details within each individual ticket are empty, making it difficult to determine specific customer-facing symptoms beyond the submission of the burn request itself.

Diagnostics

  • Ticket subject line: Confirm the ticket is titled "New wbtc burn request" (Salesforce case prefix SF#).
  • Volume pattern: These tickets arrive in high volume, often many within the same short time window (minutes apart). Verify whether the ticket is part of a known batch.
  • Created-by identifier: Confirm the ticket was created by the expected automated or internal source (e.g., creator ID 158009540847 is the consistent originator across all sampled tickets).
  • Resolution confidence: Note that all sampled tickets carry a resolution confidence of "medium" and contain no additional problem description, diagnostic notes, or resolution details in their body. This is the expected state for these tickets in the dataset.
  • Salesforce case number: Each ticket maps to a unique SF case number. Use this to cross-reference in Salesforce if further context is needed.

Resolution

Scenario: burn-wbtc-press-new#standard-burn-request-intake

Trigger: A ticket arrives with the subject "New wbtc burn request" and contains no additional problem or resolution detail in its body.

Signals: New wbtc burn request, wbtc, burn, SF#, high volume, bulk tickets, medium confidence

Steps:

  1. Confirm the ticket subject matches the pattern "New wbtc burn request" and note the associated Salesforce case number (SF#).
  2. Verify the ticket creator ID matches the expected internal/automated source (158009540847).
  3. Route the ticket to the internal WBTC operations team responsible for processing burn requests.
  4. Do not request additional information from the customer unless the WBTC operations team flags a discrepancy or missing data.
  5. If the ticket is part of a large batch (multiple burn requests arriving within minutes), treat them as a normal operational pattern — no escalation is needed solely due to volume.

Notes: The source tickets for this cluster uniformly contain empty problem descriptions and empty resolution notes. Resolution confidence is consistently "medium." Because no detailed diagnostic threads or resolution steps are present in any of the 50 sampled tickets (out of 257 total), agents should rely on the established internal WBTC burn processing workflow. If a customer follows up asking about the status of a burn request, check with the WBTC operations team for the current processing state of the associated SF case.

Scenario: burn-wbtc-press-new#wallet-security-discussion-miscluster

Trigger: A ticket in this cluster has the subject "Invitation to discuss wallet security" or "Invitation to discuss Wallet Security" rather than a WBTC burn request.

Signals: wallet security, invitation to discuss, SF#00041956, SF#00043945, SF#00043944

Steps:

  1. Identify that the ticket is not a WBTC burn request — it is an outreach or invitation related to wallet security discussions.
  2. These tickets share the same creator ID (158009540847) and the same empty problem/resolution structure as the burn requests, but are a distinct topic.
  3. Route the ticket to the appropriate security or business development team rather than the WBTC operations team.
  4. Do not process these as burn requests.

Notes: A small number of "Invitation to discuss wallet security" tickets (e.g., SF#00041956, SF#00043945, SF#00043944) appear clustered alongside burn requests due to similar metadata. They require different handling.

Related

  • none identified