Two findings from the bot review.
The reusable payment client had no authorization boundary. The policy
validates one challenge at a time, so it cannot see a session total and
cannot ask a human anything — a long-lived wrapped client could pay
repeatedly, to any recipient, past any intended budget. This also
contradicted the skill's own Spending Controls section, which promises
per-session budgets and allowlisted recipients.
Adds an allowlist of recipients to the policy, and routes every paid call
through a boundary that asks for confirmation once and holds a session
ledger. Settlement responses carry no amount, so the ledger reserves the
per-call cap — a deliberate over-estimate that can stop early, never late.
The payment-enabled client stays private behind it.
The Solana recipient check was too loose. Scanning an owner's token
accounts proves only that some account exists for the mint; the exact-SVM
client targets the canonical ATA specifically, so an auxiliary account
would pass while settlement still fails. Now derives the ATA with
findAssociatedTokenPda and checks that exact address. Also corrects the
provisioning advice: a bare transfer does not create the account, only one
that includes the create instruction does.
Mirrored across en, ja-JP, and zh-CN.
Notorious D.E.V
f1c3511268