# Does sBTC actually cash out to Bitcoin? Measurement over withdrawal requests u3500-u3600

All figures come from `print` events of `SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4.sbtc-registry`,
read via Hiro. No money moved for this analysis; nothing was submitted on-chain.

## Method, and its one limitation

I joined `withdrawal-create` to `withdrawal-accept` **on request-id**. The brief
also offers read-only contract calls (`get-withdrawal-request`,
`get-completed-withdrawal-sweep-data`) as a second method. Those return **404 on
Hiro's public API**, so I could not run the cross-check and am not claiming one.
Where the two methods would be compared, this report states only what the event
join supports.

Paging note: these events are dominated by deposits (roughly 100:1 against
withdrawals), so covering this window meant walking offsets 0-5700 in pages of 50.
Every one of the 101 request-ids in the window was seen; none were missing from
the fetch, and no request-id appeared with two create or two accept events. The
window is therefore complete and un-duplicated.

## 0. Chain identity, established before any subtraction

This matters for Q2 and Q5, so it comes first rather than as a footnote.

- Stacks height **9089236** reports `burn_block_height` **969162** (Hiro
  `/extended/v1/block`). The Stacks and Bitcoin counters are therefore ~9.08M and
  ~0.97M, and are not interchangeable.
- The create event's `block-height` for u3500 is **968470**, which sits in the
  *Bitcoin* counter's range, not Stacks'.

**Both heights in each create/accept pair are Bitcoin heights.** The brief asks for
"the gap between the Stacks block-height at create and the burn-height at accept";
taken literally that subtraction is undefined, because these events carry no
Stacks block-height. What is computable is a **Bitcoin-block** latency. I report
that and flag the unit, rather than presenting the difference as Stacks blocks.

## 1. Counts

| | count |
|---|---|
| request-ids seen in window | 101 |
| withdrawal-create events | 101 |
| completed sweeps (withdrawal-accept) | **97** |
| create with no sweep | **4** |

Every id in the window was created; none was missing. Decided by **event join on
request-id**. No second method was available, so there is no disagreement to
report.

## 2. Latency (Bitcoin blocks, create -> accept)

n = 97

- median **7**
- min **7** (64 of 97 requests sit at the floor)
- max **10** (ids 3562, 3573, 3579, 3582, 3585)

At roughly 10 minutes per Bitcoin block this is a ~70 minute median and a ~2 hour
worst case. Units are Bitcoin blocks throughout; nothing above mixes chains.

## 3. Fees (sats), actual at accept vs max-fee at create

- **actual == cap: 0 of 97.** The cap was never the binding constraint.
- actual fee values observed: 34, 35, 36, 37, 39, 41, 45, 65, 68, 69, 70, 71, 72,
  74, 76, 77, 78, 79, 86, 136, 140, 338 sats
- caps observed: 340, 500, 510, 680, 720, 750, 850, 1000, 1500, 2000, 3000, 3001,
  4000, 5000, 10000 sats
- largest shortfall: **9931 sats** at u3549 (cap 10000, charged 69)
- largest excess: **none.** The tightest case is still 204 sats under cap, at
  u3555. The fee never exceeded the cap.

## 4. Requests in the window with no completed sweep

**u3591, u3592, u3593, u3594**

- rejected: **all four**. The distinguishing observable is a
  `complete-withdrawal-reject` event carrying the same request-id.
- still pending: **none**.

## 5. The way this dataset would mislead you

**Rejections are not independent; they arrive in bursts, so the success rate is a
property of the window you pick, not of sBTC.**

The requested window reports **96.0%** success (97/101). Sliding a 101-wide
window across data I had already fetched (u3391-u3659, 269 created):

| window | success |
|---|---|
| u3488-u3588 | 100.0% |
| **u3500-u3600 (the one requested)** | **96.0%** |
| span-wide u3391-u3659 | 91.1% |
| u3548-u3648 (shifted 48 ids) | **77.2%** |

Rejections cluster into consecutive runs rather than scattering: u3466 (1),
u3591-u3594 (4), u3609-u3611 (3), **u3633-u3648 (16)**.

The window asked about is therefore unusually clean. Anyone computing "is sBTC
cashable?" from u3500-u3600 would conclude 96-100%, while a window just 48
request-ids later gives 77%. The burst at u3633-u3648 alone moves the span-wide
figure by several points. **The specific request-ids that expose it:
3633-3648.**

A second hazard sits in the same dataset: because the read-only calls are not
available publicly, an analyst who joins only create to accept and reports
"latency" without checking which chain the heights belong to would compute
`burn-height - block-height` and describe the result as Stacks blocks, producing
a clean integer (median 7) that is really a Bitcoin-block figure. Both readings
are plausible; only one is right.

## Bottom line

In this window sBTC did cash out: 97 of 101 requests completed, median ~7 Bitcoin
blocks, and no request overpaid its fee cap. The honest caveat is that a clean
window is not a general claim, and the failure mode is bursty rather than uniform.