diff --git a/website/next.config.js b/website/next.config.js
index 88e5e9cbbf37..aca94d28bba3 100644
--- a/website/next.config.js
+++ b/website/next.config.js
@@ -75,6 +75,13 @@ const withNextra = nextra({
type: 'children',
title: t('global.navigation.indexing'),
},
+ '---gateways': {
+ type: 'separator',
+ },
+ gateways: {
+ type: 'children',
+ title: 'Gateway Software',
+ },
'---5': {
type: 'separator',
},
diff --git a/website/public/img/gateway/gateway-architecture.png b/website/public/img/gateway/gateway-architecture.png
new file mode 100644
index 000000000000..b5450e60ad34
Binary files /dev/null and b/website/public/img/gateway/gateway-architecture.png differ
diff --git a/website/public/img/gateway/gateway-architecture.svg b/website/public/img/gateway/gateway-architecture.svg
new file mode 100644
index 000000000000..ba6b705fc2b5
--- /dev/null
+++ b/website/public/img/gateway/gateway-architecture.svg
@@ -0,0 +1,82 @@
+
diff --git a/website/public/img/gateway/gateway-kafka-topics.png b/website/public/img/gateway/gateway-kafka-topics.png
new file mode 100644
index 000000000000..89a167fbf81b
Binary files /dev/null and b/website/public/img/gateway/gateway-kafka-topics.png differ
diff --git a/website/public/img/gateway/gateway-kafka-topics.svg b/website/public/img/gateway/gateway-kafka-topics.svg
new file mode 100644
index 000000000000..8bcd75bd0ffe
--- /dev/null
+++ b/website/public/img/gateway/gateway-kafka-topics.svg
@@ -0,0 +1,61 @@
+
diff --git a/website/public/img/gateway/subgraph-gateway-black.svg b/website/public/img/gateway/subgraph-gateway-black.svg
new file mode 100644
index 000000000000..ea0bf6451231
--- /dev/null
+++ b/website/public/img/gateway/subgraph-gateway-black.svg
@@ -0,0 +1,14 @@
+
diff --git a/website/public/img/gateway/subgraph-gateway-icon.png b/website/public/img/gateway/subgraph-gateway-icon.png
new file mode 100644
index 000000000000..c38bedd66f5f
Binary files /dev/null and b/website/public/img/gateway/subgraph-gateway-icon.png differ
diff --git a/website/public/img/gateway/subgraph-gateway-white.svg b/website/public/img/gateway/subgraph-gateway-white.svg
new file mode 100644
index 000000000000..3e17b4149459
--- /dev/null
+++ b/website/public/img/gateway/subgraph-gateway-white.svg
@@ -0,0 +1,14 @@
+
diff --git a/website/src/layout/Layout.tsx b/website/src/layout/Layout.tsx
index c09212f50c9e..c6a2bc029609 100644
--- a/website/src/layout/Layout.tsx
+++ b/website/src/layout/Layout.tsx
@@ -198,6 +198,30 @@ export default function Layout({ pageOpts, children }: NextraThemeLayoutProps
}
+ if (routeWithoutLocale === '/gateways' || routeWithoutLocale.startsWith('/gateways/')) {
+ const maskUrl = `url(${process.env.BASE_PATH ?? ''}/img/gateway/subgraph-gateway-icon.png)`
+ return (
+
+ )
+ }
if (routeWithoutLocale === '/graph-horizon' || routeWithoutLocale.startsWith('/graph-horizon/')) {
return
}
diff --git a/website/src/pages/en/gateways/_meta-titles.json b/website/src/pages/en/gateways/_meta-titles.json
new file mode 100644
index 000000000000..e3843df356bc
--- /dev/null
+++ b/website/src/pages/en/gateways/_meta-titles.json
@@ -0,0 +1,3 @@
+{
+ "subgraphs": "Subgraph Gateway"
+}
diff --git a/website/src/pages/en/gateways/_meta.js b/website/src/pages/en/gateways/_meta.js
new file mode 100644
index 000000000000..8815305ecd92
--- /dev/null
+++ b/website/src/pages/en/gateways/_meta.js
@@ -0,0 +1,7 @@
+import titles from './_meta-titles.json'
+
+// Gateway Software groups the different gateway offerings in The Graph ecosystem.
+// Add future gateway software packages here to control their order.
+export default {
+ subgraphs: titles['subgraphs'] ?? '',
+}
diff --git a/website/src/pages/en/gateways/subgraphs/_meta-titles.json b/website/src/pages/en/gateways/subgraphs/_meta-titles.json
new file mode 100644
index 000000000000..5c7eb56ac745
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/_meta-titles.json
@@ -0,0 +1,6 @@
+{
+ "components": "Gateway Components",
+ "consumer-side": "Consumer-Side",
+ "supply-side": "Supply-Side",
+ "ecosystem": "Ecosystem Contributions"
+}
diff --git a/website/src/pages/en/gateways/subgraphs/_meta.js b/website/src/pages/en/gateways/subgraphs/_meta.js
new file mode 100644
index 000000000000..61dcefc54d6e
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/_meta.js
@@ -0,0 +1,9 @@
+import titles from './_meta-titles.json'
+
+export default {
+ overview: '',
+ components: titles['components'] ?? '',
+ 'consumer-side': titles['consumer-side'] ?? '',
+ 'supply-side': titles['supply-side'] ?? '',
+ ecosystem: titles['ecosystem'] ?? '',
+}
diff --git a/website/src/pages/en/gateways/subgraphs/components/_meta.js b/website/src/pages/en/gateways/subgraphs/components/_meta.js
new file mode 100644
index 000000000000..ed00096674f6
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/components/_meta.js
@@ -0,0 +1,8 @@
+export default {
+ overview: '',
+ 'operating-a-gateway': '',
+ 'indexer-selection': 'Indexer Selection',
+ 'graph-tally': '',
+ titorelli: '',
+ 'gateway-in-a-box': '',
+}
diff --git a/website/src/pages/en/gateways/subgraphs/components/gateway-in-a-box.mdx b/website/src/pages/en/gateways/subgraphs/components/gateway-in-a-box.mdx
new file mode 100644
index 000000000000..53dd8960c2c5
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/components/gateway-in-a-box.mdx
@@ -0,0 +1,95 @@
+---
+title: Gateway in a Box (Beta)
+---
+
+Gateway in a Box (gib) is a self-hostable Subgraph Gateway for The Graph Horizon on Arbitrum One, packaged in a Docker Compose bundle. It exists to let a service provider stand up a working, TAP-native, Horizon-ready Gateway without a multi-day setup ceremony. It is a community reference deployment (a [Nightswatch](https://github.com/nightswatchhq/gib) project, MIT licensed), not an official Graph Foundation release, and it is a good starting point for understanding what a minimal production Gateway actually runs.
+
+## What is in the Box
+
+Under the hood, gib wires together a Gateway fork (TAP v2 / Horizon-native) plus the `graph-tally` aggregator and escrow-manager, a Redpanda bus, and optional Prometheus and Grafana, all configured from a single `.env` file. An Operator's consumer API keys are their own; no Subgraph Studio account is needed for an Operator's users (topology bootstrap currently does require a read-only Studio key, discussed below).
+
+| Service | Role |
+| ------------------------ | ---------------------------------------------------------------------------- |
+| `gateway` | Routes queries, signs TAP v2 receipts |
+| `tap-aggregator` | Public endpoint that aggregates receipts into RAVs for Indexers |
+| `escrow-manager` | Auto-authorizes the signer and tops up escrow |
+| `redpanda` | Kafka-API bus for receipts and attestations (the fee-metering bus, required) |
+| `prometheus` + `grafana` | Optional `monitoring` profile: escrow and query dashboards |
+
+```
+ Gateway in a Box
+ ┌──────────────────────────────────────────────┐
+ client ──query──▶ │ gateway ── signs TAP v2 receipts │
+ (Bearer key) │ │ │
+ │ ├─▶ trusted_indexers ─▶ network subgraph │ indexer discovery
+ │ └─▶ selected indexers ─▶ query results │
+ │ │
+ │ redpanda ◀─ query fee records (metering) │
+ │ │ │
+ │ escrow-manager ─▶ PaymentsEscrow (on-chain) │ auto top-up
+ │ tap-aggregator ─▶ RAVs for indexers (public)│
+ └──────────────────────────────────────────────┘
+```
+
+## Footprint
+
+gib is light. Measured on Arbitrum One with the full network topology resident (around 16,000 Subgraphs, 26,000 deployments, 12,500 indexings):
+
+| Component | Resident memory |
+| --------------- | --------------- |
+| gateway (VmRSS) | around 207 MB |
+| redpanda | around 330 MB |
+| tap-aggregator | around 10 MB |
+| Full stack | around 570 MB |
+
+A 2 GB, 1 vCPU box runs it comfortably. A Gateway holds the network topology in memory, but that cost is around 200 MB in practice. Disk needs are a few GB for images plus Redpanda retention.
+
+## Quickstart
+
+Prerequisites: Docker and Compose, `gettext-base` (`envsubst`), `python3`, and optionally Foundry's `cast` for key generation (Docker is used as a fallback). A funded sender wallet is only needed for real payments.
+
+```sh
+git clone https://github.com/nightswatchhq/gib && cd gib
+
+cp .env.example .env # 1. fill the TODOs (SENDER_ADDRESS, TOPOLOGY_STUDIO_KEY, GATEWAY_API_KEYS)
+./scripts/fetch-addresses.sh # 2. auto-fill verified Horizon addresses -> config/addresses.env
+./scripts/gen-keys.sh # 3. generate sender + signer keys -> ./secrets
+./scripts/render.sh # 4. render runtime/{gateway.json,escrow-manager.json,.env}
+docker compose --env-file runtime/.env up -d # 5. go
+```
+
+gib ships payment-safe by default: `PAYMENT_REQUIRED=false` and `ESCROW_DRY_RUN=true`, so an Operator can validate query routing before a single wei moves. Flip both when an Operator is ready for real payments. See [Managing Escrow](/gateways/subgraphs/supply-side/managing-escrow/).
+
+## The Smoke Test
+
+`gib smoke` is the self-test every operator should run before asking any Indexer to whitelist them. It runs one command against a running deployment, touches nothing on-chain, and needs no funded keys:
+
+```sh
+docker compose --profile smoke run --rm smoke
+```
+
+It self-configures from the Operator's rendered `runtime/gateway.json` and prints a pass/fail table. The checks prove, end to end, that topology synced, a real query selected candidate Indexers and attached receipts, the running Gateway signed with the Operator's configured signer, those receipts aggregate into a RAV that recovers to the Operator's signer with the correct EIP-712 domain and value, RAV fields match the Operator's sender and SubgraphService, and tampered or wrong-key receipts are rejected. A green result is the credibility artifact an Operator brings to Indexers.
+
+## The Onboarding Wall (Why Fresh Deployments Return 402)
+
+A fresh gib deployment signs valid receipts that every Indexer rejects with a `402`. This is protocol design, not a defect, and it is the one part of running a Gateway an Operator cannot do alone.
+
+Indexers only serve paid queries from senders they have explicitly whitelisted. The whitelist is the Indexer's `[tap.sender_aggregator_endpoints]` config: a map of `sender address` to `your aggregator URL`. It is simultaneously the trust list (whose receipts the Indexer will accept) and the address book (where the Indexer's `tap-agent` sends receipts to be turned into RAVs). A sender that is not in the map is rejected, because an unredeemable receipt is a loss the Indexer eats.
+
+An established Gateway avoids this wall only because every Indexer already carries its sender in their config out of the box. That pre-installed trust is the onboarding moat; it is protocol-level and social, not technical, and it is the same wall any independent Gateway faces. Getting Indexers to accept a Gateway is covered in [Routing Queries to Indexers](/gateways/subgraphs/supply-side/routing-queries/), and the aggregator handshake in [Managing Escrow](/gateways/subgraphs/supply-side/managing-escrow/).
+
+A realistic onboarding sequence is: pick the target Subgraphs an Operator's users query, identify the Indexers serving them with good QoS, make the ask to each (the Operator's `gib smoke` output, the one config line mapping the Operator's sender to the Operator's aggregator URL, and confirmation the Operator funded per-Indexer escrow), verify with a paid query, then expand. Because a Gateway selects up to three Indexers per query, three or more accepting Indexers per target Subgraph is the practical point at which that Subgraph serves reliably.
+
+## Deploying a Subgraph Gateway with Skill
+
+For operators using Claude Code, the [companion `gib-skill` plugin](https://github.com/nightswatchhq/gib-skill) acts as a concierge for the whole flow. It is not a generator (gib's own scripts do the mechanics); it adds the judgment around them. The skill interviews an Operator (target box, vhost domains, topology source, key count, fee target, stage, monitoring), hardens the box if it is shared, deploys gib at its pinned release, runs `gib smoke`, and interprets the result, then hands off with exactly what is proven and what still needs escrow and Indexer onboarding.
+
+```
+/deploy-gateway
+```
+
+Key hygiene is non-negotiable in the skill: sender and signer private keys are generated on the box and never leave it. The only key allowed through chat is the read-only topology (Studio) key, which signs nothing and holds no funds.
+
+## Status and Boundary
+
+gib verifies the payment path up to a signed, verified RAV: signing, EIP-712 domain, Gateway and aggregator signer consistency, and aggregation, all provable by the operator alone. What remains is on-chain and cooperation-dependent: the Indexer's whitelist entry, escrow funding, and the Indexer redeeming RAVs against the Operator's escrow on-chain. A fresh Gateway returns `402` to paid queries by design until an operator funds escrow and Indexers whitelist the sender; that `402` is itself the evidence that the receipts are valid. Every operator must still supply a topology source, fund escrow, and get Indexers to whitelist their sender.
diff --git a/website/src/pages/en/gateways/subgraphs/components/graph-tally.mdx b/website/src/pages/en/gateways/subgraphs/components/graph-tally.mdx
new file mode 100644
index 000000000000..1ad7458868f6
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/components/graph-tally.mdx
@@ -0,0 +1,71 @@
+---
+title: Graph Tally for Gateway Operators
+sidebarTitle: Graph Tally
+---
+
+Graph Tally is the trust-minimized micropayment system that Subgraph Gateways use to pay Indexers for the queries they serve. It is what makes per-query payment economically viable: instead of one on-chain transaction per query, Indexers are paid through signed off-chain receipts that settle on-chain only periodically.
+
+Graph Tally was formerly known as TAP (Timeline Aggregation Protocol). The Gateway software documented here is Horizon-ready and generates TAP v2 receipts exclusively where "TAP v2" and "Graph Tally" refer to the same thing. Source and services now live in [`graphprotocol/graph-tally`](https://github.com/graphprotocol/graph-tally). The older [`tap-escrow-manager`](https://github.com/edgeandnode/tap-escrow-manager) repo is archived and superseded by the escrow manager in `graph-tally`. Specs: [GIP-0054](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0054-timeline-aggregation-protocol.md) (original TAP) and [GIP-0066](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0066-graph-horizon.md) (Graph Horizon / TAP v2).
+
+## How Graph Tally Scales Micropayments
+
+The Graph aims to support all queries for blockchain data. The most active Indexers already serve on the order of 500,000+ queries per day. Settling each query with its own on-chain transfer is impractical: even at roughly $0.09 per transfer on a low-cost L2, 500,000 queries per day would cost an Indexer about $45,000 per day in fees alone. Graph Tally moves payment off-chain and settles in batches, so the dominant on-chain cost becomes verifying a single ECDSA signature (around 3,000 gas, roughly $0.015 per redemption on Arbitrum at the figures in the source post).
+
+### Graph Tally's Core Properties
+
+- **High-throughput:** the bottleneck is ECDSA sign and verify, one of the fastest crypto operations.
+- **Stateless and scalable:** senders do not track totals, enabling distributed Gateways.
+- **Trust-minimized:** Receivers configure a risk threshold and can settle on-chain without further Sender interaction.
+- **Cost-efficient:** one signature verification per redemption instead of one transaction per query.
+
+## How Graph Tally Works
+
+Payments in The Graph Subgraph Network flows in one direction only -- from Gateways (the Sender) to Indexers (the Receiver). That one-way property is what removes the need for a dispute window: the Receiver has every incentive to post the latest, highest signed amount, so as long as receipts are validly signed there is nothing to dispute. Senders are also stateless: they sign the amount owed for each individual query rather than a running total, which lets a Gateway run distributed, horizontally-scaled senders.
+
+```
+Gateway (Sender) ──signed receipt per query──▶ Indexer (Receiver)
+ ▲ │
+ │ RAV (signed aggregate) │ batches receipts
+ └─────────── aggregator ◀─────────────────────┘
+ │ redeems RAV
+ escrow manager ──funds──▶ Horizon escrow ◀──┘
+```
+
+The Graphy Tally payment flow goes as follows:
+
+1. **Receipts:** the Gateway sends a signed Receipt to the Indexer alongside each query, stating the amount owed for that single request (EIP-712 / ECDSA signed).
+2. **Accumulation:** the Indexer verifies and stores receipts, tallying the running total owed.
+3. **RAV request:** once the accumulated total reaches a threshold the Indexer is willing to risk, it sends all receipts up to a timestamp back to the Sender and requests aggregation.
+4. **RAV:** the Sender verifies the batch, computes the total, and returns a signed Receipt Aggregate Voucher (RAV), a single message representing the cumulative amount owed. Timestamps prevent double-spending: only receipts newer than the previous RAV's timestamp are added.
+5. **Settlement:** the Indexer can redeem the latest RAV on-chain against the Gateway's escrow to claim payment, and may accumulate multiple RAVs before submitting a single on-chain transaction.
+
+Because the Sender can decline to aggregate, the Receiver sets its threshold according to how much it trusts the Sender: the trust-minimized (not fully trustless) property of the system.
+
+## What Gateway Operators Run
+
+A Gateway Operator acts as the TAP Sender and runs two supporting services alongside the Gateway. Both are part of `graphprotocol/graph-tally`:
+
+| Service | Binary | Role |
+| --- | --- | --- |
+| Aggregator | `graph_tally_aggregator` | Public endpoint where Indexers submit batches of receipts and receive signed RAVs in return |
+| Escrow manager | `graph_tally_escrow_manager` | Maintains the on-chain GRT escrow balance the Gateway pays Indexers from, depositing enough to cover outstanding receipts |
+
+### Escrow Manager in Detail
+
+The escrow manager keeps the [Graph Horizon `PaymentsEscrow`](https://github.com/graphprotocol/contracts/blob/main/packages/horizon/contracts/payments/PaymentsEscrow.sol) funded so Indexers can always redeem. It monitors:
+
+- the [Network Subgraph](https://thegraph.com/explorer/subgraphs/DZz4kDTdmzWLWsV373w2bSmoar3umKKH9y82SUKr5qmp?view=Query&chain=arbitrum-one) for active allocations, escrow accounts, and authorized signers, and
+- Kafka topics for receipts and RAVs, which track outstanding debt to each Receiver.
+
+It then deposits GRT to keep balances ahead of what is owed. Startup is faster when the `gateway_indexer_fees_hourly` topic (produced by [Titorelli](/gateways/subgraphs/components/titorelli/)) is available, since it can read pre-aggregated fee history instead of replaying raw data.
+
+Key config options (single JSON file): `authorize_signers` (auto-authorize signers on startup), `dry_run` (skip contract calls for testing), `update_interval_seconds` (main loop polling), and `port_metrics` (Prometheus port, default 9090). Useful escrow metrics include `escrow_total_debt_grt`, `escrow_total_balance_grt`, `escrow_debt_grt{receiver}`, `escrow_balance_grt{receiver}`, and `escrow_deposit_ok` / `escrow_deposit_err`. See [Managing Escrow](/gateways/subgraphs/supply-side/managing-escrow/).
+
+## Wallets Gateway Operators Must Manage
+
+Graph Tally requires the Gateway Operator to manage at least two wallets:
+
+- **Sender:** needs ETH for transaction gas and GRT to allocate into TAP escrow to pay Indexers.
+- **Authorized signer:** used by the Gateway and aggregator to sign v2 receipts and RAVs. Signers must be authorized on-chain against the sender (the escrow manager can do this automatically when `authorize_signers` is `true`, or an Operator can call `authorizeSigner` manually on the escrow contract).
+
+See [Operating a Gateway](/gateways/subgraphs/components/operating-a-gateway/) for the full wallet, funding, and signer-authorization setup.
diff --git a/website/src/pages/en/gateways/subgraphs/components/indexer-selection.mdx b/website/src/pages/en/gateways/subgraphs/components/indexer-selection.mdx
new file mode 100644
index 000000000000..f0584f33e611
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/components/indexer-selection.mdx
@@ -0,0 +1,75 @@
+---
+title: Indexer Selection Algorithm
+---
+
+When a query arrives for a deployment, many Indexers may be able to serve it. The [Indexer Selection Algorithm (ISA)](https://github.com/edgeandnode/candidate-selection) decides which Indexers actually get the request, balancing quality, freshness, economic security, and cost. The ISA is the core of how a Gateway delivers high QoS on top of an unreliable set of independent Indexers.
+
+## How the Indexer Selection Algorithm Does
+
+The ISA selects up to three Indexers per query such that:
+
+- the response is fast and likely to succeed,
+- the data is close to chain head,
+- the serving Indexers have meaningful economic stake at risk, and
+- cost stays within the Gateway's budget.
+
+At least one Indexer is always selected, provided at least one candidate has a non-zero score.
+
+## How the Indexer Selection Algorithm Works
+
+Each candidate Indexer is scored using a [weighted product model](https://en.wikipedia.org/wiki/Weighted_product_model): this takes individual factor scores, multiplied together, and then normalizes them between `[0, 1]`. Because the factors are multiplied rather than added, a near-zero score on any single factor drags the whole candidate down. An Indexer that is fast and cheap but failing most requests, or far behind chain head, scores poorly overall. This makes the model intolerant of weak spots, which is exactly what a Gateway Operator wants for high QoS.
+
+### Per-Candidate Factors
+
+A candidate's score is the product of four factor scores:
+
+```
+score = success_rate_score × latency_score × seconds_behind_score × slashable_grt_score
+```
+
+| Factor | Intuition | Curve behavior |
+| --- | --- | --- |
+| Success rate | Reliability of recent responses | `success_rate^7`, punishes anything below near-perfect reliability very steeply (floor around 1e-8) |
+| Latency | Expected response time | Logistic curve centered around 400 ms; high latency is penalized but floored (around 0.001) because extreme latency already shows up as timeouts and failures |
+| Seconds behind chain head | Data freshness | Logistic decay; full credit near the head, falling off past around 30 seconds behind |
+| Slashable GRT | Economic security, skin in the game | Rises toward 1 as stake increases; around 0.8 at the 100,000 GRT minimum stake |
+
+### Fee and Budget
+
+Fees are handled separately rather than inside the product. More specifically, fees come from each Indexer's Agora cost model, served by `indexer-service` at `/cost`. The Gateway executes the cost model over the indexer request to get each Indexer's fee, then favors cheaper Indexers, when all else equal. Concretely, selection maximizes marginal score per unit fee (the fee is clamped to a small minimum so free quotes do not divide by zero). Fees are clamped to the Gateway's budget, and the Gateway's payment control system may pay slightly above a cost model to hit a target average fee per query.
+
+## Selecting a Set, Not Just the Best One
+
+Indexer selection is greedy and marginal. The Gateway does not simply take the top three scorers. It builds the set one Indexer at a time, each time adding the candidate that most improves the combined score of the set per unit of fee, and stops once no remaining candidate adds positive marginal value (or the limit of three is reached).
+
+This matters because the value of a set of Indexers is not the sum of their individual scores. The combined score accounts for correlation across the set:
+
+- **Combined Success Rate:** models the probability that at least one selected Indexer returns a usable response, ordering candidates by latency so faster responders count first. Adding a second reliable Indexer raises the odds the client gets an answer.
+- **Combined Latency:** a probability-weighted blend across the set. A fast-but-flaky Indexer paired with a slower-but-reliable one yields good expected latency.
+- **Combined Seconds Behind:** uses the worst (maximum) lag in the set. The set is only as fresh as its stalest member.
+- **Combined Slashable GRT:** uses the minimum stake in the set. The set is only as economically secure as its least-staked member.
+
+The result is diversification: the Gateway favors a small set whose members complement each other rather than three near-identical candidates.
+
+## Runtime Feedback Loop
+
+Selection is not static. Every Indexer response, success or failure and its observed latency, feeds back into the performance data (`ExpectedPerformance`: success rate and latency) used for future scoring. Indexers that degrade are scored down automatically and quickly stop being selected while Indexers that recover earn their way back in. Combined with the failover behavior (if all selected Indexers fail, the Gateway re-selects until candidates are exhausted), this is what lets the Gateway maintain high QoS over a constantly shifting Indexer set.
+
+## Innovating on Selection Models
+
+The ISA described here is a strong default, not a fixed ceiling. Because selection is where a Gateway turns an unreliable Indexer set into a quality-of-service guarantee, it is also the most valuable place for a Gateway Operator to differentiate. Operators are encouraged to innovate on new selection models to provide a Gateway Operator with a competitive advantage over other competitors. While the existing Indexer Selection component will remain open-source, Gateway Operators may likely not open-source their own algorithms to sustain that advantage over competitors.
+
+Several directions are open for exploration:
+
+- **Tune the Weights:** the curves and weights live in `candidate-selection` and can be reasoned about (each scoring function links to a Desmos graph in source). A Gateway Operator can raise the importance of latency, freshness, or economic security to match the profile their customers care about. Reference deployments expose per-dimension importance exponents so the common cases can be tuned without code changes (see [Routing Queries to Indexers](/gateways/subgraphs/supply-side/routing-queries/)).
+- **Add New Factors:** nothing prevents extending the product model with additional normalized factors (e.g. geographic proximity, historical dispute record, per-customer preferences) as long as each is expressed on a `[0, 1]` scale.
+- **Explore New Models:** the weighted product model is one approach. Operators serving specialized workloads (e.g. low-latency trading data, archival analytics, agent traffic) may find that different scoring or set-construction strategies serve their users better, and the reference implementation is a starting point rather than a mandate.
+
+Selection models that improve QoS or cost efficiency benefit the whole ecosystem, and sharing improvements back is encouraged.
+
+## Why Gateway Operators Should Care
+
+- **QoS Without Manual Tuning:** the model continuously routes around slow, stale, or failing Indexers.
+- **Cost Control:** budget-relative fee scoring keeps per-query spend predictable.
+- **Security-Aware Routing:** slashable-GRT weighting biases toward Indexers with real economic accountability, complementing POI and Fisherman verification.
+- **Configurable:** the curves and weights can be reasoned about and tuned if an Operator needs to understand or change selection behavior.
diff --git a/website/src/pages/en/gateways/subgraphs/components/operating-a-gateway.mdx b/website/src/pages/en/gateways/subgraphs/components/operating-a-gateway.mdx
new file mode 100644
index 000000000000..dae290144c73
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/components/operating-a-gateway.mdx
@@ -0,0 +1,80 @@
+---
+title: Operating a Gateway
+---
+
+A practical reference for what Gateway Operators actually run, fund, and monitor to stand up a Subgraph Gateway. This page frames the work as two sides: the consumer side (everything facing the developers who query a Gateway) and the supply side (everything facing the Indexers who serve those queries). The conceptual components are covered in [Technical Overview](/gateways/subgraphs/components/overview/), [Indexer Selection](/gateways/subgraphs/components/indexer-selection/), [Graph Tally](/gateways/subgraphs/components/graph-tally/), and [Titorelli](/gateways/subgraphs/components/titorelli/). For a ready-to-run reference deployment, see [Gateway in a Box](/gateways/subgraphs/components/gateway-in-a-box/).
+
+## The Two Sides of a Gateway
+
+A Gateway sits between two populations and owes each of them something different:
+
+- [**Consumer-Side:**](/gateways/subgraphs/consumer-side/overview/) Customers present credentials, send GraphQL queries, and expect fast, correct answers with predictable pricing. A Gateway Operator's responsibilities are authentication, API keys, routing, pricing and billing, data curation, and support.
+- [**Supply-Side:**](/gateways/subgraphs/supply-side/overview/) Indexers serve a Gateway's queries and expect to be paid reliably. An Operator's responsibilities here are Indexer selection and routing, escrow funding, sync incentives, and quality-of-service tracking.
+
+## Subgraph Gateway Components
+
+| Service | Required | Purpose |
+| --- | --- | --- |
+| [Graph Gateway](https://github.com/graphprotocol/gateway) | Yes | Routes queries, discovers and selects Indexers, signs Graph Tally receipts |
+| [Indexer Selection](https://github.com/edgeandnode/candidate-selection) | Yes | Rewrites client request to Indexer request, choose Indexer response |
+| [Graph Tally Aggregator](https://github.com/graphprotocol/graph-tally/blob/main/crates/bin/aggregator/README.md) | Yes | Aggregates Indexer receipts into signed RAVs |
+| [Graph Tally Escrow Manager](https://github.com/graphprotocol/graph-tally/blob/main/crates/bin/escrow_manager/README.md) | Yes | Keeps the on-chain GRT escrow funded to pay Indexers |
+| Kafka / Redpanda | Yes | Transports exported query and receipt data; escrow manager reads from it |
+| [Titorelli](https://github.com/edgeandnode/titorelli) | Optional | Hourly aggregations for billing, QoS, and faster escrow startup |
+
+Gateway Operators also depend on two external data sources: the [Network Subgraph](https://thegraph.com/explorer/subgraphs/DZz4kDTdmzWLWsV373w2bSmoar3umKKH9y82SUKr5qmp?view=Query&chain=arbitrum-one) (on-chain allocation and escrow state) and the Indexers' `indexer-service` endpoints (status, cost models, query serving).
+
+## Supply-Side Wallets and Escrow Setup
+
+Gateway Operators act as a Graph Tally (TAP) Sender, which means managing at least two wallets:
+
+| Wallet | Funds it needs | Used for |
+| --- | --- | --- |
+| Sender | ETH (gas) and GRT (escrow) | Allocating GRT into TAP escrow to pay Indexers; on-chain escrow transactions |
+| Authorized Signer | None (signing only) | Signing Graph Tally v2 receipts (gateway) and RAVs (aggregator) |
+
+The authorized signer must be authorized on-chain against the sender before it can sign valid receipts.
+
+- **Automatic:** set `authorize_signers: true` in the escrow-manager config and provide the signer secret keys in the `signers` field; signers are authorized on startup.
+- **Manual:** find the escrow contract for the Operator's network, connect the sender address, and call `authorizeSigner` (with a generated `proof` and `proofDeadline`) on the contract's Write tab. Repeat per signer. The exact proof-generation script is in the escrow-manager README.
+
+Gateway Operators should treat sender and signer keys as production secrets. The sender controls real GRT and ETH; signer keys can authorize payments.
+
+The escrow manager keeps the [Graph Horizon `PaymentsEscrow`](https://github.com/graphprotocol/contracts/blob/main/packages/horizon/contracts/payments/PaymentsEscrow.sol) balance ahead of outstanding receipts so Indexers can always redeem RAVs. Keep enough GRT in the sender wallet for it to top up balances; a depleted escrow stalls payments and Indexers will stop serving the Operator. Full detail is in [Managing Escrow](/gateways/subgraphs/supply-side/managing-escrow/).
+
+## Consumer-Side Authentication Setup
+
+Gateways authenticate inbound requests two ways. Operators can support either or both:
+
+| Method | Best for | Endpoints | Auth |
+| --- | --- | --- | --- |
+| API key | Humans, applications | `POST /api/subgraphs/id/{subgraph_id}`, `POST /api/deployments/id/{deployment_id}` | `Authorization: Bearer ` |
+| x402 | Humans, AI agents | `POST /api/x402/subgraphs/id/{subgraph_id}`, `POST /api/x402/deployments/id/{deployment_id}` | Pay-per-query in USDC; no key required |
+
+API keys can be issued from from within a Gateway Operator's user interface or from within Subgraph Studio. API keys can carry restrictions (allowed domains, Subgraphs, rate limits) enforced before a request runs. x402 settles per query in USDC on Base (Base Sepolia on testnet). Full detail is in [Serving Queries](/gateways/subgraphs/consumer-side/serving-queries/) and [Pricing & Payments](/gateways/subgraphs/consumer-side/pricing-payments/).
+
+## Gateway Configuration
+
+- **Gateway:** a single JSON config file passed as the first argument to `graph-gateway` (structure defined in `src/config.rs`). Set `kafka_topic_environment` when sharing a Kafka cluster across environments (for example, `"staging"` produces `gateway_queries_staging`).
+- **Escrow Manager, Aggregator, and Titorelli:** each takes its own JSON config (Kafka connection, contract and network settings, intervals, metrics port).
+- **Logging:** `RUST_LOG` controls levels per module, for example `RUST_LOG="info,graph_gateway=debug"`. Client requests log under the `client_request` span; Indexer requests carry the `indexer_request` label.
+
+## Gateway Monitoring
+
+Run Prometheus against each service:
+
+- **Gateway:** metrics at `:${METRICS_PORT}/metrics` (definitions in `metrics.rs`). Watch query success rate, latency, and per-Indexer selection and feedback.
+- **Escrow Manager:** metrics on `port_metrics` (default 9090). Key gauges and counters: `escrow_total_debt_grt`, `escrow_total_balance_grt`, `escrow_debt_grt{receiver}`, `escrow_balance_grt{receiver}`, `escrow_deposit_ok`, `escrow_deposit_err`, `escrow_loop_duration_seconds`.
+
+Alert especially on escrow balance falling toward outstanding debt and on deposit errors; both directly threaten an Operator's ability to pay Indexers and therefore to serve queries. More in-depth QoS tracking is covered in [Tracking QoS](/gateways/subgraphs/supply-side/tracking-qos/).
+
+## Gateway Bootstrapping Checklist
+
+1. Provision sender and signer wallets; fund the sender with ETH and GRT.
+2. Stand up Kafka / Redpanda and create the Gateway topics.
+3. Deploy the Gateway with its JSON config; confirm it discovers Indexers via the Network Subgraph.
+4. Deploy the aggregator (a public endpoint Indexers can reach).
+5. Deploy the escrow manager; authorize signers (auto or manual); confirm escrow deposits in `dry_run` first, then live.
+6. Optionally deploy Titorelli for billing and QoS aggregation and faster escrow startup.
+7. Issue API keys and/or enable x402; run test queries against a high-volume deployment (e.g. Uniswap).
+8. Wire Prometheus and set alerts on escrow balance and deposit errors.
diff --git a/website/src/pages/en/gateways/subgraphs/components/overview.mdx b/website/src/pages/en/gateways/subgraphs/components/overview.mdx
new file mode 100644
index 000000000000..c3f239ec1f23
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/components/overview.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgraph Gateway Technical Overview
+sidebarTitle: Technical Overview
+---
+
+A technical overview of the Subgraph Gateway system: its components, the path a query takes, and the supporting services a Gateway Operator runs.
+
+
+
+## Subgraph Gateway at a Glance
+
+A Gateway has three primary responsibilities:
+
+1. **Manage Consumer Access and Billing:** authenticate consumers, issue and scope API keys, and collect payment for the queries they make.
+2. **Serve Client Requests:** accept GraphQL queries from consumers and return correct, low-latency responses.
+3. **Facilitate Indexer Payments:** pay the Indexers that serve those queries through Graph Tally.
+
+Everything else (data export, analytics, blocklists) is secondary: it is designed so that its failure has minimal impact on the three primary responsibilities. A Gateway is expected to be a reliable system that compensates for Indexers being individually unreliable.
+
+The system is built from a core Gateway process plus a set of supporting services and data sources:
+
+| Component | Function | Operator Run |
+| --- | --- | --- |
+| [Graph Gateway](https://github.com/graphprotocol/gateway) | Routes queries, discovers and selects Indexers, signs Graph Tally receipts | Yes |
+| [Indexer Selection](https://github.com/edgeandnode/candidate-selection) | Rewrites client request to Indexer request, choose Indexer response | Yes |
+| [Graph Tally Aggregator](https://github.com/graphprotocol/graph-tally/blob/main/crates/bin/aggregator/README.md) | Aggregates receipts into RAVs | Yes |
+| [Graph Tally Escrow Manager](https://github.com/graphprotocol/graph-tally/blob/main/crates/bin/escrow_manager/README.md) | Maintains on-chain GRT escrow balances to pay Indexers | Yes |
+| Kafka / Redpanda | Transport for exported query and attestation data | Yes |
+| [Titorelli](https://github.com/edgeandnode/titorelli) | Optional hourly aggregation over the Gateway's Kafka output | Optional |
+| [Network Subgraph](https://thegraph.com/explorer/subgraphs/DZz4kDTdmzWLWsV373w2bSmoar3umKKH9y82SUKr5qmp?view=Query&chain=arbitrum-one) | Indexes The Graph Network contracts, the source of truth for Subgraphs, deployments, and Indexer allocations | Optional |
+| [Indexer Service](https://github.com/graphprotocol/indexer-rs) | Serve queries, publish cost models and indexing status, collect receipts | Optional |
+
+## The Request Lifecycle
+
+### 1. Authentication
+
+Every client request must include credentials so the Gateway can associate it with a consumer and track usage for billing:
+
+- **API key:** issued from Subgraph Studio, passed as `Authorization: Bearer `. Best for humans and applications. Keys may carry additional restrictions (allowed domains, Subgraphs, rate limits) that are checked before the request runs.
+- **x402:** pay-per-query in USDC on Base, no account required. Best for autonomous agents. The x402 protocol negotiates and settles payment automatically.
+
+### 2. Resolving the Request Path
+
+Requests take one of three shapes:
+
+- **Subgraph ID (from GNS contract):** must first be resolved to a deployment. The Gateway selects the latest deployment for which some Indexer reports an indexing status within 30 minutes of chain head; if none qualifies, it falls back to the latest deployment.
+- **Deployment ID (IPFS hash from manifest):** used directly.
+- **Deployment ID and Indexer address:** intended only for cross-checking a specific Indexer's responses. Not guaranteed to behave as expected for production data, and the rest of this flow assumes no Indexer address is pinned.
+
+### 3. Indexer Discovery
+
+To route a query, the Gateway must know which Indexers have active allocations on the target deployment. A Gateway learns this by periodically querying the Network Subgraph, which indexes The Graph Network contracts, through a subset of the Network's Indexers.
+
+Each Indexer registers a URL for its `indexer-service`. After collecting the on-chain allocation tree, the Gateway calls each active Indexer's `indexer-service` to fetch (a) software version, (b) per-allocation indexing status (based on how far the Indexer has progressed relative to chain head), and (c) an Indexer's Agora cost models.
+
+Optionally, the Gateway can block public Proofs of Indexing (POIs) associated with bad responses. When that is enabled, Indexers on affected deployments must submit their public POI during discovery. An Indexer whose POI is blocked is excluded until it returns a good POI.
+
+### 4. Indexer Selection
+
+The Gateway rewrites the client request into an indexer request (the client query plus any extra data the Gateway needs to track each Indexer's progress) and selects up to three Indexers to execute it. Selection uses a weighted product model over (a) success rate, (b) expected latency,(c) seconds behind chain head, (d) slashable GRT, and (e) fee from the Indexer's cost model, relative to the Gateway's budget.
+
+The full algorithm is documented in [Indexer Selection](/gateways/subgraphs/components/indexer-selection/) and is designed to be a component that can be iterated on to provide a Gateway Operator with a competitive advantage over other Gateways. While the existing Indexer Selection component is open-source, Gateway Operators may likely not open-source their own algorithms to sustain that advantage over competitors.
+
+### 5. Execution, Response, and Feedback
+
+The selected Indexers execute the indexer request in parallel. The first response that passes the Gateway's filters is returned to the client with any data the client did not request stripped out. Every Indexer response, including failures, feeds performance data back into the selection algorithm. If all selected Indexers fail, the Gateway repeats selection until the available Indexers are exhausted.
+
+### 6. Gateway-Indexer Payments
+
+Each indexer request is sent with a [Graph Tally v2](/gateways/subgraphs/components/graph-tally/) receipt signed by the Gateway (acting as a TAP sender). Indexers collect these receipts, periodically aggregate them into RAVs via the Gateway Operator's aggregator, and redeem RAVs on-chain against the Operator's escrow balance. The Gateway runs a control system that may pay Indexers slightly more than their cost model requests in order to hit a target average fee per query, clamped to the Gateway's budget.
+
+## Data Export (Secondary Path)
+
+The Gateway exports operational data to Kafka topics (`gateway_queries` and `gateway_attestations`) and consumes from `gateway_blocklist`. When multiple environments share a Kafka cluster, set `kafka_topic_environment` (for example, `"staging"` produces `gateway_queries_staging`).
+
+Optionally, [Titorelli](/gateways/subgraphs/components/titorelli/) aggregates these topics into hourly summaries used for analytics and to speed up escrow-manager startup. This entire path is designed to fail without affecting query serving or payments.
+
+
+
+## Operational Surface
+
+- **Configuration:** a single JSON config file passed as the first argument to the `graph-gateway` executable (structure defined in `src/config.rs`).
+- **Logging:** controlled by `RUST_LOG` (for example, `RUST_LOG="info,graph_gateway=debug"`). Each client request emits events under the `client_request` span; Indexer requests carry the `indexer_request` label.
+- **Metrics:** exposed for Prometheus at `:${METRICS_PORT}/metrics`.
+
+For wallets, escrow funding, and the full list of services to run, see [Operating a Gateway](/gateways/subgraphs/components/operating-a-gateway/). For a ready-to-run reference deployment, see [Gateway in a Box](/gateways/subgraphs/components/gateway-in-a-box/).
diff --git a/website/src/pages/en/gateways/subgraphs/components/titorelli.mdx b/website/src/pages/en/gateways/subgraphs/components/titorelli.mdx
new file mode 100644
index 000000000000..259090bbe17d
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/components/titorelli.mdx
@@ -0,0 +1,51 @@
+---
+title: Titorelli
+---
+
+Titorelli is an optional data-science service that reinterprets the Kafka messages a Gateway emits, producing hourly aggregations used for analytics and billing, and to speed up the [escrow manager's](/gateways/subgraphs/components/graph-tally/) startup. It sits entirely on the Gateway's secondary data path: if Titorelli is down, query serving and payments are unaffected.
+
+Source: [`edgeandnode/titorelli`](https://github.com/edgeandnode/titorelli).
+
+
+
+## What Titorelli Does
+
+The Gateway exports raw operational data into Kafka topics (primarily through `gateway_queries` and `gateway_attestations`). Titorelli consumes the Gateway's query stream and rolls it up into hourly aggregations, emitting three derived topics:
+
+| Topic | Aggregated per hour | Used for |
+| --- | --- | --- |
+| `gateway_client_fees_hourly` | Per consumer / API key / deployment: GRT and USD fees, query count, success rate, average response time | Client billing, usage analytics |
+| `gateway_indexer_fees_hourly` | Per signer to receiver: GRT fees owed to each Indexer | Faster escrow-manager startup |
+| `gateway_indexer_qos_hourly` | Per Indexer / deployment / chain: success and failure counts, average seconds behind, average latency, average fee | Indexer QoS monitoring, network analytics |
+
+### Why Operators Run Titorelli
+
+- **Faster Escrow Manager Startup:** the escrow manager can read pre-aggregated `gateway_indexer_fees_hourly` instead of replaying raw receipt history to compute outstanding debt. This is currently the primary documented reason to run Titorelli.
+- **Client Billing:** `gateway_client_fees_hourly` gives a ready-made, per-API-key fee and usage feed for invoicing.
+- **QoS and Analytics:** `gateway_indexer_qos_hourly` provides hourly Indexer performance data for dashboards and network health monitoring (outlined in [Tracking QoS](/gateways/subgraphs/supply-side/tracking-qos/)).
+
+Each message is a protobuf with a `timestamp` (aggregation window start, unix ms) and a repeated list of aggregation rows. Full schemas are in the Titorelli README.
+
+## Titorelli Configuration
+
+Titorelli is configured with a single JSON file pointing at the Kafka cluster:
+
+```json
+{
+ "kafka": {
+ "bootstrap.servers": "example.com:9092",
+ "group.id": "titorelli",
+ "security.protocol": "sasl_ssl",
+ "sasl.mechanism": "SCRAM-SHA-256",
+ "sasl.username": "example_username",
+ "sasl.password": "example_password",
+ "ssl.ca.location": "./example.crt"
+ }
+}
+```
+
+When multiple Gateway environments share one Kafka cluster, the Gateway's `kafka_topic_environment` setting appends an environment qualifier to topic names (for example, `gateway_queries_staging`). Make sure Titorelli consumes and produces the matching environment-qualified topics.
+
+## When Operators Can Skip Running Titorelli
+
+Titorelli is optional. A minimal Gateway can serve queries and pay Indexers without it: the escrow manager will simply do more work at startup, and an Operator will need another path for client billing and QoS analytics. Run Titorelli when an Operator wants efficient escrow startup, per-client fee reporting, or Indexer QoS aggregation out of the box.
diff --git a/website/src/pages/en/gateways/subgraphs/consumer-side/_meta.js b/website/src/pages/en/gateways/subgraphs/consumer-side/_meta.js
new file mode 100644
index 000000000000..0bd630e8a3b4
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/consumer-side/_meta.js
@@ -0,0 +1,9 @@
+export default {
+ overview: '',
+ 'pricing-payments': '',
+ 'serving-queries': '',
+ 'subgraph-collections': '',
+ 'publication-flows': 'Publication Flows',
+ 'customer-support': '',
+ 'indexing-approaches': 'Indexing Approaches',
+}
diff --git a/website/src/pages/en/gateways/subgraphs/consumer-side/customer-support.mdx b/website/src/pages/en/gateways/subgraphs/consumer-side/customer-support.mdx
new file mode 100644
index 000000000000..d6f8323188b8
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/consumer-side/customer-support.mdx
@@ -0,0 +1,26 @@
+---
+title: Customer Support
+---
+
+Running a Gateway means supporting the developers and consumers who depend on it. Some of that support is provided directly by the Gateway Operator; some can be backed by The Graph's community and The Graph Foundation. This page covers the channels available and how they fit together.
+
+## The Graph Discord
+
+[The Graph Discord](https://discord.gg/graphprotocol) is the primary community support channel. Developers and consumers can ask questions there and reach contributors from across the ecosystem, including core contributors and other Gateway Operators. For most general questions about Subgraphs, querying, and The Graph Network, pointing consumers to Discord, especially the `#indexers` channel, is a reliable first step, and it is where a lot of shared knowledge already lives.
+
+### Dedicated Discord Channels
+
+For a Gateway Operator running meaningful volume, The Graph Foundation can provide a dedicated support channel by contacting The Graph Discord moderators. This gives the Gateway Operator a direct line for operator-specific issues (onboarding Indexers, escrow, protocol questions) rather than relying only on general community channels, and it lets the Foundation route the right contributors to them. If an Operator is standing up a production Gateway, it is worth engaging the Foundation early so this channel is in place before their consumers need it.
+
+## Telegram and Slack Channels
+
+Depending on the relationship and the audience, support may also run through Telegram or Slack:
+
+- **Telegram:** common for fast, informal coordination with Indexers and ecosystem contributors.
+- **Slack:** common for enterprise customers and formal operator relationships, where a shared Slack channel fits how the customer already works.
+
+For enterprise consumers in particular, a private Slack or Telegram channel paired with an SLA is a typical support arrangement. See [Gateway Indexing Approaches](/gateways/subgraphs/consumer-side/indexing-approaches/) for the SLA-backed environments these customers often expect.
+
+## Structuring Support as an Operator
+
+A practical structure is tiered: community channels (Discord) for general questions, an Operator's own direct support for a Gateway's consumers, a Foundation-provided channel for operator and protocol issues, and dedicated Telegram or Slack channels for enterprise accounts. Which mix an Operator uses depends on their customer base, but the goal is the same: a consumer should always know where to go when a query does not behave as expected.
diff --git a/website/src/pages/en/gateways/subgraphs/consumer-side/indexing-approaches.mdx b/website/src/pages/en/gateways/subgraphs/consumer-side/indexing-approaches.mdx
new file mode 100644
index 000000000000..b2b4518120fe
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/consumer-side/indexing-approaches.mdx
@@ -0,0 +1,37 @@
+---
+title: Gateway Indexing Approaches
+---
+
+A Gateway routes queries to Indexers on The Graph Network, but many Gateway Operators also run some indexing infrastructure of their own. This page covers when that is appropriate, The Graph Foundation's general position on it, and the two most common reasons to run their own indexing alongside the network: staging environments and enterprise or SLA environments.
+
+## Gateway Operators as Centralized Indexers
+
+The Graph Foundation's position is that it is acceptable, but not recommended, for Gateway Operators to run centralized indexers alongside the network, specifically to provide staging environments or enterprise-grade support with an SLA that meets user demands. Running an Operator's own indexing is a legitimate way to meet requirements the decentralized network does not yet serve directly, such as pre-production testing or a contractual latency guarantee. Keep in mind that running this centralized indexer can come at a high cost, diminishing the value of the network's value prop offloading infrastructure costs to Indexers who specialize on that core compotency.
+
+## Becoming an Indexer on The Graph Network
+
+Instead, The Foundation's recommendation is that Gateway Operators are best off participating as an Indexer on The Graph Network rather than treating private indexing as a permanent substitute for it. In other words, Gateway Operators should use their own indexing to fill genuine gaps (i.e., staging or SLA-backed enterprise service), but do so as a network participant, contributing their indexing capacity back to the network where they can, rather than building a parallel, fully centralized service. This keeps the operator aligned with the decentralized network while still letting them meet demands the network alone cannot yet cover.
+
+If a Gateway Operator is going to run indexing infrastructure anyway, the recommended path is to run it as an Indexer on The Graph Network. An Indexer stakes GRT, indexes Subgraphs, serves queries, and earns query fees and indexing rewards, and an Operator's Gateway can route to their own Indexer the same way it routes to any other, on quality and cost.
+
+Standing up an Indexer is its own body of work (the Indexer tech stack, allocations, cost models, and operations). This process is outlined in The Graph's indexing documentation: [Indexing Overview](https://thegraph.com/docs/en/indexing/overview/). Run through that to become a network Indexer rather than operating an isolated, off-network indexing service.
+
+## Staging Environments
+
+The most common reason for an Operator to run their own indexing alongside the network is to provide a staging environment for their consumers. In the past, this role was filled by Edge & Node's Upgrade Indexer and hosted service.
+
+Staging environments typically provide:
+
+- **Pre-indexing of the latest versions:** index a new Subgraph version ahead of time so a consumer can test it before any production traffic is moved onto it. This de-risks upgrades, because the new version is validated on real infrastructure first.
+- **Safe path to move traffic:** once a new version is validated in staging, production traffic can be cut over deliberately rather than all at once.
+- **Debugging and log access:** a staging environment a Gateway Operator controls gives the Operator and their consumers access to logs and diagnostics that are not available from independent network Indexers, which is invaluable when a new Subgraph version misbehaves.
+
+The [Upgrade Indexer](https://thegraph.com/docs/en/subgraphs/providers/subgraph-studio/upgrade-indexer/) is the network-aligned version of this idea: an Indexer designed to act as a fallback for Subgraph queries not yet served by other Indexers, so consumers can query a Subgraph even before the broader network has picked it up. It is not competitive with other Indexers; it exists to smooth the path onto the network. Offering a staging path is optional and depends on how much indexing an Operator is willing to run, but it is one of the clearest consumer-facing benefits of an Operator running some of their own indexing.
+
+## Enterprise & SLA Environments
+
+The second common reason for a Gateway Operator to run their own indexing is to back enterprise commitments. Large customers frequently require guarantees the open network does not contractually provide: a latency ceiling, an uptime target, guaranteed capacity for specific Subgraphs, or priority support.
+
+To meet these, a Gateway Operator can run dedicated indexing for the Subgraphs an enterprise customer depends on, so those queries have known, controllable performance rather than depending solely on independent Indexers' availability. This is typically paired with a flat enterprise fee and a dedicated support channel (see [Pricing & Payments](/gateways/subgraphs/consumer-side/pricing-payments/) and [Customer Support](/gateways/subgraphs/consumer-side/customer-support/)).
+
+To reiterate, The Graph Foundation's position is that running dedicated indexing to honor an SLA is appropriate, and the preferred way to do it is as a participant on The Graph Network, contributing that indexing capacity to the network rather than walling it off. Done in this way, a Gateway Operator can meet demanding enterprise requirements while still strengthening, rather than bypassing, the decentralized network.
diff --git a/website/src/pages/en/gateways/subgraphs/consumer-side/overview.mdx b/website/src/pages/en/gateways/subgraphs/consumer-side/overview.mdx
new file mode 100644
index 000000000000..b39dddc6c0b1
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/consumer-side/overview.mdx
@@ -0,0 +1,45 @@
+---
+title: Consumer-Side
+sidebarTitle: Overview
+---
+
+The consumer side of running a Subgraph Gateway includes everything facing the developers and applications that query it. To those users, an Operator's Gateway is the product: a single endpoint, an API key or an x402 payment system, and fast GraphQL responses drawn from The Graph Network. This section covers how an Operator presents network access to consumers, how an Operator prices it, how they query and authenticate, how an Operator curates data for them, how they publish Subgraphs, and how an Operator supports them.
+
+## Where Gateways Interface with the Subgraph Network
+
+The Graph Network is a decentralized set of Indexers who sync and serve data from Subgraphs. A data consumer could query those Indexers directly, but doing so means discovering which Indexers serve a given Subgraph, judging their quality, handling failover, and settling per-query payment on-chain. Almost no consumer wants this.
+
+Gateways abstract much of that complexity. They sit between most consumers and the network of Indexers: consumers send a query to one endpoint, and then Gateways discover the Indexers that can serve it, route requests to the best candidates, absorb individual Indexer failures, and settle payments on the consumer's behalf. From the consumer's perspective, the decentralized network looks like a single reliable API.
+
+For a service provider, this is where the commercial relationship lives. An Operator owns the endpoint, the authentication, the pricing, and the support experience, while The Graph Network provides the indexed data underneath. See the [Overview](/gateways/subgraphs/overview/) for how this enables vertical integration.
+
+## Functions of a Gateway for Consumers
+
+A Gateway performs three core functions on behalf of the consumers who use it, with a fourth that is optional.
+
+### Authentication and API Keys
+
+A Gateway identifies who is making each request and enforces what they are allowed to do. It supports two methods: API keys (`Authorization: Bearer `) for humans and applications, and x402 pay-per-query in USDC for autonomous agents with no account.
+
+API keys are the primary way human developers consume a Gateway. A Gateway Operator issues keys, attaches restrictions and rate limits, tracks usage per key for billing, and revokes or caps keys as needed. Keys can be scoped to specific Subgraphs, domains, and rate limits, and they are also the unit that curation and collections attach to. Learn more in the [Serving Queries](/gateways/subgraphs/consumer-side/serving-queries/) section.
+
+### Routing
+
+The Gateway turns one consumer query into a routed request across the network. It resolves Subgraph IDs or Deployment IDs, discovers the Indexers with active allocations, selects up to three by quality and cost, and returns the first response that passes its filters. The consumer never chooses an Indexer. The Gateway does it for them, continuously routing around slow or failing ones. The selection logic is covered in [Indexer Selection](/gateways/subgraphs/components/indexer-selection/).
+
+### Payments
+
+A Gateway pays Indexers for the queries it serves, so the consumer does not have to transact on-chain per query. Behind a simple usage-based bill or a pay-per-query charge, the Gateway signs Graph Tally receipts and settles them in batches. This is what lets an Operator offer consumers familiar pricing (a monthly bill, a card on file, or per-query USDC) on top of a micropayment network. See [Pricing & Payments](/gateways/subgraphs/consumer-side/pricing-payments/).
+
+### Optional: Staging Environments
+
+Some operators offer consumers a staging path: an environment for testing new Subgraph versions before moving production traffic to them, often backed by a dedicated indexing environment for pre-indexing and debugging. This is optional and depends on a [Gateway's Indexing Approach](/gateways/subgraphs/consumer-side/indexing-approaches/).
+
+## What Is In This Section
+
+- [Pricing & Payments](/gateways/subgraphs/consumer-side/pricing-payments/): separating query costs from indexing, and the pricing models an Operator can offer.
+- [Serving Queries](/gateways/subgraphs/consumer-side/serving-queries/): how consumers query a Subgraph and authenticate.
+- [Subgraph Collections](/gateways/subgraphs/consumer-side/subgraph-collections/): curating a chosen set of Subgraphs for end users.
+- [Enabling Publication Flow](/gateways/subgraphs/consumer-side/publication-flows/): letting consumers publish Subgraphs to the network.
+- [Customer Support](/gateways/subgraphs/consumer-side/customer-support/): how to support the developers who use a Gateway.
+- [Gateway Indexing Approaches](/gateways/subgraphs/consumer-side/indexing-approaches/): centralized indexing, staging, and enterprise SLA environments.
diff --git a/website/src/pages/en/gateways/subgraphs/consumer-side/pricing-payments.mdx b/website/src/pages/en/gateways/subgraphs/consumer-side/pricing-payments.mdx
new file mode 100644
index 000000000000..5f6f907f8c0c
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/consumer-side/pricing-payments.mdx
@@ -0,0 +1,43 @@
+---
+title: Pricing & Payments
+---
+
+One of the main reasons to run a Gateway is to control how consumers pay. The Gateway settles with Indexers in the background through Graph Tally, which frees an Operator to present whatever pricing model fits their customers: pay-as-you-go, a subscription, a flat enterprise fee, or a blend of different plans. This page covers how Gateway costs are structured and the models an Operator can offer on top.
+
+## Separating Query Costs From Indexing
+
+A key concept for pricing is that querying and indexing are separate economic activities on The Graph Network, and a Gateway is concerned almost entirely with the first.
+
+- **Query Costs:** what Gateway Operators pay Indexers to serve live queries. These are the per-query fees a Gateway settles through [Graph Tally](/gateways/subgraphs/components/graph-tally/), sized by each Indexer's Agora cost model and an Operator's budget. Query cost scales with usage: more queries, more fees. This is the cost a Gateway Operator passes through (with margin) to data consumers.
+- **Indexing Costs:** what it takes to get a Subgraph indexed and kept fresh in the first place. On The Graph Network, indexing is incentivized through curation signal and indexing rewards (new GRT issuance) on rewards-enabled chains, and through Indexing Payments (e.g., recurring on-chain payments via CHIPs and DIPs with no curation signal) where rewards do not reach or baseline coverage falls short, rather than paid per query. If a Subgraph an Operator's customers need is under-indexed, the lever is [incentivizing Indexers](/gateways/subgraphs/supply-side/incentivizing-syncs/) to sync it, not paying more per query.
+
+At the protocol level, The Graph keeps these pricing mechanisms separate. When these Gateway costs are consumer-facing, there is flexibility in how a Gateway Operator can handle pricing. Query costs and indexing costs can be managed as add-ons, bundles, or have entirely different pricing models. Indexing is a supply-side concern Gateways manage separately, and it is why a Subgraph that no Indexer has synced cannot simply be bought into existence at query time.
+
+## Pay-As-You-Go Models
+
+The most natural model for a Gateway is usage-based: consumers pay in proportion to the queries they make. This maps directly onto how the Gateway itself incurs cost, so margins are predictable.
+
+There are two common implementations:
+
+- **Metered API Keys:** a consumer holds an API key, a Gateway meters queries per key (Titorelli's `gateway_client_fees_hourly` aggregation is built for exactly this), and an Operator bills periodically. For example, Edge & Node's Subgraph Studio pricing is a reference point for this model: a free tier of 100,000 queries per month, then usage-based pricing beyond it (for example, $2 per additional 100,000 queries). An Operator can mirror that shape or set their own rates and free allowance.
+- **x402 Pay-Per-Query:** for autonomous agents and accountless consumers, x402 settles each query in USDC on Base at request time. There is no bill and no account; the consumer pays as they go, query by query. This is the pure pay-as-you-go model and is well suited to AI data services and agent traffic.
+
+Pay-as-you-go pricing is transparent and fair, and it aligns an Operator's revenue with their cost. Its tradeoff is variability: a consumer with spiky usage sees a spiky bill.
+
+## Subscription and Flat-Fee Models
+
+For customers who prefer predictable spend, or for enterprise relationships, a Gateway can offer subscription or flat-fee pricing instead of (or alongside) metering.
+
+- **Subscription Tiers:** bundle an included query volume into a monthly price, with overage billed usage-based above the cap. The Substreams pricing tiers are a reference for this shape: a free tier, mid tiers at fixed monthly prices with generous included volume, and per-unit overage rates. Tiers let a consumer pick a predictable plan and only pay usage-based rates once they exceed it.
+- **Enterprise Tier:** a single negotiated price for a defined scope of access, often paired with an SLA, dedicated support, and possibly a dedicated or staging indexing environment. This suits large customers who value predictability and guarantees over paying exactly per query. See [Gateway Indexing Approaches](/gateways/subgraphs/consumer-side/indexing-approaches/) for the SLA-backed environments that typically accompany these deals.
+
+Because a Gateway absorbs the underlying per-query settlement, an Operator is free to decouple what the consumer pays from what any single query costs the Operator. Subscriptions trade some usage-alignment for predictability, which is often exactly what enterprise customers want.
+
+## Payment Methods
+
+A Gateway can accept familiar payment rails from consumers, independent of the GRT settlement happening underneath:
+
+- **Card:** for metered and subscription billing, the same way Subgraph Studio and The Graph Market accept cards.
+- **Crypto:** GRT and, for x402, USDC on Base.
+
+Underneath any of these, a Gateway pays Indexers in GRT through Graph Tally escrow. The consumer's payment method and an Operator's Indexer settlement are deliberately decoupled, which is what makes flexible pricing possible.
diff --git a/website/src/pages/en/gateways/subgraphs/consumer-side/publication-flows.mdx b/website/src/pages/en/gateways/subgraphs/consumer-side/publication-flows.mdx
new file mode 100644
index 000000000000..c96f4a8709ef
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/consumer-side/publication-flows.mdx
@@ -0,0 +1,45 @@
+---
+title: Enabling Publication Flows
+---
+
+Beyond querying, a Gateway Operator often wants to help consumers publish Subgraphs to The Graph Network, so the data they depend on is indexed and served by The Graph network rather than by private infrastructure. Publishing is an on-chain action, which introduces a wallet requirement and some choices about how that wallet is managed. This page covers what a consumer needs to publish and the workflows an operator can support.
+
+## A Wallet is Required for Publishing Subgraphs
+
+Querying a Subgraph needs only an API key or an x402 payment. Publishing a Subgraph is different: it is an on-chain transaction against The Graph Network contracts (i.e. the GNS on Arbitrum One), so it requires a wallet.
+
+Concretely, to publish a Subgraph a consumer needs:
+
+- A wallet that can sign transactions on Arbitrum One and holds enough ETH for gas.
+- Optionally, GRT to signal (curate) on a Subgraph to [incentivize Subgraph syncing](/gateways/subgraphs/supply-side/incentivizing-syncs/). Curation signal attracts Indexers to index the Subgraph, so a small self-signal is a common way to bootstrap indexing on a freshly published Subgraph.
+
+This is a real difference in the consumer experience: a query consumer may never touch a wallet, but a publishing consumer must. Part of enabling publication is making that step as smooth as possible, whether by guiding them through Subgraph Studio's publish flow or by supporting publication within an Operator's own product surface.
+
+## Wallet vs Multi-Sig Publication Flows
+
+Who holds the publishing wallet, and how it signs, matters as soon as more than one person is involved or the Subgraph is operationally important. There are three common workflows, in increasing order of control.
+
+### Single Wallet (EOA)
+
+A single externally-owned account signs the publish transaction directly. This is the simplest path and fine for individual developers and low-stakes Subgraphs. The tradeoff is that one key is a single point of failure and a single point of compromise: whoever holds it can publish, update, or transfer the Subgraph.
+
+### Multi-Sig Wallets
+
+For teams and production Subgraphs, a multi-signature wallet (e.g., a Safe) holds the publishing rights, and a threshold of signers must approve each action. This gives:
+
+- **Shared control:** no single person can unilaterally publish or update a Subgraph.
+- **Continuity:** signers can be added or removed as a team changes without losing the Subgraph.
+- **Auditability:** each publication or update is an explicit, co-signed on-chain action.
+
+Multi-sig workflows are the recommended default for any Subgraph a business depends on, and enabling it is largely a matter of letting the consumer point their publish flow at a multi-sig address rather than an individual key.
+
+### Account Abstraction
+
+Account-abstraction (or smart-account) wallets extend this further, letting the signing logic itself be programmable: session keys, spending policies, sponsored gas, and social recovery. For a Gateway Operator building a smooth publishing experience inside their own product, account abstraction can hide much of the wallet friction from the consumer (for example, sponsoring gas or batching the publish and signal steps) while keeping strong controls.
+
+## What an Operator Can Do
+
+- Guide consumers to a wallet-ready publish flow (Subgraph Studio, or an Operator's own product surface).
+- Recommend multi-sig for any production Subgraph, and support pointing publication at a multi-sig address.
+- Where it fits an Operator's product, use account abstraction to reduce wallet friction (sponsored gas, batched publish-and-signal) without giving up control.
+- Pair publication with a small curation signal so the newly published Subgraph attracts Indexers.
diff --git a/website/src/pages/en/gateways/subgraphs/consumer-side/serving-queries.mdx b/website/src/pages/en/gateways/subgraphs/consumer-side/serving-queries.mdx
new file mode 100644
index 000000000000..833ea9dce4c1
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/consumer-side/serving-queries.mdx
@@ -0,0 +1,43 @@
+---
+title: Serving Queries
+---
+
+This page covers the consumer-facing mechanics of querying through a Gateway: how a consumer sends a query for a Subgraph, and how they authenticate. The internal routing and Indexer selection that happen behind these requests are covered in [Technical Overview](/gateways/subgraphs/components/overview/) and [Indexer Selection](/gateways/subgraphs/components/indexer-selection/).
+
+## How to Query a Subgraph
+
+A consumer queries a Subgraph by sending a GraphQL request to a Gateway endpoint for that Subgraph, with credentials in the header. The Gateway resolves the target, selects Indexers, and returns the response.
+
+Requests take one of two consumer-facing shapes:
+
+- **Subgraph ID:** `POST /api/subgraphs/id/{subgraph_id}`. The Gateway resolves the Subgraph ID to the appropriate deployment automatically (the latest deployment an Indexer reports as sufficiently synced). This is the usual path for a consumer who wants "the current version of this Subgraph."
+- **Deployment ID:** `POST /api/deployments/id/{deployment_id}`. The Deployment ID is the IPFS hash of a specific Subgraph manifest, used directly. This pins the consumer to an exact version.
+
+A minimal query against a running Gateway looks like this:
+
+```sh
+curl "https://your-gateway.example/api/subgraphs/id/" \
+ -H 'content-type: application/json' \
+ -H "Authorization: Bearer " \
+ -d '{"query":"{ _meta { block { number } } }"}'
+```
+
+The Gateway returns the first Indexer response that passes through its filters, with any fields the consumer did not request stripped out. If every selected Indexer fails, the Gateway re-selects until candidates are exhausted, so a data consumer generally sees a good response or a clear error rather than a hung request. On a Gateway whose escrow is unfunded or whose sender is not yet whitelisted by Indexers, paid queries return a `402`.
+
+## Authentication and API Keys
+
+Every request must carry credentials so a Gateway can attribute usage and enforce access. Graph Gateways support two methods:
+
+### API Keys
+
+API keys are the primary method for humans and applications, passed as `Authorization: Bearer `. A Gateway Operator issues keys to their consumers and can attach restrictions that are enforced before a request runs:
+
+- **Subgraph allow-list:** restrict a key to a specific set of Subgraph IDs (empty means all). This is the mechanism behind serving only a curated set; see [Subgraph Collections](/gateways/subgraphs/consumer-side/subgraph-collections/).
+- **Domain allow-list:** restrict a key to specific `Origin` or `Referer` domains.
+- **Rate limits and status:** cap a key's throughput, or disable it without deleting it (for example, a service-shutoff or monthly-cap status).
+
+Keys can be issued from Subgraph Studio, or a Gateway Operator can mint and manage their own keys for their consumers, which is what enables independent branding and billing.
+
+### x402 Payments
+
+x402 is the method for autonomous agents and accountless consumers: pay-per-query in USDC on Base with no API key. The consumer's request is served against an automatic per-query payment negotiated and settled by the x402 protocol. The endpoints mirror the API-key paths under an `x402` prefix (for example, `POST /api/x402/subgraphs/id/{subgraph_id}`).
diff --git a/website/src/pages/en/gateways/subgraphs/consumer-side/subgraph-collections.mdx b/website/src/pages/en/gateways/subgraphs/consumer-side/subgraph-collections.mdx
new file mode 100644
index 000000000000..b4b5f66eff73
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/consumer-side/subgraph-collections.mdx
@@ -0,0 +1,28 @@
+---
+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.
diff --git a/website/src/pages/en/gateways/subgraphs/ecosystem/_meta.js b/website/src/pages/en/gateways/subgraphs/ecosystem/_meta.js
new file mode 100644
index 000000000000..4e8134548ebb
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/ecosystem/_meta.js
@@ -0,0 +1,4 @@
+export default {
+ 'graph-node': '',
+ 'chain-integrations': '',
+}
diff --git a/website/src/pages/en/gateways/subgraphs/ecosystem/chain-integrations.mdx b/website/src/pages/en/gateways/subgraphs/ecosystem/chain-integrations.mdx
new file mode 100644
index 000000000000..ea5cd1722de3
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/ecosystem/chain-integrations.mdx
@@ -0,0 +1,84 @@
+---
+title: Chain Integrations
+---
+
+> **August 2026 Release:** This page is still a work-in-progress and is subject to change.
+
+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](/gateways/subgraphs/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](/gateways/subgraphs/supply-side/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](https://github.com/graphprotocol/networks-registry) and surfaced on [The Graph's Supported Networks page](https://thegraph.com/docs/en/supported-networks/).
+
+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](/gateways/subgraphs/supply-side/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](https://forum.thegraph.com/t/gip-0081-indexing-payments/6271), [GIP-0087](https://forum.thegraph.com/t/on-chain-indexing-agreements-and-issuance-allocation-gip-0087-gip-0088/6869), and [GIP-0088](https://forum.thegraph.com/t/on-chain-indexing-agreements-and-issuance-allocation-gip-0087-gip-0088/6869).
+
+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](/gateways/subgraphs/supply-side/incentivizing-syncs/).
+
+### Model Comparison
+
+| Dimension | Rewards-Enabled | Off-Chain Deals | CHIPs & DIPs |
+| --- | --- | --- | --- |
+| Who decides | The Graph Council (GIP + GGP vote) | Curating ecosystem member | Payer (Foundation, chain, Gateway) + accepting Indexers |
+| Indexer compensation | Indexing rewards from GRT issuance, directed by curation signal | Negotiated off-chain payments | Recurring payments, paid on-chain |
+| Curation signal required | Yes (rewards follow signal) | No | No |
+| Settlement | On-chain (protocol issuance) | Off-chain today | On-chain (escrow + agreement contracts) |
+| Trust model | Protocol-native | Bilateral trust in the curating party | Trust-minimized (escrow, POI-based collection, slashing recourse) |
+| Status | Live (GIP-0057) | Live | Approved, not yet live |
+
+## 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](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468) 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.
diff --git a/website/src/pages/en/gateways/subgraphs/ecosystem/graph-node.mdx b/website/src/pages/en/gateways/subgraphs/ecosystem/graph-node.mdx
new file mode 100644
index 000000000000..321972dd28e6
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/ecosystem/graph-node.mdx
@@ -0,0 +1,21 @@
+---
+title: Graph Node
+---
+
+Operating a Gateway does not have to be a one-way relationship with The Graph Network. The most impactful way a Gateway Operator gives back is by strengthening the infrastructure the whole network runs on, and Graph Node is at the center of that infrastructure.
+
+## What is Graph Node?
+
+[Graph Node](https://github.com/graphprotocol/graph-node/) is the component of the Indexer stack that indexes Subgraphs and makes the resulting data available to query through a GraphQL API. Graph Node reads a Subgraph's manifest, processes the chain data the Subgraph describes, and stores the result so it can be served. Every Indexer on The Graph Network runs Graph Node, so its correctness and performance directly determine the quality of the data a Gateway routes to. When a Gateway measures an Indexer's freshness and latency, it is, in large part, measuring that Indexer's Graph Node.
+
+## How Gateways Can Contribute to Graph Node
+
+There are several ways operating a Gateway connects back to Graph Node, in increasing order of investment.
+
+- **Run Graph Node as an Indexer:** If an Operator runs their own indexing (for staging or enterprise SLAs, per [Gateway Indexing Approaches](/gateways/subgraphs/consumer-side/indexing-approaches/)), doing it as an Indexer on The Graph Network means running Graph Node and contributing that indexing capacity to the network rather than walling it off. This is the Foundation's preferred approach and the most direct contribution.
+- **Surface real-world signal:** A Gateway sits on a large stream of live query traffic and QoS data (see [Tracking QoS](/gateways/subgraphs/supply-side/tracking-qos/)). That data surfaces where Graph Node performs well and where it struggles: slow query shapes, freshness gaps on particular chains, deployments that are expensive to serve. Feeding those observations back to the teams who maintain Graph Node helps prioritize improvements that benefit every Indexer.
+- **Contribute directly to Graph Node codebase:** Graph Node is open source. Gateway Operators with the engineering capacity can contribute fixes, performance improvements, and features, especially ones motivated by problems they hit while serving real traffic. Improvements to Graph Node raise the quality floor for the whole network, which in turn improves what every Gateway can serve.
+
+## Why This Matters
+
+A Gateway's product quality is ultimately bounded by the quality of the data the network can produce, and that is bounded by Graph Node. Contributing to Graph Node, whether by running it as a network Indexer, feeding back real-world signal, or improving the software directly, is therefore not charity; it raises the ceiling on what an Operator's own Gateway can deliver. The operators who invest here strengthen the network they depend on.
diff --git a/website/src/pages/en/gateways/subgraphs/overview.mdx b/website/src/pages/en/gateways/subgraphs/overview.mdx
new file mode 100644
index 000000000000..d84c516767dc
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/overview.mdx
@@ -0,0 +1,75 @@
+---
+title: Subgraph Gateway
+sidebarTitle: Overview
+---
+
+A Subgraph Gateway is the entry point between Data Consumers and the Indexers who serve their data on The Graph Network. This documentation is written for teams who want to operate a Gateway: it covers what a Gateway does, how it fits into The Graph, and the consumer-side and supply-side responsibilities that come with running one.
+
+## Who Runs Subgraph Gateways
+
+| Operator type | Benefits of Subgraph Gateway |
+| -------------------------- | -------------------------------------------------------------------------------------- |
+| Data and API providers | Resell access to 15,000+ Subgraphs under own brand and billing |
+| Analytics platforms | Query protocol data across many chains without maintaining own indexing infrastructure |
+| Wallets and portfolio apps | Position and activity data without protocol-specific indexing |
+| AI data services | x402-native, pay-per-query access for autonomous agents |
+| Enterprises | Self-hosted, SLA-controlled access to blockchain data |
+
+## The Subgraph Network
+
+The Graph is an indexing and query protocol for blockchain data. One of The Graph's products are Subgraphs, which open APIs that extract, process, and store blockchain data so anyone can query it. Through The Graph protocol, the Subgraph Network is the decentralized set of independent Indexers who sync those Subgraphs and serve those results to end consumers.
+
+The network hosts [15,000+ published Subgraphs across dozens of chains](https://thegraph.com/explorer), including high-demand ones like Uniswap, ENS, and Lido. With [Graph Horizon now live](https://thegraph.com/blog/horizon-upgrade-live/), The Graph protocol has generalized into an open marketplace of interchangeable data services: the Subgraph data service is the first, and the payment rails in this documentation (Graph Tally and Horizon Escrow) are the same ones future services will use.
+
+A Subgraph Gateway lets a service provider put all of this to work under their own brand. Consumers send GraphQL queries to a gateway endpoint, and it discovers which Indexers can serve each one, routes to the best candidates, returns the response, and pays the Indexers it used. It is not strictly required (as consumers can query Indexers directly), but since individual Indexers are independent operators that may slow down or drop offline at any time, a Gateway absorbs that variability to maintain higher quality of service (QoS) while handling per-query payment.
+
+For an Operator that runs data infrastructure (like an RPC provider, analytics platform, wallet backend, AI data service, or any product that resells or embeds blockchain data), running a Subgraph Gateway offers their customers managed access to The Graph Network under the Operator's own authentication, billing, and service level agreements (SLAs).
+
+## Why Providers Run Subgraph Gateways
+
+### Enable Vertical Integration of Data Services
+
+A Gateway is not only cheaper than running an Operator's own indexing stack, it changes what an Operator can offer. Because a Gateway owns authentication, routing, payment, and QoS, a service provider can integrate The Graph Network into a full product stack: pair network data with their own APIs, add their own auth and rate limits, bundle Subgraph access with adjacent services, and present one endpoint and one bill to their customers. An Operator controls the consumer experience end to end while the network absorbs the cost and complexity of indexing. This vertical integration, owning the customer relationship while outsourcing the indexing, is the core commercial advantage of operating a Gateway.
+
+### Leverage 15,000+ Public Blockchain Data APIs
+
+Running a Gateway gives service providers and their customers query access to every published Subgraph on The Graph Network, including the high-demand, hard-to-maintain ones, without having to stand up and babysit that indexing infrastructure directly. For most teams, the alternative is running Graph Node (or equivalent) for every protocol they want to support, each with its own archive node, sync time, re-org handling, and ongoing maintenance. A Gateway replaces that with a single integration point in front of infrastructure that already exists on the network.
+
+### Support More Indexed Chains
+
+The Graph Network indexes Subgraphs across dozens of chains, and that coverage grows as new chains are integrated. Routing through a Gateway means Operators can support more chains for their customers without operating a node on each one: as The Graph adds chain support, Gateway Operators can serve those Subgraphs through the same endpoint. This lets a service provider expand multichain coverage at the speed of the network rather than the speed of their own infrastructure buildout. An Operator is not limited to the chains already integrated, either: an Operator that needs a new chain can help drive its integration onto the network, covered in [Chain Integrations](/gateways/subgraphs/ecosystem/chain-integrations/).
+
+### Offset Indexing Infrastructure Costs
+
+Indexing popular protocols is expensive and operationally heavy: archive nodes, storage, sync times measured in days, and around-the-clock reliability engineering. By routing to Indexers who already run that infrastructure, a Gateway converts a large fixed infrastructure cost into a usage-based query cost. Operators pay Indexers for the queries they actually serve, settled as efficient micropayments through Graph Tally rather than a per-query on-chain transaction. To learn more, see [Pricing & Payments](/gateways/subgraphs/consumer-side/pricing-payments/).
+
+### Curate Common Data through Collections
+
+Most consumers do not want the full surface area of 15,000+ Subgraphs. Instead, consumers typically want the handful that matter to their product, presented simply. [Subgraph Collections](/gateways/subgraphs/consumer-side/subgraph-collections/) let a Gateway Operator group and curate a chosen set of Subgraphs for end users, reducing complexity and turning raw network access into a tailored data product. Offering curated, common data (the pools, names, and balances an Operator's customers actually query) is a clear advantage over an unfiltered view of every Subgraph on the network.
+
+### Enabling Blockchain Data for Humans _and_ Agents
+
+A Gateway authenticates requests with either API keys (best for humans and applications) or x402 pay-per-query in USDC (best for autonomous AI agents that pay as they go with no account). One piece of infrastructure serves both audiences. See [Serving Queries](/gateways/subgraphs/consumer-side/serving-queries/).
+
+### Eliminating Single Points of Failure
+
+Queries are served by a decentralized set of Indexers rather than one hosted backend, and responses can carry attestations backed by Proof of Indexing (POI) and Fisherman dispute resolution. A Gateway can select multiple Indexers per query that fails over automatically, so no single Indexer outage takes down the Operator's service.
+
+## What Subgraph Gateway Operators Run
+
+Running a Gateway means running a small set of services and managing a few wallets. At a high level these components include:
+
+- [**Graph Gateway:**](/gateways/subgraphs/components/overview/) routes queries, discovers and selects Indexers, and signs payment receipts.
+- [**Indexer Selection:**](/gateways/subgraphs/components/indexer-selection/) the mechanism that picks the best Indexers per query.
+- [**Graph Tally:**](/gateways/subgraphs/components/graph-tally/) the payment layer (receipts, RAVs, on-chain settlement) plus the aggregator and escrow-manager services a Gateway Operator runs.
+- [**Titorelli:**](/gateways/subgraphs/components/titorelli/) an optional data-science service that aggregates a Gateway's Kafka output.
+- [**Operations:**](/gateways/subgraphs/components/operating-a-gateway/) wallets, escrow funding, configuration, authentication, and monitoring.
+
+## How Graph Gateway Docs Are Organized
+
+This documentation is split into the two sides of a Gateway plus the shared components and ecosystem context.
+
+- [**Components:**](/gateways/subgraphs/components/overview/) the internals of a Subgraph Gateway, how a query flows through it, and how to deploy one.
+- [**Consumer-Side:**](/gateways/subgraphs/consumer-side/overview/) everything facing the developers and consumers who use a Subgraph Gateway, including pricing, query routing, collections, publication, and support.
+- [**Supply-Side:**](/gateways/subgraphs/supply-side/overview/) everything facing the Indexers who serve an Operator's queries, including routing, escrow, sync incentives, and quality of service.
+- [**Ecosystem Contributions:**](/gateways/subgraphs/ecosystem/chain-integrations/) how operating a Gateway connects back to the broader Graph ecosystem, including Graph Node and chain integrations.
diff --git a/website/src/pages/en/gateways/subgraphs/supply-side/_meta.js b/website/src/pages/en/gateways/subgraphs/supply-side/_meta.js
new file mode 100644
index 000000000000..ea8793858a85
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/supply-side/_meta.js
@@ -0,0 +1,7 @@
+export default {
+ overview: '',
+ 'routing-queries': 'Routing Queries',
+ 'managing-escrow': '',
+ 'incentivizing-syncs': '',
+ 'tracking-qos': '',
+}
diff --git a/website/src/pages/en/gateways/subgraphs/supply-side/incentivizing-syncs.mdx b/website/src/pages/en/gateways/subgraphs/supply-side/incentivizing-syncs.mdx
new file mode 100644
index 000000000000..41be56d0f883
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/supply-side/incentivizing-syncs.mdx
@@ -0,0 +1,54 @@
+---
+title: Incentivizing Syncs
+---
+
+A Gateway can only route to Subgraphs that Indexers have actually synced and are serving queries. When a Subgraph that consumers need is under-indexed, or not indexed at all, getting it synced is often supply-side task depending on the payment/pricing model a Gateway has established. How Gateways do this depends on whether the chain in question has indexing rewards enabled or not. This page covers both cases.
+
+## Why Incentivizing Syncs is a Distinct Problem
+
+Query routing and paying for queries (covered in [Routing Queries to Indexers](/gateways/subgraphs/supply-side/routing-queries/) and [Managing Escrow](/gateways/subgraphs/supply-side/managing-escrow/)) only work once Indexers are already serving a deployment. Nothing about paying more per query causes a Subgraph to get indexed; query fees reward serving, not syncing. Incentivizing an Indexer to take on the up-front work of syncing a new deployment is a separate mechanism, and it is where a Gateway Operator has to think about the economics that attract indexing on The Graph Subgraph Network.
+
+## Chains with Indexing Rewards
+
+On chains where indexing rewards are enabled, the built-in mechanism is curation. Indexing rewards are funded by new GRT issuance (currently at 2-3% annually) and distributed to Subgraphs in proportion to the curation signal on them. Signaling on a Subgraph therefore does two things: it tells Indexers the Subgraph is worth indexing, and it directs a share of indexing rewards to whoever indexes it. More signal means more Indexers are willing to allocate to and sync that Subgraph.
+
+As of December 2022, curation on The Graph Network uses a flat bonding curve (see [GIP-0039: Curation v1.x](https://forum.thegraph.com/t/gip-0039-curation-v1-x/3613)). Under a flat curve, curation shares are minted at a constant price rather than along a rising curve, which means:
+
+- **Predictable cost:** signaling a given amount of GRT gets an Operator a proportional, predictable share, without an early-curator price advantage that a rising curve would create.
+- **Less speculative dynamics:** because shares are not cheaper for being early, curation behaves more like a straightforward signal of demand than a trading game.
+- **Simple mental model for operators:** to attract indexing on a rewards-enabled chain, add signal proportional to how much indexing attention an Operator wants to attract, and expect a proportional response.
+
+For a Gateway Operator, the practical move is to signal (or encourage their consumers to signal) on the Subgraphs an Operator needs served, often paired with the publication flow when a Subgraph is first published (see [Enabling Publication Flows](/gateways/subgraphs/consumer-side/publication-flows/)). A select amount of self-signal at publishing time is a common way to bootstrap indexing on a fresh Subgraph. As a rough guide to the quality of service each level of signal tends to attract. As of August 2026, the recommended signal is:
+
+- **10,000 GRT:** typically attracts 5+ Indexers, the level to aim for when a Subgraph is serving production traffic and an Operator wants redundancy well beyond the three Indexers a Gateway selects per query.
+- **5,000 GRT:** typically attracts 3+ Indexers, enough to cover a Gateway's per-query selection so that no single Indexer's outage leaves the Subgraph unserved.
+- **1,000 GRT:** typically attracts 1-2 Indexers, a reasonable starting point for a fresh or low-volume Subgraph, but thin enough that availability depends on very few operators.
+
+## Chains without Indexing Rewards
+
+Not every chain has indexing rewards enabled. On those chains, curation signal does not attract indexing the same way, because there are no issued rewards to direct, so an Operator needs to compensate Indexers for syncing through other means. The protocol's answer to this gap is **Indexing Payments**: a mechanism that pays Indexers directly to sync and serve a Subgraph through recurring on-chain payments, with no curation signal required. The payer funds an on-chain escrow, and Indexers accept agreements and collect payment by posting Proofs of Indexing (POIs), with either party able to exit gracefully.
+
+### In Progress: Indexing Payments (CHIPs and DIPs)
+
+Where query routing decides who serves a live query, Indexing Payments decide who an Operator (or the Foundation, or a chain) pays to index a Subgraph in the first place. The same underlying mechanism is expected to take two forms in practice:
+
+- **Chain-to-Indexer Payments (CHIPs):** used by The Graph Foundation, a chain, or another surrogate to fund a baseline level of support for a chain on The Graph Network — N Indexers syncing M Subgraphs within a fair-use policy at a defined quality of service. For an Operator, CHIPs is baseline coverage that multiple Gateways can build on to offset infrastructure costs, rather than something the Operator funds directly.
+- **Direct Indexing Payments (DIPs):** used by a Gateway Operator to pay the network's Indexers to sync specific Subgraphs on behalf of its own consumers — typically to "boost" Subgraphs beyond the CHIPs baseline, or to fund indexing on a chain where no baseline exists. This is the lever an Operator reaches for when a Subgraph matters to its product but on-chain rewards or baseline coverage do not yet attract indexing on their own.
+
+How these fit into the Foundation's broader chain-integration model, including how Operators source deals and split revenue, is covered in [Chain Integrations](/gateways/subgraphs/ecosystem/chain-integrations/).
+
+As of August 2026, [Indexing Payments is still a developing part of the protocol](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0081.md): the model is defined in GIP-0081, with the on-chain agreement lifecycle, escrow, and Subgraph Service integration specified in GIP-0087 and GIP-0088. Treat the mechanism as forward-looking: the exact agreements, tooling, and availability are evolving, and this section will be expanded as they land. Do not communicate a timeline externally.
+
+### Off-Chain Deals
+
+Until Indexing Payments is live, Operators commonly arrange off-chain deals: a direct commercial agreement with one or more Indexers to sync and serve specific deployments, on agreed terms, for agreed compensation. This is the interim model that Indexing Payments is designed to replace, and the pragmatic path today when a Subgraph matters to an Operator's product but the on-chain incentives do not yet exist to attract indexing on their own. It resembles the enterprise and staging arrangements discussed in [Gateway Indexing Approaches](/gateways/subgraphs/consumer-side/indexing-approaches/), applied to syncing rather than serving.
+
+### Communicating Sync Requests to Indexers
+
+Whether through DIPs or an off-chain deal, syncing a new deployment ultimately requires talking to Indexers. Practical steps:
+
+- Identify Indexers already serving related deployments with good QoS (the Network Subgraph and Graph Explorer show who serves what).
+- Communicate the specific deployment an Operator needs synced, the expected query volume, and the terms being offered, through an Operator's Indexer relationships (see [Customer Support](/gateways/subgraphs/consumer-side/customer-support/) for the channels operators use).
+- Confirm the Indexer has synced and is serving before routing production traffic, and watch freshness and success rate as it ramps. See [Tracking QoS](/gateways/subgraphs/supply-side/tracking-qos/).
+
+Because a Gateway selects up to three Indexers per query, aim for at least three Indexers syncing any deployment an Operator wants served reliably, so that no single Indexer's outage leaves that Subgraph unserved.
diff --git a/website/src/pages/en/gateways/subgraphs/supply-side/managing-escrow.mdx b/website/src/pages/en/gateways/subgraphs/supply-side/managing-escrow.mdx
new file mode 100644
index 000000000000..aac3ee839c1f
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/supply-side/managing-escrow.mdx
@@ -0,0 +1,53 @@
+---
+title: Managing Escrow
+---
+
+Escrow is the GRT a Gateway Operator holds on-chain to pay Indexers, and keeping it funded is what keeps Indexers serving an Operator's Gateway. This page covers the escrow lifecycle, how Operators set the price they pay for query behavior, and how Indexers price their own service through Agora cost models. The payment protocol itself is covered in [Graph Tally](/gateways/subgraphs/components/graph-tally/).
+
+## The Escrow Lifecycle
+
+As a Graph Tally (TAP) Sender on Horizon (Arbitrum One), payment flows one way: a Gateway signs a receipt per query, Indexers aggregate receipts into RAVs through the Operator's aggregator, and Indexers redeem RAVs on-chain against the Operator's escrow. A Gateway Operator's job is to keep that escrow ahead of what is owed. The sequence to go live is:
+
+1. Fund the sender wallet with ETH (for gas) and GRT (to back escrow).
+2. Authorize the signer on the `GraphTallyCollector` (an EIP-712 proof binds the signer to the Operator's sender).
+3. Approve GRT to the `PaymentsEscrow` contract.
+4. Deposit into escrow, per receiver (per Indexer).
+
+Steps 2 and 4 are automated by the escrow-manager when it is running with signer authorization enabled: it reads outstanding query debt from the `gateway_queries` Kafka topic and sizes deposits up to the Operator's configured GRT allowance. Operators do not redeem RAVs; Indexers do. A Gateway Operator's responsibility is keeping escrow funded and the aggregator healthy.
+
+Two safety flags let an Operator validate before spending: run with payments not required and escrow in dry-run mode, and a Gateway will route, answer, and sign receipts while no funds move. Flip to real payments only after an Operator has watched the escrow-manager log the deposits it would make and confirmed the amounts and target contracts.
+
+Note that Operators should always pull Horizon contract addresses from the authoritative address book rather than hand-copying them. Never reuse legacy pre-Horizon escrow or dispute contracts. A mismatched collector or `SubgraphService` address causes Indexers to reject an Operator's receipts.
+
+## Monitoring Escrow
+
+The signals that matter most, exposed as escrow-manager metrics:
+
+- **`escrow_total_balance_grt` versus `escrow_total_debt_grt`:** keep balance comfortably above debt. A coverage ratio below 1x means Indexers may not be redeemable and will stop serving an Operator. Per-receiver detail is in `escrow_balance_grt{receiver}` and `escrow_debt_grt{receiver}`.
+- **`escrow_deposit_err`:** failed top-up transactions. Alert on these, as they reveal when a depleted escrow stalls payments.
+- **Aggregator health:** RAV request failures mean Indexers cannot get paid, so escrow will not draw down and Indexers may stop serving an Operator.
+
+Keep enough GRT in the sender wallet for the escrow-manager to top up balances, and tune the reconcile interval for how quickly an Operator's query volume runs balances down. See [Tracking QoS](/gateways/subgraphs/supply-side/tracking-qos/) for the broader monitoring picture.
+
+## Setting Prices for Indexer Query Behavior
+
+Gateway Operators control what they are willing to pay Indexers, which in turn shapes which Indexers serve an Operator and how well. The primary lever is the query fee target: the average fee, in USD terms, an Operator is willing to pay per query. It bounds what a Gateway will pay per indexer request and feeds directly into selection.
+
+The tradeoff is direct:
+
+- A higher fee target makes more Indexers economically viable and biases toward better QoS, at higher cost per query.
+- A lower fee target reduces cost per query but shrinks the set of Indexers willing to serve an Operator at that price, which can hurt availability and freshness.
+
+A Gateway's payment control system may pay slightly above an Indexer's cost model to hit an Operator's target average, clamped to the Operator's budget, so the fee target behaves as a smooth economic dial rather than a hard cutoff. This must be set to reflect the QoS that consumers are paying Gateways for: premium, low-latency products justify a higher target; bulk, cost-sensitive workloads justify a lower one. This is the supply-side complement to the pricing an Operator presents to consumers (see [Pricing & Payments](/gateways/subgraphs/consumer-side/pricing-payments/)).
+
+## How Indexers Use Agora Cost Models
+
+On the other side of the price, each Indexer sets its own fees using an Agora cost model, served by its `indexer-service` at `/cost`. Agora is a small declarative language that lets an Indexer express what it charges for different queries: a flat price per query, different prices for different Subgraphs or query shapes, or prices that scale with query complexity.
+
+When routing, a Gateway executes each candidate Indexer's cost model over the specific indexer request to get that Indexer's fee for that query, then favors cheaper Indexers, all else equal, by maximizing marginal score per unit fee. This means:
+
+- Indexers compete on price as well as quality. An Indexer that prices itself out of an Operator's budget simply is not selected.
+- Pricing is per-query and query-aware. A complex query can legitimately cost more than a trivial one, because the Indexer's cost model can say so.
+- An Operator's fee target and the Indexers' cost models meet at selection time. A Gateway reconciles what an Operator will pay with what each Indexer charges, per query, and routes accordingly.
+
+Gateways do not set Indexers' prices directly, but they shape them through Agora. What Gateways set is a budget and how much they value the four quality dimensions, and the ISA finds the best-value Indexers within that budget. Understanding Agora is mostly useful for interpreting why certain Indexers are or are not being selected at an Operator's current fee target.
diff --git a/website/src/pages/en/gateways/subgraphs/supply-side/overview.mdx b/website/src/pages/en/gateways/subgraphs/supply-side/overview.mdx
new file mode 100644
index 000000000000..f5b6cdd22432
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/supply-side/overview.mdx
@@ -0,0 +1,22 @@
+---
+title: The Supply-Side of Subgraph Gateway
+sidebarTitle: Overview
+---
+
+The supply side of running a Gateway relates to everything facing the Indexers who actually serve a Gateway Operator's query requests. Where the consumer side is about presenting a clean product, the supply side is about sourcing reliable data from a decentralized set of Indexers and paying them for it. This section covers how an Operator routes to Indexers, how they fund and manage payment, how they get Subgraphs synced in the first place, and how they track the quality of what the network serves them.
+
+## Indexers on The Graph Network
+
+Indexers on The Graph Network are independent service providers who stake GRT, index Subgraphs, and serve queries in exchange for query fees and indexing rewards. They are not a Gateway's employees and not under a Gateway's control: any Indexer may be fast or slow, fresh or stale, available or down, at any moment. A Gateway's job is to turn that shifting, independent supply into a dependable service for their consumers. That job breaks into four responsibilities.
+
+## A Gateway's Four Supply-Side Responsibilities
+
+- [Routing Queries to Indexers:](/gateways/subgraphs/supply-side/routing-queries/) For each query, a Gateway must choose which Indexers get it. This is where the Indexer Selection Algorithm turns quality, freshness, economic security, and cost into a routing decision, and where a Gateway Operator can block specific Indexers or bias toward preferred ones.
+
+- [Managing Escrow:](/gateways/subgraphs/supply-side/managing-escrow/) Indexers serve an Operator's queries on the promise of payment, and that promise is backed by GRT held in Horizon escrow. Keeping escrow funded ahead of outstanding debt, and setting the fee an Operator is willing to pay per query, is what keeps Indexers serving them.
+
+- [Incentivizing Syncs:](/gateways/subgraphs/supply-side/incentivizing-syncs/) A Gateway can only route to Subgraphs that some Indexer has actually synced. When a Subgraph their consumers need is under-indexed, a Gateway Operator has to incentivize Indexers to sync it, through curation signal where indexing rewards exist, and through [Indexing Payments](/gateways/subgraphs/ecosystem/chain-integrations/) where they do not.
+
+- [Tracking Quality of Service:](/gateways/subgraphs/supply-side/tracking-qos/) To route well and to hold Indexers accountable, a Gateway Operator needs to measure what they actually deliver: success rates, latency, and freshness per Indexer and deployment. This is the data that feeds selection and informs blocking and sync decisions.
+
+The supply side is where a Gateway's payment machinery ([Graph Tally](/gateways/subgraphs/components/graph-tally/)) and selection machinery ([Indexer Selection](/gateways/subgraphs/components/indexer-selection/)) do their work, and it is the harder half of running a Gateway, because it depends on cooperation from independent Indexers a Gateway does not control. Getting Indexers to accept an Operator's Gateway at all is the onboarding wall described in [Gateway-in-a-Box](/gateways/subgraphs/components/gateway-in-a-box/). Everything in this section assumes an Operator is working through or past it.
diff --git a/website/src/pages/en/gateways/subgraphs/supply-side/routing-queries.mdx b/website/src/pages/en/gateways/subgraphs/supply-side/routing-queries.mdx
new file mode 100644
index 000000000000..a776f95eb3e2
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/supply-side/routing-queries.mdx
@@ -0,0 +1,36 @@
+---
+title: Routing Queries to Indexers
+---
+
+Routing queries is the core supply-side function of a Subgraph Gateway: for every query, a Gateway decides which Indexers execute it. This page covers how to use the Indexer Selection Algorithm to route, how to block specific Indexers, and how to bias routing towards preferred Indexers based on their performance.
+
+## Using the ISA to Route Queries
+
+The Indexer Selection Algorithm (ISA) is what turns "many Indexers can serve this" into "these up to three Indexers get it." For each query, a Gateway scores every candidate Indexer as a product of four curves, success rate, expected latency, seconds behind chain head, and slashable GRT, then greedily builds the best-value set per unit fee. While the full mechanics are in [Indexer Selection](/gateways/subgraphs/components/indexer-selection/) section, this page is about operating that component.
+
+A Gateway Operator influences routing through the ISA in three ways:
+
+- **Selection Weights:** each of the four dimensions has an importance exponent. Reference deployments expose these directly (e.g., `SELECTION_WEIGHT_SUCCESS_RATE`, etc.), where a blank value is `1.0` and reproduces stock behavior exactly. Raising the latency weight favors faster Indexers more, while lowering the slashable-GRT weight cares less about stake size. This is the "latency-vs-everything-else" dial, and it is the friendly front for the deeper curve parameters (logistic midpoints, steepness) that also live in a Gateway's JSON `selection` block.
+- **Fee Budget:** `QUERY_FEES_TARGET` sets the average fee an Operator is willing to pay per query, which bounds selection and applies economic pressure toward Indexers whose cost models fit an Operator's budget, which is covered in more detail in [Managing Escrow](/gateways/subgraphs/supply-side/managing-escrow/).
+- **Version Floors:** minimum Indexer and Graph Node versions exclude Indexers running stale software before scoring even begins.
+
+After changing any of these parameters, a Gateway Operator will need to re-render their config and restart their Gateway instance, then watch the routing distribution shift in their query metrics. This is a supply-side control, not a per-query one: Gateways are shaping the population a Gateway routes across, and the ISA does the per-query selection within it.
+
+## Blocking Indexers
+
+Sometimes the right action is to remove an Indexer (or a specific deployment on an Indexer) from consideration entirely, rather than merely scoring it down. A Gateway supports explicit blocking:
+
+- **Blocklist:** add a `(deployment, indexer)` block to exclude a specific Indexer from serving a specific deployment. This works today with no code change, and it is the tool for an Indexer that is serving bad data or dominating an Operator's error rate.
+- **POI Blocking:** optionally block Indexers whose public Proof of Indexing is associated with bad responses. When enabled, an Indexer whose POI is blocked is excluded until it returns a good POI. This ties routing to data correctness, complementing Fisherman dispute resolution.
+
+Blocking is a blunt, deliberate instrument. The ISA already routes around Indexers that degrade, through its runtime feedback loop, so reserve explicit blocks for cases an Operator wants to guarantee (a known-bad Indexer, a compromised deployment) rather than for ordinary performance variation. An Operator should watch their query metrics for a single Indexer dominating errors as the signal that a block may be warranted.
+
+## Sending Queries to Preferential Indexers
+
+The inverse of blocking is preferring: routing more of an Operator's traffic to Indexers they trust. There are several ways to express a preference without breaking the network's competitive routing:
+
+- **Bias by Weight:** if the Indexers an Operator prefers are preferred because they are faster, fresher, or better staked, raising the corresponding selection weights will naturally send them more traffic, because the ISA already rewards those properties.
+- **Prefer an Operator's own Indexer:** if a Gateway runs indexing themselves (see [Gateway Indexing Approaches](/gateways/subgraphs/consumer-side/indexing-approaches/)), that Indexer is a candidate like any other and will win selection when its quality and cost justify it, which is the network-aligned way to route to an Operator's own capacity.
+- **Pin a Specific Indexer (Diagnostic Only):** a Gateway can target a specific `(deployment, Indexer)` for cross-checking a particular Indexer's responses. This is intended for verification, not production routing; pinning removes the failover and quality guarantees the ISA provides, so it is not a way to run preferential production traffic.
+
+The healthy pattern is to encode what an Operator values as selection weights and let the ISA prefer the Indexers that satisfy those values, rather than hard-pinning traffic. That keeps failover, freshness, and cost control intact while still steering toward the Indexers an Operator trusts.
diff --git a/website/src/pages/en/gateways/subgraphs/supply-side/tracking-qos.mdx b/website/src/pages/en/gateways/subgraphs/supply-side/tracking-qos.mdx
new file mode 100644
index 000000000000..91e53ad3f357
--- /dev/null
+++ b/website/src/pages/en/gateways/subgraphs/supply-side/tracking-qos.mdx
@@ -0,0 +1,292 @@
+---
+title: Tracking Gateway Quality of Service
+sidebarTitle: Tracking QoS
+---
+
+Routing well depends on knowing what an Operator's Indexers actually deliver. Quality of service (QoS) tracking is the supply-side feedback that tells an Operator which Indexers are fast, fresh, and reliable, which are degrading, and which Subgraphs are well served across the network.
+
+This page works outward in three layers:
+
+1. **The network data sources every Gateway reads.** The Network Subgraph and the Epoch Block Oracle (EBO) are not optional add-ons. A Gateway cannot route without the first, and cannot reason about Indexer supply per chain without the second.
+2. **An Operator's own telemetry.** Prometheus metrics and, optionally, Titorelli aggregations turn the Gateway's raw output into a durable per-Indexer and per-consumer view.
+3. **Publishing that view back out.** A QoS Subgraph takes those aggregations and makes them queryable, so Indexers can see how they are scored and consumers can verify service claims.
+
+## What QoS Tracking Is For
+
+A Gateway already reacts to quality in real time: every Indexer response feeds success rate and latency back into the [Indexer Selection Algorithm](/gateways/subgraphs/components/indexer-selection/), so degrading Indexers are scored down automatically. QoS tracking is the durable, aggregated view on top of that live loop. It answers questions the per-query feedback cannot:
+
+- Which Indexers consistently serve a deployment well over hours and days?
+- Where are the freshness or reliability gaps across the Subgraphs my consumers query?
+- Which Indexers are candidates for blocking, or for a preferential-routing relationship?
+- What usage and quality data do I need for billing consumers and reporting to customers?
+
+## The Network Data Sources a Gateway Requires
+
+Before any of the optional tooling on this page, two network-level data sources are part of running a Gateway at all. Everything else in this page layers on top of them.
+
+### The Network Subgraph
+
+The [Network Subgraph](https://thegraph.com/explorer/subgraphs/DZz4kDTdmzWLWsV373w2bSmoar3umKKH9y82SUKr5qmp?view=Query&chain=arbitrum-one) is a Gateway's source of truth for on-chain protocol state: which Indexers exist, their allocations, their stake, escrow accounts, and authorized signers. Gateways read it continuously to discover Indexers, and it cannot route a query without it (see [Technical Overview](/gateways/subgraphs/components/overview/)).
+
+For QoS purposes it is also the authoritative reference for who is allocated to what, how much stake is at risk, and which Indexers are actively serving a deployment, the on-chain complement to the performance data an Operator's Gateway observes directly. Combining the two (on-chain allocation and stake from the Network Subgraph, observed performance from an Operator's own telemetry) gives an Operator the full basis for routing, blocking, and preferential-routing decisions.
+
+### The Epoch Block Oracle (EBO)
+
+The [Epoch Block Oracle](https://thegraph.com/explorer/subgraphs/4KFYqUWRTZQ9gn7GPHC6YQ2q15chJfVrX43ezYcwkgxB?view=Query&chain=arbitrum-one) records the starting block of each epoch for every supported chain. It exists because The Graph Network spans many chains while the protocol's accounting (epochs, allocations, and the POIs Indexers submit to close allocations and claim rewards) needs a canonical notion of "where each chain was" at each epoch boundary. The EBO provides that canonical per-chain, per-epoch block reference.
+
+For a Gateway Operator, the EBO matters indirectly but importantly: it underpins whether Indexers can allocate to and be rewarded for indexing Subgraphs on a given chain, which affects which chains have healthy Indexer supply. When an Operator is assessing whether a chain is well served (or planning to incentivize syncs on it, per [Incentivizing Syncs](/gateways/subgraphs/supply-side/incentivizing-syncs/)), the EBO's coverage of that chain is part of the picture.
+
+The EBO is also worth understanding architecturally, because it is the same pattern the QoS Subgraph uses: an off-chain oracle posts compressed messages to a DataEdge contract, and a Subgraph indexes and interprets them. For an Operator that goes on to build a QoS oracle later in this page, [`graphprotocol/block-oracle`](https://github.com/graphprotocol/block-oracle) is a second reference implementation of that architecture with a more sophisticated encoding.
+
+## Aggregating Gateway Telemetry with Titorelli
+
+The Network Subgraph tells an Operator what the protocol says. It does not tell an Operator how any Indexer actually performed on their traffic; only an Operator's Gateway sees that. Titorelli is the optional data-science service that rolls a Gateway's raw Kafka output into hourly aggregations, and it is the primary tool for turning that observation into a durable record. Its `gateway_indexer_qos_hourly` topic aggregates, per Indexer, deployment, and chain: success and failure counts, average seconds behind chain head, average latency, and average fee. That is exactly the per-Indexer, per-deployment QoS picture an Operator needs to make routing and blocking decisions with confidence.
+
+Running [Titorelli](/gateways/subgraphs/components/titorelli/) also produces two other useful streams: `gateway_client_fees_hourly` (per-consumer usage and fees, for billing) and `gateway_indexer_fees_hourly` (per-Indexer fees owed, which also speeds up escrow-manager startup). It sits on a Gateway's secondary data path, so if it goes down, query serving and payments are unaffected; the aggregated view is simply lost until it recovers.
+
+An Operator that does not run Titorelli can still monitor live QoS through a Gateway's Prometheus metrics (query success rate, latency, per-Indexer selection and feedback) and the escrow-manager's metrics; the hourly aggregation is simply done manually or forgone.
+
+## The QoS Subgraph
+
+Titorelli and Prometheus give a Gateway Operator a private view of quality. A Gateway's QoS Subgraph makes that view public and permissionless: it takes a Gateway's own QoS aggregations, publishes them to IPFS, anchors a pointer on-chain, and indexes the result as a Subgraph that anyone can query on The Graph Network.
+
+The original instance is the [Gateway QoS Oracle Subgraph](https://thegraph.com/explorer/subgraphs/CnfJ5tC5cfAmt2tUyUaM6vPrtmNYasavkDDn793FkbN3?view=Query&chain=arbitrum-one), which publishes QoS data for the Gateway operated by Edge & Node on The Graph Network. The rationale and original design are described in [Off-Chain Data and web3 Data Pipelines](https://thegraph.com/blog/the-graph-off-chain-data-web3-data-pipelines/), and the reference implementation of the indexing Subgraph is [`juanmardefago/gateway-qos-oracle-example-subgraph`](https://github.com/juanmardefago/gateway-qos-oracle-example-subgraph), contributed by Juan Manuel Rodriguez Defago of GraphOps.
+
+### Why Publish QoS Data as a Subgraph
+
+Gateway telemetry is, by default, a closed dataset that only the Gateway Operator can see. That is a problem for a network whose supply side is independent:
+
+- **Indexers cannot see how they are being scored:** Publishing per-Indexer success rate, latency, and freshness gives Indexers the same view of their performance that a Gateway uses to route, so they can diagnose and fix problems rather than guess why traffic dropped.
+- **Consumers cannot verify service claims:** Published QoS data lets a data consumer check the quality of the Subgraphs they depend on, and compare Gateways, without taking any operator's word for it.
+- **The ecosystem cannot analyze the network:** Public QoS data is what makes third-party dashboards, Indexer leaderboards, and network health research possible without a data-sharing agreement with the operator.
+- **Nobody has to run an Operator's infrastructure to read it:** Because the output is a Subgraph, consumers query it at their own expense through the normal network path. There is no API to maintain, no rate limits to manage, and no dependency on the operator's uptime.
+
+For a Gateway Operator, the trade is straightforward: the Operator takes on a small, cheap publishing pipeline, and in exchange gets supply-side transparency that improves Indexer behavior and consumer trust without building a reporting product.
+
+### How the Pipeline Works
+
+The QoS Subgraph is an instance of a general pattern for getting off-chain computation into a Subgraph. Four stages:
+
+1. **Aggregate Off-chain:** A scheduled job reads a Gateway's query and Indexer telemetry (in practice, the Kafka topics described in [Titorelli](/gateways/subgraphs/components/titorelli/)) and computes QoS aggregations over a fixed window. The canonical oracle uses a five-minute window and emits two datasets per window: one keyed by Indexer and deployment, one keyed by deployment.
+2. **Publish the aggregation to IPFS.** Each dataset is serialized as a JSON array, one object per row, and added to IPFS. The job keeps the resulting content hash.
+3. **Post a Pointer On-chain:** The job sends a transaction to a [DataEdge](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/grcs/0001-data-edge.md) contract on Gnosis carrying a small JSON payload with the topic name, the IPFS hash, and the window timestamp. DataEdge is a deliberately minimal contract: it has an empty `fallback()` and does nothing with the calldata. Its only job is to get bytes into a block cheaply so that a Subgraph can index them.
+4. **Index it with a Subgraph.** A Subgraph indexes calls to the DataEdge contract, parses the pointer, fetches the referenced IPFS file, and unpacks each row into entities. The QoS data is then queryable over GraphQL like any other Subgraph.
+
+A Gateway never has to be online for consumers to read this data, and the pipeline sits entirely on the secondary data path: if the oracle stops, query serving and Indexer payments are unaffected.
+
+### The Oracle Message Format
+
+The on-chain payload is intentionally small. The canonical oracle calls `submitQoSPayload(bytes)` on the DataEdge contract at `0x5b4293b4c0f36cb5d4448950830bc777759b6c4f` on Gnosis, with a payload of the form:
+
+```json
+{
+ "topic": "gateway_indexer_attempt_qos_5_minutes_prod_v3",
+ "hash": "QmTAVJrwSF3G7YbXBnzebGK5JwWhHnz8Pi4LCFNWmyVRCD",
+ "timestamp": 1785791100
+}
+```
+
+The mapping accepts either a single object or an array of them, so one transaction can carry several pointers.
+
+Two topics are in use, one per dataset:
+
+| Topic | Contents | Becomes |
+| --- | --- | --- |
+| `gateway_indexer_attempt_qos_5_minutes_prod_v3` | Per Indexer, per deployment: what each Indexer delivered on each attempt | `AllocationDataPoint` |
+| `gateway_query_result_qos_5_minutes_prod_v3` | Per deployment: what a Gateway returned to the consumer | `QueryDataPoint` |
+
+The topic name is the versioning mechanism. When the schema of the aggregation changes, the oracle moves to a new topic (`_v3` supersedes `_v2`), and the Subgraph's allowlist of accepted topics is updated. Messages on unrecognized topics are ignored. The Subgraph also enforces a submitter allowlist: a message from an address that is not an authorized submitter is recorded with `valid: false` and an error message, but its data is not processed. That allowlist is what makes the DataEdge contract safe to leave permissionless.
+
+### What a QoS Subgraph Exposes
+
+The schema separates raw five-minute data points from rolled-up daily aggregates, and provides three rollup dimensions.
+
+| Entity | Grain | Use |
+| --- | --- | --- |
+| `OracleMessage` | One per on-chain transaction | Audit the pipeline: was the message valid, who submitted it, when |
+| `MessageDataPoint` | One per IPFS file referenced | Row counts and provenance for a single window |
+| `AllocationDataPoint` | Indexer × deployment × 5 min | Finest-grained Indexer performance |
+| `QueryDataPoint` | Deployment × 5 min | Finest-grained end-consumer experience |
+| `AllocationDailyDataPoint` | Indexer × deployment × day | "How well did this Indexer serve this Subgraph today?" |
+| `IndexerDailyDataPoint` | Indexer × day | "How well did this Indexer serve overall today?" |
+| `QueryDailyDataPoint` | Deployment × day | "How well was this Subgraph served today?" |
+| `Indexer`, `SubgraphDeployment` | Lookup entities | Traverse from an Indexer address or deployment hash into its data points |
+
+The metrics themselves split along the same line as the two topics.
+
+**Indexer-Attempt Metrics** (on `AllocationDataPoint` and the daily rollups) describe what a specific Indexer delivered:
+
+- `proportion_indexer_200_responses` and `num_indexer_200_responses`: reliability
+- `avg_indexer_latency_ms`, `max_indexer_latency_ms`, `stdev_indexer_latency_ms`: speed and consistency
+- `avg_indexer_blocks_behind`, `max_indexer_blocks_behind`: freshness
+- `avg_query_fee`, `max_query_fee`, `total_query_fees`, `query_count`: cost and volume
+- `indexer_wallet`, `indexer_url`, `subgraph_deployment_ipfs_hash`, `chain_id`, `gateway_id`: identity and scope
+
+**Query-Result Metrics** (on `QueryDataPoint` and `QueryDailyDataPoint`) describe what the consumer actually experienced, after a Gateway has selected among Indexers, retried, and filtered:
+
+- `gateway_query_success_rate`: the number that matters to a consumer
+- `user_attributed_error_rate`: failures caused by the consumer's own request, separated out so they do not count against a Gateway or Indexers
+- `avg_gateway_latency_ms`, `max_gateway_latency_ms`, `stdev_gateway_latency_ms`: end-to-end latency including selection and retries
+- `most_recent_query_ts`, `query_count`, `avg_query_fee`, `total_query_fees`
+
+The distinction between the two is the useful part. Indexer-attempt metrics tell an Operator how the supply side is performing; query-result metrics tell an Operator how well a Gateway is compensating for it. A deployment can have mediocre Indexer latency and excellent Gateway success rate, which is precisely what a Gateway is for.
+
+### Querying the Canoncical QoS Subgraph
+
+Daily performance for a given Indexer, most recent day first:
+
+```graphql
+{
+ indexerDailyDataPoints(first: 10, orderBy: dayNumber, orderDirection: desc, where: { indexer_wallet: "0x..." }) {
+ dayNumber
+ query_count
+ proportion_indexer_200_responses
+ avg_indexer_latency_ms
+ avg_indexer_blocks_behind
+ avg_query_fee
+ }
+}
+```
+
+Which Indexers served a deployment best on a given day:
+
+```graphql
+{
+ allocationDailyDataPoints(
+ first: 20
+ orderBy: query_count
+ orderDirection: desc
+ where: { subgraph_deployment_ipfs_hash: "Qm...", dayNumber: 20000 }
+ ) {
+ indexer_wallet
+ query_count
+ proportion_indexer_200_responses
+ avg_indexer_latency_ms
+ max_indexer_blocks_behind
+ }
+}
+```
+
+Consumer-facing quality for a deployment over time:
+
+```graphql
+{
+ queryDailyDataPoints(
+ first: 30
+ orderBy: dayNumber
+ orderDirection: desc
+ where: { subgraph_deployment_ipfs_hash: "Qm..." }
+ ) {
+ dayNumber
+ query_count
+ gateway_query_success_rate
+ user_attributed_error_rate
+ avg_gateway_latency_ms
+ }
+}
+```
+
+To audit the pipeline rather than the data, query `oracleMessages` for `valid` and `errorMessage`, and `messageDataPoints` for the IPFS hash and row counts behind any window.
+
+## Running an Operator's Own QoS Oracle
+
+A Gateway Operator who wants to publish QoS data builds the same four stages. Nothing in the design is specific to any one Gateway: the DataEdge contract is permissionless, and the Subgraph is open source. What differentiates instances is the topic namespace, the submitter allowlist, and the `gateway_id` field carried on every row.
+
+### Step 1: Aggregate the Telemetry
+
+Start from a Gateway's Kafka output. The `gateway_queries` topic carries per-query records with the Indexer, deployment, chain, response status, latency, and fee, which is everything the two QoS datasets need. If an Operator runs [Titorelli](/gateways/subgraphs/components/titorelli/), `gateway_indexer_qos_hourly` already computes most of the Indexer-attempt aggregation on their behalf, though at hourly rather than five-minute grain.
+
+Decisions to make here:
+
+- **Window size:** The canonical oracle uses five minutes. Shorter windows mean more transactions and more IPFS files; longer windows mean cheaper operation but coarser data. Five minutes has proven a reasonable balance.
+- **Grain:** Aggregate to Indexer × deployment × chain for the attempt dataset, and deployment × chain for the result dataset. Do not publish per-query rows; the point of the aggregation is that the published dataset stays small and contains no consumer-identifying information.
+- **What to exclude:** API keys, consumer identity, and query bodies must not appear in the published data. Publish the quality of service, not who requested it.
+
+Emit each dataset as a JSON array of flat objects, using the field names in the schema above so the reference mapping can parse them without modification. Include `gateway_id` on every row so consumers can distinguish an Operator's data from other operators' if a topic namespace is ever shared.
+
+### Step 2: Publish to IPFS
+
+Add each window's JSON array to IPFS and keep the resulting content hash. Pin the content: if the file becomes unavailable before Indexers have processed the message, the corresponding window is lost from the Subgraph and cannot be recovered without republishing under the same hash.
+
+Retention is a real decision. The Subgraph only holds what Indexers have fetched, so the Operator's pinning policy determines how much history a fresh Indexer can sync from scratch. Pin indefinitely if the Subgraph should be resyncable from its start block; pin on a rolling window if only recent data matters, and set the Subgraph's `startBlock` and pruning to match.
+
+### Step 3: Post the Pointer On-Chain
+
+Send a transaction to a DataEdge contract with the `{topic, hash, timestamp}` payload. Two options:
+
+- **Reuse the existing DataEdge contract on Gnosis at `0x5b4293b4c0f36cb5d4448950830bc777759b6c4f`:** It is permissionless, so anyone can submit to it; the Operator's Subgraph submitter allowlist is what separates their messages from anyone else's. Use a dedicated topic namespace so the data does not collide with the canonical oracle's.
+- **Deploy a dedicated DataEdge:** The contract is trivial (an empty `fallback()`), which gives a clean namespace and a transaction stream that is entirely the Operator's. See [GRC-0001: DataEdge](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/grcs/0001-data-edge.md).
+
+Gnosis is the conventional choice because gas is cheap enough that the on-chain cost is negligible. The original writeup put a comparable workload at roughly one to two dollars per month for about ten thousand transactions. Any chain that Graph Node supports will work; the cost profile is the main reason to prefer one.
+
+Run the submitter as a scheduled job with a dedicated hot wallet. The canonical implementation uses a cron-style automation task. Keep the wallet funded, monitor for failed submissions, and treat a submission gap as an alert: a missing window is a permanent hole in the published record.
+
+### Step 4: Build the Indexing Subgraph
+
+Fork [`juanmardefago/gateway-qos-oracle-example-subgraph`](https://github.com/juanmardefago/gateway-qos-oracle-example-subgraph) and change three things.
+
+**1. The manifest:** Point `source.address` at the Operator's DataEdge contract, set `network` to the chain being posted on, and set `startBlock` to the block of the first submission.
+
+```yaml
+specVersion: 1.0.0
+features:
+ - ipfsOnEthereumContracts
+indexerHints:
+ prune: auto
+schema:
+ file: ./schema.graphql
+dataSources:
+ - kind: ethereum
+ name: DataEdge
+ network: gnosis
+ source:
+ address: '0x5b4293b4c0f36cb5d4448950830bc777759b6c4f'
+ abi: DataEdge
+ startBlock: 46970110
+ mapping:
+ kind: ethereum/events
+ apiVersion: 0.0.9
+ language: wasm/assemblyscript
+ entities:
+ - OracleMessage
+ abis:
+ - name: DataEdge
+ file: ./abis/DataEdge.json
+ callHandlers:
+ - function: submitQoSPayload(bytes)
+ handler: handleSubmitQoSPayload
+ file: ./src/data-edge.ts
+```
+
+Note that this uses a call handler, not an event handler. DataEdge emits nothing; the data is the calldata, so the mapping reads `call.inputs._payload`. The ABI in the manifest exists only so Graph Node can decode the selector and argument; the contract itself does not implement it.
+
+**2. The constants:** Update `JSON_TOPICS` to the Operator's topic names and `SUBMITTER_WHITELIST` to its submitter addresses. These two lists are the entire trust model: the contract accepts anything, and the Subgraph decides what counts.
+
+**3. The schema and parsing, if the fields differ:** If an Operator publishes exactly the fields the reference implementation expects, the mapping works unchanged. To add metrics, add them to `schema.graphql` and to the corresponding `create*DataPoint` function, and add them to the daily rollup helpers if they should be aggregated.
+
+The mapping flow is worth understanding before modifying it. `handleSubmitQoSPayload` creates an `OracleMessage` keyed by transaction hash, checks the submitter against the allowlist, and, if the submitter is authorized, parses the JSON payload. For each accepted topic it calls `processIpfsHash`, which fetches the file, iterates the array, and creates one `AllocationDataPoint` or `QueryDataPoint` per row, choosing based on whether the topic name contains `indexer` or `query`. Each row creation also updates the relevant daily rollup entities in place, which is why the daily entities are mutable while the raw data points are immutable.
+
+**On IPFS access in mappings:** The reference implementation calls `ipfs.cat` inside the mapping, enabled by the `ipfsOnEthereumContracts` feature flag, and that is what the canonical deployment runs. It is the simplest approach, but it makes indexing dependent on the file being retrievable at index time: an Indexer that cannot fetch the file logs a warning and skips that window. [File data sources](https://thegraph.com/docs/en/subgraphs/developing/creating/advanced/#ipfsarweave-file-data-sources) are the alternative, and provide a retryable, template-based path for off-chain file content. An Operator building a new oracle rather than mirroring the canonical one should evaluate file data sources first, and expect to restructure the mapping into a template handler.
+
+### Step 5: Publish and Operate
+
+Deploy to Subgraph Studio, test against live submissions, and publish to The Graph Network so consumers can query it through the normal path. Signal enough curation to attract Indexers; see [Incentivizing Syncs](/gateways/subgraphs/supply-side/incentivizing-syncs/) for the levels that tend to attract how many.
+
+Ongoing operational concerns:
+
+- **Submission monitoring:** Alert on missed windows and on transactions that land but produce `valid: false` records, which usually means a submitter key rotated without a corresponding Subgraph update.
+- **Topic versioning:** When the aggregation schema changes, publish to a new topic and add it to `JSON_TOPICS` rather than changing the meaning of an existing topic. Consumers depending on the old shape keep working.
+- **History and pruning:** The canonical deployment sets `indexerHints: prune: auto` and a recent `startBlock`, so it serves a rolling window rather than the full history. Decide whether consumers need deep history, and set pinning, `startBlock`, and pruning consistently. These three have to agree, or the result is a Subgraph that claims history it cannot serve.
+- **Data hygiene:** Everything published is permanent and public. Review the aggregation output once before the first submission, and again whenever a field is added.
+
+## Putting It Together
+
+A healthy supply-side monitoring setup layers outward from the sources a Gateway cannot run without:
+
+- **The Network Subgraph** for authoritative on-chain state: who is allocated, with how much stake, to what.
+- **The EBO Subgraph** for per-chain allocation health, which tells an Operator where Indexer supply is likely to be thin.
+- **A Gateway's live selection feedback** for instant routing, reacting to quality query by query.
+- **Titorelli's hourly aggregations** for the durable per-Indexer and per-consumer view that live feedback cannot provide.
+- **QoS Subgraph** for publishing that view, so Indexers can see how they are scored and consumers can verify what they are getting.
+
+These join cleanly because they share keys. The Network Subgraph, a Gateway Operator's telemetry, and the QoS Subgraph all key on Indexer address and deployment IPFS hash, so a single analysis can combine an Indexer's stake and allocation size with its measured latency and freshness on the same deployment. Together they reveal not just that a query succeeded, but whether an Operator's Gateway is sourcing the best available service from the network, which is the whole point of tracking QoS.
diff --git a/website/src/pages/en/global.json b/website/src/pages/en/global.json
index 1a09520ad1a9..a39d29fd121c 100644
--- a/website/src/pages/en/global.json
+++ b/website/src/pages/en/global.json
@@ -5,7 +5,7 @@
"hide": "Hide navigation",
"subgraphs": "Subgraphs",
"substreams": "Substreams",
- "indexing": "Indexing",
+ "indexing": "Indexer Software",
"graph-horizon": "Graph Horizon",
"resources": "Resources",
"archived": "Archived"