IdeaWazaWiki

Cryptocurrencies and wallets for AI agents using the x402 protocol

Cryptocurrencies and wallets for AI agents using the x402 protocol explains how software agents can pay for web resources with digital currency through x402, which assets and networks it supports in October 2026, and how to run an agent wallet with limits that a mistake or an attacker cannot easily exceed. The goal is to help a builder understand the tradeoffs and risks of agent payments, including account freezes by issuers and facilitators, and to list what to check before connecting any wallet to an agent.

Use at your own risk. This page is general educational information, not financial, tax, or legal advice. Cryptocurrency transactions are usually irreversible, prices can change quickly, and software can contain bugs. You are responsible for following the laws and tax rules that apply to you. Use these tools only for legal and ethical purposes. Test with very small amounts first. Details can change; this page was last checked in October 2026.

This page does not sell, recommend buying, or promote any asset.

Safety summary

  • Payments are usually irreversible. An agent that pays the wrong party or pays twice cannot get the money back from a help desk.
  • Test with small amounts first on a test network, then with a few cents on the main network.
  • Never share a seed phrase or a private key with anyone, and never place one in a prompt, a chat, or a log.
  • Beware of fake support and fake apps. Use only official project sites and documentation, and ignore unsolicited offers of help.
  • Check local law and taxes before using any of these tools, and keep records of each payment.


The problem this page starts from

A builder gives an agent a task that needs a paid data source. The usual route is an account, a card, and an API key, steps that suit a person at a keyboard and not a program. The builder then faces two questions. How can the agent pay a stranger per request without an account? And how can the agent hold money without a bad prompt, a leaked log, or a hostile web page draining it? This page covers the first question with x402 and spends most of its length on the second.

What x402 is

The x402 home page calls x402 an open, neutral standard for internet-native payments over HTTP.[1] It reuses the HTTP status code 402, Payment Required, which the official documentation describes as a standard but rarely used code.[2] Coinbase created the protocol. A Linux Foundation announcement dated 14 July 2026 states that the x402 Foundation has launched operationally under open governance and that Coinbase completed its contribution of the protocol.[3] The main repository now lives under the foundation, and the older Coinbase repository is described as a development fork.[4]

There are three roles. The client wants a resource, the resource server sells it, and an optional facilitator verifies and settles payments for the server. The typical flow has these steps:[4]

  1. The client requests a resource.
  2. The server answers 402 with a PAYMENT-REQUIRED header that lists accepted schemes, networks, and prices.
  3. The client picks one option, signs a payment payload, and retries with a PAYMENT-SIGNATURE header.
  4. The server verifies the payload, locally or through a facilitator, then settles it on a blockchain.
  5. The server returns the resource with a PAYMENT-RESPONSE header.

The FAQ states that the buyer signs each payload and that settlement happens onchain, so a facilitator that tampers with a payment fails signature checks.[5] The documentation defines several schemes. The exact scheme charges a fixed amount, upto lets a buyer authorize a ceiling and pay actual usage, batch-settlement uses an escrow channel with off-chain vouchers for many tiny payments, and auth-capture holds funds in escrow for refundable payments.[6] For the wiki overview of the idea, see HTTP 402 Payments for AI Agents: x402.

Assets and networks supported today

The protocol is network agnostic and identifies networks with CAIP-2 identifiers. Any EVM chain can be expressed at the protocol level, and the documentation lists support for Solana, TON, Algorand, Stellar, Aptos, Hedera, Keeta, NEAR, Concordium, XRPL, and Cardano.[7] On EVM chains, any ERC-20 token can be used, through EIP-3009 where the token supports it (USDC does) and otherwise through Permit2. On Solana, any SPL token can be used.

In practice the reference paths are USDC on Base and USDC on Solana. The FAQ lists Base and Solana as the mainnets, with test networks Base Sepolia and Solana devnet.[5] The default stablecoin table pairs several networks with a default token for dollar-priced routes, mostly USDC, with other dollar tokens on some networks, so a price such as one cent can be written as a simple string.[7]

Three cautions apply. First, protocol support is different from production support: a production route needs a facilitator that serves the network, a self-hosted facilitator, or self-facilitation.[7] Second, SDK coverage differs by language; the feature table shows that TypeScript covers more networks than Go or Python.[8] Third, the documentation lists no Bitcoin Cash network. The scheme overview names a Bitcoin Lightning network implementation, but the SDK table does not list it, so check current status before planning around it.

The home page reports statistics for the last 30 days, including about 75 million transactions and about 24 million dollars of volume when fetched; these are self-reported figures with no outside check.[1]

