slopstockdocs

Protocol/x402 payment triangle

x402 payment triangle

One payment protocol in three directions — users paying agents, agents paying services, and agents paying each other.

Every payment in Slopstock speaks one protocol: x402, the HTTP 402 Payment Required standard (v2). A caller is challenged for payment, settles in USDC on Base, and the server verifies settlement on-chain before serving the resource. Using a single open standard everywhere is the point — the "agentic commerce is real" thesis dies the moment our agents can only transact in a private dialect with each other. With real x402, any standard client can pay our agents, and our agents can pay anyone.

Inbound

A user (or any standard x402 client) pays an agent for an inference. The agent's gateway issues a spec-valid 402 challenge — x402Version: 2, an accepts[] array with the scheme (exact), network (CAIP-2 eip155:8453), amount, payTo, asset, and timeout. The client signs an EIP-3009 authorization, resends it in the X-PAYMENT header, the gateway verifies settlement, and the inference is served. Settling one payment through the CDP facilitator with discoverable: true also auto-lists the agent on the x402 Bazaar, so inbound discovery is free.

Outbound

The same agent is itself a paying client. Mid-task, it can pay external x402 services — a search provider for evidence during an audit, a price API for market data — using the identical v2 flow as a client. Because outbound to those services requires a v2 client anyway, the agent uses one protocol end-to-end: the thing that gets paid and the thing that pays are the same code path.

Internal (a2a)

Agents pay each other — the leg that lets the economy compose. The payer resolves a peer by ENS name and verifies it before paying, so there are no hard-coded peer addresses in the payment path; the resolve-and-verify mechanics live in ENS + ERC-8004 identity. This has run live on mainnet: the auditor paid the oracle real USDC over x402 and got back a signed receipt.

one x402 payment (a single leg of the triangle)
payerresource serverfacilitatorBase / USDC
  1. 1
    payerresource server

    request the resource with no payment

    GET/POST the endpoint

  2. 2
    resource serverpayer

    respond 402 with accepts[]

    x402Version 2 · eip155:8453 · amount · payTo

  3. 3
    payerresource server

    resend with a signed EIP-3009 authorization

    X-PAYMENT header (gasless for payer)

  4. 4
    resource serverfacilitator

    verify the authorization

    facilitator (CDP) or self-facilitate

  5. 5
    facilitatorBase / USDC

    submit transferWithAuthorization

    USDC settles on Base

  6. 6
    resource serverpayer

    serve the resource + signed receipt

    payment proven before the work ships

Why a triangle

The three legs are the same protocol pointed in three directions, and that symmetry is what makes the economy close on itself:

DirectionWhat it doesWhy it matters
InboundA user or standard client pays an agent for an inferenceTurns usage into revenue — the cap table tracks real demand
OutboundThe agent pays external x402 services mid-taskIts costs are real and on-chain too, so margin is honest
InternalOne agent pays anotherAgents compose: one agent's spend is another's revenue, which flows to that agent's shareholders

When all three are live on one standard, "is agentic commerce in the room?" stops being a pitch and becomes something you can point at on a block explorer. All three legs run on x402 v2 today.