When Polymarket switched to CLOB V2 on 2026-04-28, it brought new CTF Exchange contracts, pUSD collateral, and builder-code attribution. That change broke a lot of the analytics people had built on V1 events. I rebuilt my subgraphs for V2 and published them on The Graph's decentralized network. Below is everything I know about them: what each one covers, what's actually synced right now, real queries with real output, and the gaps.

Source (PRs welcome; TODO: confirm license): https://github.com/PaulieB14/polymarket-v2-subgraphs

The subgraphs

Status was checked 2026-10-16 at about 7:02 PM ET. The Polygon chain head was block 95,657,583.

Legacy V1 subgraphs are still up for history before the migration: Polymarket main QmdyCguL…QX8a, Orderbook QmVGA9vv…pUup, and P&L QmZAYiMe…wQU. TODO: confirm sync status before linking these.

Example queries (real output, trimmed)

1. Platform totals plus the top V2 markets by volume (orderbook)

{
  globalStats(id: "global") { tradesQuantity scaledCollateralVolume scaledCollateralFees tradersCount marketsCount buildersCount }
  markets(first: 3, orderBy: scaledCollateralVolume, orderDirection: desc) { id tradesQuantity scaledCollateralVolume lastPrice }
}

"globalStats": { "tradesQuantity": "868875100", "scaledCollateralVolume": "34324527882.98",
  "scaledCollateralFees": "201150627.72", "tradersCount": "1275086",
  "marketsCount": "3650588", "buildersCount": "3862" },
"markets": [
  { "id": "319268930482876715…480574", "tradesQuantity": "86064",  "scaledCollateralVolume": "256203489.84", "lastPrice": "0.999" },
  { "id": "590469406952990582…791078", "tradesQuantity": "148323", "scaledCollateralVolume": "117238750.64", "lastPrice": "0.999" }
]

Note: markets are keyed by outcome tokenId, not by question. You need Polymarket's Gamma API, or MarketData.condition in the main subgraph, to turn a tokenId into a human-readable question. "Volume" here is the summed collateral across fill events. TODO: check whether that double-counts relative to Polymarket's headline volume before quoting the $34B figure.

2. Builder attribution (new in V2)

{ builders(first: 3, orderBy: scaledVolume, orderDirection: desc) { id orderCount scaledVolume } }

[ { "id": "0xceebf77a…ce0c1", "orderCount": "2991872", "scaledVolume": "785020729.79" },
  { "id": "0x25a86cf1…0afda4", "orderCount": "344926",  "scaledVolume": "573084309.72" },
  { "id": "0x6b0e773f…c67984", "orderCount": "2665966", "scaledVolume": "288251744.66" } ]

This shows which front ends and bots route V2 flow. The builder codes are bytes32, and mapping them to names is off-chain (TODO: is there a public registry?).

3. Live trade tape

{ orderFilledEvents(first: 3, orderBy: timestamp, orderDirection: desc) { timestamp side price size exchange market { id } } }

[ { "timestamp": "1792191723", "side": 0, "price": "0.38999999", "size": "51.282052", "exchange": "CTF" },
  { "timestamp": "1792191723", "side": 0, "price": "0.61000000", "size": "48.972052", "exchange": "CTF" },
  { "timestamp": "1792191723", "side": 1, "price": "0.39",       "size": "2.31",      "exchange": "CTF" } ]

side 0 = BUY and 1 = SELL. exchange is either CTF or NEG_RISK.

4. A trader's positions and realized P&L (pnl)

{ accounts(first: 2, where: { tradesQuantity_gt: "100" }) {
    id tradesQuantity scaledCollateralVolume realizedPnl
    positions(first: 2) { tokenId amount avgPrice realizedPnl } } }

{ "id": "0x0000000000110124f0712c657fc401c0d6b80f9c", "tradesQuantity": "4065",
  "scaledCollateralVolume": "184975.61", "realizedPnl": "5672.33",
  "positions": [ { "tokenId": "100276467…914745", "amount": "633333332", "avgPrice": "0.15", "realizedPnl": "0" } ] }

In practice, filter with accounts(where: { id: "0x…" }) for one wallet. amount uses 6 decimals.

5. Resolutions and market catalog (main)

{ globals(first: 1) { numConditions numOpenConditions numClosedConditions numTraders }
  conditions(first: 2, orderBy: resolutionTimestamp, orderDirection: desc, where: { resolutionTimestamp_not: null }) { id resolutionTimestamp payouts } }

"globals": [ { "numConditions": 4412308, "numOpenConditions": 379818, "numClosedConditions": 4032490, "numTraders": "898695" } ],
"conditions": [ { "id": "0xfc23aaa7…ba02c1", "resolutionTimestamp": "1792191722", "payouts": ["0","1"] } ]

What you can build

• Leaderboards by trader volume or realized P&L (V2 era)
• Live trade feeds and "hot market" detection by recent fill counts
• Builder and front-end market share since the V2 cutover
• Resolution watchers, for example to alert when a condition resolves and show payouts
• Bots that check a wallet's cost basis before trading

Limitations (please read before building on this)

• Open Interest V2 currently syncing
• P&L is V2-only. Cost basis starts at the V2 deploy block, so positions opened under V1 will show incomplete cost basis. Combine with the V1 P&L subgraph if you need full history. Realized P&L only; unrealized P&L needs live prices from the CLOB API.
• Heavy queries can time out. accounts(orderBy: realizedPnl, orderDirection: desc) across all accounts timed out on both indexers when I tested it. Filter first, for example by id or tradesQuantity_gt.
• Adapter masking: V2 splits, merges, and redeems go through CtfCollateralAdapter and NegRiskCtfCollateralAdapter, so stakeholder on Split/Merge can be the adapter rather than the user's wallet. Fill-based data (orderbook, pnl) isn't affected.
• No question text on-chain. Everything is keyed by conditionId or tokenId, so join with the Gamma API for titles and slugs.
• Some MarketData.condition values are null, specifically NegRisk positions minted through the NegRisk Adapter.
• On-chain fills only: no resting orders, no order-book depth, and no off-chain cancellations.
• Usage is still low. The gateway's 30-day query counter showed 0 for these deployments. That may be a reporting lag (TODO: verify), but expect few indexers per deployment, so latency varies.

How to query

1. Get a free API key at https://thegraph.com/studio/ (API Keys). TODO: confirm the current free-tier allowance before stating a number.
2. POST GraphQL to https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>, or use /deployments/id/<Qm…> to pin a specific version.
3. Check freshness with { _meta { block { number } hasIndexingErrors } }.

