DEV Community: cryptonite cryptonite

How AI agents pay for APIs without an API key

cryptonite cryptonite — Fri, 03 Jul 2026 06:04:31 +0000

Originally published at true402.dev/guides/how-ai-agents-pay-for-apis-x402.

An autonomous agent can't sign up for an account or paste in a credit card — but it has a wallet. The x402 protocol lets it pay for any API per call, with no key, no account, and no human in the loop. Here's how it works.

The problem: API keys assume a human

An API key presumes someone signed up, entered a card, and manages the secret — plus rate-limit tiers, key rotation, and a billing relationship per provider. None of that fits software that runs on its own. For an autonomous agent, every keyed API is a human-shaped bottleneck in front of an otherwise machine-to-machine transaction.

The fix: HTTP 402, revived

x402 turns the long-dormant HTTP 402 "Payment Required" status into a real payment rail. The service answers an unpaid call with 402 and a price; the agent signs a USDC payment with its wallet (EIP-3009) and retries. The signature is auth and payment — so there's nothing to sign up for and no key to manage.

The flow: 402 → sign → 200

# 1) Unpaid request → 402 with the price.
curl -i -X POST https://true402.dev/api/v1/token-safety -d '{"token":"0x…"}'
HTTP/1.1 402 Payment Required
{ "accepts": [{ "scheme":"exact", "network":"eip155:8453",
                "asset":"0x833589…USDC", "amount":"5000" }] }   # $0.005

# 2) Agent signs an EIP-3009 USDC authorization and retries with X-PAYMENT.
curl -X POST https://true402.dev/api/v1/token-safety \
  -H "X-PAYMENT: <base64 signed authorization>" -d '{"token":"0x…"}'
HTTP/1.1 200 OK   # the result — no account, no API key

What it unlocks

No sign-up, no API key, no KYC, no rate-limit tier. The agent pays a few hundredths of a cent when it needs an answer and nothing when it doesn't. Gas is sponsored by the facilitator, so the wallet only needs a little USDC on Base. And because services publish machine-readable surfaces (OpenAPI, MCP, llms.txt), an agent can find and pay for one with no human integration step.

Client libraries (x402-fetch, x402-axios) automate the sign-and-retry. Or skip HTTP entirely and use an MCP server so the paid call shows up as a native tool in Claude, Cursor, or any MCP client.

A live example

true402 is an x402 marketplace of agent-payable tools on Base — on-chain token safety (rug/honeypot checks with a real buy/sell simulation), DeFi signals, web/SEO audits, and LLM inference, each $0.001–$0.015 per call, no key. Try one with zero setup:

npx @true402.dev/rugcheck 0x<any-base-token>   # free to try, no wallet needed

FAQ

How can an AI agent pay for an API without an API key?
With x402. Instead of a pre-issued key tied to a human account, the service answers an unpaid request with HTTP 402 and a price; the agent signs a USDC payment with its own wallet and retries. The wallet signature is both authentication and payment.

Why are API keys a poor fit for autonomous agents?
Keys assume a human signed up, entered a card, and manages the secret. An agent has none of that — it has a wallet. Keys also mean tiers to negotiate, secrets to store and rotate, and a billing relationship per provider. Pay-per-call removes all of it.

What does an agent need to pay over x402?
A wallet holding a little USDC on the chain the service settles on (commonly Base). Gas is typically sponsored by the facilitator via EIP-3009, so the wallet needs only USDC, not ETH.

Your rug scanner says clean. The token still won't sell.

cryptonite cryptonite — Fri, 03 Jul 2026 05:58:23 +0000

Originally published at true402.dev/guides/static-scan-vs-honeypot-simulation.

A token can pass a rug-checker and still refuse to sell. The reason is a gap in how most checkers work — they read the contract but never run it. Here's what a static scan can't see, and what a simulation catches.

What a static scan does: read the contract for bad patterns

A static rug scanner (Token Sniffer and most "rug checkers" work this way) reads the contract's bytecode or source and flags known-bad patterns: a mint function, a blacklist, a 100% sell tax, non-renounced ownership, lopsided holder distribution. It's fast, free, and genuinely useful for catching the obvious stuff.

The blind spot: it never runs the trade

Because a static scan only reads, it can't see traps that only appear at runtime:

an upgradeable proxy whose logic is swapped after launch,
a sell that reverts only above a certain size (max-tx / anti-whale traps),
a block that depends on external state,
conditions a static read just can't evaluate.

The contract looks clean — and still won't let you sell.

What a simulation does: actually buy, then sell

A honeypot simulation trades the token without spending anything: it runs a buy and then a sell in a single gas-free eth_call with a state override — no real transaction, no on-chain footprint — and measures whether the tokens come back out. If the sell reverts or returns dust, it's a honeypot.

Because it executes the real transfer path, it catches the runtime sell-block a scan can't. The key property: the "did WETH actually come back out" measurement can't be faked by the token contract, because it's the real swap code path being executed.

true402's implementation probes at two sizes, so it also catches the nastier variant — sellable small, blocked at size.

The honest take: use both

Static scans aren't useless — they're a fast, free first filter for the obvious red flags. But for anything you're about to actually buy, add a simulation that proves the sell works. The strongest check does both in one pass: structural checks (mint, ownership, proxy), liquidity depth, and the buy/sell simulation, returning a single avoid/caution/ok verdict.

# Free to try — a few checks a day, no wallet, no signup. Simulates the buy + sell on-chain.
npx @true402.dev/rugcheck 0x<token>

# ⚠️  CAUTION (score 75/100)
#   • ownership is not renounced
# checked on-chain: honeypot sim + liquidity + ownership

