GraphQL serves the paid REST data for free #358

Background

src/middleware/x402.ts gates routes behind USDC micropayments:

export const GATED_ROUTES: readonly GatedRoute[] = [
  { path: '/price',   method: 'GET', price: '$0.10', description: 'Unified SDEX+AMM price with VWAP and best route' },
  { path: '/pools',   method: 'GET', price: '$0.05', description: 'AMM liquidity pool reserves and spot prices' },
  { path: '/candles', method: 'GET', ... },
  ...
]

Every entry is a GET on a REST path. GraphQL is POST /graphql, so
findGatedRoute never matches it — and getPrice returns the same aggregated
price, VWAP and best route that GET /price charges $0.10 for.

Anyone who notices can read the entire paid surface for nothing, and the
graphiql: true console (L192) hands them the schema to do it with.

What to build

This needs a decision before it needs code, so propose one in the PR:

• Gate the operation, not the path. A GraphQL request carries one or more
  operations; pricing has to be derived from which fields are requested, not
  from the URL. That is the only approach that survives a query asking for
  getPrice and getBestRoute together.
• Or put GraphQL behind a paid API key and leave x402 for REST, if per-call
  settlement on a batched query is not worth the complexity.

Whichever you pick:

• A single request asking for several gated fields must be priced as several,
  not one.
• An unpaid request must be rejected before any resolver does database work.
• Subscriptions are the same problem — see L193 — so say how your approach
  extends to them even if you do not implement it here.
• Document the pricing in the same place GATED_ROUTES is documented.

Acceptance criteria

• A GraphQL query for a gated field is not free
• Price scales with the gated fields requested, not with the request count
• An unpaid request is rejected before any resolver queries the database
• A test asserts an unpaid getPrice query is refused while an unpaid listPairs is not
• The approach and its reasoning are written down, including how it extends to subscriptions

Drips Wave · Complexity: Advanced · 200 points

Repo: Divinity-Labs/Lens. Node + TypeScript, Fastify, mercurius for
GraphQL at POST /graphql, Prisma on Postgres, Redis, Prometheus.

Run the tests: npm test. The tests are vitest, not jest. Running jest
here reports "66 suites, 0 tests" and means nothing. A single file is
npx vitest run src/__tests__/graphqlSubscription.test.ts.

Load test (prices) is already failing on main and has been for some
time. It is not your PR. Everything else should be green.

Read src/__tests__/graphqlSubscription.test.ts before you start. It is the
house pattern for testing this surface and it is good — it drives a real
subscription through a real server and asserts on what a client receives.

This service prices real assets on Stellar mainnet. A wrong number is worse
than a missing one, because the caller cannot tell.

Never elide an address, a contract id or a key in code, comments or test
fixtures. A previous batch shortened a contract id in an issue and five
contributors invented plausible-looking ids to fill the gap. Write it in full or
not at all.

Required: Before submitting, join the contributor Telegram so your work can be tracked and counted toward the Stellar Wave: https://t.me/+fxHXq8f1SwlkZDBk