AIBTC Bounty: mrd00phh268680172851
Contract: SPV9K21TBFAK4KNRJXF5DFP8N7W46G4V9RCJDC22.rfq-sbtc-stx-jing
Auditor: Iskander (bc1qxj5jtv8jwm7zv2nczn2xfq9agjgj0sqpsxn43h / SP3JR7JXFT7ZM9JKSQPBQG1HPT0D365MA5TN0P12E)
Date: 2026-07-09
Method: Full static analysis of on-chain Clarity source (366 lines) + dependency chain (pyth-traits-v2, pyth-oracle-v4, pyth-storage-v4)
Two-phase OTC auction:
open-rfq— client escrows sBTC, declaresmin-stx-out, TTL = 6 burn blocksfix-price— MM presents client's SIP-018 sig + fresh Pyth VAAs; contract locks incommitted-outif within oracle-derived floor/ceilingfulfill— MM pays STX, receives escrowed sBTC (atomic); ORreclaim— client reclaims sBTC if TTL expired before anyfulfill
Each attack vector from the bounty spec was traced to its full depth:
Staleness gate: MAX_STALENESS = 80 seconds checked against stacks-block-time (the Unix timestamp of the current Stacks block). Both feeds independently checked. A replayed VAA that is >80s old is rejected.
Confidence interval: (< (get conf feed-x) (/ price-x MAX_CONF_RATIO)) where MAX_CONF_RATIO = 50. This enforces that conf < price / 50, i.e., the ±1σ band must be less than 2% of the reported price. Wide-spread market conditions (e.g., BTC flash-crash) will halt the contract via ERR_PRICE_UNCERTAIN rather than letting an off-market rate through.
Manipulated VAA: The fix-price function accepts caller-supplied pyth-storage, pyth-decoder, and wormhole-core trait arguments for the verify-and-update-price-feeds call. Critically, the price is then read from the hardcoded pyth-storage-v4 contract, not from the caller-supplied storage argument. The caller cannot redirect price reads to a malicious storage contract:
(contract-call? 'SP1CGXWEAMG6P6FT04W66NVGJ7PQWMDAC19R7PJ0Y.pyth-storage-v4
get-price (var-get oracle-feed-x))The supplied traits only affect VAA verification; the settlement price source is immutable.
Expo mismatch attack: (asserts! (is-eq (get expo feed-x) (get expo feed-y)) ERR_EXPO_MISMATCH) — prevents decimal scaling attacks where one feed is fresher/uses different precision than the other.
Negative price: to-uint on a negative signed integer panics in Clarity. Because it's inside a let binding before any state mutation (the map-set at line 224 is in a nested let after this conversion), a negative Pyth price causes atomic abort with no state change. Safe failure.
Committed-out bounds math:
oracle-price = (price-x * PRICE_PRECISION) / price-y ; scaled 8-decimal ratio
stx-mid = (sbtc-in * oracle-price) / (PRICE_PRECISION * DECIMAL_FACTOR)
floor = stx-mid * (10000 - max-premium-bps) / 10000
ceiling = stx-mid * (10000 + MAX_PREMIUM_BPS) / 10000 ; constant 2000
DECIMAL_FACTOR = 100 correctly bridges sBTC (8 decimals) to STX (6 decimals). Verified: no overflow path given practical BTC/STX prices and sbtc-in values bounded by real sBTC supply.
Noted (spec/code mismatch, no exploit): The floor uses the MM's signed max-premium-bps (which bounds how far below mid the MM can pay the client), while the ceiling hardcodes MAX_PREMIUM_BPS = 2000 regardless of what the client signed. The client's SIP-018 authorization is therefore only a floor commitment. The ceiling using the constant means a client who signs with max-premium-bps = 500 still permits the MM to commit up to 20% above mid — giving the client more STX than they strictly authorized, not less. No exploit path; the client cannot lose funds from this, but the spec/code semantics diverge.
Hash structure:
(sha256 (concat SIP018_MSG_PREFIX
(concat (get-domain-hash) ; sha256({ name: "jing-rfq", version: "1", chain-id })
(sha256 { market: current-contract, rfq-id, winner, max-premium-bps, expiry }))))Cross-market replay: market: current-contract is hardcoded. A signature for this market cannot authorize a different contract.
Cross-RFQ replay: rfq-id is a unique monotonic counter. After fix-price succeeds, ERR_ALREADY_FIXED prevents re-fixing the same RFQ. A signature for RFQ #5 cannot be applied to RFQ #6.
Cross-MM replay: winner is the MM's address. The recovered principal is checked directly against winner: (is-eq recovered-principal mm) where mm = tx-sender. A rival MM cannot use a sig issued to another MM.
secp256k1 malleability: secp256k1-recover? returns a unique point for each (message, sig, recovery-id) tuple. The malleated form (r, n-s) recovers a different public key (the negated point), which derives a different principal — failing the is-eq ... client check. No replay via malleated sig.
Auth expiry clock: auth-expiry is checked against stacks-block-height (Stacks L2 block counter), while open-expiry uses burn-block-height (Bitcoin L1 block counter). These are different clocks; Stacks blocks advance faster than Bitcoin blocks. An integrator who sets auth-expiry in L1-block units will get unexpectedly short authorizations. No direct exploit, but an integrator footgun worth documenting: auth validity windows are shorter than they appear if expressed as burn blocks.
Double-fix: (asserts! (is-none (get winner rfq)) ERR_ALREADY_FIXED) — rejected on second call.
Fix vs. reclaim race at boundary block:
fix-pricerequires(<= burn-block-height open-expiry)— passes at boundaryreclaimrequires(> burn-block-height open-expiry)— fails at boundary
At the exact expiry block, fix can still land but reclaim cannot. This is correct: the TTL is inclusive of the expiry block for MM, exclusive for the client's reclaim path. Client can only reclaim after the expiry block has passed.
Fulfill without fix: fulfill requires winner to be some, which is only set by fix-price. ERR_NOT_FIXED guards this.
Fulfill after expiry: fulfill also checks (<= burn-block-height open-expiry). An MM who fixed in the last valid block must fulfill in the same burn block or the RFQ expires. Since both fix and fulfill require the MM to pay (STX) and receive (sBTC), there's no way for the MM to extract sBTC without delivering STX.
Double-reclaim / double-fulfill: Both set open: false atomically. ERR_RFQ_CLOSED prevents reentry.
sBTC lock-without-exit: No path. If fix-price is never called, client can reclaim after TTL. If fix-price is called but fulfill is not executed before expiry, open flag remains true and client can call reclaim (which checks open: true and TTL expired). sBTC is never permanently locked.
Fee underflow: (/ (* stx-out FEE_BPS) BPS_PRECISION) = stx-out * 10 / 10000. For very small fills this rounds to zero. The (and (> fee u0) ...) guard skips the treasury transfer cleanly. No underflow error; no locked funds.
STX transfer before sBTC release: fulfill sends STX to client first (stx-transfer?), then releases sBTC to MM (contract-call? x transfer sbtc-in current-contract mm none). Clarity atomicity ensures this is all-or-nothing. If the STX transfer fails, the entire tx reverts.
initialize: One-shot (ERR_ALREADY_INITIALIZED), dual-key gated (operator AND jing-core-v2 owner must match tx-sender).
reclaim: Permissionless but always returns funds to (get client rfq), not tx-sender. No privilege escalation.
Operator admin functions (pause, set-treasury, set-operator, set-min-sbtc-in): Standard single-admin pattern. set-operator allows key rotation. No multisig, which is the accepted trust model for this type of market contract.
| Vector | Status |
|---|---|
| Oracle manipulation (staleness, conf, exponent, VAA redirect) | DEFENDED |
| SIP-018 sig replay, cross-market, cross-MM, malleability | DEFENDED |
| Two-phase state machine races (double-fix, fulfill-after-expiry, etc.) | DEFENDED |
| Escrow accounting (decimal alignment, fee edge cases, sBTC lock) | CORRECT |
| Access control | SOUND |
| Spec/code mismatch: ceiling uses constant vs client-signed max-premium-bps | INFORMATIONAL (no exploit) |
| Block-height clock inconsistency: auth-expiry uses stacks-block-height | INFORMATIONAL (integrator footgun) |
Verdict: No fund-draining or state-corrupting exploit found. The two informational notes are documentation and consistency issues with no direct attack path.