Asks for a signature nobody can build — x402 defect class transfer-method-unrecognized

Asserts: Where an accepts entry names extra.assetTransferMethod, the value is an authorization standard a published x402 client can produce — eip3009 (TransferWithAuthorization), permit2, or erc7710.

What a buyer loses when it is present: A buyer who reads the field has nothing to construct from it and a buyer who ignores it signs blind. The refusal lands before any payment reaches the seller, whose logs record it as nobody wanting the goods. Absence of the field is not this class: it is optional, most doors omit it, and eip3009 is the settled default.

Detectable: by an unpaid probe — a GET nobody paid for can see it.

Falsified by: The same entry naming one of the published methods at the stated moment, or a client implementation that builds an authorization from the named method — the second retires the finding by making the method recognized, and the register is the thing that should move.

How an operator clears it: Name the method your facilitator actually verifies — for USDC on an EVM rail that is almost always eip3009 — or omit the field, which reads as eip3009 by default. If the value names a standard your own stack defines, publishing what a client must build for it turns a door only your clients can walk into one anybody can.

Our signal: transfer-method-signable.

Vocabulary v9, CC BY 4.0. Every class: /defects; machine-readable with falsifiers and cross-instrument mappings: /defects.json. A class describes a property of one endpoint at one moment and never accumulates into a judgment on an operator.