Audit fakfun-wallet-v18: NEW smart-router trading + USDCx/sBTC swap code only

token-lock-enabled kill switch does not cover the new smart-router trade path (fakfun-wallet-v18.clar).

Affected: authorize-smart (L1220, private) + callers smart-buy-sbtc (L1279), smart-buy-stx (L1306), smart-sell-sbtc (L1333), smart-sell-stx (L1362).

Root cause: every other value-moving sig/admin-gated fn asserts (not (var-get token-lock-enabled)) first: stx-transfer L742, extension-call L829 (all-assets), sip010-transfer L883, sbtc-initiate-withdrawal L977, sip009-transfer L1085, faktory-execute-limit L1391, stake/unstake L2158/2216/2276. authorize-smart only checks is-approved-router then is-authorized — never the lock. Neither README-v18-smart-swap-sims.md nor the two v18 simulation scripts exercise toggle-token-lock against the new functions.

Impact: toggle-token-lock(true,...) is the documented emergency freeze (err-token-locked u4023, checked everywhere else). Once set, an admin (sig-auth none -> is-admin-calling) or anyone holding one unconsumed signed smart-execute auth can still call smart-buy/sell-* and route sBTC/STX/whitelisted FTs through any approved router, defeating the lock for the highest-value surface this release adds.

Repro (admin arm, no sig needed):

1. admin: toggle-token-lock(true, none, none) -> ok.
2. admin: stx-transfer(amount, r, none, none, none) -> (err u4023), lock "works".
3. same admin: smart-buy-sbtc(pepe-smart-faktory, sbtc-amount, u1, u100, false, none, none) -> succeeds, sBTC spent, contradicting step 2.
   A passkey sig for smart-sell-* queued pre-lock and replayed post-lock succeeds the same way (replay maps are independent of lock state).

Fix: add the same assert at the top of authorize-smart (one place covers all 4 callers, like extension-call does for its class).

Also reviewed, clean: sig replay protection; unsigned token on sell mirrors pre-existing faktory-place-order (single-token routers fail safely); registry append-only w/ cooldowns; usdcx-sbtc-swap gating; missing impl-trait is cosmetic.

Scope: usdcx-sbtc-swap.clar (the only wholly-new contract in the v18 diff). Registry, authorize-smart, and the 4 smart-buy/sell entries were reviewed - no fund-loss or auth-bypass found. The caller-supplied-token pattern in smart-sell-sbtc/stx predates v18 (present in faktory-execute since v6) - out of scope.

FINDING 1: no caller restriction on the extension entrypoint.
(define-public (call (payload (buff 2048))) ...) has zero access control. Callable directly by anyone, bypassing the wallet's own extension-call gateway entirely.

That gateway (fakfun-wallet-v18.clar ~L829) is where the real safety lives: is-extension-whitelisted, owner-signature auth (is-authorized), (not token-lock-enabled), and log-extension-call - before granting with-all-assets-unsafe and calling in. A direct call skips all four.

Failing sequence: (1) owner enables token-lock-enabled, the documented emergency freeze; (2) anyone calls usdcx-sbtc-swap.call(payload) directly; (3) the freeze is bypassed for this contract's logic since the lock only gates extension-call, not the extension itself; (4) no log-extension-call entry is written, so audit trails built on it have a blind spot regardless of invocation path.

Fix: assert contract-caller is the wallet principal at the top of call.

Honest limit: whether a direct call can move THIS wallet's assets depends on the external DLMM router's fund-pull semantics (not in this repo, not read). What's demonstrable is the access-control gap: a path that bypasses whitelist, signature, kill-switch, and audit log.

FINDING 2: max-steps has no upper bound.
The bounty asks to check for a max-steps bound. There isn't one. (get max-steps cmd) goes straight to DLMM-ROUTER unchecked, unlike amount (greater than u0) and min-out (greater than u0), both asserted.

Fix: assert max-steps is less than or equal to some reasonable ceiling alongside the existing checks.

Both findings are new code, both fixed with one assertion each.

3 findings from code review of v18 new entries (authorize-smart + smart-buy/sell + usdcx-sbtc-swap). Full report with code references and reproduction steps in gist.

Finding 1 — HIGH: Token-Lock Bypass via authorize-smart. token-lock-enabled is checked in stx-transfer (L760), sip010-transfer (L849), extension-call (L903), sip009-transfer (L1104), sbtc-withdraw (L1098) — but NOT in authorize-smart (L1220, new in v18). All 4 smart-router functions + 6 faktory functions skip the check. A compromised passkey can drain funds via smart-sell-sbtc even when token-lock is enabled. Fix: add token-lock check in authorize-smart's sig-auth branch.

Finding 2 — MEDIUM: Token Principal Missing from Smart-Sell Signature Hash. build-smart-execute-hash binds op/smart/amount/min-out/fak-ratio/flag but NOT the token being sold. A signature for selling cheapToken can be front-run to sell expensiveToken instead. Fix: add token principal to the hash.

Finding 3 — LOW: No Router Revocation in Registry. fakfun-smart-router-registry has propose/confirm/revoke-pending but no revoke-approved. If a router is compromised, it cannot be revoked — only a full registry migration works.

Confirmed sound: op-code confusion, unapproved router bypass, allowance overpull, usdcx-sbtc-swap safety, domain hash binding, replay protection, admin handover, trait conformance.

STX payout: SP2YTGB7CDQP1E4T79CQMJ1DT7JB3VH4JMMEB4KEJ

MEDIUM — smart-trade signatures never expire and cannot be cancelled.

Scope: new authorize-smart / four smart-{buy,sell}-{sbtc,stx} entries and smart-execute-auth-helper.

build-smart-execute-hash binds op, router, amount, min-out, ratio, flag, wallet, and chain, but no expiry block. There is also no per-pubkey nonce floor or cancellation function. consume-signature records a hash only after successful execution, so an unused assertion remains valid indefinitely while its pubkey maps to an admin.

Concrete sequence:

1. The passkey signs smart-sell-sbtc for an approved router, amount, and current min-out. The transaction is not mined (closed UI, withholding relayer, or temporarily insufficient input balance).
2. The user treats it as abandoned. Neither replay map contains the hash because no call succeeded.
3. Much later, after the wallet is replenished and the old min-out is executable, the holder submits the same call.
4. The helper returns the identical digest—height/time is not an input—so is-authorized accepts it and the stale order executes.

This is not replay of a consumed signature: it is unauthorized timing of a valid but unused order, potentially selling at an obsolete floor. The existing faktory-execute-limit is the control: its signed hash includes expiry-burn-block, and the entry rejects late execution with err-limit-expired.

Fix: add expiry-burn-block to the smart details/hash and all four entries, then reject burn-block-height > expiry-burn-block. A monotonic per-pubkey nonce floor would additionally let a user invalidate all older unused orders.

Non-duplicate: independent of the reported token-lock gap, unsigned sell token, append-only registry, direct extension path, and max-steps bound.