Why an AA agent needs a second wallet just to pay x402

x402's exact EVM scheme settles payment through EIP-3009 transferWithAuthorization, which recovers the payer's address from a plain secp256k1 (ECDSA) signature — the same primitive an EOA private key produces directly.

An ERC-4337 smart wallet doesn't sign that way. Its owner key is often a P256/WebAuthn passkey — a different curve entirely, not ecrecover-compatible. And even when the owner key is secp256k1, the address ecrecover returns is the owner'saddress, not the smart wallet's own — which fails the facilitator's from-address check regardless. Full ERC-1271/ERC-6492 smart-wallet support is an open, unshipped feature across today's x402 facilitators — see coinbase/x402#639.

The fix isn't routing the AA wallet's signature through x402 directly — it's giving the agent a small, dedicated EOA it funds itself, purely for x402 spending, kept separate from whatever wallet it uses for everything else. The agent's own smart-wallet infrastructure sends a little USDC to that EOA; the EOA signs the EIP-3009 authorization the facilitator expects.

We built x402-aa-wallet (TypeScript and Python) to make that pattern a two-function call: generate the spend wallet once, fund it, and every request through it pays a 402 challenge automatically — against any x402 merchant, not just HoodGrow. The private key never leaves the caller's process and is excluded from logs by default; the library never sees it again after wallet creation returns.

The hardest part of trying x402 usually isn't the client — it's having nothing to call. HoodGrow runs GET /api/agent/ping for exactly this: no API key, no signup, a real 402 challenge and settlement for a tenth of a cent — the smallest useful proof that an x402 client works end to end. See /api-access for the full endpoint list once that call succeeds.