​

curl -s -X POST "https://gateway.thegraph.com/api/$KEY/subgraphs/id/B9mm21DKCex8ka4g8cteQU4NQqtviwmcTjQAYLbzQ1eR" \
  -H 'content-type: application/json' \
  -d '{"query":"{ globalStats(id:\"global\"){ tradesQuantity tradersCount } }"}'

There's also an MCP server that wraps these subgraphs together with Polymarket's Gamma and CLOB APIs: https://github.com/PaulieB14/graph-polymarket-mcp

Questions, bug reports, and schema requests are welcome in the comments or as GitHub issues.

If you'd rather not write GraphQL, Graph Advocate (graphadvocate.com) answers these kinds of questions for about $0.01 per call via x402.

OPINION's free Open API is great for live data (market titles, current prices, 24h volume). But it has no wallet history, no PnL, and no long-term trade history. So I built an open-source subgraph that indexes every OPINION trade on BNB Chain, and the two fit together really well.

How they fit together

• The subgraph has all the on-chain data: every matched fill (with fees), wallet positions and realized PnL, splits/merges/redemptions, open interest, and hourly/daily candles.
• The API has the plain-English question titles, which aren't stored on-chain.
• You join them on questionId. Use marketType=2 to get multi-outcome markets too; they come back as childMarkets.

In my tests, 10 of the top 10 markets matched, and the markets that have titles cover 99.7% of traded volume. The last prices matched the API on all the live markets I checked.

Examples you can only get by combining them

Top markets with names (subgraph volume, API titles):

• Which companies will be acquired before 2027? → Anthropic: $1.54B, 79,812 fills
• Will Satoshi move any Bitcoin in 2025?: $1.11B, 395,619 fills, resolved
• Fed Rate Decision in January? → 50+ bps decrease: $692M, 583,081 fills
• USDT depeg in 2025?: $312M, 324,280 fills

Whale tracking: the top wallet by realized PnL (0x39c3…bf26) is up about $1.22M on $13.6M volume. Its two biggest wins were betting NO on "Bank of Japan decreases rates in January" (+$1.24M) and NO on "Fed 50+ bps cut in January" (+$1.24M). Neither source can show you that on its own.

Example query (top markets, then look up the titles in the API by questionId):

{ markets(first: 5, orderBy: volume, orderDirection: desc) { questionId volume openInterest tradeCount lastYesPrice } }

Links

• Subgraph endpoint: https://api.studio.thegraph.com/query/111767/opinion-prediction-market/v0.1.1
• OPINION Open API: https://openapi.opinion.trade/openapi/market
• Repo (includes a short Python script, demo.py, that does the join): https://github.com/PaulieB14/opinion-subgraph

Caveats

Volume counts what the maker paid, so it runs about 1.2–2x above OPINION's site. Some of the giant markets trading at 0.002 look like bot churn, so treat raw volume with care.

Feedback welcome. Would a taker-side volume field be useful?

