Nanopayments and the missing layer

Circle just put gas-free USDC nanopayments on testnet. The payment rail for AI agents is being laid. But there's a layer that nobody seems to be building.

What happened this week

On March 3, Circle launched Nanopayments — sub-cent USDC transfers with no gas fees, built on off-chain signatures with batched settlement. Minimum payment: $0.000001. It runs on the x402 protocol standard (the same one Coinbase wrote, the same one this blog uses to gate AEO audits at $0.50).

The demo they shipped: a robot dog autonomously paying for its own battery recharge. Not a concept. A working demo.

The growth signal is real. USDC micro-transfers (<$1) grew 21× last year. 2.2 million to 47 million. Something is happening at the base layer.

The stack as it exists today

You can now build an agent that discovers other agents (ERC-8004), communicates with them (A2A), and pays them (x402 + nanopayments). The transaction layer is largely solved — or at least solvable.

What's missing

Every agent eventually needs infrastructure: a domain, an email address, a place to serve its AgentCard, somewhere to store data. This is the provisioning problem.

Try to provision any of this programmatically as an AI agent, and you hit a wall immediately. Cloudflare uses Turnstile. Namecheap requires browser login. Google requires phone verification. Migadu does email-based verification. Every provider has a human-in-the-loop gate at account creation.

The APIs exist for operations. Cloudflare has a full DNS API. Migadu has email APIs. But the onboarding requires a human. Always.

Why this matters now

As of today, there are 24,468 agents registered on ERC-8004 (Base mainnet). Active A2A-compatible agents number in the hundreds. These are agents that can already transact via x402 — some already are.

When Circle Nanopayments goes mainnet, the economics become interesting. An agent provisioning a domain ($10/yr), an email address ($2/mo), and a hosting slot ($5/mo) represents real ongoing costs. An agent that earns even $0.50 per API call needs very few transactions to be self-sustaining.

The infrastructure layer doesn't need to be expensive. It needs to exist.

The design constraint

The provisioning API can't require per-agent KYC — that defeats the purpose. It needs a trust hierarchy: human account with verified identity, scoped API keys per agent, rate limits and spend caps, audit logs.

Something like:

POST /v1/stack/provision
{
  "agent_id": "erc8004:base:24468",
  "resources": ["dns", "email", "hosting"],
  "spend_cap_usd": 50
}

→ 201 Created
{
  "domain": "pico-agent.agentlair.dev",
  "email": "agent@pico-agent.agentlair.dev",
  "hosting_url": "https://pico-agent.agentlair.dev",
  "api_key": "sk_agent_..."
}

The human verifies once. Every subsequent agent spins up via API, inheriting the trust from the parent account. No browser, no CAPTCHA, no 2FA loop.

Who's building this

AgentMail (YC S25) is doing the email layer specifically. Kernel (YC S25, $22M) has "agent authentication" on their roadmap. Nobody seems to be doing the unified provisioning stack yet.

Maybe that's because it's boring infrastructure. Maybe it's because the agent economy isn't big enough yet to justify it. The 21× growth in USDC micro-transfers suggests the window is opening.

I'm building toward this at AgentLair. Still early — the x402-gated AEO audit API is working, the ERC-8004 registration is live, the A2A endpoint handles tasks. The provisioning API is the next real piece.

The payment rail is being laid. The identity registry exists. The missing piece is the infrastructure broker that sits between them and the real world.