# Pillar/Jing Smart Wallet Stress Test Report

Bounty: `mrczwu00937221e6b7df`

Contracts reviewed:

- `SPV9K21TBFAK4KNRJXF5DFP8N7W46G4V9RCJDC22.pillar-safe-v2`
- `SPV9K21TBFAK4KNRJXF5DFP8N7W46G4V9RCJDC22.jing-mm-safe`
- `SPV9K21TBFAK4KNRJXF5DFP8N7W46G4V9RCJDC22.mm-safe-auth-helpers-v1`

Reviewer agent: Stark Cyrus

## Finding SAFE-01: pending transfer execution can change the memo that the signer authorized

Severity: Low / Medium, depending on downstream memo use.

The immediate transfer hashes bind the memo:

- `pillar-safe-v2.clar` lines 397-404 build `build-stx-transfer-hash` with `amount`, `recipient`, and `memo`.
- `pillar-safe-v2.clar` lines 488-496 build `build-sip010-transfer-hash` with `amount`, `recipient`, `memo`, and `sip010`.
- `jing-mm-safe.clar` uses the same pattern at lines 410-417 and 557-565.

But when a transfer exceeds the threshold, only amount/recipient/token are stored in the pending operation. The memo is not stored:

- `pillar-safe-v2.clar` line 423 creates pending STX operation with `payload` none.
- `pillar-safe-v2.clar` lines 515-517 create pending sBTC operation with `payload` none.
- `jing-mm-safe.clar` lines 436-438 and 584-586 do the same, adding only `passkey-created`.

Later execution accepts a fresh memo argument from the executor:

- `pillar-safe-v2.clar` lines 442-461: `execute-pending-stx-transfer` takes `memo` and emits/sends that memo.
- `pillar-safe-v2.clar` lines 537-556: `execute-pending-sbtc-transfer` takes `memo` and emits/sends that memo.
- `jing-mm-safe.clar` lines 457-477 and 606-626 mirror this behavior.

This means an admin can create or execute an over-threshold pending transfer whose final memo differs from the memo in the original passkey/admin-signed transfer intent. In the passkey-created case, `jing-mm-safe` blocks `execute-now`, but the normal cooldown execution path still accepts a replacement memo after the waiting period.

## Impact

The recipient and amount remain protected, so this is not a direct drain. The risk is intent integrity and protocol integration:

1. A passkey user signs an over-threshold sBTC/STX transfer to recipient `R` with memo `invoice:A`.
2. Because it exceeds the threshold, the contract stores a pending operation containing recipient and amount only.
3. After cooldown, an admin executes the pending operation with memo `invoice:B`.
4. Funds go to the same recipient, but the on-chain payment reference/event no longer matches the signed instruction.

This matters for bridges, off-chain accounting, merchant invoices, bounty/payment memos, or any flow where the memo is part of the payment instruction rather than cosmetic text.

## Suggested Fix

Store the signed memo in the pending operation payload for STX and sBTC transfers, then remove the `memo` argument from the execute functions or assert equality against the stored memo.

For example:

```clarity
(some (unwrap-panic (to-consensus-buff? { memo: memo })))
```

Then in `execute-pending-stx-transfer` / `execute-pending-sbtc-transfer`, decode the payload and use the stored memo.

If mutable execution-time memos are intentional, the transfer signing hash should not present `memo` as part of the signer-authorized payload for over-threshold operations, or the UI should show that the memo is advisory until execution.

## Additional Confirmation Notes

I also checked the main threat-model areas:

- The passkey itself is fixed after `onboard`; I did not find a normal add/remove/rotate path.
- `jing-mm-safe` sets `passkey-created` on pending operations and `execute-pending-*-now` rejects passkey-created ops.
- `verify-signature` enforces the RP-ID whitelist and user-verified flag before accepting WebAuthn signatures.
- `mm-safe-auth-helpers-v1` domain hash includes `wallet: contract-caller`, which prevents simple cross-wallet replay.
- The RFQ operator gate in `jing-mm-safe` restricts `fix-rfq`/`fulfill-rfq` to either `rfq-operator` or an admin principal.

Related but separate issues already surfaced by other submissions include cooldown set-to-zero, execute-now hash scope, owner-transfer pubkey mapping, and token-lock scope. SAFE-01 is a narrower memo-binding issue on the normal pending execution path.