This is the public one: [Blockchain Data Expert](https://x.ai/bot/eyFr_G8h9UmrQHNpZpNfx). It's Derek's bot at Data Nexus. It uses The Graph's official subgraph MCP, and each person still adds their own Studio query key.

Here's a grokbot from Data Nexus that queries The Graph. Add it, drop in a Studio API key, and ask in plain English. https://x.ai/bot/eyFr_G8h9UmrQHNpZpNfx

Key setup: https://thegraph.com/docs/en/subgraphs/querying/managing-api-keys/

Ink is Kraken's OP Stack L2 for DeFi. Substreams and Firehose are now live for Ink, on the Extended block model.

Why Extended Blocks matter here: on Ink, the interesting activity is DeFi, and DeFi moves value through internal calls. Base blocks give you transactions, receipts, and logs. Extended Blocks add the four things base blocks miss:

• Internal calls: the full call tree for every transaction. Attribute every transfer through Aave, Tydro, routers, and liquidations instead of guessing from top-level transactions.
• Balance changes: exact native-balance history for any address, without re-deriving it from transactions and gas math.
• Storage changes: index contract state that never emits an event, and verify indexed state against on-chain state for audit-grade data.
• Code changes: track every contract deployment on Ink, including the pools, markets, and vaults a factory creates through internal calls that never appear as a top-level transaction.

Firehose extracts each Ink block once and stores it as flat files that Substreams reads in parallel, so you get real-time streaming and fast backfills without the rate limits of live RPC.

Get started with Ink using Pinax: https://app.pinax.network/

The Graph’s Ink Docs: https://thegraph.com/docs/en/supported-networks/ink/

Extended Blocks work: https://thegraph.com/blog/extended-blocks-for-substreams

More on Extended Blocks: https://app.pinax.network/docs/guides/block-types/

This quarter, The Graph started putting growth behind the Network instead of a centralized staging path. Subgraphs made The Graph the standard for querying chain data. The Network is what keeps them running: independent Indexers who sync Subgraphs, serve queries, and stand behind the data.

Full recap: https://thegraph.com/blog/q3-2026-in-review/

1. Studio traffic is moving to the Network
BNB Smart Chain and Polygon staging queries end on October 8, 2026. After that, Indexers serve those queries and collect the fees.

• Already published to the Network: nothing changes.
• Still on the Studio staging endpoint for these chains: publish before Oct 8, set up billing and an API key, then switch to a Gateway endpoint. The Foundation will curate newly published Subgraphs on those chains with a bot until Oct 8 so Indexers have a signal. Other chains are expected to follow.

2. REO is live: indexing rewards now follow query service
The Rewards Eligibility Oracle ties rewards to actually serving queries. An Indexer stays eligible by serving at least one qualifying query on 5+ days in a rolling 28-day window. A qualifying query returns HTTP 200 in under 5,000 ms, is within 50,000 blocks of chainhead, and hits a Subgraph with at least 500 GRT in signal.
Issuance does not change. Who receives it does. Rewards are withheld, not confiscated.
Check status: https://hub.thegraph.foundation/reo/
Delegators: if your Indexer is impacted, your rewards are too.

3. New Foundation mandate
The Foundation now operates the Network directly. It runs the Subgraph Gateway, Subgraph Studio, and Graph Explorer, with engineers from GraphOps and Edge & Node joining to run infrastructure and own protocol work. The job is to keep developers, data consumers, Indexers, and Delegators pointed at the same place.

4. Innovation Allocation (GIP-0089)
Council-approved. 20% of protocol issuance goes to a Foundation-managed Innovation Allocation for operational continuity, product experience, data service provider onboarding, and chain integrations. Still accountable to the Council.
Forum: https://forum.thegraph.com/t/gip-0089-is-live-20-of-issuance-now-sent-to-the-innovation-allocation/7053

5. Chains

• Anubis: Subgraphs
• Arc, HyperEVM, Ink: Firehose and Substreams with extended blocks
• Robinhood Chain: additional Firehose and Substreams providers, plus testnet Extended blocks include internal calls, balance changes, storage diffs, and code changes that a normal RPC misses.

6. Graph Office Hours
Indexer Office Hours is now Graph Office Hours. Tuesdays at 17:00 UTC in Discord. All six Q3 recordings are in the recap (mandate, Studio migration, REO, chain integrations, liquid staking).

7. Liquid staking, Phase 1
Small soft launch. stGRT represents a staked position and accrued rewards. Vault deployed by Avantgarde on Enzyme tooling; Foundation manages it. Wider Delegator rollout is planned in the coming weeks. Early access: [vault@thegraph.foundation](mailto:vault@thegraph.foundation)
Not financial advice. Rewards are variable.

8. Substreams
Hosted Stores and Hosted Sinks are in beta on The Graph Market. Stores are a block-aware key/value store. Sinks can now expose a read-only GraphQL API so teams moving off Subgraphs can keep the interface they already use.

9. ETHOnline
354 submissions across three tracks. Nine winners split $15,000 (Alpha Markets, Sentinel, OpenBook, Covenant, Turnstile, and others).

TL;DR: BSC and Polygon Studio traffic moves to Indexers on Oct 8, indexing rewards now require real query service (check the REO dashboard), and the Foundation is operating the Network directly under GIP-0089.

Hi community, sorry for being the one carrying bad news, but maybe the email verification templates are broken. I was trying to verify my account an this was the result (attached). I'll be so grateful if you can help us with that.

New post on the blog: a breakdown of the two EVM block models behind Substreams, and what extended support actually unlocks.

Short version:

• Base blocks are what a standard RPC exposes: blocks, transactions, receipts, and logs. Good for event-based indexing, and easy for a new chain to support.
• Extended blocks come from full-node instrumentation: internal calls (the full call tree), balance changes, storage diffs, and contract code changes. This is the stuff you’d normally need debug_traceTransaction and a premium trace plan to get.

Use extended if you’re indexing routers/aggregators, tracking exact native-token balances, following contract deployments through the call tree, or reading contract state that never emits an event.

Use base if you just key off logs.

Check whether your chain has extended support, then read the full post:

• Blog: https://thegraph.com/blog/extended-blocks-for-substreams
• Supported networks: https://thegraph.com/docs/en/supported-networks/

Building on a chain that isn’t available yet? Email The Graph Foundation at info@thegraph.foundation and they can talk through an integration.

Firehose and Substreams endpoints for HyperEVM (operated by Pinax) have moved from base blocks to extended blocks. That puts internal calls, balance changes, and storage changes in the stream, not just logs.

On HyperEVM that matters: native HYPE moving inside a call, a health factor crossing a threshold, or a vault rebalancing never emit an event. Extended blocks record them anyway.

Huge thanks and congrats to Pinax for building on the Extended Blocks support for HyperEVM and their continued support of The Graph and Substreams!

The Graph Docs: https://pinax.network/chain/hyperevm
Built by Pinax: https://pinax.network/chain/hyperevm

The Graph gives you ability to turn your ideas into real products!

All three winning builds proved one thing: Standardized Subgraphs turn "integrate each protocol from scratch" into "add a single config row."

🏆 The Winners:

🥇 Alpha Markets ($2.5K)

A fundamental forecasting market where AI analysts publish protocol financials and back their research with USDC stakes. Using standardized lending schemas, a single GraphQL query executes seamlessly across 28 Ethereum lending deployments without writing custom adapters.

https://ethglobal.com/showcase/alpha-markets-yit80

🥈 Sentinel ($1.5K)

A confidential systemic-risk oracle uncovering hidden cross-protocol leverage before liquidations cascade. It maps 9 lending deployments on Account.id inside a TEE scanning 37,862 accounts and identifying ~$35.9M in multi-protocol debt against shared collateral.

https://ethglobal.com/showcase/sentinel-fwf81

🥉 OpenBook ($1K)

An autonomous data marketplace for AI agents with programmatic freshness guarantees. Every query delivery is verified against _meta{block}; if data is stale, the onchain escrow refunds the buyer. It turns 15,000+ active Subgraphs into monetizable, SLA-backed data feeds.

https://ethglobal.com/showcase/openbook-8ngw6

Yesterday a chain with zero subgraphs got its first one. Start to finish in a day, most of it spent checking things rather than writing code, which is exactly the part an AI assistant is good at.

Anubis Mainnet had no subgraphs. Not a small number. Zero. It also had RocketSwap, a Uniswap V2 fork carrying essentially all of the chain's DeFi activity, emitting swaps into the void at a rate nobody was indexing.

That subgraph now exists. Here is what actually took the time, what didn't, and where an assistant helped versus where it confidently got things wrong.

• 811 pairs on the factory
• ~188k swaps per day
• 0 lines of mapping logic written
• 1 day research to published

The first step is not writing code

The most valuable thing you can do before building a subgraph is establish that you need to. Most of the time something already indexes what you want, and querying it costs an afternoon instead of a fortnight.

So: search the Explorer for your protocol. Paste your contract address. If a subgraph already covers it, you are done, and a subgraph earning real query fees is a strong signal it works, because somebody is paying indexers to serve it.

For Anubis the search came back empty, which is the one answer that justifies building. Even then the next question isn't "how do I write mappings" but "what can I fork?"

Fork the right thing

RocketSwap is a Uniswap V2 fork, so the subgraph is a Uniswap V2 subgraph. But there are two repositories with similar names, and picking the wrong one costs you days.

The current Uniswap/v2-subgraph has a multi-chain config system. Adding a chain is a directory:

// config/anubis/config.json
{
  "network": "anubis",
  "factory": "0xaf6f4e641c86a25518509bc840051a8652af598a",
  "startblock": "2059"
}

plus a chain.ts declaring which token prices the others and which are trusted enough to count toward tracked volume. No mapping logic was written or changed. The swap, mint, burn and pricing code is Uniswap's, battle-tested across nineteen chains.

The same instinct applies one level up. The Graph's own Substreams docs carry a section titled Reuse Existing Substreams Before Building, pointing at published packages from StreamingFast, Pinax and TopLedger. Reuse is the house style, not a shortcut.

Verify on-chain, never from a listing

This is where an assistant earns its keep, and where the discipline matters most. Every fact below was read directly from the chain over JSON-RPC rather than taken from a block explorer page or a docs table:

# is it really a Uniswap V2 factory?
allPairsLength()  -> 811
feeTo()           -> responds

# do the pairs have the standard ABI?
token0() token1() getReserves() totalSupply() symbol()  -> all present

# does PairCreated match the canonical signature?
topic0 == 0x0d3648bd0f6ba80134a33ba9275ac585d9d315f0ad8355cddefde31afa28d0e9

That last check is the one people skip. A chain can host something that looks like a Uniswap fork but emits a different event signature, and you will not find out until your subgraph syncs to chainhead with zero entities. Confirming the first PairCreated log resolves to the same address as allPairs(0) takes one minute and removes that entire class of failure.

A mistake worth copying the fix for. An early activity check reported zero swaps in 40,000 blocks, which would have killed the project on the spot.

It was wrong. The RPC caps eth_getLogs at 500 blocks and had returned an error, which got read as an empty result. Sampling properly inside the cap gave 27,306 swaps in 10,000 blocks, roughly 188,000 a day.

Assistants make this mistake and so do people. The guard is to treat an empty result and an error as different things, always.

The pricing config is where subgraphs go wrong

A Uniswap V2 subgraph prices everything against one reference token, normally wrapped ETH. On Anubis the gas token is gasDAI, so the hub asset is itself a stablecoin. DAI sits on one side of 580 of the 811 pairs. Three decisions followed, and all three are the kind that quietly poison a dataset.

Derive the reference price, don't assume it

DAI measured at 0.9970 USDT, not 1.0000. The config points at two deep stable pools and lets the reserve-weighting carry that small depeg through, rather than hardcoding a dollar.

Check that your pricing pool is alive

There was a DAI/WETH pair with both reserves at zero. Whitelisting WETH would have priced tokens through a dead pool. A pair existing is not the same as a pair having liquidity.

Match tokens by address, never by symbol

Among the top 40 tokens on this chain: three contracts call themselves DAI, and one of them is named "Anubis". Three call themselves USDT, at two different decimal counts. Four call themselves ANB. Symbol matching would have produced a confident, completely wrong dataset.

Best practices worth the effort

Immutable entities and Bytes as IDs

The Graph's documented best practice is worth following: entities that never change after creation should be immutable, and ids that are addresses or hashes should be Bytes rather than String. Composite ids concatenate as bytes:

// before
hash.toHexString().concat('-').concat(index.toString())

// after
hash.concatI32(index)

Two things that cost real time here, which no guide mentions. Shared code is shared: this repository builds two subgraph variants from one src/common, so converting one schema compiled cleanly for the target being worked on and broke the other with ten type errors. Build every target, not the one you are looking at. And the generated types directory is rewritten per target, so codegen has to run before each build when switching between them.

Do not rank by USD fields you have not checked

Sorting Uniswap-V2-schema pairs by reserveUSD surfaces untracked pairs reporting around 8.8e33 USD against zero volume. That is not a hypothetical. It was verified on Uniswap's own mainnet subgraph. Rank by trackedReserveETH or volumeUSD. Read reserveUSD only on a pair you already selected.

Probe freshness before trusting anything

{ _meta { block { number } } }

Compare it to the chain head, every time. Lifetime query fees tell you a subgraph was useful once, not that it answers today. One subgraph checked during this build had six figures of lifetime fees and returned no data at all.

Where AI helped, and where it didn't

Honestly: the assistant did not write the interesting code, because the interesting code already existed and was forked. What it did was the work that usually gets skipped: enumerating all 811 pairs, resolving 652 token symbols and decimals, ranking pools by real liquidity, probing every contract for ABI conformance, and sampling the chain to prove there was activity worth indexing. That is hours of mechanical verification compressed into minutes, and it is the difference between a config built on evidence and one built on assumption.

It also got things wrong in instructive ways. It read an RPC error as zero activity. It truncated a documentation page and missed the one sentence that mattered, that this chain has no Subgraph Studio support, then burned five deployment attempts on a path the docs explicitly say to skip. Both were caught by checking against reality rather than by thinking harder.

The pattern that works: let the assistant do breadth, then verify the specific things a wrong answer would break. Ask it to prove claims with a command whose output you can read.

Publishing

Deployment differs by chain, and it is worth reading the network's page before assuming. Some chains support Subgraph Studio for staging. This one does not, and publishes directly to the decentralized network instead:

graph codegen && graph build
graph publish

One thing that catches people: signal. On a chain without indexing rewards, no Indexer has any incentive to index your subgraph until it carries curation signal. Publishing succeeds and then nothing syncs, which looks like a bug and isn't. Note also that curation tax applies. 500 GRT of signal records as 495.

Start here

• Supported networks — every chain The Graph indexes, with the exact network identifier your manifest needs, and each chain's own quirks
• Explorer — search before you build. Paste your contract address first
• Best practices — immutable entities and Bytes as IDs, plus the rest of the performance guidance
• Substreams agent skills — open-source knowledge packs that give an AI assistant real Substreams expertise
• Uniswap V2 subgraph — the multi-chain fork base. Adding a chain is a config directory

Every figure here was measured rather than recalled: 811 pairs and 652 tokens from the factory over JSON-RPC, ~188,000 swaps/day from 10,919 swap logs sampled across 5,000 blocks, and the 0.9970 DAI/USDT quote from pool reserves, all on 15 September 2026. Numbers move; the method doesn't.

The resulting subgraph is open source under GPL-3.0, forked from Uniswap/v2-subgraph.

Whenever a new network launches, one of the earliest operational bottlenecks for engineering teams is data accessibility. Without dedicated indexing infrastructure, developers are forced to run custom RPC polling loops, handle chain reorganizations manually, and babysit fragile internal database sinks.

The Graph has officially introduced day-one support for Arc, providing decentralized indexing and high-throughput data streaming capabilities to developers and institutional builders from the genesis block.

Core Capabilities Available from Launch:

GraphQL Querying with Subgraphs

Developers can construct and publish dedicated Arc Subgraphs directly on The Graph. This maps raw contract events into structured, open APIs queryable via GraphQL, simplifying frontend application data fetching, user balance tracking, and protocol analytics.

High-Speed Streaming via Substreams & Extended Blocks

For applications requiring lower latency and deeper execution visibility, Substreams offers a parallelized, streaming-first pipeline. With Extended Blocks support, builders receive full call-trace details and state-change data as it happens on Arc. This enables developers to ingest complex contract interactions without missing nested execution events.

Empowering Next-Generation Use Cases

Arc is designed to facilitate high-throughput financial and automated operations, and The Graph's indexing infrastructure provides the verifiable data backbone for several core verticals:

- Stablecoin Payment Rails: Real-time settlement monitoring, payment tracking, and low-latency transaction confirmation.

- Tokenized Real-World Assets (RWAs): Verifiable audit trails for asset issuances, redemptions, and secondary market liquidity.

- Autonomous Agentic Workflows: Deterministic onchain data inputs that allow AI agents to monitor balances, trigger contract calls, and execute programmatic tasks safely.

By offering day-one integration, teams deploying on Arc can bypass backend data plumbing entirely and focus immediately on shipping user-facing products.

Get started with the official Arc integration guide:

https://thegraph.com/docs/en/supported-networks/arc/

Interested in using The Graph but unsure where to start? Don't duplicate existing work if you don't have to. Check this out before you waste your time. The Graph may already index the data. Let me know if this helps

Anubis is a privacy-focused, EVM-compatible L1 (PLONK ZK proofs + selective disclosure, mainnet since April) — is now supported by Subgraphs on The Graph Network. What that means for builders: you can define exactly the onchain data your app needs from Anubis: contract events, DeFi activity, token flows and query it with GraphQL through a subgraph, instead of standing up archive nodes or scraping RPC. Useful for DeFi frontends, dashboards, explorers, portfolio tools, and onchain agents.

Check out their website: https://anubischain.ai/

The Anubis ecosystem is DeFi-heavy so far. RocketSwap (native DEX, the bulk of the chain's ~$369M TVL) and AWAKE (genesis project) are natural first subgraphs. The chain is running 1M+ transactions/day, which is exactly the volume where hand-rolled indexing starts to hurt.

Integration was built with InfraDAO. Docs and getting started: https://thegraph.com/docs/en/supported-networks/anubis/

Happy to answer questions if you're building on Anubis.

Hosted Sinks + your Postgres — Morpho Blue as the worked example

You already know the pitch for Substreams: parallel historical backfill, typed modules, Firehose instead of hammering RPC. The part people still bounce on is the last mile:

That last mile is what StreamingFast Hosted Sinks and the Hosted Sink GraphQL layer are for. Morpho Blue is just the example we used this week — the same path works for any Substreams package that can emit SQL-friendly output (DatabaseChanges / sink-sql). Uniswap, your own protocol, a niche oracle, a L2 DEX — same shape.

The problem (in plain language)

Protocol-native APIs (Morpho, Uniswap interface backends, etc.) optimize for product UX. They are not your warehouse. Subgraphs optimize for decentralized queries, but ops and backfill cost still land on you. Substreams already solved decode + parallel history. What’s missing for many builders is a boring, shareable serving layer on top of a DB they own.

Hosted Sink = always-on writer into your Postgres/ClickHouse.
GraphQL layer = read-only Hasura over that same DB — console + HTTP, keyed by your Market org.

Morpho Blue below is the concrete run. Mentally replace morpho-blue-paulie with your pack.

The pattern (works for any pack)

  [substreams.dev package]
            │
            ▼
   Hosted Sink runner  ──────►  YOUR Postgres / ClickHouse
   (SF operates this)           (you provision: Railway, Neon, CH Cloud, …)
            │
            ▼
   Hosted Sink GraphQL (Hasura, read-only)
            │
            ├── Console for humans
            └── /v1/graphql for apps & agents

Rules of the road

1. StreamingFast does not host your database. Hosted Sink only runs the sink process and connects outbound to a DB you provide (public TCP / reachable host).
2. Prefer a pack with a db_out (or sink-sql) module emitting sf.substreams.sink.database.v1.DatabaseChanges.
3. Quality-gate with substreams run on a short window before you Deploy — garbage in, GraphQL out.
4. Publish to substreams.dev so Hosted Sink can pull a public .spkg URL.
5. Deploy Hosted Sink → point at your DB → enable GraphQL in the Market UI → share console/API links.

That’s the whole product story. Everything else is choosing a protocol.

Walkthrough (Morpho Blue as the example)

0. Pick a question the stack should answer

For Morpho we cared about:

• Markets, positions, MetaMorpho vaults as exact chain state in SQL
• A GraphQL surface others can hit without our Railway password
• Something we could screenshot for an advocate post — not a full tip risk oracle on day one

Your question might be “top pools by fee,” “oracle updates,” “ERC-20 transfers for a set of contracts.” Same pipeline.

1. Own the Substreams pack (or reuse one)

We published morpho-blue-paulie (ETH + Base variants) to the registry — stores + db_out for Blue + MetaMorpho.

• Registry: https://substreams.dev/packages/morpho-blue-paulie/v0.2.3
• Repo: https://github.com/PaulieB14/morpho-blue-substreams

If a good pack already exists for your protocol, start there. The Hosted Sink / GraphQL story does not require you to invent Morpho — it requires a public .spkg and a SQL-shaped output module.

2. Bring a database you control

We used Railway Postgres with a public TCP proxy (altaria.proxy.rlwy.net). Neon, RDS, self-hosted — anything the sink can reach with TLS.

Why this matters: analytics stay in your VPC/project. You can psql, chart with matplotlib, join to off-chain tables, delete the whole thing. Hosted Sink never becomes the source of truth — your DB does.

3. Quality-gate before Deploy

Before burning Hosted Sink quota, run a short substreams run on db_out and read the rows. We caught a same-block double-CREATE that would have crash-looped Postgres on first deploy. Fix → republish → then Deploy.

This step is protocol-agnostic and saves real money on FREE plans.

4. Deploy Hosted Sink

In thegraph.market (use the login that owns the org — for us GitHub, not a second Google account):

1. Create deployment → attach DB (stored secret for the password — don’t paste into chat agents)
2. Point at https://api.substreams.dev/v1/packages/<name>/<version>
3. Module: db_out / DatabaseChanges
4. Scale replicas to 1

What you stopped doing yourself: keeping a sink process up, wiring restarts, explaining SSH to the next person who wants the data.

What you still own: schema, disk, backups, “do we pause on FREE quota?”

Our sink: https://thegraph.market/sinks/depsaco3165576dfbda7117

5. Turn on GraphQL (the enhancement)

On the sink: enable GraphQL. Hasura sits read-only on the same Postgres.

Console: https://morpho-blue-eth-graphql-117-gq.hs.streamingfast.io/console
API: https://morpho-blue-eth-graphql-117-gq.hs.streamingfast.io/v1/graphql

Auth: Market UI → GraphQL → Copy with key → X-Api-Key (or session in console).

This is the part that turns a private index into a shareable product surface — for any protocol, not just Morpho.

6. Query like a human (then like an agent)

Markets

query Markets {
  markets(limit: 20, order_by: { created_block: asc }) {
    id
    loan_token
    collateral_token
    oracle
    irm
    lltv
    created_block
  }
}

One concrete Morpho market (WETH / wstETH)

query WethWsteth {
  markets(
    where: {
      id: {
        _eq: "0xc54d7acf14de29e0e5527cabd7a576506870346a78a11a6762e2cca66322ec41"
      }
    }
  ) {
    id
    loan_token
    collateral_token
    lltv
    created_block
  }
}

Protocol config

query BlueConfig {
  blue_config(limit: 30, order_by: { updated_block: asc }) {
    id
    kind
    value
    updated_block
  }
}

Risk-shaped query (pattern for “agents that care”) — after you have HF rows at tip:

query Underwater {
  liquidatable_positions(
    where: { health_factor_wad: { _lt: "1000000000000000000" } }
    limit: 20
    order_by: { health_factor_wad: asc }
  ) {
    id
    market_id
    user_address
    health_factor_wad
    updated_block
  }
}

Swap table names for your pack’s schema — the habit is the point: GraphQL over your sink tables.

7. Chart from the same DB (optional but persuasive)

Because the sink writes Postgres, the same snapshot feeds matplotlib / Metabase / whatever. We generated a dark hero dashboard + util-vs-LLTV bubbles from Railway for the Morpho demo (charts/v2/). Readers believe “real data” when they see figures and can hit GraphQL.

Why this combo wins (vs the alternatives)

Hosted Sink removes the ops tax of the writer.
GraphQL removes the distribution tax of the reader.
Substreams removes the “wait a week for backfill” tax on history.

Morpho made it tangible. Your next pack makes it repeatable.

What we learned the hard way (so your walkthrough is shorter)

These are Morpho-shaped incidents with general morals:

1. db_out must upsert / dedupe — same PK twice in one block will crash Postgres. Fix in the pack; don’t hope the DB forgives you.
2. SQL sink flush batches span many blocks — a DELETE in block N and UPSERT in N+k in the same flush can fail even if each block is coherent. We moved liquidatable to never-delete, last-known HF (v0.2.3) and filter in GraphQL. Know your sink’s batch semantics.
3. Module hash changes reset cursors — republishing db_out often means re-backfill or a deliberate late start_block for smoke tests only (stores go cold if you skip history).
4. FREE plans have hard caps — parallel jobs eat block quota even when you’re “just testing.” Pause replicas when the demo is packaged.
5. One Market login ≠ one human — GitHub vs Google can be different orgs. Device-approve on the org that owns the sink.

None of that is Morpho-specific. It’s the cost of doing the last mile for real.

Snapshot we shipped for the Morpho demo

Hosted Sink paused on FREE after packaging (so quota isn’t burned on a stuck catch-up):

Enough for a good architecture + GraphQL story. Tip-complete HF feeds are the great follow-up when quota resets or you upgrade.

Copy this for your protocol

1. Find or build a Substreams pack with db_out
2. substreams run a short window — read the output
3. Publish to substreams.dev
4. Provision Postgres/ClickHouse you control
5. Deploy Hosted Sink → enable GraphQL
6. Publish two links: console + one killer query
7. Pause on FREE when the screenshot is enough

Morpho Blue was our killer query this week. Next week it can be yours.

Links

• GraphQL console: https://morpho-blue-eth-graphql-117-gq.hs.streamingfast.io/console
• GraphQL API: https://morpho-blue-eth-graphql-117-gq.hs.streamingfast.io/v1/graphql
• Sink: https://thegraph.market/sinks/depsaco3165576dfbda7117
• Pack: https://substreams.dev/packages/morpho-blue-paulie/v0.2.3
• Repo: https://github.com/PaulieB14/morpho-blue-substreams
• Hosted Sink GraphQL docs: https://docs.substreams.dev/how-to-guides/hosted-services/hosted-sinks/graphql-layer
• Hosted Sinks overview: https://docs.substreams.dev/how-to-guides/hosted-services/hosted-sinks

Your Hosted Sink can now expose a **read-only GraphQL API and browser console** over its database.

Powered by Hasura, with automatic schema tracking and support for both Postgres and ClickHouse.

Enable it in the New Sink wizard or from the GraphQL tab of a sink's Edit screen.

Scaling past what a Subgraph was built for?

This keeps a familiar GraphQL query surface as you take the next step to Substreams: same ecosystem, faster reprocessing, and substreams-convert for the port.

https://www.streamingfast.io/blog/serve-your-substreams-data-over-graphql?utm_source=discord&utm_medium=community&utm_campaign=wallet-users-indexing&utm_content=blog-graphql-layer

Circles’s L1. Official docs. Arc lists u/graphprotocol as a decentralized indexer. The Graph already has Arc on its supported-networks page.

Mainnet Sept 16.

Goldsky and HyperIndex are on the page too.

$GRT is the only token. Support isn’t exclusivity.

Volume is the bet.

Arc docs: https://docs.arc.network/arc/tools/data-indexers

Graph docs: https://thegraph.com/docs/en/supported-networks/arc/

I spent the last while building a Substreams package for Morpho Blue and MetaMorpho. Sharing what I got wrong, what the contracts do that surprised me, and a question at the end about which chains to do next.

Links - Source: https://github.com/PaulieB14/morpho-blue-substreams - Ethereum: https://substreams.dev/packages/morpho-blue-paulie/v0.2.0 - Base: https://substreams.dev/packages/morpho-blue-paulie-base/v0.2.0 - Morpho Blue contracts: https://github.com/morpho-org/morpho-blue - Morpho's official API: https://docs.morpho.org/developers/api/morpho/

First, the honest part: Morpho's API is better for most things

Before anyone asks — yes, Morpho ships an excellent GraphQL API, and for most use cases you should use it instead. It has USD values, APYs at eight timescales, rewards, PnL and ROE per position, healthFactor, priceVariationToLiquidationPrice. I measured its limits: 1,000 positions per page across 59k positions, and 12 rapid requests with zero throttling. It is not the bottleneck people assume it is.

This is for the case where you want the data in your own database, streamed, reorg-aware, composable with other indexers.

Three things in the contracts that will silently corrupt your index

1. AccrueInterest mints shares with no Supply event.

When interest accrues, feeShares are credited directly into the fee recipient's supply position. There is no Supply event. EventsLib warns about this in a comment and it's easy to miss. If you don't separately track SetFeeRecipient, that balance is wrong permanently — and it compounds, because those shares then earn.

Caveat I'll state up front: no Morpho market currently has a non-zero fee (0 of 300 I sampled), so this is latent rather than actively wrong today. It breaks the moment governance turns a fee on.

2. Bad debt is socialized across suppliers.

On Liquidate with bad debt, the loss comes off totalBorrowAssets and totalSupplyAssets, and the borrower's remaining borrow shares are zeroed. If you only decrement the borrow side, every supplier's implied assets are overstated from then on.

3. Events must be replayed in log order.

This one cost me the most. Upstream event batches are grouped by event type. If you iterate field by field — all the supplies, then all the accruals — you can apply an AccrueInterest after a Supply that actually happened later in the same transaction. On chain, interest always accrues first. The share math comes out subtly wrong and nothing errors. Every store I wrote merge-sorts on log index before applying anything.

Composition instead of forking

StreamingFast already had a Morpho Blue event decoder, so I imported it rather than reimplementing it, and spent my modules on the layer it lacks: market totals, per-user positions, MetaMorpho vaults, upsert SQL.

One wrinkle worth knowing: that decoder was never published to the registry, it only exists as source in substreams-chain-modules. So I build it and vendor the .spkg (Apache-2.0, unmodified besides network and start block). Which turned out to be lucky — Base support then cost almost nothing, because the decoder is network-agnostic and Blue is the same address on both chains. Same Rust crate, second manifest, done.

Source of that decoder: https://github.com/streamingfast/substreams-chain-modules/tree/main/lending/morpho-blue-substreams

Verifying it, given a 10k-block cap

I'm on the free tier, which caps a request at 10,000 processed blocks. Backfill from Morpho's deployment block is ~4.2M, so I couldn't just run it and compare totals.

The way around it: pick markets created recently, set the start block to just before creation so the stores observe their entire life, then read Morpho.market(id) at the same block via an archive eth_call. Two markets, all four supply/borrow asset and share totals, exact match.

What this has that the API doesn't

Health factor is on their API, so I don't count it. What isn't:

• Liquidation economics. Seizable collateral and the incentive factor, derived from the contract math: LIF = min(1.15e18, WAD / (WAD - 0.3e18 * (WAD - lltv))) seizable = borrowed.wMulDown(LIF).mulDivDown(1e36, oraclePrice)

Oracle price is read inline over RpcBatch at 1e36 scale.

• Bad debt per borrower. The API gives bad debt per market, so it can't tell you which addresses repeatedly leave it behind. This attributes it, with an incident count.

• Reorg undo signals, and composability with other Substreams on the same chain.

Known limitation, stated plainly: positions are only re-priced when an event touches them. Something that goes underwater purely because the oracle moved won't show up until the next touch. Re-pricing every open position every block would mean an RPC call per market per block. So treat the liquidatable set as "known underwater as of last touch", not a real-time liquidation feed.

The question: which chain next?

Morpho is deployed on 14 chains. I've done 2. Nine of the remaining twelve already have Substreams support, so they're mostly a start block and a factory address away:

Arbitrum, Polygon, Optimism, Unichain, HyperEVM, World Chain, Monad, Robinhood Chain, Tempo

(Katana, Stable and Arc have no Substreams support yet, so those are blocked.)

If you're indexing Morpho on any of these and hitting something the API doesn't cover, say which chain and I'll do that one next. Equally, if you think I've misread any of the accounting above, I'd rather be corrected — it's MIT, and being wrong in public is cheaper than being wrong in someone's database.

The scale of prediction markets has fundamentally shifted. After surpassing $150 billion in cumulative volume earlier this year, monthly volumes recently touched $40 billion—eclipsing the average monthly volume of the entire legal U.S. sports betting sector. With the upcoming NFL kickoff projected to drive more than $36 billion in trading volume on game outcomes, prediction markets are rapidly evolving from political betting experiments into continuous, high-liquidity financial rails.

While user volume dominates headlines, the technical infrastructure running underneath these platforms presents a massive data hurdle for engineers, quant analysts, and product teams.

The Anatomy of an Onchain Prediction Market

Turning a real-world event into a liquid, trustless market involves three interconnected mechanisms:

- Conditional Token Framework: Contracts like Gnosis CTF lock collateral and mint paired "Yes" and "No" tokens that combine to equal one unit of collateral.

- Resolution and Oracles: Unlike simple price derivatives that query an oracle feed, prediction markets settle against real-world facts, relying on optimistic dispute systems (such as UMA) to determine outcomes.

- Hybrid Order Matching: Orders match offchain at high speeds for tight spreads, while settlement executes onchain.

The resulting event stream—condition creation, token splits, merges, CLOB fills, resolutions, and claims—is public, but far from easily legible. Condition IDs are raw cryptographic hashes, order-book depth sits in offchain matching engines, and resolving questions requires stitching disparate contracts together. Building an indexing pipeline to parse this from scratch often delays projects by months.

How The Graph Indexes the Space

Rather than building redundant pipelines, teams can leverage production-ready indexing tooling deployed across The Graph ecosystem, optimized for three primary engineering workflows:

1. GraphQL and Historical Data (Subgraphs)

For backtesting strategies, calculating historical profit and loss, or designing leaderboards, Subgraphs index the entire position lifecycle. The Polymarket Activity Subgraph traces splits, merges, redemptions, and complex multi-candidate conversion states, mapping raw token IDs back to human-readable markets.

1. Real-Time Event Streaming (Substreams)

When real-time data delivery is essential—such as during live in-game sports trading or surprise macroeconomic announcements—Substreams packages process raw blocks in parallel. Production packages track order fills across contract migrations (covering CLOB v1 and v2) and calculate platform-wide realized P&L directly into external storage sinks like ClickHouse or PostgreSQL.

1. Out-of-the-Box REST Endpoints (Token API)

For applications that require pre-calculated metrics over standard HTTP, Pinax's Token API abstracts away the indexing layer entirely. It surfaces clean JSON endpoints for market OHLCV bars, open interest, user balances, and cost-basis calculations across Polymarket and HyperLiquid outcome markets.

1. LLM and Agent Tooling (MCP)

For developers integrating natural language forecasting or autonomous trading agents, the open-source graph-polymarket-mcp integration allows agents running in Claude, Cursor, or custom frameworks to inspect live market probabilities, trader activity, and open interest through standard Model Context Protocol queries.

The Takeaway for Builders

High-frequency events like football games generate a continuous flood of spreads, props, and in-game adjustments that require low-latency, deterministic data infrastructure. Rebuilding this data pipeline from zero adds unnecessary overhead.

Whether you are launching a specialized trading venue, a portfolio tracking tool, or an AI forecasting bot, the schemas and indexing pipelines are already live and battle-tested on The Graph Network. Point your product at the indexed feeds and focus on building your application.

Full post and technical guide:

https://thegraph.com/blog/prediction-markets-data-layer/

You know the problem: a module needs to look something up mid-stream (an off-chain price, token metadata, an account→owner map), and your only options were to recompute it in every pipeline or run your own key/value service that survives reorgs.

Hosted Stores is that service, managed by StreamingFast on The Graph Market. Put data in, read it back at any block height from a Substreams module or a plain gRPC client. No infra to run, no fork handling to write.

Two feed modes: • Remote feed: push data in over gRPC from your own service (off-chain prices, allowlists, KYC data) • Substreams feed: a package populates it from chain data, so many pipelines can share one lookup (token metadata, pool registries)

It sits alongside Hosted Sinks under Hosted Services: Sinks move Substreams output out to your Postgres/ClickHouse; Stores hold data you look up while a pipeline runs.

It's beta. Fully working, but we'd love for you to tell us what you think.

Docs: • Overview • Remote feed guide • Substreams feed guide

There are a few Grok Bots that can get you started with on-chain data. You’ll need the Grok Bot app (https://x.ai/bot), then tap Add on the link. Adding copies the bot onto your account. It does not copy anyone else’s keys or computer. You'll need Supergrok to use or get free trial.

The Graph / subgraphs — Blockchain Data Expert by Derek Ask about a token or protocol and it pulls a short snapshot from subgraphs (TVL, volume, holders, that kind of thing). It can also look up Aave V3 health, Uniswap LP / large pool moves, and search for other subgraphs. You bring your own Subgraph Studio query API key. The Graph bills that key, not the bot. https://x.ai/bot/eyFr_G8h9UmrQHNpZpNfx

Pinax — Token API and other data services Balances, transfers, and swaps via the Pinax Token API (and related Pinax / RPC / Substreams checks). Good when you want wallet or token activity without standing up a subgraph. https://x.ai/bot/sWgVsJcGy9mjz7NsSTwLi

Substreams — building pipelines Finds packages on substreams.dev, helps write and test modules, and run them (including sinks) with a Graph Market login. This one is for people building blockchain data pipelines, not just asking Q&A. https://x.ai/bot/4ZzeuafN9Z1boU8smYIXv

Open-source Substreams package that indexes Aerodrome on Base. What it covers:

Both venues. Aerodrome v2 (Swap/Mint/Burn/Sync) and Slipstream concentrated liquidity (Swap/Mint/Burn/Collect). Coinbase's tokenized stocks are mostly Slipstream, but a couple of live v2 AMM pools hold them too, so both rails are indexed.

Pools discover themselves. Everything comes from factory PoolCreated events across all four factories in Aerodrome's FactoryRegistry, and it watches the registry's Approve events, so a factory approved later registers itself. No hardcoded pool list.

New tokens index automatically. B20 addresses are deterministic — [10-byte prefix][variant byte][bytes9(keccak(deployer, salt))] — so detection is an address check with no allowlist. A new ticker is picked up on the block its pool is created, and the Asset/Stablecoin variant is read straight from the address with no RPC call.

Corporate actions. B20 handles splits and dividends with a multiplier rather than by rebasing. It's cosmetic to the AMM — reserves stay raw — so raw prices are continuous across a split and only the per-share series steps. Both are exposed. Scheduled multiplier updates name a future effectiveAt and flip lazily with no event, so the schedule is stored and resolved by timestamp. Renames, pauses, seizes and announcements are indexed too.

Securities vs everything else. B20 is a general RWA standard, and a 10,000-block window on Base had 503 new B20 tokens from 210 deployers — mostly memecoins, 502 of them the Asset variant. Coinbase's tokenized stocks publish a real ISIN in metadata (AAPLc → US0378331005), so views ladder from b20_pools → b20_asset_pools → stock_pools (ISIN-verified).

 Output. Prices from sqrtPriceX96 with decimals applied, OHLCV at any bucket size, per-pool and per-token stats. PostgreSQL or ClickHouse via substreams-sink-sql.

 Note that createB20 is permissionless — anyone can mint a B20 and write any metadata they want, so the ISIN indicates intent, not issuance.

 substreams.dev/packages/aerodrome-substreams MIT, source on GitHub.

Historically, indexing rewards on The Graph Network were allocated based strictly on curation signal and allocated stake. Because these metrics measured capital placement rather than network utility, a portion of network issuance consistently rewarded inactive participants. In 2025, approximately 15.2% of all indexing rewards were paid to Indexers that were not serving queries or indexing data actively used by consumers.

To align network incentives with real-world activity, the Rewards Eligibility Oracle (REO) has been officially launched following the ratification of GIP-0079.

How the Standard Works

REO verifies that an Indexer is actively serving traffic. Under current parameters:

- An Indexer must serve at least one qualifying query on 5 or more separate days within a rolling 28-day window.

- A qualifying query must return an HTTP 200 code, respond in under 5,000 ms, and be processed within 50,000 blocks of the chainhead.

- Queries must be executed against Subgraphs with at least 500 GRT in curation signal to prevent sybil traffic generation.

Eligible status lasts for 14 days and is updated on-chain daily.

What Happens to Ineligible Indexers and Delegators?

- Stake is never slashed or penalized. Ineligible nodes continue to operate and collect raw query fees.

- Indexing rewards are withheld (transactions revert) rather than permanently revoked. If an Indexer meets the threshold again before the allocation period expires, the rewards remain claimable.

- Delegators inherit the eligibility status of their chosen Indexers. Delegators are encouraged to check the public REO dashboard to monitor their Indexers' status streaks, particularly watching for "grace" periods.

Decentralization and Safety Fail-Safes

Because off-chain oracles require high transparency:

- The codebase and criteria are fully public with written changelogs and ~14-day advance notices for adjustments.

- If the oracle fails to submit updates for 7 consecutive days, the protocol automatically defaults all Indexers to eligible, preventing network stalls. Governance also maintains the power to disconnect the oracle if needed.

REO represents the first step in a broader economic overhaul for The Graph, preceding the GRT Liquid Staking Initiative and Direct Indexer Payments scheduled for later this year.

Read the full article:

https://thegraph.com/blog/rewards-eligibility-oracle/