Two transfer methods, one network (client must choose)
Compliant · GET /api/x402/dual-transfer-method-accepts · Schemes (exact / upto / batch)
On a chain whose asset supports both, advertises one accepts entry per exact transfer method — EIP-3009 and Permit2 — at the same price on the same network, so the client must read extra.assetTransferMethod rather than assume the chain's default.
Explanation
Two payable entries for the same resource on the same network, differing only in extra.assetTransferMethod — one EIP-3009, one Permit2 — so choosing between them is a real decision the client has to make from the challenge. The chain's NON-default method is advertised first on purpose, because the failure this catches is a client that reads accepts[0] for the price and the payTo but signs with whatever method it assumes the chain uses; that produces a well-formed payload whose signature recovers to nobody, and it looks identical to a funding problem. Both entries settle, so there is no wrong choice — only a wrong reason for choosing. On a chain whose asset supports a single exact transfer method there is one entry and nothing to select, which is why this scenario stays compliant on every network.
What to watch
The non-default method is advertised FIRST. A client that takes accepts[0] but signs with the chain's usual method produces a signature nothing can recover. On a single-method chain there is one entry and nothing to choose.
Facilitator
Settled against the live Radius testnet facilitator (https://facilitator.testnet.radiustech.xyz). A valid payment runs a real /verify and /settle on-chain.
Metadata
- Status: Compliant
- Method: GET
- Price: 0.0001 (100 atomic)
- Responsible party: No fix needed