For agents: the simulation, pay-per-call

If you're building a trading bot or agent, wire the check in as a pre-trade gate: POST https://true402.dev/api/v1/base/token-report over x402 — pay per call in USDC on Base, no account, no API key. There's also an MCP server (npx @true402.dev/mcp-server) that exposes it as a native agent tool.

FAQ

Can a token pass a rug-checker and still be a honeypot?
Yes. Most rug-checkers do static analysis — they read the contract for known-bad patterns. That catches the obvious traps, but it cannot run the contract, so it misses honeypots whose sell-blocking only happens at runtime. The only way to be sure is to simulate the sell.

Is a static rug scanner like Token Sniffer enough?
It's a useful first pass — fast, free, good at flagging mint/blacklist/fee/concentration red flags. But static scanners share one blind spot: they don't execute the trade. For anything you're about to actually buy, pair the scan with a buy/sell simulation that proves the token can be sold.

What is a honeypot simulation and how does it work?
It actually trades the token, without spending anything: a buy then a sell inside a gas-free eth_call with a state override — no real transaction — measuring whether the tokens come back out. If the sell reverts or returns dust, it's a honeypot.

How do I verify a token is sellable before I buy?
Run a check that simulates the round trip and inspects contract structure and liquidity in the same pass, returning one verdict. Free to try a few times a day via npx @true402.dev/rugcheck 0x…, then pay-per-call over x402 — no account, no API key.

What is x402? The HTTP payment protocol for AI agents, explained

cryptonite cryptonite — Fri, 03 Jul 2026 05:57:47 +0000

Originally published at true402.dev/guides/what-is-x402.

x402 is how software pays software — money over HTTP, using a status code that sat unused for 25 years. No accounts, no API keys, no monthly plans. A request gets a price; the client pays; the result comes back. Here's the whole idea.

The 402 finally means something

HTTP reserved a status code — 402 Payment Required — back in the 1990s, then left it blank for decades because the web had no native way to pay. x402 fills that blank: a server answers an unpaid request with 402 and machine-readable payment terms, the client pays, and the request succeeds. It's a payment layer built into the request itself, introduced by Coinbase in 2025 as an open standard, now stewarded by the x402 Foundation.

Five steps, no signup

Request a paid resource with no payment.
402 comes back with the terms — amount, asset (USDC), recipient, network (e.g. Base).
Sign a stablecoin authorization (EIP-3009 — a gasless USDC transfer, signed off-chain).
Retry with an X-Payment header carrying the signature.
Verify & serve — the server checks the payment (via a facilitator) and returns the result; settlement to chain happens async, so it doesn't slow the response.

Here's what that looks like against a real endpoint:

# Ask a paid endpoint with NO payment → the server tells you the price:
curl -i -X POST https://true402.dev/api/v1/base/token-report \
  -H 'content-type: application/json' -d '{"token":"0x…"}'

# HTTP/2 402 Payment Required
# payment-required: { "amount":"5000", "asset":"USDC", "network":"eip155:8453", "payTo":"0x…" }
#
# → sign that USDC authorization with your wallet, retry with an X-Payment header, get the result.
# No account. No API key. The wallet is the identity.

Built for agents, not forms

Every API today assumes a human: sign up, get a key, add a card, manage a plan. An autonomous AI agent can't do any of that. x402 removes all of it — the wallet is the account, and payment is one signed message per call. An agent can discover a service and pay for it with no human in the loop, no credentials to store, no subscription to cancel.

That's why x402 matters now: agents are starting to transact, and they need a payment rail that's machine-native. (For a side-by-side with the alternatives, see x402 vs API keys, Stripe, and L402.)

Pay for things. Sell things.

As a buyer: pay per call for data, tools, and inference — no account.
As a seller: gate any HTTP endpoint behind a 402 and get paid in USDC with no merchant account and no chargebacks.
Agent-to-agent: agents pay each other for sub-tasks, composing services on the fly.

true402 is a live x402 marketplace doing exactly this — on-chain safety checks, DeFi signals, web tools, and LLM inference, all pay-per-call.

Try it in one line

Run a real x402 call with no setup — npx @true402.dev/rugcheck 0x… (free to try), or check a token in the browser.

FAQ

What is x402?
An open protocol that lets software pay for things over HTTP using the 402 "Payment Required" status code. A server responds to an unpaid request with HTTP 402 and machine-readable payment terms; the client pays with USDC by signing an authorization, retries with a payment header, and the server verifies and serves. No accounts, no API keys — the wallet is the identity.

What is HTTP 402?
A status code reserved in the HTTP specification since the 1990s but never standardized — it sat dormant for decades waiting for a native web payment mechanism. x402 finally gives it a concrete meaning: a 402 response carries the price, the asset, the recipient, and the network, so a client knows exactly how to pay and retry.

Do I need an account or API key to use x402?
No — that is the point. There is no signup, no API key to provision or rotate, and no monthly plan. A client pays per call by signing with its wallet, and the wallet address is the identity. This is what makes x402 a natural fit for autonomous AI agents.

What chains and tokens does x402 use?
x402 settles in stablecoins — most commonly USDC — over EVM chains, with Base as the primary network (low fees, fast finality). The payment is an EIP-3009 signed authorization, so the payer doesn't need native gas; the facilitator submits it.

What is an x402 facilitator?
A service that verifies and settles x402 payments on behalf of the resource server, so the server never touches the blockchain itself. The server hands the signed payment to the facilitator, which checks it and submits the settlement on-chain — keeping the API fast while staying chain-backed.