FAQ

Short answers to common questions about Burnbound. Each answer links to the page with the details.

What is x402?

x402 is an open protocol for paying for HTTP requests. A paid API answers 402 Payment Required with a price; the client signs a stablecoin payment and repeats the request with it; the seller settles the payment and serves the response. Burnbound supports x402 v2 with the exact scheme in USDC.

How do I limit what my AI agent can spend?

Give the agent a Burnbound policy and let it pay only through Burnbound. You set the hosts it may pay, a maximum per payment, a daily cap and, if you want, a threshold above which a human must approve. The agent pays x402 APIs with the fetch_paid tool of the Burnbound MCP server, and every payment outside those rules is denied before it is signed. Start with the Quickstart; How to limit an AI agent's spending explains each limit.

Which agents and MCP clients are supported?

Any MCP client that can run a stdio server: Claude Code, Cursor and others. The server is the npm package @burnbound/mcp and runs with npx -y @burnbound/mcp. The integrations show the setup for Claude Code, Cursor, Claude Desktop, the Vercel AI SDK, LangChain.js and Mastra. A JavaScript SDK exists but is not published yet; see SDK.

Which networks and tokens can my agent pay with?

USDC on Base, or on Base Sepolia for tests. New agents pay on Base mainnet (eip155:8453). You can switch an agent to Base Sepolia (eip155:84532) when you create it in the onboarding, or later in its Red (network) tab in the dashboard. The policy denies any other network (network_not_allowed) or asset (asset_not_allowed). See Concepts.

How do I test without real money?

Set the agent's network to Base Sepolia, fund its wallet with test USDC from the Circle faucet, and pay an x402 API that charges on Base Sepolia. The flow is the same as on Base: caps, approvals and audit all apply. When you are done, switch the agent back to Base and fund the wallet with real USDC on Base. If the agent and the seller are on different networks, Burnbound denies the payment with network_not_allowed before anything is signed.

Do I need ETH in the wallet?

No. x402 payments are USDC transfer authorizations (EIP-3009) that the seller's facilitator submits on-chain, so the facilitator pays the gas. Your wallet only needs USDC.

Does Burnbound hold my private keys or my money?

No. Burnbound never stores a wallet private key and never holds funds: payments go from your wallet to the seller. With Coinbase CDP, Burnbound stores your CDP API credentials encrypted so it can request signatures for the payments your policy allows. With client-side signing it knows only your wallet's address. See Security and trust model.

Which signing mode should I choose?

Choose Coinbase CDP if your agent can run shell commands or you need enforcement that does not depend on the agent's cooperation: the agent never holds anything that can sign. Choose client-side signing if you want the key on your own machine and accept that an agent with shell access could bypass the policy. See Concepts.

Can my agent raise its own limits?

No. An agent key can read its budget and payments, ask to authorize a payment and check its approvals, but it cannot change the policy, approve a payment or create keys. Those actions need a human signed in to the dashboard.

What happens if Burnbound is down?

Your agent cannot pay, and nothing is charged. fetch_paid fails closed: if it cannot load the agent's allowed hosts or get a decision from Burnbound, it returns an error (control_plane_unavailable, api_unavailable, api_unreachable or api_timeout) and pays nothing.

What happens if a payment does not complete?

fetch_paid returns paid only when the seller served the paid request (a 2xx). Anything else is a tool error with a code, and fetch_paid never signs the payment a second time on its own:

• insufficient_funds: the paying wallet does not hold enough USDC on the payment's network, for example Wallet 0x1234…5678 has 0.00 USDC on Base; this payment needs 0.01 USDC. Burnbound checks this before anything is signed, so nothing was paid. Add USDC to that wallet on that network and try again. The check is a courtesy, not a guarantee: the balance can change before the seller settles, and if Burnbound cannot reach the network it skips the check.
• payment_rejected_by_seller: the payment was signed and sent, but the seller refused it (often with another 402) and did not serve the response. The seller's reason, when it gives one, comes as sellerReason, marked as untrusted text. A common cause is a wallet without enough USDC; another is a seller whose facilitator is failing. Check the cause before trying again.
• payment_not_completed: the seller answered the paid request with something else, such as a redirect or a server error. The payment may still settle; check list_payments before retrying.
• payment_outcome_unknown: the seller's answer was lost. Check list_payments to see whether the payment settled.

In the last three cases the error carries the intentId and the idempotencyKey, and Burnbound records the failed receipt with the seller's status and reason. Retrying fetch_paid with the same idempotencyKey never charges twice. See MCP tools.

Does Burnbound take a fee on payments?

No. Burnbound does not take a percentage of what your agents pay; payments go in full from your wallet to the seller. You pay for the plan.

The approvals inbox, caps, allowed hosts and policy rules are on every plan. Billing is handled by Stripe.

How do I stop an agent from paying?

Revoke its key in the dashboard. The MCP server then gets unauthorized on every call and cannot authorize payments. To stop it immediately without revoking the key, remove its allowed hosts or lower its daily cap: an empty host list allows no payment.

Is there documentation for LLMs?

Yes. /llms.txt lists every documentation page with a one-line description, and /llms-full.txt has the whole documentation as one plain-text Markdown file.