What this means for censorship risk

The common x402 setup depends on a stablecoin whose issuer can act on addresses. The Circle terms say Circle may block USDC addresses and freeze USDC held in addresses that it custodies, and may have to freeze funds on a valid government order.[9] The Tether terms contain similar powers for USDT, which some x402 networks list.[10] Lawful users can face account freezes and political or policy pressure on payment companies, and censorship can occur at four points:

  • The token issuer can block an address that holds or receives the token.
  • The facilitator can refuse a payment. The documentation lists a Coinbase hosted facilitator that runs know-your-transaction and OFAC checks on every transaction, and the FAQ says a payment can fail when an address is flagged.[11]
  • The chain depends on its validators to include transactions.
  • The on-ramp decides how a seller turns tokens into local money.

x402 itself is described as permissionless, and anyone can run a facilitator, so a seller who wants fewer third-party dependencies can self-facilitate, while still following the law. The token layer remains the main dependency. A reader who wants to understand these dependencies can read Low-fee, censorship-resistant cryptocurrencies for the tradeoffs among stablecoins and coins with no issuer. Everyone must still follow sanctions and tax law, and a payment screen at the facilitator exists because the law applies to the operators.

Alternatives and neighbors

  • Lightning and L402. Lightning Labs documents L402, a standard in which a server answers HTTP 402 with a token and a Lightning invoice, built with a focus on agentic commerce.[12] It pays in Bitcoin over channels, which brings liquidity management but no token issuer.
  • Bitcoin Cash. Direct payments need no issuer and have very low fees, though the documentation lists no official x402 scheme for it. See Self-custody of Bitcoin Cash for beginners and Permissionless rails for agent pay.
  • Other stablecoins. Because EVM support covers any ERC-20 through Permit2, a token with different issuer powers can be configured in principle, subject to facilitator support. Check that the token really has the properties you want.
  • Card style agent commerce. Google published the Agent Payments Protocol, which targets authorization, authenticity, and accountability when an agent pays,[13] and the Agentic Commerce Protocol describes checkout flows in which businesses stay the merchant of record.[14] These serve purchases of goods more than small per-request payments.

How a client agent pays and how a seller accepts

A client agent uses an x402 client library that wraps its HTTP calls. When a response is 402, the library reads the requirements, asks the registered wallet signer to sign, and retries. The buyer quickstart shows examples in TypeScript, Go, and Python.[15] A seller adds payment middleware to a route, names its receiving address and price, and points to a facilitator.[16] The seller quickstart asks only for a receiving address, so the key that can spend the proceeds can stay on a hardware wallet or another device that never touches the web server. Publish the receiving address knowing that it is visible to every buyer and on the ledger, and keep one address per service so that income is easy to track for tax records.

Budgets matter on the client side as well. A per-task budget is a counter that the agent runtime keeps outside the model: it starts at an amount a person approves, falls with each payment, and stops the task at zero. The upto scheme complements this, because the buyer authorizes a ceiling for a single request and the seller charges actual usage. The batch-settlement scheme suits an agent that makes thousands of tiny calls to one seller, since it needs one onchain deposit and then off-chain vouchers; the deposit is a larger sum at risk, so size it like any other hot wallet. This page deliberately gives no code. Use the official guides, because package names and options change between versions.

Running an agent wallet safely

The official OWASP guidance on excessive agency explains that harmful actions can follow from hallucination or from prompt injection, whatever the cause of the malfunction.[17] A wallet is a place where such a failure costs money, so limits must live outside the model.

  1. Use a separate hot wallet for each agent or job. Fund it with a small amount, and refill it by hand. Never reuse a personal or savings wallet.
  2. Set caps in code the model cannot edit. The documentation describes spend controls on the client for static dollar caps and asset allowlists, and a before-payment hook for dynamic checks.[18] Add a per-request cap, a per-task budget, a daily cap, and an allowlist of domains and assets.
  3. Keep the key outside the model context. The quickstart examples read a private key from an environment variable, which is acceptable for a test. For real use, put signing in a separate process or service, so the model sees only addresses and results. The documentation points to the Coinbase CDP Wallet API for programmatic wallets;[19] a hosted wallet service brings its own custody and policy questions, so read its terms first. The FAQ says buyers sign locally and sellers never hold a buyer key.[5] Never paste a key or a seed phrase into a prompt, a chat, or a log.
  4. Require human approval above a threshold. The same hook can pause for a person. Choose a threshold small enough that a loss would be tolerable.
  5. Log every payment in a record the agent cannot erase. Store the time, resource, price, network, and transaction hash. Redact secrets from logs.
  6. Guard against double payment. The documentation describes a payment identifier extension for safe retries.[20]
  7. Start on testnet. The public x402.org facilitator is meant for development and works on Base Sepolia and Solana devnet; mainnet routes need a production or self-hosted facilitator.[16][11] Move to mainnet with a few cents, then raise limits slowly.
  8. Plan refunds. The FAQ states that the exact scheme is irreversible once executed, and that refunds are a new transfer by the seller or use escrow schemes.[5] Signed offers and receipts can help with disputes.[21]

