FastPool xbtc-sbtc-swap-v4

One-way xBTC-to-sBTC swap contract with custodial bridge model

Verdict: PASS — Core swap logic is sound. The receipt token is well-guarded. The custodial model is explicit, intentional, and appropriate for the xBTC deprecation use case. One medium finding related to the enroll function's open trait parameter. No funds at direct risk.

Overview

This contract implements a one-way xBTC-to-sBTC migration path:

1. Deposit: User sends xBTC to the contract, receives swxBTC receipt tokens 1:1
2. Unwrap: Operator sends accumulated xBTC to custodian for BTC conversion and sBTC bridge deposit
3. Claim: User burns swxBTC receipt tokens and receives sBTC 1:1 (when available)
4. Withdraw: User can cancel and reclaim xBTC before the unwrap cycle (if xBTC still in contract)

The architecture is deliberately simple: two contracts (swap + receipt token), two privileged roles (deployer + operator), one custodian, and a hardcoded excess receiver. No maps, no complex state. The attack surface is minimal.

What Works Well

• One-shot initialization: initialize sets custodian and operator exactly once. The is-none guard prevents re-initialization even by the deployer. This is a clean pattern.
• Receipt token access control: swapping-xbtc-v4 restricts mint/burn to the swap contract via set-swap-contract (also one-shot). No external caller can mint or burn receipt tokens.
• Transfer validation: Receipt token transfer checks tx-sender or contract-caller matches the sender parameter. Standard SIP-010 compliant.
• Partial claims: claim-sbtc handles the case where sBTC balance is less than user's swxBTC balance — claims what's available without reverting. Users don't get stuck.
• Withdraw safety: withdraw-xbtc double-checks both the user's swxBTC balance AND the contract's xBTC balance before allowing withdrawal. No underflow possible.
• Clean error codes: All errors are named constants with distinct codes (401, 403, 510-514). No opaque panics in public functions.
• Minimal surface area: 7 public functions, 1 private helper, 4 read-only views. Easy to reason about. No unnecessary complexity.

Findings

(define-public (enroll
    (enroll-contract <enroll-trait>)
    (receiver (optional principal))
  )
  (begin
    (asserts! (is-eq tx-sender deployer) err-unauthorized)
    (as-contract? () (try! (contract-call? enroll-contract enroll receiver)))
  )
)

(define-read-only (get-xbtc-balance (user principal))
  (unwrap-panic (contract-call? 'SP3DX3H4FEYZJZ586MFBS25ZW3HZDMEW92260R2PR.Wrapped-Bitcoin
    get-balance user
  ))
)

Receipt Token Analysis: swapping-xbtc-v4

The receipt token is clean and well-implemented. The set-swap-contract one-shot pattern is a good practice — it prevents the deployer from redirecting mint/burn authority after deployment.

Architecture Diagram

User                      Swap Contract                 Custodian
  |                            |                            |
  |-- deposit-xbtc ---------->|                            |
  |<-- swxBTC minted ---------|                            |
  |                            |                            |
  |                            |-- init-unwrap (operator) ->|
  |                            |   (all xBTC sent)          |
  |                            |                            |
  |                            |                [converts xBTC -> BTC -> sBTC bridge]
  |                            |                            |
  |                            |<-- sBTC deposited ---------|
  |                            |                            |
  |-- claim-sbtc ------------>|                            |
  |<-- sBTC received ---------|                            |
  |   (swxBTC burned)          |                            |

Summary

This is a well-scoped, minimal contract that does one thing: migrate xBTC holders to sBTC. The code is clean, the access controls are correct, and the receipt token pattern is solid. The one medium finding (open trait in enroll) is a defense-in-depth concern, not an active exploit vector — it requires deployer key compromise. The custodial model is inherent to the xBTC deprecation process and is handled transparently.

For users: Safe to use. Understand that after the operator triggers init-unwrap, your xBTC is with the custodian until sBTC arrives. Use withdraw-xbtc if you change your mind before the unwrap cycle.