```
Running without a code and with no existing balance will link you to the web onboarding.
## 2. Give your agent the skill
The simplest way to connect AgentCash to your agent is through the skill file. Add this URL to your agent's context or configuration:
```
agentcash.dev/skill.md
```
This teaches your agent how to discover and use all available premium APIs.
Add a rule file at `.cursor/rules/agentcash.md` with:
```markdown theme={null}
Set up agentcash.dev/skill.md
```
Or just tell your agent: "Set up agentcash.dev/skill.md"
Add to your `CLAUDE.md` or tell Claude directly:
```
Set up agentcash.dev/skill.md
```
Or install as an MCP server for tool-based access:
```bash theme={null}
claude mcp add agentcash --scope user -- npx -y agentcash@latest
```
Point your agent at `agentcash.dev/skill.md`, or install [MCP mode](/docs/mcp-mode) for direct tool access.
If you onboarded through the web flow, the CLI already installed the skill and configured MCP for detected clients. You can skip this step.
## 3. Ask your agent to do something
Ask your agent to use any premium API. For example:
> Use AgentCash to look up the company "Anthropic" on stableenrich.dev.
The agent will:
1. Discover available APIs
2. Check the price
3. Pay with USDC from your wallet
4. Return the results
You're set up. Your agent can now access 3,200+ premium APIs.
## Next steps
Browse available services and their pricing.
Use AgentCash directly from the terminal.
Run AgentCash as an MCP server in your AI client.
Understand the x402 and MPP payment flows under the hood.
# Provider quickstart
Source: https://agentcash.dev/docs/quickstart-providers
Copy and paste this prompt into your coding agent and it will figure out where you are and what you need in order to start selling your API to agents.
Building in TypeScript, or starting from scratch? Use [AgentCash Router](/docs/router/overview) instead: it handles payments, wallet identity, and discovery for you, and the [Vercel template](/docs/router/quickstart) deploys a working pay-per-call API in one click.
## When the agent finishes
1. Your API should respond with `402` and payment metadata on unpaid requests.
2. Your `/openapi.json` should describe each payable route with pricing info.
3. Your origin will be registered on [x402scan](https://x402scan.com) and/or [mppscan](https://mppscan.com) so agents can find you.
# Configuration
Source: https://agentcash.dev/docs/router/configuration
Environment variables, KV stores, and plugin hooks for @agentcash/router.
## Two ways to initialize
**`createRouterFromEnv` (recommended)** reads `process.env`, validates every value up front, and throws a single `RouterConfigError` listing every problem at once. Protocols toggle on by presence: x402 when the CDP key pair is set, MPP when `MPP_SECRET_KEY` is set (at least one is required).
```typescript lib/router.ts theme={null}
import { createRouterFromEnv } from '@agentcash/router';
export const router = createRouterFromEnv({
title: 'My API',
description: 'Pay-per-call search.',
guidance: 'POST /search with { q: string }. Returns top 10 results.',
});
```
**`createRouter(config)`** takes an explicit `RouterConfig`: use it for custom networks, multiple payees, non-standard assets, or anything the env entry point doesn't expose. It runs the same validation.
## Core
| Var | Required | Purpose |
| ------------------- | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `EVM_PAYEE_ADDRESS` | yes | `0x…` address that receives x402 and MPP payments. The zero address is rejected. |
| `BASE_URL` | yes outside Vercel | Origin URL (`https://api.example.com`). Used as the 402 realm, OpenAPI server URL, and MPP memo prefix, so it must match your public domain. On Vercel it is auto-derived from `VERCEL_PROJECT_PRODUCTION_URL`, then `VERCEL_URL`. |
## x402
Auto-enabled when both CDP vars are set.
| Var | Required | Purpose |
| -------------------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `CDP_API_KEY_ID`, `CDP_API_KEY_SECRET` | when x402 is enabled | [Coinbase Developer Platform](https://portal.cdp.coinbase.com/projects/api-keys) credentials for the default EVM facilitator. The free tier is enough. |
| `X402_BUILDER_CODE` | no | Base Builder Code for ERC-8021 on-chain attribution. Credits each settled payment to your app on the [Base dashboard](https://dashboard.base.org). |
| `SOLANA_PAYEE_ADDRESS` | no | Adds a Solana accept. Solana clients can only pay static-priced `.paid()` routes (`.upTo()` is Base-only and `.session()` is MPP-only). |
Creating the router kicks off a background fetch of the facilitator's supported payment kinds, including during `next build`. With missing or placeholder CDP keys you'll see `[x402] facilitator /supported failed, using hardcoded baseline` in build logs. That's a graceful fallback, not a fatal error.
## MPP
Auto-enabled when `MPP_SECRET_KEY` is set.
| Var | Required | Purpose |
| ------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `MPP_SECRET_KEY` | when MPP is enabled | Server-side MPP secret (`openssl rand -hex 32`). |
| `MPP_CURRENCY` | when MPP is enabled | Tempo currency address. Use the exported `TEMPO_USDC_ADDRESS` constant for Tempo USDC. |
| `MPP_OPERATOR_KEY` | for `.session()` | Signs server-side close/settle. Setting it auto-enables session mode. Must be the private key **of** `EVM_PAYEE_ADDRESS`. |
| `MPP_FEE_PAYER_KEY` | no | Sponsors client gas for channel open/topUp. Must resolve to a different address than the operator. |
| `TEMPO_RPC_URL` | no | Tempo JSON-RPC endpoint. Defaults to the public `https://rpc.tempo.xyz`. |
For local development, mint a throwaway keypair where payee and operator line up:
```bash theme={null}
node -e "const {generatePrivateKey, privateKeyToAccount} = require('viem/accounts');
const pk = generatePrivateKey();
console.log('EVM_PAYEE_ADDRESS=' + privateKeyToAccount(pk).address);
console.log('MPP_OPERATOR_KEY=' + pk);"
```
## KV store
| Var | Required | Purpose |
| -------------------------------------- | -------------------------- | ------------------------------------------------------------------------------------- |
| `KV_REST_API_URL`, `KV_REST_API_TOKEN` | recommended for production | Upstash / Vercel KV. Backs SIWX nonces, SIWX entitlements, and MPP replay protection. |
Without a KV store, this state lives in per-process memory. On serverless or multi-instance deployments, a wallet that paid on instance A is treated as unpaid on instance B, so pay-once-then-replay routes charge users twice. Attach a KV store before production traffic.
## Plugin hooks
Pass a `RouterPlugin` to observe the request lifecycle. All hooks are optional and fire-and-forget: they never delay the response.
```typescript theme={null}
import { createRouterFromEnv, type RouterPlugin } from '@agentcash/router';
const myPlugin: RouterPlugin = {
onRequest(meta) {},
onPaymentVerified(ctx, payment) {},
onPaymentSettled(ctx, settlement) {},
onResponse(ctx, response) {},
onError(ctx, error) {},
onAlert(ctx, alert) {},
};
export const router = createRouterFromEnv({
title: 'My API',
plugin: myPlugin,
});
```
### Debugging with `onAlert`
The router reports internal warnings (failed payment verification, simulation failures, misconfiguration) through `onAlert`. With no plugin registered these are silently dropped, so a logging plugin is the fastest way to see why a request failed:
```typescript theme={null}
const loggingPlugin: RouterPlugin = {
onAlert(_ctx, alert) {
(alert.level === 'error' ? console.error : console.warn)(
`[router:${alert.route}] ${alert.message}`,
alert.meta ?? '',
);
},
onError(_ctx, error) {
console.error(`[router] ${error.status} ${error.message} (settled=${error.settled})`);
},
};
```
# Hosting
Source: https://agentcash.dev/docs/router/hosting
Run the router on Next.js, Hono, Bun, Node, or any fetch runtime, and serve discovery endpoints.
The router speaks Web-standard `Request`/`Response` and dispatches through an embedded [Hono](https://hono.dev) app, so the same route definitions run anywhere. Three hosting modes:
## Next.js catch-all (recommended)
One route file serves every registered route:
```typescript app/api/[[...route]]/route.ts theme={null}
import '@/lib/routes'; // side-effect import: registers all routes
import { router } from '@/lib/router';
import { nextHandlers } from '@agentcash/router/next';
export const { GET, POST, PUT, PATCH, DELETE } = nextHandlers(router);
```
The catch-all serves `/{basePath}/*` (default `/api/*`), including `/api/openapi.json` and `/api/llms.txt`. Unmatched paths get a JSON 404 with rediscovery links automatically.
## Next.js per-file
One route file per endpoint also works:
```typescript app/api/search/route.ts theme={null}
import { router } from '@/lib/router';
export const POST = router
.route('search')
.paid('0.01')
.body(schema)
.handler(handler);
```
Three per-file specifics the catch-all makes obsolete:
* **Verb declaration**: the exported const name (`GET`/`POST`) controls which verb Next.js serves, while `.method()` controls the verb advertised in discovery. The router defaults to `POST` (or `GET` when `.query()` is used), so any other GET route must declare it explicitly.
* **Discovery needs a barrel**: Next.js lazy-loads route files, so your `openapi.json` route must import a barrel module that imports every route file, or unloaded routes won't appear in the spec.
* **404 fallback**: mount `router.notFound()` in a catch-all so stale agent calls get a JSON 404 with rediscovery links instead of an HTML error page.
## Hono / Bun / Node / any fetch runtime
```typescript theme={null}
import { serve } from '@hono/node-server';
import { Hono } from 'hono';
import './routes';
import { router } from './router';
const app = new Hono();
app.route('/', router.hono()); // or use router.fetch directly
serve({ fetch: app.fetch, port: 3000 });
```
`router.fetch(request)` is a standard fetch handler; `router.hono()` exposes the internal app for mounting into a larger one. See [`examples/hono`](https://github.com/merit-systems/agentcash-router/tree/main/examples/hono) for a runnable server.
## `basePath`
`RouterConfig.basePath` (default `'api'`) controls the mount and advertised prefix: routes serve at `{baseUrl}/{basePath}/{path}`. Pass an empty string to mount at the origin root.
## Discovery endpoints
The router generates two discovery surfaces from your route definitions:
* **`/openapi.json`**: OpenAPI 3.1 with pricing extensions. Indexed by [AgentCash](https://agentcash.dev), [x402scan](https://x402scan.com), and [mppscan](https://mppscan.com).
* **`/llms.txt`**: plain-text guidance for agents.
`router.fetch` (and the Next.js catch-all) serves both under the `basePath` automatically, plus the root aliases on fetch runtimes. On Next.js, add the conventional root paths with two one-line route files:
```typescript app/openapi.json/route.ts theme={null}
import '@/lib/routes';
import { router } from '@/lib/router';
export const GET = router.openapi();
```
```typescript app/llms.txt/route.ts theme={null}
import { router } from '@/lib/router';
export const GET = router.llmsTxt();
```
`router.wellKnown()` (the `/.well-known/x402` listing) is deprecated. It still works for legacy x402 clients, but new integrations should rely on `/openapi.json` and `/llms.txt`. See [Become discoverable](/docs/discovery) for the full discovery contract.
### Bazaar catalog metadata
x402 facilitators persist service metadata from settled payments into the [Bazaar](https://docs.x402.org/extensions/bazaar) catalog. The router forwards it from discovery config onto each 402 challenge:
```typescript theme={null}
createRouterFromEnv({
title: 'Quote API', // serviceName defaults to title when ≤32 ASCII chars
serviceName: 'Quote API', // explicit override
tags: ['quotes', 'wisdom'], // ≤5 tags, each ≤32 chars
iconUrl: 'https://example.com/icon.png', // HTTPS, ≤2048 chars
// ...
});
```
Invalid values fail at startup with structured config issues rather than being silently dropped by the facilitator.
# AgentCash Router
Source: https://agentcash.dev/docs/router/overview
An open-source TypeScript router for shipping pay-per-call APIs on x402 and MPP with minimal boilerplate.
We've tested tens of thousands of endpoints and found that the hand-rolled ones tend to break in the details, with malformed 402 challenges, network identifiers agents can't settle against, and missing discovery metadata. **The [`@agentcash/router`](https://github.com/merit-systems/agentcash-router) gets all of this right for you.**
The router is the fastest and most effective way to ship an API on x402 and MPP. Just define routes with a fluent builder, and the router handles payment challenges, verification, settlement, wallet identity, and discovery.
## What you get
**Every pricing model.** One route definition and support every pricing model across x402 and MPP.
```typescript theme={null}
router.route('search').paid('0.01').handler(run); // fixed price
router.route('research').upTo('0.05').handler(meter); // billed as the handler works
router.route('llm').session({ unitCost: '0.0001' }).stream(gen); // per-unit, SSE streaming
```
**[Discovery](/docs/discovery) built in.** Your route definitions generate the documents that get you indexed by [x402scan](https://x402scan.com), [mppscan](https://mppscan.com), and [AgentCash](https://agentcash.dev), so agents can instantly find, understand, and call your API.
```text theme={null}
GET /openapi.json → OpenAPI 3.1 with pricing extensions
GET /llms.txt → plain-text guidance for agents
```
**Identity without accounts.** `.siwx()` verifies who's calling with a wallet signature, giving you per-user state with no signup flow or API keys.
```typescript theme={null}
router.route('inbox').siwx().handler(async ({ wallet }) => inboxFor(wallet));
router.route('report').paid('0.01').siwx().handler(fn); // pay once, replay free
```
## Deploy in one click
The recommended way to start is the Vercel template: a working pay-per-call API that exercises every pricing mode.
![Deploy with Vercel]()
See the [quickstart](/docs/router/quickstart) for the full walkthrough.
Deploy the template or add the router to an existing app.
Every auth mode with examples.
Next.js, Hono, Bun, Node, and discovery endpoints.
Environment variables, KV stores, and plugin hooks.
# Router quickstart
Source: https://agentcash.dev/docs/router/quickstart
Ship a pay-per-call API in one click with the Vercel template, from scratch on any runtime, or inside an existing app.
The [Vercel template](https://github.com/merit-systems/agentcash-router/tree/main/examples/vercel-deploy) is a standalone Next.js app that clones into your GitHub and deploys a working pay-per-call API. The demo is a fortune teller that exercises every pricing mode.
![Deploy with Vercel]()
Vercel clones only the template directory into a fresh repo in your GitHub account.
The deploy flow prompts for them inline:
* `EVM_PAYEE_ADDRESS`: the `0x…` wallet that receives payments.
* `CDP_API_KEY_ID` and `CDP_API_KEY_SECRET`: [Coinbase Developer Platform](https://portal.cdp.coinbase.com/projects/api-keys) credentials for the default x402 facilitator. The CDP free tier is enough.
`BASE_URL` is auto-derived from Vercel's system env vars, so there is no manual step.
The landing page at your deployment's root lists every endpoint with a copy-pasteable command:
```bash theme={null}
npx agentcash fetch https:///api/fortune -m POST
```
Add Upstash Redis / Vercel KV from the Vercel Storage tab before production traffic. Without it, SIWX entitlement and replay state is per-Lambda-instance and pay-once-then-replay routes break at scale. See [Configuration](/docs/router/configuration#kv-store).
To make it your own, replace the routes in `app/api/fortune/*` with your endpoints, add each new route file to `lib/routes.ts`, and update the title and `guidance` in `lib/router.ts`. Push to GitHub and Vercel redeploys.
## Minimal server from scratch
The router runs on any fetch runtime, including Next.js, Hono, Bun, and Node. Below is a complete server in one file, using Hono on Node:
```bash theme={null}
mkdir my-api && cd my-api
npm init -y
npm i @agentcash/router hono @hono/node-server zod
npm i -D tsx
```
```typescript server.ts theme={null}
import { serve } from '@hono/node-server';
import { Hono } from 'hono';
import { createRouterFromEnv } from '@agentcash/router';
import { z } from 'zod';
const router = createRouterFromEnv({
title: 'Quote API',
description: 'Pay-per-call quotes.',
guidance: 'GET /api/health is free. POST /api/quote with { topic } returns a quote for $0.001.',
});
router
.route('quote')
.paid('0.001')
.body(z.object({ topic: z.string() }))
.description('Random quote for a topic')
.handler(async ({ body }) => ({ quote: pickQuote(body.topic) }));
router
.route({ path: 'health', method: 'GET' })
.unprotected()
.handler(async () => ({ ok: true }));
const app = new Hono();
app.route('/', router.hono());
serve({ fetch: app.fetch, port: 3000 });
```
```bash theme={null}
export BASE_URL=http://localhost:3000 # 402 realm + OpenAPI server URL
export EVM_PAYEE_ADDRESS=0x... # receives payments
export CDP_API_KEY_ID=... # Coinbase Developer Platform key
export CDP_API_KEY_SECRET=... # (free tier: portal.cdp.coinbase.com)
npx tsx server.ts # http://localhost:3000
```
Routes serve at `/api/*`, and discovery (`/openapi.json`, `/llms.txt`) works immediately.
The server is a plain Node process: deploy it to Fly, Railway, a VPS, or any container host. Set `BASE_URL` to your public origin (it's the 402 realm and OpenAPI server URL, so it must match the domain agents call), and add an Upstash KV for production. See [Configuration](/docs/router/configuration#kv-store).
The runnable version of this server lives at [`examples/hono`](https://github.com/merit-systems/agentcash-router/tree/main/examples/hono). Bun, Deno, and Cloudflare Workers work the same way via `router.fetch`. See [Hosting](/docs/router/hosting).
## Add to an existing app (Next.js)
```bash theme={null}
pnpm add @agentcash/router zod
```
`zod` (v4) is a peer dependency.
`createRouterFromEnv` reads config from `process.env` and validates every value up front. Set `EVM_PAYEE_ADDRESS`, `CDP_API_KEY_ID`, and `CDP_API_KEY_SECRET` (plus `BASE_URL` outside Vercel).
```typescript lib/router.ts theme={null}
import { createRouterFromEnv } from '@agentcash/router';
export const router = createRouterFromEnv({
title: 'My API',
description: 'Pay-per-call search.',
guidance: 'POST /search with { q: string }. Returns top 10 results.',
});
```
One side-effect module registers every route:
```typescript lib/routes.ts theme={null}
import { z } from 'zod';
import { router } from './router';
router
.route('search')
.paid('0.01')
.body(z.object({ q: z.string() }))
.handler(async ({ body }) => search(body.q));
```
```typescript Next.js catch-all theme={null}
// app/api/[[...route]]/route.ts
import '@/lib/routes'; // side-effect import: registers all routes
import { router } from '@/lib/router';
import { nextHandlers } from '@agentcash/router/next';
export const { GET, POST, PUT, PATCH, DELETE } = nextHandlers(router);
```
```typescript Hono / Bun / Node theme={null}
import { serve } from '@hono/node-server';
import './routes';
import { router } from './router';
serve({ fetch: router.fetch, port: 3000 });
```
On Next.js, add the root discovery aliases with two one-line route files. See [Hosting](/docs/router/hosting#discovery-endpoints).
## Test the 402 flow
An unpaid request gets a `402` whose challenge lives in headers:
```bash theme={null}
curl -i -X POST https://api.example.com/api/search \
-H 'content-type: application/json' -d '{"q":"hello"}'
```
Pay it with any x402 or MPP client:
```bash theme={null}
# AgentCash CLI: auto-negotiates x402 or MPP
npx agentcash fetch https://api.example.com/api/search -m POST -b '{"q":"hello"}'
# mppx CLI: MPP reference client
npx mppx https://api.example.com/api/search -J '{"q":"hello"}'
```
# Routes and pricing
Source: https://agentcash.dev/docs/router/routes
Every auth mode the router supports, plus schemas, discovery examples, and error handling.
Every route picks exactly one auth mode. `.paid()`, `.upTo()`, and `.session()` are mutually exclusive pricing modes; `.siwx()` and `.apiKey()` compose with pricing.
| Method | Purpose |
| ---------------------------------- | ----------------------------------------------------------------------------------- |
| `.paid(price)` | Fixed, body-derived, or tiered payment up front (x402, MPP, or both). |
| `.upTo(maxPrice)` | Handler-computed billing via `charge(amount)`, settled once. **x402 only.** |
| `.session({ unitCost, maxPrice })` | Per-unit billing over an MPP payment channel. Required for streaming. **MPP only.** |
| `.siwx()` | Wallet identity, no payment. |
| `.apiKey(resolver)` | `X-API-Key` or `Authorization: Bearer `. Composes with pricing modes. |
| `.unprotected()` | No auth. |
## `.paid()`
Fixed price per request:
```typescript Fixed theme={null}
router
.route('search')
.paid('0.01')
.body(z.object({ q: z.string() }))
.handler(async ({ body }) => search(body.q));
```
Compute the price from the parsed body: the challenge quotes the exact amount before payment. Requires `.body(schema)`:
```typescript Body-derived theme={null}
router
.route('generate')
.paid((body) => calculateCost(body), { maxPrice: '5.00' })
.body(genSchema)
.handler(async ({ body }) => generate(body));
```
`maxPrice` caps the computed amount. If the pricing function throws an `HttpError`, the request is rejected with that status before any payment; any other throw falls back to quoting `maxPrice`. Or pick a tier from a body field:
```typescript Tiered theme={null}
router
.route('upload')
.paid({
field: 'tier',
tiers: {
'10mb': { price: '0.02', label: '10 MB' },
'100mb': { price: '0.20', label: '100 MB' },
},
})
.body(uploadSchema)
.handler(async ({ body }) => upload(body));
```
## `.upTo()`
Handler-computed billing, x402 only. The handler calls `charge(amount)` as it works; the request settles once for the running total, capped at `maxPrice`:
```typescript theme={null}
router
.route('research')
.upTo('0.05')
.body(schema)
.handler(async ({ body, charge }) => {
await charge('0.001');
const extra = await deepDive(body);
await charge('0.002');
return extra;
});
```
A `charge()` that would push the total past `maxPrice` throws a 400 `CHARGE_OVER_CAP` error and nothing settles: it is not silently clamped. Guard your loop if partial work should still be billed.
## `.session()`
Per-unit billing over an MPP payment channel, MPP only. Requires `MPP_OPERATOR_KEY` (see [Configuration](/docs/router/configuration#mpp)). In request mode, `.handler()` bills exactly `unitCost` per request:
```typescript Request mode theme={null}
router
.route('llm')
.session({ unitCost: '0.01', maxPrice: '0.05', unitType: 'request' })
.body(schema)
.handler(async ({ body }) => complete(body.prompt));
```
Streaming serves the session over SSE; each `charge()` bills one unit:
```typescript Streaming theme={null}
router
.route('stream')
.session({ unitCost: '0.0001', maxPrice: '0.05', unitType: 'token' })
.body(schema)
.stream(async function* ({ body, charge }) {
for await (const token of streamLLM(body.prompt)) {
await charge();
yield token;
}
});
```
Streaming is MPP-only: `.stream()` on any other pricing mode throws at registration.
## `.siwx()`
Free routes gated by wallet identity. Unpaid requests get a 402 with a SIWX challenge; the verified wallet address is available to the handler:
```typescript theme={null}
router
.route({ path: 'profile', method: 'GET' })
.siwx()
.handler(async ({ wallet }) => getProfile(wallet));
```
### Pay once, replay free
`.paid()` and `.upTo()` compose with `.siwx()`: the first request pays normally, the wallet is recorded, and later requests with a valid SIWX signature skip payment:
```typescript theme={null}
router
.route({ path: 'inbox' })
.paid('0.01')
.siwx() // first call pays $0.01, later calls present a SIWX sig instead
.handler(async ({ wallet }) => getInbox(wallet));
```
Serverless deployments need a real KV store for this: without one, entitlements live in a per-process `Map` and a wallet that paid on one instance gets charged again on another. See [Configuration](/docs/router/configuration#kv-store).
## `.apiKey()`
The resolver receives the key from `X-API-Key` or `Authorization: Bearer`; return `null` to reject with 401:
```typescript theme={null}
router
.route({ path: 'admin/users' })
.apiKey(async (key) => db.admin.findByKey(key))
.handler(async ({ account }) => db.user.findMany());
router
.route({ path: 'gated' })
.apiKey(resolver)
.paid('0.01') // key AND payment
.handler(fn);
```
## Schemas and examples
Chain `.body()`, `.query()`, and `.output()` with Zod schemas. Types propagate through the builder, so `body`, `query`, and the expected return type are fully typed in the handler:
```typescript theme={null}
const SearchSchema = z.object({ q: z.string(), limit: z.number().default(10) });
const ResultSchema = z.object({ hits: z.array(z.string()) });
router
.route('search')
.paid('0.01')
.body(SearchSchema)
.output(ResultSchema)
.handler(async ({ body }) => ({ hits: await db.search(body.q, body.limit) }));
```
* **`.body(schema)`**: parses and validates the JSON body, typed as `ctx.body`.
* **`.query(schema)`**: parses the query string and switches the route to `GET`, typed as `ctx.query`.
* **`.output(schema)`**: declares the response shape for OpenAPI generation. The runtime does not validate handler return values; call `schema.parse()` inside the handler if you want strict output validation.
### Discovery examples
`.inputExample()` and `.outputExample()` attach examples to the OpenAPI document. Both are validated against the registered schemas at registration, so a drifted example fails at build time instead of misleading agents:
```typescript theme={null}
router
.route('search')
.paid('0.01')
.body(SearchSchema)
.inputExample({ q: 'coffee shops in soho', limit: 5 })
.output(ResultSchema)
.outputExample({ hits: ['Blue Bottle', 'La Colombe'] })
.handler(async ({ body }) => search(body));
```
### `.description()`
A one-line, human-readable summary of the route. It surfaces in the OpenAPI spec and `llms.txt`, so it's often the first thing an agent reads when deciding whether to call you:
```typescript theme={null}
router
.route('search')
.paid('0.01')
.description('Full-text search over indexed web pages.')
.body(SearchSchema)
.handler(async ({ body }) => search(body));
```
## Path params
Paths declare `{param}` segments, extracted in every hosting mode:
```typescript theme={null}
router
.route('drafts/{draftId}/commit')
.unprotected()
.handler(async ({ params }) => commit(params.draftId));
```
## Pre-payment validation
`.validate()` runs before the 402 challenge, so callers are never charged for a request that was going to fail:
```typescript theme={null}
router
.route({ path: 'domain/register' })
.paid(calculatePrice, { maxPrice: '10.00' })
.body(RegisterSchema)
.validate(async (body) => {
if (await isDomainTaken(body.domain)) {
throw Object.assign(new Error('Domain taken'), { status: 409 });
}
})
.handler(async ({ body, wallet }) => registerDomain(body.domain, wallet));
```
Pipeline order: body parse → validate → 402 challenge → payment → handler. On paid routes, the paying retry always parses and validates the body before settlement, so a 400 never costs the caller money.
## Throwing errors
Throw `HttpError` from handlers, pricing functions, or validators to reject with a specific status code. A plain `Error` with a numeric `status` property works the same way; anything else becomes a 500:
```typescript theme={null}
import { HttpError } from '@agentcash/router';
throw new HttpError('Fortune too long (max 100 chars)', 400);
// equivalent plain-error form
throw Object.assign(new Error('Domain taken'), { status: 409 });
```
In a body-derived pricing function, only `HttpError` instances are rethrown before the 402 challenge (so callers see the rejection without paying); any other throw (including a plain error with a `status` property) falls back to quoting `maxPrice` instead. Use `HttpError` when a pricing function needs to reject. Handlers can also return a `Response` directly for full control over status, headers, and body.
# Sell to agents
Source: https://agentcash.dev/docs/sell-to-agents
Start onboarding agents as customers.
## Why sell to agents?
AI agents are becoming the primary way people interact with the internet. As more activity flows through agent interfaces instead of browsers, ad-based business models break since there are no human eyeballs to monetize. The businesses that thrive will be the ones that charge for their content and services directly.
Most agent users have never called an API before. Pay-per-request pricing at fractions of a cent opens your service to a massive new audience that your existing subscription tiers never reach. AgentCash becomes the tip of the spear for your go-to-market.
## Start selling to agents
Add a few lines of code to enable pay-per-call, publish a discovery specification, and AI Agents can start calling your API. We support open payment standards like [x402](https://www.x402.org) and [MPP](https://docs.stripe.com/payments/machine).
A few lines of code enable per-request pricing. AI Agents pay automatically. No subscriptions, no invoices. The fastest path is [AgentCash Router](/docs/router/overview), our open-source TypeScript router: deploy a working pay-per-call API in one click.
Add a simple file that tells AI Agents what your API does, what it costs, and how to call it. [See how](/docs/discovery). The router generates this for you automatically.
AI Agents discover your API and start calling it. You get immediate distribution to Claude, Cursor, Codex, and every agent on x402 or MPP.
# Supercharge your agent
Source: https://agentcash.dev/docs/start-agent
AgentCash equips your agent with native access to the Open Agentic Web.
Enrichment, social data, image generation, web scraping, email. All accessible instantly.
Claude Code, Cursor, Codex, Windsurf, OpenClaw, Hermes, and 14+ more clients.
No subscriptions. Calls cost fractions of a cent to a few cents each. Fund once, use everywhere.
Agent skill, CLI, or MCP mode. Use whichever fits your workflow.
## What can your agent do with AgentCash?
Agents with AgentCash can access premium data and services that would normally require separate accounts, API keys, and subscriptions for each provider:
| Category | Examples |
| ----------------------------- | --------------------------------------------------------- |
| **People & company research** | Contact info, company data, LinkedIn profiles, org charts |
| **Social media data** | Instagram, TikTok, YouTube, Reddit, Facebook |
| **Web search & scraping** | Exa search, Google Maps, Firecrawl scraping |
| **Image & video generation** | State-of-the-art AI media creation |
| **File hosting** | Upload files, get permanent download URLs |
| **Email** | Send transactional and outreach emails |
## Three ways to use AgentCash
Choose how your agent connects: one shared balance, three entry points.
Tell your agent to read `agentcash.dev/skill.md` and it will learn to discover and call premium APIs on its own.
Run `npx agentcash` commands directly from your terminal to discover APIs, check balances, and make calls.
Install AgentCash as an [MCP server](/docs/mcp-mode) for native tool integration in Claude Code, Cursor, and other clients.
# Suggested frameworks
Source: https://agentcash.dev/docs/suggested-frameworks
High-level architectures for building agent-payable services.
## Proxy architecture
Restructuring your backend and database to support agentic payments can be a daunting, time-consuming task, and in most cases it isn't strictly necessary to bring your service online. The pattern below lets you add agentic commerce support with minimal changes to your production architecture.
### Overview
You stand up a thin proxy in front of your existing backend. The proxy should handle everything x402/mpp-specific. Payment verification, wallet identity, per-wallet authorization, rate limiting, and discovery exist in this service while your production API stays untouched.
```mermaid theme={null}
flowchart LR
agent["Agent"] -- "x402/MPP" --> proxy["Proxy"]
proxy -- "API key" --> api["Production API"]
proxy --- features["Payment verify\nWallet identity\nPer-wallet authz\nRate limiting\nDiscovery doc"]
proxy --- db["Wallet mapping DB"]
```
### How it works
Stand up a separate server (we typically use Next.js with [AgentCash Router](/docs/router/overview), but any HTTP framework works). The router covers the proxy's payment, wallet identity, and discovery responsibilities out of the box, leaving you to write the per-wallet authorization and upstream calls. Provision a single API key from your production backend with "god-mode" permissions: as much spend authority and as few rate limits as possible. The proxy then acts as a pure consumer of your production API, wrapping each endpoint you want to expose over x402/MPP with a corresponding payable endpoint on the proxy.
All agentic traffic to your production backend appears under a single API key. The complexity of per-wallet accounting stays isolated in the proxy, so your original backend's data model is unchanged.
### Responsibility split
| Concern | Proxy server | Production API |
| ------------------------------------ | ------------ | -------------- |
| Payment verification (x402/MPP) | Yes | — |
| Wallet identity | Yes | — |
| Per-wallet authorization | Yes | — |
| Per-wallet rate limiting | Yes | — |
| Discovery document (`/openapi.json`) | Yes | — |
| Business logic | — | Yes |
| User records, billing, quotas | — | Yes |
| Long-term data storage | — | Yes |
The proxy owns everything agent-specific. The production API owns everything you already had.
### Wallet identity
Each x402 or MPP request carries a signed payment proof. The proxy verifies the signature and treats the signing wallet address as the caller's identity. That wallet address becomes the primary key for owned resources, rate limits, session state, or anything else you track per-caller.
If you also need free endpoints gated by wallet identity without payment, use SIWX (Sign-In with X). The signature flow is the same, but no funds move.
### Wallet-aware authorization
Because every agent call reaches your production API under a single god-key, the proxy must enforce per-wallet authorization itself. The production API will happily return every row the key can see. It's the proxy's job to filter.
For example, if your API exposes `list_jobs()`:
* **Wrong:** the proxy calls `list_jobs()` and returns the full response. This leaks every wallet's jobs to every caller.
* **Right:** the proxy looks up which job IDs belong to the calling wallet in its own database, fetches only those from the production API, and returns the filtered set.
The same rule applies to `get_job`, `update_job`, and delete operations. Any endpoint that takes a resource ID must verify that the calling wallet owns that resource before proxying through.
### Rate limiting
The god-key is intentionally provisioned with loose or absent rate limits so that legitimate agent traffic isn't throttled. The tradeoff is that the proxy is now the only thing standing between an abusive wallet and your production backend. Apply per-wallet rate limits at the proxy by request count, by spend, or both.
### Failure semantics
x402 and MPP settle payment as part of the request. If the downstream call to your production API fails after settlement, you have two options:
1. **Don't settle on failure.** Validate upstream health and cheap preconditions before accepting payment, and return `402` on predictable failures.
2. **Refund on failure.** Catch downstream errors and issue a refund through the settlement network before returning `5xx` to the caller.
Pick one policy per endpoint and document it. The worst outcome is silently charging a wallet for a failed request.
Request validation should not block unauthenticated discovery probes from seeing a `402` challenge. Preserve `WWW-Authenticate` through proxy layers so MPP clients can parse the challenge before payment.
### Wallet mapping database
If you need to track which wallets own which resources, a lightweight database alongside the proxy is usually enough. Common tables:
* `wallet_address → owned_resource_ids` for ownership lookups.
* `wallet_address → usage_counters` for rate limiting and spend caps.
* `wallet_address → session_state` for stateful workflows.
All of this sits outside your production database. From the production API's perspective, nothing changed and it still sees a single API key making calls.
### Exposing discovery
The proxy is also where you serve your AgentCash discovery document. Publish `/openapi.json` on the proxy origin with `x-payment-info` and `402` responses on each payable operation ([AgentCash Router](/docs/router/hosting#discovery-endpoints) generates this automatically). Agents discover and call the proxy and never the production API directly.
For proxied upstreams, rewrite `Location` redirects to the public proxy origin instead of leaking Railway/internal hostnames, and enforce body limits against bytes actually read rather than only `Content-Length`.
See [Server Discovery](/docs/discovery) for the full OpenAPI contract.
### When this pattern fits
Good fit:
* You want to expose existing endpoints over x402/MPP with minimal risk to production.
* Your business logic is already accessible via a clean internal API.
* Per-wallet state is shallow enough to live in a sidecar database.
### Questions?
For further questions, contact us at [merchants@merit.systems](mailto:merchants@merit.systems).
# check_endpoint_schema
Source: https://agentcash.dev/docs/tools/check-endpoint-schema
Probe an endpoint for pricing, auth requirements, and schema without paying.
The `check_endpoint_schema` tool inspects an endpoint to learn its price, supported methods, input/output schema, and auth mode without making a payment.
Equivalent CLI command: `npx agentcash check `
## Parameters
The endpoint URL to check.
Specific HTTP method to probe. If omitted, AgentCash probes multiple methods and checks the OpenAPI spec.
Additional headers to include. Each entry must use `Name: value` format.
## Response
Cost per request in USDC.
Supported HTTP methods (GET, POST, etc.).
Expected request body format (JSON schema).
Response body format (JSON schema).
Authentication mode: `x402`, `siwx`, `mpp`, or `none`.
## Behavior
1. Sends a probe request to the endpoint
2. Reads the `402 Payment Required` response for pricing and auth details
3. Fetches the OpenAPI spec (if available) for schema information
4. Probes multiple HTTP methods in parallel to determine which are supported
5. Returns all metadata without making a payment
## Example
Ask your agent:
> Check the pricing and schema for [https://stableenrich.dev/api/company/lookup](https://stableenrich.dev/api/company/lookup) using AgentCash.
# discover_api_endpoints
Source: https://agentcash.dev/docs/tools/discover-api-endpoints
Find all available endpoints on an origin.
The `discover_api_endpoints` tool fetches the OpenAPI document from an origin and returns a list of all available endpoints. Works with any origin that publishes a spec, not just the pre-indexed ones.
Equivalent CLI command: `npx agentcash discover `
## Parameters
The origin URL to discover endpoints on (e.g., `https://stableenrich.dev`).
## Response
The origin that was queried.
List of discovered endpoints.
Endpoint path.
HTTP method.
What the endpoint does.
Cost in USDC.
Usage instructions from the origin, if provided.
## Behavior
1. Fetches `/openapi.json` from the origin (falls back to `/.well-known/x402`)
2. Parses the OpenAPI document and its `x-payment-info` annotations
3. Returns endpoints with their descriptions, pricing, and accepted protocols
## Known origins
These origins are pre-indexed and available by default:
* `stableenrich.dev`
* `stablesocial.dev`
* `stablestudio.dev`
* `stableupload.dev`
* `stableemail.dev`
## Example
Ask your agent:
> Discover all available endpoints on stableenrich.dev using AgentCash.
# fetch
Source: https://agentcash.dev/docs/tools/fetch
Make HTTP requests with automatic SIWX authentication and payment handling.
The `fetch` tool sends an HTTP request to any URL and automatically handles SIWX authentication and payment if the endpoint requires them.
Equivalent CLI command: `npx agentcash fetch `
## Parameters
The URL to fetch.
HTTP method. One of `GET`, `POST`, `PUT`, `PATCH`, `DELETE`.
Raw request body string. When provided, `Content-Type: application/json` is set by default unless overridden by a header entry.
Additional HTTP headers. Each entry must be a string in `Name: value` format.
Request timeout in milliseconds.
Force a specific payment protocol: `x402` or `mpp`. By default, AgentCash auto-selects.
Preferred network for SIWX and payment when applicable. By default, AgentCash auto-selects.
Maximum amount (in USD) to pay if the route still requires payment.
## Response
The tool returns the response body along with metadata from the final response:
The parsed response body from the endpoint.
All headers from the final endpoint response. This includes the raw
`payment-receipt` header for MPP or `payment-response` /
`x-payment-response` header for x402 when supplied by the server, so callers
can retain the original payment proof. Headers are also included when the
final endpoint response is an HTTP error.
Payment details, present when a 402 payment was made.
USDC amount paid.
On-chain transaction hash.
Chain used for the payment.
## Behavior
1. Sends the request to the target URL
2. If the response is `402 Payment Required` with a SIWX challenge, signs the challenge and retries with auth headers
3. If the route still returns `402`, reads the accepted protocols (`x402`, `mpp`) and networks from the challenge
4. Picks a protocol/network your wallet supports and checks the balance against the required amount
5. Signs the payment proof (on-chain USDC transfer for x402, off-chain signed intent for MPP)
6. Retries the request with the payment proof attached
7. Returns the final response and payment info
## Example
Ask your agent:
> Use AgentCash to POST to [https://stableenrich.dev/api/company/lookup](https://stableenrich.dev/api/company/lookup) with body `{"domain": "stripe.com"}`.
# fetch_with_auth
Source: https://agentcash.dev/docs/tools/fetch-with-auth
Compatibility alias for fetch.
The `fetch_with_auth` tool is a deprecated compatibility alias for [`fetch`](/docs/tools/fetch). It uses the same unified flow: probe the route, attempt SIWX (Sign-In With X) when available, and only pay if the route still returns `402`.
Equivalent CLI command: `npx agentcash fetch-auth ` (deprecated alias for `npx agentcash fetch `)
## Parameters
The URL to fetch.
HTTP method. One of `GET`, `POST`, `PUT`, `PATCH`, `DELETE`.
Raw request body string.
Additional HTTP headers. Each entry must be a string in `Name: value` format.
Request timeout in milliseconds.
## Response
The parsed response body from the endpoint.
Payment details, present when the request still required payment after the SIWX retry.
## Behavior
1. Sends the initial request
2. If the response includes a SIWX challenge, extracts the challenge
3. Signs the challenge with your wallet's private key
4. Retries the request with signed auth headers
5. If the route still returns `402`, pays and retries again
6. Returns the final response
## When to use
Prefer `fetch` for new integrations. Keep `fetch_with_auth` only for compatibility with older prompts or clients.
# get_balance
Source: https://agentcash.dev/docs/tools/get-balance
Get your total wallet balance.
The `get_balance` tool returns your total USDC balance across all supported networks.
Equivalent CLI command: `npx agentcash balance`
## Parameters
This tool takes no parameters.
## Response
Total USDC balance across all supported networks.
## Behavior
* Creates the wallet automatically at `~/.agentcash/wallet.json` if one does not exist
* Aggregates balances across all supported payment networks
* Use this before paid API calls to confirm that funds are available
## Example
Ask your agent:
> What is my AgentCash balance?
# get_wallet_info (legacy)
Source: https://agentcash.dev/docs/tools/get-wallet-info
Deprecated combined wallet tool.
The `get_wallet_info` tool has been replaced by two tools:
* [`get_balance`](/docs/tools/get-balance) for total balance
* [`list_accounts`](/docs/tools/list-accounts) for per-network balances, addresses, and deposit links
Equivalent CLI commands:
* `npx agentcash balance`
* `npx agentcash accounts`
## Migration
Use `get_balance` when you only need to know whether paid endpoints are currently affordable.
Use `list_accounts` only when you need network-specific funding details, such as deposit links or wallet addresses.
# list_accounts
Source: https://agentcash.dev/docs/tools/list-accounts
List wallet accounts and deposit links by network.
The `list_accounts` tool returns the per-network account list for your AgentCash wallet, including balance, wallet address, and deposit link for each supported network.
Equivalent CLI command: `npx agentcash accounts`
## Parameters
This tool takes no parameters.
## Response
One entry per supported network.
Supported network name.
USDC balance on that network.
Wallet address for that network.
Funding link for that network.
Whether the wallet is new and likely needs funding.
Present when the user has not completed onboarding. Show its message when returned.
## Behavior
* Creates the wallet automatically at `~/.agentcash/wallet.json` if one does not exist
* Returns funding details only when you need network-specific deposit instructions
* Prefer [`get_balance`](/docs/tools/get-balance) when you only need to know whether funds are available
## Example
Ask your agent:
> If I need to fund my AgentCash wallet, what deposit links can I use?
# redeem_invite
Source: https://agentcash.dev/docs/tools/redeem-invite
Redeem an invite code for free USDC.
The `redeem_invite` tool redeems an invite code to deposit USDC into your wallet on Base.
Equivalent CLI command: `npx agentcash redeem `
## Parameters
The invite code to redeem.
## Response
Amount of USDC deposited.
On-chain transaction hash on Base.
## Behavior
* Sends the invite code to the AgentCash redemption service
* Deposits USDC directly to your wallet on Base
* Returns the amount and transaction hash
Invite codes are one-time use. Each code can only be redeemed once.
## Example
Ask your agent:
> Redeem invite code ABC123 with AgentCash.
# search
Source: https://agentcash.dev/docs/tools/search
Find API providers by describing what you need in natural language.
The `search` tool finds paid API services that match a natural-language query. It returns ranked origins along with endpoint details and pricing, so you can call the best match immediately via [`fetch`](/docs/tools/fetch).
Equivalent CLI command: `npx agentcash search `
## When to use
Use `search` when you don't already know which origin to call. If the task clearly maps to a registered origin (people research → StableEnrich, image generation → StableStudio, social data → StableSocial, and so on), skip `search` and call [`discover_api_endpoints`](/docs/tools/discover-api-endpoints) on that origin directly.
`search` is for discovering capabilities outside the registered origins.
## Parameters
Natural-language description of what you need. Examples: `"send physical mail"`, `"generate music"`, `"flight prices"`, `"company financials"`.
## Response
The original query, echoed back.
Ranked origins. The top result's `endpoint` includes the full input/output schema so it can be called without an extra `check_endpoint_schema` round-trip.
Origin URL.
Human-readable name.
What the origin offers.
Favicon URL.
Payment protocols the origin supports (e.g., `x402`, `mpp`).
Best-matching endpoint for the query, when one exists.
HTTP method.
Endpoint path.
What the endpoint does.
`paid` or `siwx`.
Cost in USDC.
Request body schema.
Response schema.
## Behavior
1. Sends the query to the AgentCash search index
2. Returns a ranked list of origins and their most relevant endpoints
3. The top result is pre-loaded with schema details so you can go straight to `fetch`
## Example
Ask your agent:
> Use AgentCash to search for an API that can send a physical postcard.
The agent calls `search`, picks the best matching origin, and then calls `fetch` on the endpoint it returned.
# Funding your wallet
Source: https://agentcash.dev/docs/wallet/funding
How to add USDC to your AgentCash wallet.
You need USDC in your wallet to make paid API calls. There are several ways to fund it.
## Get free credits
The fastest way to get started is through the onboarding flow:
Onboard at agentcash.dev/onboard to get up to \$25 in free credits.
Or onboard from the terminal:
```bash theme={null}
npx agentcash onboard
```
## Redeem an invite code
If you have an invite code, ask your agent:
> Redeem invite code `YOUR_CODE` with AgentCash.
Or use the CLI:
```bash theme={null}
npx agentcash redeem YOUR_CODE
```
Invite codes are one-time use and deposit USDC directly to your wallet on Base.
## Deposit USDC directly
Open the guided funding flow:
```bash theme={null}
npx agentcash fund
```
Or, if you need the deposit links and addresses for each supported network:
```bash theme={null}
npx agentcash accounts
```
You can also visit `agentcash.dev/deposit/` for a guided funding experience with options for bridging from other chains and on-ramps.
Base is the default network for AgentCash payments and most endpoints accept USDC on Base. Your wallet also holds USDC on Solana. Fund that address only if you plan to call endpoints that require Solana. Run `npx agentcash accounts` to see deposit links for every supported network.
## Minimum balance
There is no minimum balance requirement. Each API call costs a specific amount of USDC (typically $0.001 to $0.10 per request). AgentCash checks your balance before each payment and warns you if funds are insufficient.
# Supported networks
Source: https://agentcash.dev/docs/wallet/networks
Blockchain networks supported for USDC payments.
AgentCash pays endpoints in USDC across a small, curated set of networks.
## Networks
| Network | CAIP-2 identifier | Type | Status |
| ---------- | ----------------------------------------- | ------ | --------- |
| **Base** | `eip155:8453` | EVM | Default |
| **Solana** | `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp` | Solana | Supported |
| Tempo | `eip155:4217` | EVM | Testnet |
Base is the default for payments. Most endpoints accept USDC on Base and transaction costs are minimal. Solana support is available for endpoints that prefer it.
## Addresses
Your wallet holds two distinct addresses:
* **EVM address**: one Ethereum-style address covers every supported EVM network (Base, Tempo).
* **Solana address**: a separate Solana keypair for USDC payments on Solana.
Run `npx agentcash accounts` (or the [`list_accounts`](/docs/tools/list-accounts) MCP tool) to see each network's address, balance, and deposit link.
## Payment network selection
The endpoint decides which network to use. The OpenAPI `x-payment-info` block or the runtime `402` response declares the accepted networks and protocols. AgentCash matches that against your wallet and pays on the correct chain automatically. You can override with `--payment-network` on the CLI or the `paymentNetwork` field on the MCP [`fetch`](/docs/tools/fetch) tool.
# Wallet overview
Source: https://agentcash.dev/docs/wallet/overview
How AgentCash manages your local wallet for making payments.
AgentCash creates and manages a local wallet that holds USDC for paying premium APIs. The wallet is created automatically the first time you use AgentCash.
## Where is the wallet stored?
Your keys live under `~/.agentcash/` with restricted file permissions (`600`):
* **`wallet.json`**: EVM keypair (covers Base and Tempo)
* **`solana-wallet.json`**: Solana keypair
Each file contains a private key, its address, and a creation timestamp.
Private keys are stored in plaintext on disk. Do not share these files or commit them to version control. Anyone with the keys can spend your USDC.
## Using an existing key
To use specific private keys, set environment variables:
```bash theme={null}
export X402_PRIVATE_KEY=0xYOUR_EVM_PRIVATE_KEY # hex-encoded, 32 bytes
export X402_SOLANA_PRIVATE_KEY=YOUR_SOLANA_SECRET_KEY # base58-encoded
```
Either variable can be set independently. You can choose to omit one if you don't want to use that chain. Useful for CI/CD environments or when you want multiple machines to share a wallet.
## Checking your balance
Ask your agent:
> What is my AgentCash balance?
Or use the CLI directly:
```bash theme={null}
npx agentcash balance
```
This returns your total USDC balance across supported networks.
If you need deposit links or network-specific wallet addresses, run:
```bash theme={null}
npx agentcash accounts
```
This returns the per-network account list, including each address, balance, and deposit link.
## Wallet addresses
Your wallet exposes two addresses:
* A single **EVM address** that receives USDC on every supported EVM network (Base, Tempo).
* A separate **Solana address** for USDC on Solana.
Run `npx agentcash accounts` to see each one along with its current balance and deposit link. See [networks](/docs/wallet/networks) for the full list.