AIBTC RFQ sBTC STX Jing Stress Review

RFQ sBTC/STX Jing Stress Review

Bounty: `mrd00phh268680172851`
Contract: `SPV9K21TBFAK4KNRJXF5DFP8N7W46G4V9RCJDC22.rfq-sbtc-stx-jing`
Reviewer BTC address: `bc1qmphv24unv5qf6qy4uyhcaxa69tmyw5mkfkk09h`
Review date: 2026-07-23

Executive Summary

I pulled the deployed Clarity source from Hiro and reviewed the RFQ state machine, client authorization hash, oracle settlement path, fee/accounting path, expiry split, and admin surface. I did not find a reproducible escrow double-spend or an obvious way for a maker to set `committed-out` outside the enforced floor/min/ceiling constraints. The core escrow state machine is directionally sound: each RFQ starts `open: true`, can be fixed once, and only exits through `fulfill` before/at `open-expiry` or `reclaim` after `open-expiry`.

The residual risk I would still harden is around freshness semantics and operational safety rather than direct theft. In particular, `fix-price` accepts caller-supplied Pyth/Wormhole trait contracts for the update call while reading the final price from canonical `pyth-storage-v4`; this makes the proof/update dependency less explicit than the settlement read. I also flag the narrow block-boundary settlement race as a product-level free-option issue and recommend documenting the intended "fulfill wins at height == open-expiry, reclaim starts at height > open-expiry" behavior.

Method

- Source fetched from `https://api.hiro.so/v2/contracts/source/SPV9K21TBFAK4KNRJXF5DFP8N7W46G4V9RCJDC22/rfq-sbtc-stx-jing`.
- Reviewed public entrypoints: `open-rfq`, `fix-price`, `fulfill`, `reclaim`, `initialize`, `set-treasury`, `set-paused`, `set-operator`, `set-min-sbtc-in`.
- Mapped all writes to `rfqs`, `next-rfq-id`, `token-x`, `token-y`, `oracle-feed-x`, `oracle-feed-y`, `min-sbtc-in`, `operator`, `treasury`, `paused`.
- Checked transfer ordering and atomicity assumptions around `try!`, `stx-transfer?`, and SIP-010 `transfer`.

Findings

L-01: Oracle update traits are caller-supplied while settlement reads canonical storage

Affected lines: 137-188, 190-210.

`fix-price` lets the caller provide `pyth-storage`, `pyth-decoder`, and `wormhole-core` trait implementations to `pyth-oracle-v4.verify-and-update-price-feeds`. Immediately afterwards, however, the contract reads settlement prices directly from hardcoded canonical `SP1CGX...pyth-storage-v4`.

This is not a direct price-spoofing issue in the reviewed contract because the actual `price-x` and `price-y` values used for bounds come from canonical storage and are checked for positive price, matching exponent, freshness, and confidence. The gap is semantic: the function signature suggests the supplied VAAs and trait contracts are the update source of truth, while the settlement source of truth is the canonical storage contract. If canonical storage is already fresh from another transaction, a maker does not need their supplied update path to be meaningfully tied to the exact price eventually read by this market.

Impact: low, mostly assurance and auditability. It weakens "this RFQ fix was priced from these verified VAAs" as an invariant, but I did not find a path to bypass the final canonical freshness/confidence/price checks.

Recommended fix: pin the expected Pyth storage, decoder, and wormhole-core contract principals instead of accepting arbitrary trait contracts, or assert `(contract-of pyth-storage) == '...pyth-storage-v4`, `(contract-of pyth-decoder) == '...`, and `(contract-of wormhole-core) == '...` before the update call. If dynamic traits are intentional for upgradeability, emit the trait principals in the `rfq-fix` event and document that settlement uses canonical storage freshness rather than per-call VAA provenance.

I-01: Expiry boundary intentionally favors maker fulfillment at equality

Affected lines: 158, 267, 303.

The contract permits `fix-price` and `fulfill` while `burn-block-height <= open-expiry`, and permits `reclaim` only when `burn-block-height > open-expiry`. This creates a clean no-overlap split: at exactly `open-expiry`, the maker can still fulfill and the client cannot yet reclaim.

I do not consider this a bug because it prevents same-height reclaim/fulfill ambiguity. It should be documented as an intentional option boundary, because clients may assume "expiry height" means reclaimable at that height rather than after it.

Recommended fix: document the exact semantics in UI/client signing text: "maker may fulfill through block H; client reclaim starts at H+1." If the desired product semantics are stricter, change both `<=` checks to `<` or make the client-facing expiry one block earlier.

I-02: Pause mode does not stop settlement or reclaim

Affected lines: 114, 155, 249-314, 347-350.

`paused` blocks new opens and price fixes, but it does not block `fulfill` or `reclaim`. I treat this as likely intentional: during an incident, users should be able to unwind existing RFQs and fixed makers should be able to settle.

Recommended fix: document this as "pause new risk, allow exits." If emergency response ever requires freezing all movement, add a separate `settlement-paused` or `emergency-freeze` flag rather than overloading the current pause.

Confirmed Invariants

Escrow state machine

`open-rfq` transfers `sbtc-in` from the client to the contract before storing the RFQ. `fix-price` requires `open == true`, `winner == none`, and `burn-block-height <= open-expiry`, then sets `winner`, `fixed-stx-out`, and `fixed-oracle-price`. `fulfill` requires the caller to be `winner` and closes the RFQ after paying STX and returning escrowed sBTC. `reclaim` requires `burn-block-height > open-expiry` and closes the RFQ after returning escrowed sBTC to the client.

Because Clarity state writes and transfers roll back on `try!` failure, I did not find a partial-fill path that leaves `open: false` without completing the intended transfer sequence.

Replay and wrong-winner authorization

`build-auth-hash` binds `market: current-contract`, `rfq-id`, `winner`, `max-premium-bps`, and `expiry`, under a domain hash that includes `name`, `version`, and `chain-id`. `fix-price` recovers the signer and checks it against the stored RFQ `client`. This blocks cross-market replay, cross-RFQ replay, and wrong-winner fix attempts under the reviewed hash construction.

Price bounds

`fix-price` rejects zero prices, stale publish times, high confidence ratios, exponent mismatch, `max-premium-bps > 2000`, `committed-out < floor`, `committed-out < min-stx-out`, and `committed-out > ceiling`. Integer division rounds downward, which is conservative for `floor` and permissive by at most one unit in expected fixed-point arithmetic. I did not find a wraparound path in these bounded uint calculations under realistic Pyth BTC/STX magnitudes.

Trait-based token selection

`open-rfq`, `fulfill`, and `reclaim` all assert `(contract-of x) == token-x` before transferring. This prevents a caller from substituting an arbitrary SIP-010 token contract for escrow release.

Residual Gaps Worth Testing Next

- A stxer/clarinet harness that pins canonical Pyth storage at a fresh value, then calls `fix-price` with no-op trait implementations to prove whether L-01 is only a provenance ambiguity or can affect practical update requirements.
- Boundary tests around `open-expiry`: fix+fulfill at equality, reclaim at equality, reclaim at equality+1.
- End-to-end net-output UI tests so clients understand `min-stx-out` is checked against `committed-out` while fees reduce `client-receives`.

Suggested Patch Sketch

(asserts! (is-eq (contract-of pyth-storage)
  'SP1CGXWEAMG6P6FT04W66NVGJ7PQWMDAC19R7PJ0Y.pyth-storage-v4)
  ERR_WRONG_TRAIT)

Repeat the same principal pin for the expected decoder and wormhole core contracts, or remove the dynamic trait parameters and call the canonical contracts directly.