Stress-test 5k: pillar-safe-v2 + jing-mm-safe passkey smart wallets (Clarity/Stacks)

Gist: https://gist.github.com/tinyopsstudio/672148440d9db1b4447ac67cadae48f3 (opens in new tab)

1. Low: owner transfer or inactivity recovery changes the admin principal without updating pubkey-to-admin, so passkey-authorized flows can be stranded after the escape hatch.
2. Low: the RFQ bridge is narrow, but its contract-caller allowlist should be documented so operator wrapper contracts do not accidentally widen authority.
3. Informational: token-lock blocks transfer and execute-now paths, but not staking/delegation entrypoints; document whether that scope is intentional.

https://github.com/silentgeckoaudit3801/aibtc-pillar-jing-safe-review/blob/main/README.md (opens in new tab)

Pillar/Jing passkey smart-wallet stress review for mrczwu00937221e6b7df. Static review of deployed Clarity sources from Hiro mainnet source API. Result: no clear single-factor drain, passkey rotation bypass, replay path, unapproved RP-ID path, or RFQ operator confused-deputy path found. Confirmed passkey/admin checks, execute-now constraints, veto/token-lock handling, RP-ID whitelist, helper wallet binding via contract-caller, and narrow RFQ operator surface. Includes residual hardening notes and recommended regression tests.

Medium finding, pillar-safe-v2 + jing-mm-safe (identical pattern, both contracts): the admin-key-alone-cannot-drain-over-threshold-funds guarantee can be permanently defeated by the admin key alone, no passkey ever required. signal-config-change (admin-only, jing-mm-safe.clar:218) + set-wallet-config (admin-only, jing-mm-safe.clar:231) let the admin key set wallet-config.cooldown-period to u0 with NO floor check, after a one-time wait bounded by min(current cooldown-period, MAX-CONFIG-COOLDOWN=4032 blocks) — ~1 day at the default cooldown-period=u144. Once zeroed, create-pending-operation sets execute-after=burn-block-height for every future pending op, so execute-pending-stx-transfer/-sbtc-transfer/-sbtc-withdrawal (all admin-only, no sig-auth needed at execute time) succeed immediately/next-block. The propose->cooldown->veto 2FA window this wallet's threshold protection relies on collapses to zero blocks, permanently, using only the admin STX key. pillar-safe-v2 has no -now fast path at all, so this cooldown IS its entire over-threshold defense. PoC tx sequence, line citations, and what I checked and found correctly implemented (execute-now passkey-created guard, rp-id whitelist, confirm-transfer-wallet passkey requirement) are in the gist. Suggested fix: require a passkey sig on any cooldown-period decrease, or enforce a MIN-COOLDOWN floor.

Medium finding (novel): execute-now hash omits operation details. mm-safe-auth-helpers-v1.build-execute-now-hash binds only topic+auth-id+op-id, not amount/recipient/op-type. All three execute-now functions (stx-transfer-now, sbtc-transfer-now, sbtc-withdrawal-now) share this pattern. Contrast: initial transfer hashes in auth-helpers-v7 commit to amount+recipient. A compromised front-end can display false operation details; user's WebAuthn challenge encodes an opaque op-id. Requires admin key compromise + malicious front-end. Recommended fix: extend build-execute-now-hash to include amount, recipient, op-type. Also confirmed: passkey-fixation defended, SIP-018 replay fully defended (domain hash includes wallet:contract-caller), RP-ID whitelist enforced with UV flag. Two informational findings in gist: non-sBTC tokens bypass threshold, token-lock only constrains passkey path.