How to Give Your AI Agent a Wallet (And What It Can Buy for a Cent)

Your agent can read, plan, and call tools. What it cannot do is buy anything.

Every useful API on the internet sits behind a signup form, an API key, and a credit card belonging to a person. That works fine when you are the one clicking. It falls apart the moment you want an agent to go and fetch something it did not know it would need an hour ago. It hits the paywall and stops, or it guesses, which is worse.

There is now a working way around this, and it takes about twenty minutes to set up.

The idea, in one paragraph

HTTP has always had a status code for this. 402 Payment Required was reserved in the original spec and then sat unused for thirty years. The x402 protocol finally gave it a job. A server that wants paying answers your request with a 402 and a small JSON body describing what it costs and where to send the money. Your client pays, retries the same request with a payment header attached, and gets the response. No account, no key, no invoice. The wallet is the account.

What you actually need

Three things, and only three.

A wallet the agent controls. This is an ordinary EVM keypair. You are not doing anything exotic; you are generating a private key and letting your agent sign with it.

Some USDC on Base. Base is where most x402 endpoints settle today, and USDC is the asset almost all of them price in. Five dollars is a sensible starting balance and more than enough to explore.

An x402-aware client. Reference implementations exist for TypeScript and Python, and they wrap the fetch call so the payment handshake happens for you.

One practical relief worth knowing early: in the usual setup your agent signs a payment authorization and a facilitator service submits the actual transaction. Your agent needs USDC. It does not need ETH for gas. Check each endpoint's terms, because not every deployment works this way, but the common path spares you funding a second asset.

What the handshake really looks like

This is a live payment challenge, returned by a browser-automation endpoint when you call it without paying:

scheme:            exact
network:           base
maxAmountRequired: 2000
asset:             0x8335...2913   (USDC)
payTo:             0x03BA...A675
maxTimeoutSeconds: 300

Read maxAmountRequired carefully, because it trips up nearly everyone the first time. USDC carries six decimals, so 2000 is not two thousand dollars. It is two tenths of a cent. The asset field is the USDC contract on Base, payTo is the operator's address, and scheme: exact means the price is fixed rather than metered.

Your client reads that block, signs an authorization for exactly that amount, base64-encodes it into an X-PAYMENT header, and repeats the original request. The server verifies the payment, settles it, and returns what you asked for. From your agent's point of view a single call took slightly longer than usual and then worked.

Now the fun part: what does a cent actually buy?

We index the agentic web and probe the endpoints ourselves rather than reading their marketing pages, so we can answer this with prices we have actually observed rather than what anyone claims. Across 20,413 paid endpoints on hosts we have measured:

11% cost a tenth of a cent or less. 44% cost under a cent. 31% fall between one and ten cents. Only 1.4% cost more than a dollar.

Put differently, the median call is a penny, and five dollars of USDC is roughly five hundred requests.

What is on the other end of those calls is more interesting than the price. Web search built for agents, returning ranked results rather than a page of HTML to parse. Blockchain RPC access. Live market and crypto prices. Hosted browser sessions, so your agent can drive a real Chromium instance for a few tenths of a cent a minute. Document work: OCR, PDF extraction, invoice and ID parsing. Image and media processing. Inference routing that fans one call out to whichever frontier model is cheapest right now.

None of that requires an account with any of those providers. Your agent decides mid-task that it needs a web search, pays a tenth of a cent, and carries on.

The part nobody tells you

Most of what is published about this space is written from listings, and listings lie by omission. Here is the number that should shape how you build.

Of the MCP servers listed in the official registry, 5,085 do not answer a live handshake. We know because we call every one of them. Some were demos. Some are npm packages that were never hosted anywhere. Some worked in March and quietly stopped.

The same rot affects paid endpoints. A directory entry proves somebody once published a description. It does not prove anything is listening today.

So build defensively. Treat every endpoint as something that can vanish, because a meaningful share of them will. Wrap calls in timeouts and fall back to a second provider. Give the agent a spending cap it cannot exceed, ideally by funding the wallet with a small amount and topping it up, rather than trusting a limit you wrote in a config file. Log what it spent and on what, because an agent that can pay is an agent that can waste money in a loop at three in the morning.

And prefer endpoints with evidence behind them. Two signals are worth more than any listing: has this host answered a real handshake recently, and has anyone actually paid it. The second is expensive to fake.

Where to look

Specific endpoints churn, so a list frozen into an article ages badly within weeks. That is exactly the problem this piece has been describing.

We keep the live version. AgentIndex tracks paid and callable endpoints, what they charge, which ones answered when we last probed them, and which have settled real payments on-chain. You can browse it by protocol or capability at agents.traderszone.net, and if you want your agent to search it directly rather than you doing the reading, it speaks MCP.

Fund a wallet with five dollars. Point your agent at something that costs a tenth of a cent. The first time it pays for a search on its own and keeps going, the whole model clicks.