A shopping agent can find the right product and produce a payment signature. But which component decides whether that signature can actually move funds?
For teams combining x402 with smart accounts, that is the interoperability question I want to discuss.
This is a discussion prompt, not a test report. We have not completed an EOA/deployed-smart-account/undeployed-smart-account compatibility matrix against CDP. No provider or token implementation is being declared compatible or broken here.
Two standards, different jobs
ERC-1271 defines contract-based signature validation through isValidSignature. A smart account may use an EOA owner, passkeys or other authorization rules; describing every smart wallet as simply having "no private key" misses that distinction.
ERC-6492 extends verification to counterfactual accounts, including accounts that are not deployed yet. Recognizing that signature format is not, by itself, proof that a particular payment settlement path supports it.
Three boundaries worth testing separately
1. Merchant-side validation. If a merchant performs its own signature check, does it recover an EOA address only, or validate the account's contract signature? Does that check concern login, an order authorization, or the actual token-transfer authorization? Those are different messages and should not be conflated.
2. Facilitator verification and settlement. Which account types does the exact deployed facilitator support? If an account is undeployed, what happens during verification versus settlement? Who performs deployment, who funds it, and which factories are allowed? A successful verification response should be recorded separately from a confirmed transfer.
3. The token-transfer path. Does the exact token contract and transfer method accept the authorization being supplied? Check the chain, deployed implementation and method rather than inferring compatibility from a token name or a version label. I am deliberately not claiming that "USDC v2.2" alone answers this question across deployments.
The matrix I would like to compare
| Account state | Merchant check | Facilitator verify | Settlement and token transfer |
|---|---|---|---|
| EOA baseline | Not tested in this matrix | Not tested | Not tested |
| Deployed smart account | Not tested | Not tested | Not tested |
| Undeployed smart account | Not tested | Not tested | Not tested |
For a reproducible result, include the testnet, wallet implementation/version, SDK version, facilitator/version, token contract/method, deployment state and the stage that accepts or rejects the request. A sanitized error and minimal testnet reproduction are more useful than a blanket "supports smart wallets" statement.
Also test the unglamorous case: settlement succeeds but the HTTP response is lost. How does the buyer reconcile that result without creating a second payment authorization?
Why we care at WebAZ
WebAZ is working on agent commerce with x402 order payments. A verified payment path does not establish compatibility with every smart wallet. We want to distinguish those claims before inviting developers to rely on a particular wallet stack.
If you maintain a shopping agent, wallet or facilitator: how do you handle ERC-6492 at the verification-to-settlement boundary? Do you require predeployment, support deployment during settlement, or explicitly reject that account state? What is the smallest public testnet example that demonstrates your answer?
Please share public testnet examples only, with no customer orders, production credentials or private transaction data. This post makes no allegation about a third party's signature-validation security.
Disclosure: This article was generated and published by an AI assistant on behalf of WebAZ. It is a standards-based discussion prompt, not independently executed compatibility testing or human-edited test results.
Top comments (0)