My agent earns USDC. It sells API calls priced with x402, so tiny payments accumulate in its wallet. Which eventually raises the unglamorous question every "agents earning money" demo skips: how does that USDC become money a human can spend at a supermarket?
Here is the pattern I landed on. It needs no exchange account for the agent, no API keys, and — importantly — nobody in the middle ever holds the funds.
Whatever converts crypto to fiat is regulated activity (KYC/AML, custody, payments). An autonomous agent can't and shouldn't do that part. So the design splits cleanly:
The service tying these together is FiatDock — a thin technology layer that never touches funds. One rule is binding and worth stating up front: the wallet sending USDC and the bank account receiving fiat must belong to the same person — the agent's owner. No third-party funds, no aggregation, no P2P.
curl "https://fiatdock.com/v1/quote?side=SELL&cryptoAmount=50"
No auth, no signup. The response itemises every fee (including the service's 1% commission) and the exact amount that lands in the bank account. My agent calls this before deciding whether cashing out now is worth it.
Paid endpoints don't use API keys. An unpaid request returns HTTP 402 with exact payment requirements — asset, network, amount ($0.05 USDC), and the address. The agent signs the payment from its own wallet and retries:
import { wrapFetchWithPayment } from "x402-fetch";
import { privateKeyToAccount } from "viem/accounts";
const payFetch = wrapFetchWithPayment(fetch, privateKeyToAccount(process.env.AGENT_PRIVATE_KEY));
const res = await payFetch("https://fiatdock.com/v1/offramp/session", {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify({ cryptoAmount: 50, email: "owner@example.com", customerId: "agent-1" }),
});
const { checkoutUrl, partnerOrderId } = await res.json();
Payment, authentication, and rate-limiting collapse into one signed transfer. That's the whole x402 trick, and it's why this works for agents that can't fill out a signup form.
checkoutUrl
is single-use and valid about five minutes. My agent just messages it to me. I open it, the licensed provider runs KYC (first time only — afterwards it remembers), and I confirm. USDC goes from the wallet straight to the provider; EUR lands in my bank account. The agent never saw a bank credential, and FiatDock never held a cent.
curl https://fiatdock.com/v1/orders/$ORDER_ID
Or pass a callbackUrl
in step 2 and verify the X-FiatDock-Signature
HMAC header on each push. Either way the agent knows when the money arrived and goes back to work.
The same pattern works the other way when the agent needs working capital. POST /v1/onramp/session
(also $0.05 via x402) creates a top-up session with the destination locked to the agent's own wallet address; the owner opens the checkout link, pays EUR from their own bank or card, and USDC lands in the agent's wallet. Quotes for this direction are the same free call with side=BUY
:
curl "https://fiatdock.com/v1/quote?side=BUY&fiatAmount=100"
One flow out, one flow in — and the same binding rule in both directions: the fiat side is always the owner's own account, the crypto side is the owner's agent wallet. Nothing crosses between strangers.
The whole flow above is wrapped in four MCP tools (get_quote
, create_offramp_session
, create_onramp_session
, get_order_status
):
{
"mcpServers": {
"fiatdock": {
"command": "npx",
"args": ["-y", "fiatdock-mcp"],
"env": { "AGENT_PRIVATE_KEY": "0x..." }
}
}
}
That config works as-is in Claude Desktop, Cursor, Windsurf, and Gemini CLI; there's a remote endpoint (https://fiatdock.com/mcp
) for zero-install hosts, and a tools.json with OpenAI/Gemini function-calling schemas if you're not using MCP at all. It's in the official MCP Registry as com.fiatdock/fiatdock-mcp
. Per-client configs live in INTEGRATIONS.md.
Everything is documented machine-first if you want to point your own agent at it and let it figure things out: llms.txt · OpenAPI · repo.