A marketplace where every buyer is a program.
Use InvokePort tools with explicit USDC pricing and a machine-readable catalog.
Discover provider capabilities in a machine-readable catalog. Base settlement uses real USDC for first-party paid tools. Free tools remain available separately. Third-party execution is closed.
One crossing, eight moves
This is the protocol flow: discovery, publishing, credentials, API keys, signed SDK sync, 402 verification, settlement and delivery use the same gateway.
- 01DiscoverQuote · agent → gateway
GET /api/catalog — capabilities, prices and schemas, as JSON
- 02RequestQuote · agent → gateway
The unpaid call to a routing key. Nothing has been charged yet.
- 03402 Payment requiredQuote · gateway → agent
Payment required — the gateway's own quote names the asset, the amount, the network (eip155:8453), payTo and the resource.
- 04AuthorizePay · agent, locally
EIP-3009 transferWithAuthorization, signed in the agent's wallet
- 05RetryPay · agent → gateway
The identical request, now carrying the payment header
- 06SettledPay · gateway, before forwarding
The facilitator settles to the payTo address quoted by the gateway: a verified split for third-party services, or the owner wallet for a first-party offer.
- 07ExecuteDeliver · gateway → destination
Only a verified payment ever reaches the destination
- 08Result returnsDeliver · destination → agent
HTTP 200, plus a settlement reference the agent can resolve
Magenta is refusal. Cyan is settlement. The gate is the only thing here that opens, and only payment opens it.
Steps 01–06 never touch the destination: it is not called, and the provider is not paid, until the facilitator has settled. The quote above is an illustrative one — the real scheme, asset, amount and payTo come from the gateway's own 402 response, and the settlement reference comes from the facilitator.
Two sides, one protocol
The gateway is the only piece that knows x402. Neither side implements it.
Prepare a service before monetization
- List an HTTP API, an MCP server, a read-only contract, or an automated task.
- External execution remains closed even after publishing a provider listing.
- Only InvokePort first-party paid tools are enabled; proceeds go to the displayed owner wallet.
- See calls and failures, including seller revenue.
- Disable a capability and the next call never reaches your destination.
Pay for a call the way a program can
- Select a service from JSON at
/api/catalog, not by scraping HTML. - Parse price, asset, network and payTo straight out of the 402 body.
- Apply a budget policy before signing anything. Over budget means no call.
- Retry the identical request with a payment header and get the real response.
- Each payment resolves on a Base explorer.
What InvokePort deliberately is not
The first-party audit pays the displayed owner wallet directly. InvokePort does not hold a customer balance. Third-party settlement is not enabled.
Base is the configured payment network. Real USDC has financial value; check the final 402 quote before signing.
There is no InvokePort token, no points, and no governance. Prices are in real USDC on Base.
The gateway decides the price in the 402, whether a payment verified, and whether to forward upstream. A compromised gateway could overcharge or take payment and not deliver. This release documents that boundary clearly. Paid upstream failures have no automatic refund.