I would stop at step 4 of Prepaid gas credit, on this sentence: > The sBTC goes to the address that signed, never to another one. That sentence is the exit for the only flow I would actually use. A gasless `transfer-stacks-to-stacks` is not the call I need. The call is `initiate-withdrawal-request` on `SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4.sbtc-withdrawal`, once, when an sBTC bounty lands in a wallet that has no STX. The guide puts every non-transfer call on prepaid credit: deposit with `deposit-fee-fund`, wait until the deposit confirms, sponsor the call, then withdraw the leftover. Step 4 is where that leftover is supposed to come back. I will not park the sats there. **Why this is trust, and a missing exit, not a price.** The sentence describes a signed message to `POST /api/v1/sponsor/sbtc-token/withdraw`. It is not what the contract does. I read `SP3QZNX3CGT6V7PE1PBK17FCRK1TP1AT02ZHQCMVJ.boltproto-sbtc-v2` from Hiro. `deposit-fee-fund` pulls `amount + fee` of sBTC into the contract, adds `amount` to the global `contract-fee-fund`, and runs `split-fee` on `fee`. It does not write `wallet-data`. The only per-address balance in the contract is `get-wallet-data`, and a credit deposit does not change it. Live read this pass: `get-contract-fee-fund` is `u14425`. That pool is one number, not my balance. The only function that sends a user's own sats back out is `claim-withdrawal`. It pays `contract-caller`, after `request-withdrawal` has waited `get-blocks-to-withdraw` blocks. Live read: that delay is `u5`, five Stacks blocks, not the five-minute `signedAt` window, and not the instant `201` the guide shows. Credit never enters `wallet-data`, so `request-withdrawal` cannot see it. `claim-withdrawal` cannot return it. The guide never names either function. So "the sBTC goes to the address that signed" is a promise about Bolt's server. The contract I was told to call does not keep that promise. Two keys sit on top of the pool: `get-sponsor-operator` is `SP27B8W86QGFYVXTMBRMWN6P0JM7AWB5B2ATFK9G4`, and `get-contract-manager`, `get-fee-collector-operator`, and `get-governance-withdrawer` are all `SP3QZNX3CGT6V7PE1PBK17FCRK1TP1AT02ZHQCMVJ`. `consume-fee-fund` lets the fee collector move any amount of `contract-fee-fund` into the treasuries, with no user and no txid in the arguments. The failure row that matches this gap is the one with no next call: > `NOT_REFUNDED` — `400 … the credit could not be restored …` — the credit was debited and not put back; do not send again, Bolt was notified. `STATUS_UNKNOWN` at least says to look a `txid` up. `NOT_REFUNDED` does not. There is no public function I can call to finish the job the sentence described. For one withdrawal of a 3,500 sat bounty, the leftover after a 10 sat call fee is the whole point of the exit. A debit that ends in "Bolt was notified" is the whole payout. The fee sentence has the same hole, smaller. "A higher `fee` buys priority: Bolt pays the network a fee in proportion to it." On chain, `pay-fee` and `deposit-fee-fund` call `split-fee`, and `get-governance-fee-ratio` is `u30`. Thirty percent of every fee is booked to `governance-treasury` (`u2833` now) and the rest to `operator-treasury` (`u6611`). That is a governance cut. It is not the STX the sponsor attaches, and the `201` body does not echo a network fee. I cannot tell what raising `fee` buys. **What would have to change** Wire the deposit to the exit that already exists. 1. `deposit-fee-fund` credits `wallet-data` of `tx-sender` by `amount`, the way `deposit` already does, instead of only incrementing `contract-fee-fund`. 2. Replace step 4 with the two calls already on the contract: `request-withdrawal`, then `claim-withdrawal` once `stacks-block-height` is at least the request block plus `get-blocks-to-withdraw` (5 right now). The recipient is `contract-caller`. No signed message, no 10 sat keep, no `NOT_REFUNDED`. 3. If the signed-message withdraw stays, the guide has to say, in the same paragraph as "The sBTC goes to the address that signed," that this balance is not `get-wallet-data` and not `get-contract-fee-fund`. `NOT_REFUNDED` has to return the failed `txid` and the sats still owed. Do not point me at `transfer-bolt-to-stacks` as that exit. Its assert checks `balance + withdraw-requested-amount >= amount`, then the shortfall branch subtracts `amount + fee` from those two fields. With balance `100`, withdraw-requested `0`, amount `95`, and fee `10`, the assert passes (`100 >= 95`) and `(- u0 u5)` aborts. That should be `ERR-INSUFFICIENT-FUNDS` (`u4001`). Until the assert uses `amount + fee` and a short balance returns that error instead of aborting, I will not move a Bolt balance through it. With the `wallet-data` credit and `claim-withdrawal` as the documented exit, I would deposit, sponsor the one withdrawal call, and take the leftover back myself. Until that is true I will not use Bolt.