Chain Integrations

The Graph Network’s value grows with every chain it can index. A Gateway Operator has both an interest in, and an ability to drive, expanding that chain coverage, because more supported chains means more data an Operator can serve consumers through a single endpoint (see the Overview on supporting more chains). Contributing chain integrations back to the ecosystem is one of the highest-leverage ways an Operator strengthens The Graph, and it is increasingly a shared, commercial process between Gateway Operators and The Graph Foundation rather than a purely technical one.

What a Chain Integration Involves

For The Graph Network to serve Subgraphs on a chain, that chain has to be integrated into the indexing stack: Graph Node needs to be able to ingest the chain’s data (typically through Firehose and Substreams tooling), and the protocol has to recognize and support indexing on it, including the epoch and allocation accounting that lets Indexers be rewarded (the Epoch Block Oracle’s per-chain coverage, discussed in Tracking QoS, is part of this). A chain integration is therefore both an engineering effort and a protocol-level step, usually proposed and coordinated through The Graph’s governance process.

Because chain integrations expand what every Gateway and every Indexer can serve, they are a natural place for Operators and core developers to collaborate: an Operator who needs a chain for their customers can help source, fund, or drive its integration, and the result benefits the whole network. What differs across integrations is how a chain’s Subgraphs get funded and served once the engineering work is done, and that is where the models below apply.

Subgraph Indexing Depends on Chain Support

Not every Subgraph is best served by the shared network. Three workload patterns determine which Subgraphs belong on The Graph Network, which stay within a Gateway Operator’s own infrastructure, and where chain integrations create the most leverage.

• Provider-Specific Subgraphs: private or bespoke Subgraphs that a customer wants deployed into a specific Gateway Operator’s infrastructure. These users want a private instance or a single accountable vendor for support and reliability, so the workload has less need to live on the shared network. Moving all Subgraph traffic to the network is neither likely nor, in these cases, desired. Provider-specific Subgraphs remain a differentiated offering within each Operator’s own stack.
• Rewards-Enabled Subgraphs: widely used “Community Subgraphs” on rewards-enabled chains (e.g., Uniswap deployments on Ethereum, Base, and BNB Smart Chain). Because indexing rewards are emitted on these chains and broadly support their Subgraphs, it makes little sense for each Operator to duplicate the work of indexing them. The network’s Indexers sync these Subgraphs, and multiple Gateway Operators surface the same Subgraphs from shared network infrastructure as part of their Subgraph plans.
• Chain-Subsidized Subgraphs: Subgraphs on lesser-known chains (e.g., smaller L2s) that today are often supported by a single Gateway Operator, creating vendor lock-in and infrastructure costs the usage rarely justifies. The goal is to bring these long-tail chains onto The Graph Network, so multiple Operators can split and offset the cost and the chain becomes supported across Gateways rather than tied to one provider.

Chain integrations create the most leverage for Community and Chain-Supported Subgraphs, which are the workloads intended to move onto shared network infrastructure.

Three Models for Chains Getting Subgraphs Support

There are currently two ways a chain’s Subgraphs get served through The Graph Network, with a third model, Indexing Payments, set to replace both as it ships.

Rewards-Enabled Chains

These are chains that have completed The Graph’s governance process, after which indexing rewards (funded by GRT issuance and directed by curation signal) are issued to Indexers serving Subgraphs on that chain. Becoming rewards-enabled requires sustained usage and developer engagement (demonstrated through active support from one or more Gateways or independent Indexers), chain readiness (verified determinism, a permissionless chain anyone can run, and at least one stable client), and Indexer readiness (the guides and tooling Indexers need to index the chain). This path was initially defined in GIP-0057 and later ratified with the revised criteria above; it remains governed by The Graph Council, not by any single ecosystem member. The canonical list of rewards-enabled chains is maintained in the networks registry⁠ and surfaced on The Graph’s Supported Networks page.

Because these chains have stable rewards, a Gateway Operator can surface a curated set of Community Subgraphs for consumers without ever indexing a Subgraph directly: curation signal attracts Indexers, and indexing rewards compensate them. Curation only drives rewards on rewards-enabled chains, which is why Community Subgraphs are most functional there. Using curation to attract syncs is covered in Incentivizing Syncs.

Off-Chain Integration Deals

These are bilateral arrangements curated by ecosystem members (e.g., Gateway Operators) that line up specific Indexers to support a chain’s Subgraphs before, or instead of, the chain becoming rewards-enabled. Today, payment and settlement happen off-chain. These deals exist because chains often need reliable Subgraph support faster than the governance process moves, need a single accountable counterpart, or because curation signal is an imprecise tool for guaranteeing service on a new chain.

The drawback is duplication: each Gateway Operator supports the chain with its own infrastructure, leading to operational overhead and duplicated work, often without enough demand to justify the cost, that the network’s Indexers are better suited to absorb. This burden is most acute for Chain-Supported Subgraphs, because a chain becomes vendor-locked to one provider and the Operator is left with more operating cost than the usage warrants. Off-chain deals are best understood as an interim model that Indexing Payments is designed to replace.

