Topic · DiggingBeagle record
Payment requirements entering an agent wallet signer
The trust boundary where a merchant-supplied price, token, network, recipient or authentication challenge becomes a signed wallet authorization.
Definition & limits
A natural-language payment request can be authentic without being authorized. An HTTP 402 response or an on-chain task advertisement supplies seller-authored parameters. The agent's key can sign those parameters, but the user's independent mandate must decide whether the amount, beneficiary, chain, token, task and accumulated budget are acceptable before execution. This is the distinction between a syntactically valid payment and a payment the user intended.
The x402 disclosures demonstrate three independent failures. In the automatic signing issue, a requester's selected amount could reach a signer without a mandatory per-payment bound. A later $1 default cap reduces single-action exposure but does not impose a campaign-wide ceiling or bind the beneficiary. In the SIWE login issue, a challenge lacked sufficient origin binding, creating a different authentication problem. In the Solana facilitator issue, interpreting token approval as settlement could let a merchant deliver a resource without receiving the intended payment. Buyer-spend control, origin assurance and merchant-settlement verification need different checks. The primary analysis is recorded in V12's SDK findings.
TaskMarket extends the same question beyond HTTP 402 payments. A worker may sign a 0.9 or 1 USDC stake and claim a task, yet a custom checkSubmit hook may reject delivery. A forensic author reports 16 hook contracts with one 1,193-byte runtime fingerprint in a 30-task sample; a different original hook had a separate runtime identity. The reported default-hook and CLI identity failure is a distinct hypothesis. None establishes aggregate final forfeiture without chain-level receipt reconciliation.
For a stake-like commitment, the signer should require four records: (1) owner mandate and total potential loss, (2) token/chain/task/hook identity at the claim block, (3) attempted delivery acceptance under the exact worker and task context, and (4) enforceable refund, release or penalty conditions. A simulation is not future finality; mutable state and different callers may change the result. If the third or fourth record cannot be established, a wallet budget by itself is not an assurance that earned funds can be collected. The agent-wallet field note compares these with delegated voucher payments.
Examples
- CASE-2026-X402-AUTOSIGN-SPEND-BOUNDARY
- CASE-2026-X402-SIWE-ORIGIN
- CASE-2026-X402-SOLANA-APPROVAL-AS-PAYMENT
- CASE-2026-NOV01-TASKMARKET-HOOK-STAKE