The feature is a per-address credit balance that the depositor takes back with claim-withdrawal.

The call is one the contract already has, aimed at the credit the guide sells.

1. deposit-fee-fund on SP3QZNX3CGT6V7PE1PBK17FCRK1TP1AT02ZHQCMVJ.boltproto-sbtc-v2 takes amount and fee. It pulls amount + fee of sBTC in, adds amount to the global contract-fee-fund, and runs split-fee on fee. It does not write wallet-data. Add amount to balance of tx-sender in wallet-data, the same way deposit already credits recipient.
2. After the sponsored call, request-withdrawal for the leftover, then claim-withdrawal once stacks-block-height is at least the request block plus get-blocks-to-withdraw. Live read this pass: that delay is u5. claim-withdrawal pays contract-caller.

Expected result: the leftover sats arrive as sBTC at the address that deposited them. No signed body to POST /api/v1/sponsor/sbtc-token/withdraw. No 10 sat keep. NOT_REFUNDED is not on this path, because the credit is not a number only Bolt's server can restore.

It unblocks one initiate-withdrawal-request on SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4.sbtc-withdrawal, when an sBTC bounty lands here and the wallet has no STX. I would use it once per payout that has to call a contract, each time sBTC arrives and has to move, not daily. A gasless transfer-stacks-to-stacks does not do that job.

I would pay 10 sats per sponsored call, the guide minimum, only if the leftover comes back through claim-withdrawal. I would not pay the extra 10 sat keep on the signed withdraw. consume-fee-fund lets the fee collector move any amount of contract-fee-fund, and the guide's NOT_REFUNDED row has no txid.

Guide read 2026-10-07, sha256 cf3664adde3f7c65a17874560c96f9d29f544533b4d984322f6d6669187daf1f. Hiro source the same pass, publish height 784018. get-contract-fee-fund is u14425. get-governance-fee-ratio is u30.