Indexing Payments (In Progress)

Indexing Payments is a protocol mechanism that directly compensates Indexers for serving a given Subgraph through recurring on-chain payments, with no curation signal required. The payer funds an on-chain escrow, Indexers accept agreements and collect payment by posting Proofs of Indexing (POIs), and either party can exit gracefully. It replaces the off-chain deal model with a simpler, trust-minimized arrangement, and it is grounded in GIP-0081⁠, GIP-0087⁠, and GIP-0088⁠.

Indexing Payments are designed to reduce unsustainable dependence on indexing rewards, convert off-chain deals into on-chain protocol revenue that drives value to The Graph Network and GRT, and offload Gateway Operators’ infrastructure costs onto the network’s Indexers. The same underlying mechanism is expected to take two forms in practice:

• Chain-to-Indexer Payments (CHIPs): an on-chain mechanism used by The Graph Foundation, a chain’s ecosystem, or another surrogate to incentivize baseline support for a chain on The Graph Network. In the common case, a smaller L2 pays the Foundation a lump sum for a year of indexing support, and the Foundation uses the mechanism to pay N Indexers to index M Subgraphs within a fair-use policy at a defined quality-of-service threshold, while maintaining a quality-of-service dashboard and coordinating Indexers. CHIPs establishes baseline coverage that multiple Gateway Operators can build on to offset infrastructure costs; it does not, by default, obligate any individual Operator to support that chain.
• Direct Indexing Payments (DIPs): used by a Gateway Operator to incentivize the network’s Indexers to sync specific Subgraphs on behalf of consumers who have signed up for a plan through that Gateway. In the common case, a large consumer publishes new Subgraphs that exceed the CHIPs baseline, and the Operator uses DIPs to “boost” those Subgraphs by paying Indexers directly for service above the baseline package.

The distinction is the key to the Foundation’s model: CHIPs is the Foundation’s preferred mechanism for baseline chain support, while DIPs is the preferred mechanism for a Gateway Operator to boost specific Subgraphs beyond that baseline. Direct Indexing Payments as they apply to the supply side are covered in more depth in Incentivizing Syncs.

Model Comparison

The Foundation’s Chain-Integration Model

The Graph Foundation’s proposed end state is a three-layered approach to funding Subgraph support for chains.

First, Rewards-Enabled Chains continue to be supported in the short-to-intermediate term: chains already integrated through GIP-0057⁠ keep receiving indexing rewards directed by curation signal. Over time, the rewards-based approach is phased out in favor of CHIPs as the primary mechanism for funding Indexer support on a chain, with timing and sequencing subject to governance.

Second, The Graph Foundation and Gateway Operators both retain autonomy to source chain-integration deals, and the Foundation advocates that they do so as a partnership, with two paths depending on who leads the deal:

• Foundation-Led CHIPs Process: when the Foundation sources a deal, it handles sourcing, qualification, negotiation, funding, and go-to-market, then uses CHIPs to fund N Indexers syncing M Subgraphs as a baseline support package.
• Combined CHIPs & DIPs: when a Gateway Operator sources a deal, the Operator and the Foundation collaboratively qualify, negotiate, and fund the chain. CHIPs funds the baseline coverage that multiple Gateways can use, while the sourcing Operator can layer DIPs on top to boost the quality of specific Subgraphs for its own consumers. The Foundation remains responsible for overall network quality; the Operator is responsible for its own consumers’ service quality.

The Foundation proposes structuring the economics of an integrated chain as a revenue split, expressed as ranges until finalized per chain: a Foundation base (covering CHIPs management, quality-of-service monitoring, and technical integration), a business-development sourcing share paid to whichever party sources the deal, and the majority submitted on-chain as recurring payments to Indexers. Where a chain wants dedicated Indexers at a higher quality of service, an additional share can be directed to the relevant Gateway Operator’s infrastructure. Specific percentages are a matter of negotiation and are not fixed by this documentation.

Third, the Foundation has a strong preference for a shared business-development and marketing pipeline across all chain integrations. Consolidation gives chains one consistent commercial counterpart, gives Indexers one consistent payment mechanism, and reduces the settlement, legal, and accountability ambiguity of several parallel bilateral deals, while creating a single front for supporting chains across The Graph’s product suite over time.

Why Gateway Operators Support Chain Integrations

• More coverage for the product: an integrated chain is one a Gateway Operator can serve consumers through the same Gateway, with no separate infrastructure.
• Lower cost through shared infrastructure: bringing a chain onto The Graph Network, rather than indexing it privately, offloads the operational burden onto the network’s Indexers, where multiple Operators split and offset the cost.
• Network-aligned expansion: integrating a chain into The Graph Network keeps the Operator contributing to the decentralized network while meeting customer demand.
• New protocol revenue: converting off-chain arrangements into CHIPs and DIPs drives value to The Graph Network and GRT rather than to parallel, off-network deals.
• Shared benefit: once a chain is integrated, every Indexer can index it and every Gateway can serve it, so the Operator who drives the integration strengthens the whole ecosystem, not just its own product.