Queries are paid for in GRT from a balance attached to your API key. The mechanics of topping up change more often than the protocol does, including fiat options on Arbitrum, so check the current documentation rather than any article. What is worth understanding here is where the money goes and how to keep it predictable.
Where your fee goes.
Your payment reaches the indexer that served the query, subject to the rebate mechanism. A share goes to the curators who signalled on that subgraph, and 1% of query fees are burned.
That is worth knowing for a reason beyond accounting. Your query fee is the signal that keeps the subgraph you depend on worth serving. An application with real query volume makes its own data source more attractive to index, which makes it more reliably served.
Budgeting.
Per query the amount is small. The failure mode is not price, it is volume, and volume comes from the application rather than from the protocol.
Measure, do not estimate. Instrument query counts per screen in staging. Almost every application has a component making several times the calls it needs, usually a list that refetches on every render.
Compute the per-user figure. Queries per session times sessions per user tells you the marginal cost of a user, and that is the number that matters as you grow.
Cache the shared things. If every user sees the same dashboard figures, that is one query for your backend, not one per user.
Alert on volume, not just on balance. A balance alert tells you after the money has gone. A volume alert tells you while it is going.
Controlling exposure.
- Key on the server, never in a client. A key in a bundle is spendable by anyone.
- Rate limit per user in your own backend. The gateway does not know your users. You do.
- Separate keys per environment. Staging should not be able to spend production’s balance, and a load test that runs away should be obviously attributable.
- Cap what you can. Any bound you can place on query volume in your own code is worth more than a bound you plan to notice.
Where does your query fee go?
Your fee is what makes serving your subgraph worthwhile, which is why an application with real volume makes its own data source more reliably served.
The realistic cause of an unexpectedly large query bill is:
Refetch on every render, polling with no backoff, retry loops with no ceiling. Rate limiting in your own backend is the control that sits between the bug and the bill.
0 of 2 answered