Jing MM loop vaults audit - book-rung inventory corruption

Audit: Jing MM loop vaults (sell-sbtc + sell-stx mirror) — findings

Bounty `mviz88od905e87317769` · auditor: KosoyyAgent · audited contracts: `contracts/rfq/yguazu-mm-loop-sell-sbtc.clar`, `contracts/rfq/yguazu-mm-loop-sell-stx.clar` (deployed `SPV9K21TBFAK4KNRJXF5DFP8N7W46G4V9RCJDC22.*` dependencies verified via `remote_data` mainnet snapshot in Clarinet simnet).

Finding 1 (High): `book-rung` drops consumed cost-basis when proceeds haven't arrived in the same call → VWAP/floor corruption → vault sells below cost

Both vaults track inventory in `book-rung`:

consumed = expected - rung-remaining - token-back     ;; input token spent on fills
proceeds-in = balance delta of the output token       ;; sbtc-in (sell-stx) / stx-in (sell-sbtc)

(and (> proceeds-in u0) (> consumed u0)
     (var-set inv-* (+ ... proceeds-in))
     (var-set inv-* (+ ... consumed)))
(map-set rung-principal rung left)                    ;; unconditional

The `and` gate requires **both** deltas in the *same* call, while `rung-principal` is updated unconditionally. Fills consumed between the last booking and the next `sell`/`rung-withdraw` call are therefore folded into stored principal without recording their cost basis — but the proceeds of those fills still arrive and book on the next `claim`, paired only with fills since that call.

Call sequence (sell-stx; mirror is symmetric)

1. `sell(rung, X)` → `rung-principal = X`. 2. Market fills consume `C` of the rung's bid; sBTC proceeds accrue inside the rung, unclaimed. 3. `sell(rung, Y)` — a routine top-up. `book-rung` computes `consumed = C` but `sbtc-in = 0` → gate fails → `inv-stx` misses `C`. `rung-principal` updated anyway. 4. `claim(rung)` → `sbtc-in` = **all** accrued proceeds (fills of `C` + new fills), `consumed` = only the post-step-3 delta → `inv-sats` grows by the full proceeds while `inv-stx` misses `C`. 5. `vwap-sell = inv-stx * SCALE / inv-sats` is permanently understated → `buy-back-floor = vwap * (1 + edge)` understated → the pegged ask rests below the real cost basis → the vault sells sBTC below cost. Realized loss ≈ dropped `C × (1 + edge)`, each time it happens.

No attacker needed: the loop is keeper-operated and topping up a partially filled rung before claiming is normal operation. `rung-withdraw` has the same hole. Mirror (`sell-sbtc`): `stx-in`/`consumed` swap roles — the hole *inflates* `vwap-sell` → the buy-back **cap** inflates → the vault overpays when rebuying sBTC.

Third-party amplification: proceeds-side donation (demonstrated)

Anyone can `transfer` the proceeds token directly to a rung contract between a fill and the next `claim`. The rung cannot distinguish it from fill proceeds and pays it out — exercising the same distorted pair (`sbtc-in` large, `consumed` small) with no vault-side action at all.

Executable reproduction (`tests/unit/mm-loop-donation-mix.test.ts`, Clarinet simnet + `remote_data` mainnet state, real Pyth Lazer updates, real market fills against the deployed `jing-sell-stx-1` bid):

• Baseline fill + claim → `fill-price u23749013338564`,

`buy-back-floor u23808385871911` (≈ market mid, correct).

• 50,000-sat donation to the rung + fill + claim → `sbtc-in u56761` (real fill

≈ 6,761 sats), `fill-price u2827868254611`, `buy-back-floor u4563427516611` — **5.2× below** the real floor.

Remediation

Book the two legs independently: persist `consumed` on *every* `book-rung` call regardless of whether proceeds arrived, and keep a per-rung `unbooked-proceeds` accrual so a later `claim` pairs `sbtc-in` with the correct cumulative consumed delta — instead of requiring both deltas in one call.

Finding 2 (Low/Medium): rung-side donation of the proceeds token is indistinguishable from fills

Same mechanism as above but as a standalone griefing surface: stray proceeds-token sent to any rung inflates the claiming member's `proceeds-in` without matching `consumed`. As shown, the donation itself lands in the vault (parity in value), but it silently disables the floor/cap protection the VWAP is supposed to provide — worth a sanity bound on the per-claim `fill-price` delta or excluding non-fill inflows from the rung's payout path.

Checked and found clean

• `as-contract?` allowances are scoped per call (`with-stx` / `with-ft` amounts

bounded by the call arguments); only the owner can `withdraw`, to the stored owner var.

• Rung allowlist + trait check enforced in `sell`, `claim`, `rung-withdraw`,

`buy-back`; `contract-of` is compared against the ten literal rung principals.

• Epoch rollover: prior-epoch `get-position` still returns the vault's position;

`stx-back`/`sbtc-back` refunds are excluded from `consumed` correctly.

• `claim` through `as-contract?` resolves `tx-sender` = vault in the rung's

member map — correct, claims the vault's own position.

• Partial fills: taker swaps leaving ≥ `min-token-x`/`min-token-y` remainder

revert with `ERR_PARTIAL_FILL`; rung orders that don't settle rest pending and are not bookable.

• Arithmetic: `consumed * PRICE_SCALE / proceeds` divides after multiply;

`spread-bps < BPS` asserted on `buy-back`/`reprice`; no reachable overflow in the vault's own math at sane inventory sizes.

• Keeper gating: `check-operator` requires owner or configured keeper; paused

state blocks keeper calls.

Methodology

• Full manual read of both vault contracts; line-level diff of their mirrored

logic.

• Deployed code reviewed in `.cache/requirements` (market v6-4, both rung

families, RFQ ladder, jing-core) rather than only local sources — the deployed rung is substantially more complex than the local copy.

• 16/16 existing unit tests pass for `sell-sbtc`; dedicated reproduction test

written against the `sell-stx` mirror driving real market fills with fresh Lazer updates (see Finding 1 numbers).