The problem ChainAgent solves

Centralized AI platforms lock credits (non-withdrawable, expiring), require KYC/accounts for access, block anonymous usage, and prevent AI agents from autonomously paying for frontier models (Claude,GPT, Grok, etc.). This wastes capital, leaks privacy,and stalls the agent economy.
Solution: ChainAgent — Decentralized AI Credit Marketplace with x402 Micropayments
Turn locked OpenRouter (or similar) credits into liquid USDC on Base via a pay-per-use proxy API.

• Sellers run a simple proxy forwarding to top models using their credits.
• Protect it with x402 (HTTP 402 Payment Required) — users/agents pay tiny USDC amounts per request (e.g., $0.01–$0.10).
• Payments settle instantly onchain to seller's wallet → fully withdrawable anytime.
• No KYC, no accounts — pure wallet-based, anonymous access.
• ENS-powered discoverability: Register e.g. chainagent.eth → users/agents resolve it to your proxy URL.
• Creative ENS twist: Text records store metadata (supported models, dynamic pricing per 1M tokens, status like "online / 60% credits left", reputation link) → enables autonomous agent discovery & trust (aligns with ERC-8004 trends).

How It Works

1. Seller sets ENS (e.g., chainagent.eth) → points to proxy + text records for models/pricing/address.
2. User/Agent resolves ENS → gets URL + pricing.
3. Requests proxy → gets 402 + payment demand.
4. x402 client (HeyElsa SDK, extension, agent lib) auto-pays USDC on Base → retries → gets AI response.
5. Proxy forwards internally with seller's key → seller earns & withdraws USDC freely.

Challenges we ran into

Challenges I Ran Into
ENS resolution on testnet was trickier than expected. I initially created the ENS provider without specifying the network, and name lookups silently failed. The fix was simple — pass 'sepolia' as the network — but it took a while to figure out because ethers.js doesn't throw, it just returns null. The ENS docs saved me here: "Specify the chain ID to whichever ENS network you're using."

Replay attacks across server restarts. My first replay guard was just an in-memory Set of used tx hashes. Worked great... until the server restarted and every old tx could be replayed. I ended up checking the transactions table in Supabase first (which has a unique constraint on tx_hash), then falling back to the in-memory set for speed.

x402 payment verification timing. When a buyer sends USDC on Base Sepolia and immediately retries with the tx hash, the transaction often isn't confirmed yet. I kept getting "tx not found" errors during testing. The solution was adding clear messaging in the 402 response telling clients to wait for confirmation before retrying.

Race condition in earnings counters. Under concurrent requests, two payments could read total_earned_usdc = 5, both write back 6, and one payment's earnings would vanish. Fixed it with an atomic SQL function (total_earned_usdc = total_earned_usdc + amount) instead of read-increment-write in JS.

API keys leaking through a legacy endpoint. The /api/proxies endpoint correctly masked seller API keys, but I forgot the old /registry endpoint returned raw data — including full API keys. Caught it during a security review and patched both endpoints to strip sensitive fields.