The setup
The rails already exist. The Graph is listed on the x402 bazaar, the pay-per-query gateway is live (@graphprotocol/client-x402, $0.01/query on Base), and PayQL wraps it as an MCP server so an agent can pay-per-query gasless and keyless. So technically, an agent can pay to query The Graph today.
It basically doesn’t happen. And it’s not the tech, it’s three specific, fixable blockers.
The data: real demand, near-zero volume
I track agent payments to The Graph on Base at x402-watch (onchain via the x402-omnigraph subgraph; ERC-8004 identity via 8004scan + the agent0 subgraph).
Scale: the EIP-3009 settlement rail x402 runs on (Base, all-time, May 9 2025 → Jun 3 2026):
- 132,187,043 settlements · $42,204,577 in USDC volume · peaked near 4M settlements/day in mid-November 2025.
Agents paying to query The Graph over x402 ($0.01/query):
- $2.22 total · 222 payments · 29 ERC-8004-identified agents (20 repeat) · last payment 18 days ago.
The demand is real: 29 identified agents found The Graph and paid to query it, but the volume is a rounding error against a ~$42M rail, and it has stalled. Here’s why.
Blocker 1 is Awareness: agents don’t know x402 exists on The Graph
Being listed on the bazaar is not the same as agents knowing The Graph is a native x402 data source. Almost no agent developer, and none of the frameworks agents are built on (AgentKit, MCP clients, the payment-capable agent stacks), surface “you can pay The Graph to query onchain data over x402.” This shipped quietly and was never marketed to the audience that would use it.
This is a marketing/distribution problem, and it’s the top of the funnel. If agents don’t know it exists, nothing downstream matters.
Blocker 2 is Discovery: agents can’t find the correct subgraph
Even an agent that knows The Graph is payable hits a wall immediately: which of 15,000+ subgraphs answers its question? There is no agent-native way to go from “I need X data on chain Y” to “query subgraph Z.” A human browses the Explorer; an agent has nothing.
The only tool attempting this today is the subgraph-registry a semantic index of the entire registry (by protocol, chain, schema, reliability) that an agent can query to resolve the right subgraph. Until discovery like this is first-class, the payment rail points at 15,000 unlabeled doors. A pay-per-query gateway is useless if the agent can’t find what to pay for.
Blocker 3 is Payments: x402 is built for one round trip, not repeat
This is what graph-client#1031 is about. x402 settles per call: one signed EIP-3009 authorization + one onchain settlement per query. It’s designed for a single request/response round trip not the repeated query loops agents actually run, where one task fires dozens or hundreds of small reads.
At loop volume, one-round-trip payments mean latency (a settlement round-trip in front of every read), overhead (an onchain event per $0.01 query), and no refund on failure (a query that returns nothing still bills). That’s the friction that turns “an agent paid a few times” into “an agent gave up.”
The fix already exists in x402: batch-settlement
Crucially, this is not a protocol gap — x402 already ships a batch-settlement scheme that is a superset of what #1031 asked for. Stateless, unidirectional payment channels:
- Deposit once into onchain escrow (via EIP-3009 or Permit2, submitted by the facilitator).
- Off-chain cumulative vouchers per request — the server verifies and serves the response without waiting for a transfer.
- Batched claim — the channel manager redeems the latest vouchers from many channels in one onchain tx, then settles.
- Cooperative refund of idle channels.
- Charge below the max — the route price is a per-request maximum; the server can charge less via settlement overrides (
setSettlementOverrides(res, { amount: "50%" })), so failed/partial reads needn’t bill full price.
Shipped, audited, and implemented in three languages: spec · docs · contract · Python · Go · TS (@x402/evm/batch-settlement).
Maps 1:1 to #1031:
| #1031 ask | batch-settlement mechanism |
|---|---|
| Avoid per-call onchain settlement | Deposit-once escrow + off-chain cumulative vouchers + batched redemption |
| Overhead at agent query-loop volume | Purpose-built for “repeated paid API calls / usage-metered endpoints” |
| No refund on failed/partial reads | Cooperative refund + settlement overrides (charge below the per-request max) |
| Payment rails | EIP-3009 or Permit2 — the same rails the gateway already uses |
Related, worth watching: x402#2273 (metered-session, prepay + auto-refund for streaming) and x402#1642 (upto scheme). The original payment-channel request, x402#136, was closed when batch-settlement landed via PR #2051.
What to do
- Market it. Get “The Graph is a native x402 data source” in front of the agent frameworks and payment stacks where agents live. This is the biggest, cheapest lever.
- Make discovery first-class. Build on / adopt an agent-native subgraph resolver like the subgraph-registry so an agent can find the right subgraph, not just pay for one.
- Adopt
batch-settlementin graph-client. It’s shipped, audited, and has reference implementations in TS/Python/Go — nothing to invent.
The demand is already onchain. The rails already exist. What’s missing is that agents don’t know it’s there, can’t find what to query, and get charged one round trip at a time. All three are fixable, and two of the three fixes are already built.