First, a
funded wallet.

You need one thing: an EVM keypair that can sign on Base. Any Base-compatible wallet produces one. There is no signup, no email, no approval and no API key to provision — the address is the identity, and the first anyone here learns about you is that an address paid for a call.

For an agent, be concrete about what “a wallet” means. The published clients — the MCP server, the ElizaOS plugin, the LangChain / Vercel AI / AgentKit / CrewAI / GAME packages — take a private key in their configuration and sign in-process, because there is no human present to approve a popup. So what you actually need is a key you are willing to paste into a config file. Hold that thought until §03.

Payments settle in USDC, a dollar-denominated stablecoin, and the 402 response names the exact contract and network it will settle against — eip155:8453, which is Base. Two ways to get it there: buy USDC somewhere that lets you withdraw to Base, or move USDC you already hold on another chain across a bridge. Whichever you pick, check the network at the point of withdrawal.

The mistake worth naming: balances are per-chain. The same address exists on Ethereum and on Base, but USDC sitting on Ethereum mainnet cannot pay a Base quote. It is not lost — it is simply on the wrong chain, and has to be moved before it can pay.

You do not need ETH. This surprises people, so it is worth stating flatly: paying for an x402 call costs you no gas. You sign an EIP-3009 authorization off-chain and the facilitator submits it on-chain, paying the gas itself. The payer never sends a transaction. A wallet holding only USDC can buy from every stall here. (Moving funds back out of that wallet yourself is an ordinary on-chain transfer and follows the usual rules — but that is you spending, not us charging.)

How much to start with? The prices are published per stall, so you can do the arithmetic rather than guess: a Base token-safety check is $0.005 and a token report or a screenshot is $0.01, so a dollar of USDC is two hundred safety checks. Fund the amount that matches the evaluation you intend to run — the next two sections are about why that number is the decision, not a detail. The catalog lists every current price.

Make a fresh wallet for this and nothing else. Not a treasury, not a long-lived identity address, not the one holding your positions. A dedicated low-balance burner, funded with an amount you would be annoyed to lose rather than harmed by.

Three reasons, all of them structural rather than distrustful. The key lives in an agent config or an environment variable, which is a place secrets leak from. The agent signs without a human confirming each payment, so a bug in your own loop spends real money. And every payment publishes the address (§05), which permanently links whatever else that address has ever done to this activity. A burner turns all three from a risk into a bounded cost.

Per call. Every published client carries a hard ceiling on a single payment — MAX_PAYMENT_USDC and its equivalents, default $0.25. Over it the client refuses to sign, so no quote can talk your agent into authorizing more than you allowed. Set it near the prices you actually use; the default is headroom, not a recommendation. One stall is priced per page rather than per call (seo-audit), so a large audit can legitimately quote above a low ceiling and be refused — raise it deliberately if you want that one.

Each authorization is also signed for exactly the quoted amount. An overpayment is rejected, not credited, so a single call cannot draw more than the price you were quoted.

In total. Here is the straight answer: there is no server-side cumulative cap on what one buyer may spend. We do not track a running total per wallet, and nothing on our side interrupts an agent that calls in a loop. The per-IP rate limit exists to keep the service standing up, not to protect your balance — treat it as a service limit, never as a spend limit.

So the ceiling on total spend is the wallet’s own balance. Each payment is an authorization drawn against it, and it cannot draw what is not there. That is not a workaround; it is the actual control, and it is why §02 and §03 are the same decision: fund the burner with only what you are willing to spend, and keep the per-call cap set. Top it up when it runs down. A balance you would not want spent in an afternoon should not be in the wallet your agent signs with.

You can get a real answer before any of this. The on-chain safety stalls — token safety, token report, address safety, the new-pairs / liquidity-pulls / whale-swaps feeds, liquidity history, tx-preflight, the quant calculators, DeFi yields and prediction markets — serve a small number of free calls per IP per day. No wallet, no signup.

To see what is left without spending one, ask: GET https://true402.dev/api/v1/free-trial. It answers with quota, used, remaining and the UTC instant the allowance resets, and reading it never costs a call. Every paid response also carries the X-Free-Trial header (curl -i shows it) reporting the same thing after the fact. The trial is aimed at server-side callers — an agent, a script, curl, MCP, an SDK — so a page on someone else’s site cannot spend its visitors’ allowance.

When the allowance runs out, or on a stall that has none, the same request answers 402 with a price and your funded wallet takes over: sign, retry, get the result. The wire format is on the buy page, the protocol itself in what is x402, and the drop-in clients under integrations.

One thing belongs in a funding decision rather than a footnote: on-chain settlement is public and permanent. Nobody can delete it — not us, not you. Each paid call ties your payer address to an amount and a timestamp, so repeated calls from one wallet accumulate into a public record of what that agent buys and when it runs.

That is a property of the rail, not a policy of ours, and it is the fourth argument for a burner: the address that pays is the address that appears. What we ourselves keep is listed field by field on the privacy page.