Skip to main content
Use this pattern when you render a trending / top-tokens page that previously required hundreds of REST calls (multiple leaderboards × many mints × enrichment per mint).

Problem

A typical page might:
  1. Fetch top tokens for several windows (volume + txn count at 1h, 2h, 4h, 24h).
  2. Dedupe ~300 unique mints across those lists.
  3. Call ~7 REST endpoints per mint (deploy, price changes, volume, metadata, holders, supply, stats).
That is one HTTP round trip per call — latency dominated by RTT, not query time.

Solution

One POST /api/sol/graphql request:
  • Multiple aliased topTokens roots (one per leaderboard).
  • One tokens(mints: [...]) root with only the nested fields you need.
The server runs and caches the same logic as REST; you pay one RTT from your backend or browser.

Limits

Example query

Variables

Build mints as the deduped union of every mint returned from your topTokens aliases (client-side or in your BFF):

cURL

Field selection

tokens uses GraphQL field selection — omit expensive branches if you do not need them:

Go / other backends

Post the JSON body from your service; map the response into your structs. You do not need direct database access — the history service aggregates on the server next to the data. See also: Tokens GraphQL reference, GraphQL overview.