---
title: Subgraph Collections
---

Subgraph Collections are a way for a Gateway Operator to group and curate a chosen set of Subgraphs and present them to end users as a coherent product. Collections are optional, but for most consumer-facing Gateways they are one of the clearest sources of added value.

## Reducing Complexity by Curating Select Data

The Graph Network holds more than 15,000 published Subgraphs across many chains. That breadth is a strength for the network, but also an overwhelming surface for many consumers. A wallet team needs a handful of Subgraphs for balances and token metadata; an analytics product needs the DEX and lending Subgraphs for the protocols it tracks. Neither wants to navigate the entire network to find them.

Collections are also where the widely used Community Subgraphs on rewards-enabled chains (for example, popular DEX or lending Subgraphs served across many Gateways from shared network infrastructure) become a packaged product: rather than each Operator indexing them privately, an Operator surfaces them as a curated set.

A Collection is the curation layer that solves this. By grouping a select set of Subgraphs, a Gateway Operator can:

- **Reduce complexity:** present end users with the specific Subgraphs relevant to their product, not the full catalog.
- **Curate for quality:** choose the versions and deployments an Operator has validated, rather than leaving version selection to each consumer.
- **Package a data product:** turn raw network access into a named, opinionated bundle ("DeFi Core", "NFT Analytics", "Wallet Essentials") that reflects an Operator's product focus.

Offering common, well-chosen data (the pools, names, and balances an Operator's customers actually query) is more valuable to most consumers than an undifferentiated deluge of every Subgraph on the network. It is also how a Gateway Operator differentiates one Gateway from another: two Gateway Operators can serve the same network, but the one with better-curated collections offers a better product.

Collections map naturally onto a Gateway's existing controls. An API key can be restricted to a specific allow-list of Subgraph IDs (see [Serving Queries](/gateways/subgraphs/consumer-side/serving-queries/)), so a Collection can be enforced technically: a key scoped to a Collection can query exactly the Subgraphs in it and nothing else. This lets an Operator sell or provision access to a curated bundle rather than to the whole network.

## Why Collections Matter for a Gateway

- **Better consumer experience:** users see a curated, relevant set rather than the whole network.
- **Differentiation:** curation quality is a product advantage one operator can hold over another.
- **Cleaner billing and access:** keys scoped to a Collection make provisioning and metering straightforward.
- **Path to vertical products:** a Collection is the seed of a packaged data product an Operator can price and support as a unit.
