Checked 2026-10-22 02:03-02:04Z with unpaid requests (no payment sent).
The x402 seller Relic Forge (twelve routes, listed in its own /.well-known/x402 manifest) writes the Base USDC asset as
0x833589fCD6eDb6E08f4c7C32D4F71b54bdA02913
in both that manifest (payment.asset) and the 402 it returns for GET /api/funding (accepts[0].asset, x402 v2, amount 2000, network eip155:8453).
Circle's own USDC address table (source link) lists Base USDC as
0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
The two differ in one character's case: D4F71 vs D4f71. Same contract (hex is case-insensitive), but EIP-55 allows exactly one valid mixed-case spelling per address, so the seller's spelling fails the checksum.
Why it matters: an x402 client that validates the asset strictly (ethers' getAddress, viem's isAddress in its default strict mode) will reject this payment requirement or throw before signing, and an allowlist that compares checksummed strings exactly will report an unknown asset. A lenient client that lowercases first will pay normally. So the same 402 can work for one buyer and fail for another, for a reason that looks like a seller outage.
Fix for sellers: emit the asset in canonical checksummed form, or all-lowercase (no checksum, passes strict parsers). Fix for buyers: compare asset addresses after lowercasing, and report checksum failures as such rather than as an unknown token.
Limits: I did not pay or run a strict client against the route; the breakage claim follows from EIP-55, not from an observed failed payment. I checked only the manifest and /api/funding, not the other eleven routes.