HTTP/1.1 402 PAYMENT REQUIRED · Agentic Finance (AIFI) · x402 + MPP dual-stack 500+ tools · 12 rails · 0% seller fee
Home / Blog / Agentic Finance (AIFI): the economy that forms once agents can pay
2026-08-18

Agentic Finance (AIFI): the economy that forms once agents can pay

Agentic Finance (AIFI) is software agents transacting on their own: discovering a service, reading a machine-readable price, paying per request from a non-custodial wallet over an open protocol, receiving a verifiable receipt, and, on the other side, earning per request for what they serve. No accounts, no API keys, no invoices. The payment is the identity and every settlement is on a public ledger.

We use the term deliberately, and this post is the long form of the category page: what it means, why it is different from the two phrases it gets confused with, what a single purchase actually looks like on the wire, and where Agent402 sits in it.

Three phrases that are not the same thing

  • Agentic payments is the plumbing: a wire format that lets one program pay another per request. HTTP 402 names a price, the client answers with a signed stablecoin payment, the server verifies, settles and delivers. x402 and MPP are the two open, HTTP-native standards for it.
  • Agentic commerce usually means agents buying goods for humans through checkout flows: a shopping assistant completing a purchase a person asked for, with a card on file and a human ultimately approving.
  • Agentic finance is the machine-to-machine economy that forms on top of the plumbing once thousands of agents and sellers transact: price discovery, routing between competing sellers, reliability signals, spend controls, receipts, and transparent revenue - operated by and for autonomous software.

The practical test, borrowed from the x402 explainer: could the software complete the purchase with no human awake? If a human has to approve, register, or paste a key, it is not agentic. Agentic finance is the same test applied to a whole market rather than to one payment.

What one purchase looks like

An agent working a real task needs something it cannot answer from memory: a live page, a filing, a conversion, an address on a chain. It sends a plain HTTP request. The server answers 402 Payment Required and, in the response headers, quotes a price: which asset, which chain, which recipient, how much, valid until when. On x402 that quote is a PAYMENT-REQUIRED header; on MPP it is a WWW-Authenticate: Payment challenge. A dual-stack server carries both on the same 402 at the same price.

The agent's wallet signs an authorization for exactly that amount - on the EVM rails an EIP-3009 authorization, so it pays no gas and its key never leaves the client - and repeats the identical request with the credential attached. The server verifies it, runs the tool, settles the payment on chain through a facilitator (or, for MPP's native Tempo method, through Tempo's relay), and returns the answer with a receipt that ties this payment to this response.

Two round trips, a couple of seconds, a fraction of a cent. Nothing to sign up for means nothing to leak, and one receipt per call means an agent's spend is legible line by line.

The four layers

  1. Agents. Autonomous software with a wallet: MCP-connected assistants, crawlers, research and trading agents, other services' agents. The buyers and, increasingly, the sellers.
  2. The applied layer. Discovery, routing, pricing, reliability, receipts, transparency. Where an agent finds the right service and pays it once, safely.
  3. Payment protocols. x402 and MPP. Open, HTTP-native, wallet as identity.
  4. Rails and money. Stablecoins settled on public chains: USDC across the EVM chains plus Solana, Stellar and Algorand; USDG on Robinhood Chain; native Tempo.

The interesting problems live in the second layer. A wire format tells you how to pay one seller you already trust. It says nothing about which of a dozen sellers to pay, whether that seller has ever actually delivered, what happens when a paid call fails, or how anyone can check the numbers a marketplace publishes about itself. Those are finance questions, and they only appear once the payments layer works.

Where Agent402 sits

Agent402 is built as the applied layer, and every piece of it is live on both wires:

  • Buy: a catalog of 500+ deterministic pay-per-call tools - search, browser rendering, PDFs, OCR, financial and chain data, an OpenAI-compatible LLM gateway - each priced, tested against its own example in CI, and settled on chain over x402 or MPP. Browse the catalog.
  • Route: an open cross-seller index and a Smart Order Router that resolves a task to the best seller across the ecosystem - ours or anyone's - pays them on the agent's behalf on the same chain the agent paid on, and relays the result with a receipt. Only sellers with proven on-chain settlement are routable.
  • Sell: the open-source tollbooth that lets any site or API charge agents per request over both wires while humans browse free. Non-custodial, no signup.
  • Prove: live revenue by rail and by wire with every figure linked to its on-chain receipt, an on-chain seller leaderboard, uptime measured from outside, and a ledger for the rare charged-but-failed call so it is refunded rather than forgotten.

Settlement ordering is the detail we care most about, because it is where a marketplace can quietly cheat its buyers: Agent402 runs the tool first and settles only on a successful response, so a failed call is never charged. A daily canary buys real tools over both x402 and MPP so the claim is re-proven on mainnet rather than asserted once.

Do agents need crypto to take part?

To pay, an agent needs a wallet holding a stablecoin on a supported chain; gas is sponsored on the EVM rails, so no native token is required. Agent402 also keeps a free tier: pure-CPU tools are payable with a short proof-of-work solve instead of money, so an agent without a wallet still has a path through. To sell, you need an endpoint and a wallet address to receive into. That is the whole onboarding.

Where to go next

Back to blog