Paying for agent infrastructure with x402 is refreshingly simple: your agent holds a wallet, and it pays a fraction of a cent per call, automatically, with no signup and no API keys. But it does raise one question that trips people up early — not how to pay, but how many wallets to set up.

As your agent grows, reading the web through Skim is just one line on the bill. It will also lean on other paid infrastructure — a vector store for retrieval, a model router, an observability layer, a sandboxed code-execution environment — each one its own service. So: a separate wallet dedicated to each, or a single wallet for all of it?

Use one wallet for your whole deterministic-infra stack — not one per service.

Think of it the way a company thinks about a corporate card. You don't issue a separate card for each SaaS subscription. You have one card with a sensible limit, and you let the statement show you where the money went. Your agent's wallet is that card.

Why one wallet wins

It's simpler to run. One wallet means one balance to fund, one to watch, one to top up. A wallet per service means several funding flows and several ways to run dry in the middle of a task — exactly the kind of friction agents are supposed to remove.

You don't lose cost visibility. This is the part people miss. Every service has its own receiving address, so even when you pay from a single wallet, the blockchain already tags each payment by who received it. You can see "spent $9,000 on Skim, $45,000 on the vector store" without segmenting wallets at all. The recipient does the accounting for you.

Runaway protection still works. The safety valve isn't keeping the balance artificially tiny — it's funding a deliberate runway. Load roughly a month of expected spend plus a buffer, and that balance itself caps your worst case if something loops out of control. A shared tank is actually better at this than a wallet per service, because it bounds the whole stack at once rather than one line item at a time.

When to break out a separate wallet

There's a sensible exception, and the rule is: isolate by risk, not by vendor. Give a dedicated wallet to anything that's expensive, experimental, or from a provider you don't fully trust yet — so a surprise can't drain the budget your reliable tools depend on. And if a single machine runs several different agents for different customers, give each agent its own wallet so you can attribute spend per customer. That's per-agent, not per-service.

Setting it up

The whole thing takes a couple of minutes:

Create a fresh wallet dedicated to agent infrastructure — not your personal one. Its key will live in a config file, so treat it as an operating account, not where you park your treasury.
Fund it to match your real volume. Take your expected monthly call count and multiply by the per-call rate for each service you'll route through it. For Skim that's $0.002 per call — so 10 million reads a month is $20,000, and 50 million is 00,000. Add a buffer, and that's your top-up. Always in USDC on Base (not Ethereum — the most common first-time mistake).
Point your whole stack at that one wallet — paste its private key into each service's config or your agent's MCP setup.
Set a runway, monitor the balance, and automate top-ups as volume grows. Sizing the balance to a month or two of usage — rather than leaving it open-ended — is what makes it your circuit breaker.

The nice payoff: once your agent has a funded infra wallet, adopting a new service like Skim costs almost nothing. You don't fund a new wallet — you just point one more tool at the budget you already keep. That's the whole promise of paid infrastructure that settles in fractions of a cent: it composes.

For the step-by-step wallet walkthrough with screenshots, see the wallet setup page.