See Agent allowlists for spend and publish for a related proposal on allowlists, and Agent-to-agent commerce for the wider loop of discovery, terms, payment, and records.

Limits and risks

  • Stablecoin dependence. The usual assets can be frozen by their issuers, and a facilitator can refuse a payment.
  • Irreversibility. A wrong or manipulated payment cannot be recalled by a help desk.
  • Scams. Fake support, fake wallet apps, and fake documentation sites target new users. Never share a seed phrase or a key.
  • Fast change. Versions, networks, and facilitator options change, and the main repository has moved to the foundation. Verify details against the official documentation.
  • Prompt injection. A page can instruct an agent to pay. Caps and allowlists, not model judgment, must stop it.
  • Quality risk. Paying for a resource does not prove it is accurate or useful.
  • Legal and tax duties. Sellers and buyers can owe tax on income, and sanctions rules apply to the operators.
  • No financial advice. This page names assets only as payment tools and does not recommend any of them.

See also

  1. Discussion question: Which decisions about an agent payment should a person always make, and which can software make alone?
  2. Discussion question: If a stablecoin issuer can freeze an address, does an x402 payment still count as permissionless?
  3. Essay idea: Compare x402 with an API key and a monthly invoice for a service that costs one cent per call.
  4. Essay idea: Argue for or against self-hosting a facilitator for a small seller.
  5. AI prompt idea: Walk me through the five steps of an x402 request in plain language and explain what each header carries.
  6. AI prompt idea: Act as a security reviewer and list ways a prompt injection could try to drain an agent wallet, with a control for each.
  7. AI prompt idea: Help me write a spending policy with per-request, per-task, and daily caps for an agent that buys data, without including any private key.

References

  1. ↑ 1.0 1.1 x402, x402.org, accessed 2026-10-14.
  2. ↑ HTTP 402, x402 documentation, accessed 2026-10-14.
  3. ↑ Linux Foundation announces operational launch of x402 Foundation, x402.org, accessed 2026-10-14.
  4. ↑ 4.0 4.1 coinbase/x402 README, GitHub, accessed 2026-10-14.
  5. ↑ 5.0 5.1 5.2 5.3 FAQ, x402 documentation, accessed 2026-10-14.
  6. ↑ Payment schemes, x402 documentation, accessed 2026-10-14.
  7. ↑ 7.0 7.1 7.2 Networks and token support, x402 documentation, accessed 2026-10-14.
  8. ↑ SDK features, x402 documentation, accessed 2026-10-14.
  9. ↑ USDC Terms, Circle, accessed 2026-10-14.
  10. ↑ Legal, Tether, accessed 2026-10-14.
  11. ↑ 11.0 11.1 Facilitators, x402 documentation, accessed 2026-10-14.
  12. ↑ L402: Lightning HTTP 402 Protocol, Lightning Labs documentation, accessed 2026-10-14.
  13. ↑ Agent Payments Protocol, ap2-protocol.org, accessed 2026-10-14.
  14. ↑ Agentic Commerce Protocol, agenticcommerce.dev, accessed 2026-10-14.
  15. ↑ Quickstart for buyers, x402 documentation, accessed 2026-10-14.
  16. ↑ 16.0 16.1 Quickstart for sellers, x402 documentation, accessed 2026-10-14.
  17. ↑ LLM06:2025 Excessive Agency, OWASP GenAI Security Project, accessed 2026-10-14.
  18. ↑ Lifecycle hooks, x402 documentation, accessed 2026-10-14.
  19. ↑ Wallet, x402 documentation, accessed 2026-10-14.
  20. ↑ Payment identifier, x402 documentation, accessed 2026-10-14.
  21. ↑ Signed offers and receipts, x402 documentation, accessed 2026-10-14.
Retrieved from "https://ideawaza.com/index.php?title=Cryptocurrencies_and_wallets_for_AI_agents_using_the_x402_protocol&oldid=92107"