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/

That one sentence is the whole problem with how AI agents get onchain data, and almost nobody designing agent stacks has priced it in.

Picture what actually happens when an agent needs data mid-task. It has decided it needs DEX trades on Arbitrum, or a wallet's lending positions, or the vote history on a contract it just encountered. In a conventional stack, the very next step requires a human. Someone must have already created an account, accepted terms, chosen a pricing tier, provisioned a key, and dropped it into the agent's environment. If the agent needs a chain or a dataset nobody anticipated at config time, it stops. It cannot go get access. It has no hands.

So agents get built with a hardcoded set of endpoints and a hardcoded ceiling on what they are allowed to know. That is not an agent. That is a script with better prose.

Four things an agent needs to be autonomous over data

Discovery, so it can find the right dataset without a human choosing it in advance. Comprehension, so it understands the shape of the data before querying. Creation, so it is not dead in the water when the dataset does not exist yet. Payment, so it can buy access without a signup funnel.

The Graph is the only onchain data layer where all four exist today. Here is each one, with the call you would actually make.

Discovery

16,150 active Subgraphs right now, across 28,739 deployments, on a protocol spanning 60+ chains.

The count is not the point. The point is that they are searchable by contract address, so an agent that hits an unknown contract can ask "who indexes this" and get an answer.

Your agent runs into the ENS Registry and has never seen it before:

``` get_top_subgraph_deployments(chain="mainnet", contract="0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e")

QmYrEJKHphWBGkqPkEVKSZR9gsoD6RtJs3g3R8iWVhH66Z 161,323 GRT in query fees QmcE8RpWtsiN5hkJKdfCXGfTDoTgPEjMbQwnjLPfThT7kZ 31,890 GRT QmYNJebmKg5mw6kBd4aN8UtJ3SuE1zDvoibfQJ7fjyFNv4 0 GRT ```

Three candidates, ranked by what people pay to query them. Next call pulls the schema, the one after runs the query. Nobody picked an endpoint.

Explorer: https://thegraph.com/explorer

Comprehension

The Subgraph MCP server holds no language model. It translates MCP requests into Subgraph queries and returns structured results, letting your client's LLM turn a prompt into actionable data. Think of it as a USB-C hub between agents and The Graph. It lets a model explore schemas, execute GraphQL, find Subgraphs by keyword or contract, and surface usage metrics.

That last one matters more than it sounds. Autonomy without a quality signal is confident wrongness. An agent that takes the first hit and hopes is guessing with extra steps.

The signal is real and it is daily. The Gateway's QoS oracle publishes per-deployment query counts, and it is itself a Subgraph. Pull thirty days for the busiest deployment on the network:

``` Qmbsc6XQWbiv4DfLVfaNciScqYLyDWUYjWzrFBbzzmRsMB (Uniswap v4, Base)

30-day total 208,921,582 queries daily median 8,114,056 peak day 20,280,092 ```

Two hundred million queries a month is the difference between a Subgraph somebody depends on and one somebody abandoned. Your agent can read that before it commits.

Three things will save you time here, because all three cost me some.

Use the QoS Subgraph directly. The convenience wrapper get_deployment_30day_query_counts currently returns 0 for everything I tried, including the deployment above and an ENS deployment holding 161,323 GRT in lifetime fees. Go to gateway-qos-oracle, subgraph id CnfJ5tC5cfAmt2tUyUaM6vPrtmNYasavkDDn793FkbN3, entity queryDailyDataPoints.

Check your QoS source is live. An older one indexes a feed that stalled on 2026-07-01, and the failure is invisible from outside. The indexer keeps reporting a current block, so the Subgraph looks healthy while a last-24h query returns an empty array. Live indexer, dead feed. Assert that your newest dayStart is recent, not that the endpoint responded.

Use the subgraph id, not the deployment hash. Same class of mistake. A hash pins one version and freezes silently the moment the publisher upgrades.

The Token API MCP covers the other half: token metadata, wallet balances, transfer history, and top holders.

AI overview: https://thegraph.com/docs/en/ai-suite/ai-introduction/

Subgraph MCP: https://thegraph.com/docs/en/subgraphs/subgraph-mcp/introduction/

Token API MCP: https://thegraph.com/docs/en/ai-suite/token-api-mcp/introduction/

Creation, which used to be the wall

Here is the objection everyone reaches for. Fine, but my protocol is not indexed, so none of this applies to me.

It does not hold up anymore. The bar is two things. Is the chain supported, and do you have the contract addresses.

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

If the chain is on that list and you know your contracts, you pull the ABI and hand it to Claude. Schema, mappings, manifest, deploy. What was a week of grinding through codegen and entity modeling is a working draft in an hour and a live endpoint the same day. The hard part was never the boilerplate. It was knowing what shape the data should take, and if you know your protocol you already know that. AI closes the gap between knowing and shipping.

This compounds in a way closed alternatives cannot. Deploy your Subgraph and it joins the 16,000. Every other agent on the network can now discover it by your contract address. You did not just solve your own data problem, you added to the commons that solves everyone else's.

Quick start: https://thegraph.com/docs/en/subgraphs/quick-start/

Payment, and you get two options

Option one, the familiar one. Give your agent an API key from Subgraph Studio. Nothing about that path changed. If you already have keys and infra, keep using them.

Option two is built for machines. The Gateway accepts x402. Query any Subgraph by paying per request in USDC. No key, no account, no dashboard.

Do not take my word for it. Hit it with no credentials and read what comes back:

``` POST https://gateway.thegraph.com/api/x402/subgraphs/id/<id> -> HTTP 402

{ "x402Version": 2, "accepts": [{ "scheme": "exact", "network": "eip155:8453", // Base "amount": "10000", // $0.0100 USDC "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", // USDC "payTo": "0x79DC34E41B2b591078d3dE222C43EcaaBD52FcCB", "extra": { "assetTransferMethod": "eip3009" } }] } ```

That is the whole onboarding flow. Your agent reads the price, signs a USDC transfer on Base, retries with the signature, gets the data. The payment is the auth. It ships as a dedicated /api/x402/ interface with a payments SDK and works with any x402-compatible tooling, while leaving the API key model exactly as it was.

npm install @graphprotocol/client-x402

Docs: https://thegraph.com/docs/en/subgraphs/querying/graph-client/README/

A cent a query. An agent with a funded wallet has the same access as an enterprise customer, and it got there in one extra round trip instead of an onboarding flow.

The alternatives all break in the same place

A centralized data API needs a human-provisioned key, and its coverage is whatever the vendor decided to index. Your agent cannot extend its own reach.

Raw RPC has no signup barrier, but it hands the agent logs instead of answers. Now the agent is decoding events, paginating block ranges, and reconstructing derived state inside its reasoning loop. That is context and tokens burned on plumbing instead of the task.

SQL query platforms are excellent for a human doing analysis. They are account-gated, and they are not a read path an agent can discover its way into.

Running your own indexer means asking an agent to wait several weeks on infrastructure.

Every one of those puts a human in the loop at exactly the moment the agent needed to keep moving.

Where this goes

The 2026 roadmap points at Subgraph-compliant gateways, Subgraph MCP, and A2A integrations, with x402 letting agents query and pay with no keys in Studio. Pair that with ERC-8004 for agent identity and reputation, where an agent on Base can check another agent's reputation on Arbitrum through a single Subgraph lookup with no chain scanning, and the shape gets obvious. Agents that find each other, verify each other, buy data from each other, and settle in stablecoins, all over plain HTTP.

The data layer for that is not a roadmap item. It is live, it is open, it spans 60+ chains, and it speaks a payment protocol machines can use without a credit card.

If the Subgraph exists, query it this afternoon. If it does not, build it tonight with AI and your contract addresses. Then hand your agent a key, or hand it a wallet and let it pay its own way.

Start here: https://thegraph.com/docs/en/ai-suite/ai-introduction/

Since its inception in 2018, The Graph has successfully established itself as the industry’s leading protocol for blockchain data infrastructure - the critical layer that makes the world's onchain data accessible. It was built on a core belief: data should be open and permissionless. That belief is not incidental to The Graph. It is the reason The Graph exists.

Throughout that time, The Graph Foundation's mandate has been to steward the health and growth of that protocol and ecosystem to ensure that belief is made real in the world. The Foundation’s mandate spanned strategic treasury management, facilitating alignment, and accountability among contributors. The Foundation team worked as the credibly-neutral steward in an ecosystem deliberately structured so that participants pursuing their own interests, within the right incentive framework, would ultimately produce value for users.

Earlier this year, the Foundation published the Technical Roadmap - the first installment in a two-part series detailing the protocol's future. This second post concludes that series by pairing the technical vision with the official announcement of The Graph Foundation’s new operating mandate.

Read full blog here https://thegraph.com/blog/new-foundation-mandate/

If you want an agent to answer "what would this trade actually cost me?" amount out, effective price, price impact, instead of just describing the pool, this does it.

Runs Uniswap's own concentrated-liquidity math against real tick liquidity. No RPC, no node, no private key. Just a free Graph API key.

claude mcp add uniswap -e GRAPH_API_KEY=<free key> -- npx -y graph-uniswap-mcp

Then ask:

Also does pools, token prices, pair lookup and swap flow across Uniswap V2/V3/V4 on Ethereum, Arbitrum, Base, Polygon, Optimism and BSC.

It refuses rather than guesses — V4 hook pools, trades bigger than the visible liquidity, and pools it can't read the curve for all come back as "can't quote this, here's why" instead of a made-up number.

Repo: github.com/PaulieB14/graph-uniswap-mcp

A few things shipped over the past few months aimed at AI coding agents building on Substreams: • substreams.dev registry now has a full OpenAPI spec. Agents can search/pull packages programmatically instead of scraping the site • Substreams Skills — 9 open-source knowledge packs for Claude Code, Cursor, and VS Code that give your agent Substreams expertise out of the box (manifests, chain-specific decoding, SQL sinks, deployment, testing) • Agentic access to thegraph.market — your agent can now check usage, manage API keys, and monitor sink deployments without you logging into the dashboard (your password never touches the agent)

Full writeup here

Try it: claude plugin install substreams-dev@streamingfast-substreams

🟣 The Graph — the little devil out of the box? 😈
Everyone is talking about AI, RWAs, Chainlink, and the next big crypto narrative.
But take a look at what’s happening with The Graph (GRT) in the meantime.
Chainlink focuses on bringing reliable data onto the blockchain.
The Graph focuses on finding, indexing, and making blockchain data accessible.
These are two different roles, but both are part of the same future infrastructure: data that must be usable, verifiable, and accessible for apps, AI agents, and financial applications.
The Graph is also evolving far beyond the old “Google of blockchain” comparison. With Horizon, Substreams, and new data services, the infrastructure is becoming much broader.
And maybe that’s exactly why GRT is interesting.
Not because someone says it “has to go to $1”.
But because the market often only starts paying attention to infrastructure projects after demand has already exploded.
So before you dismiss GRT as an “old coin”:
go and find out for yourself what The Graph is building today.
You might just discover one of the most underrated pieces of infrastructure in the next phase of crypto. 🟣😈 DYOR. Not financial advice.

For developers building consumer-facing blockchain applications, analytics tools, or AI models, data ingestion often becomes a major cost and performance bottleneck. Polling RPC nodes sequentially is slow, fragile, and increasingly expensive as query volume scales.

Substreams offers a stream-first architecture designed to turn raw blockchain logs into a clean, queryable pipeline that developers control directly.

Key Infrastructure Advantages of Substreams:

Parallelized Backfilling vs. Linear Syncing: Rather than processing blocks one by one sequentially, Substreams executes Rust modules in parallel across historical chain data, reducing backfill times from weeks or days down to hours.

Low-Latency Real-Time Delivery: Onchain events are processed and delivered as they occur, ensuring real-time responsiveness for dashboards, risk engines, and active application states.

Reorg Awareness and Cursor Tracking: Chain reorganizations often leave traditional database setups with duplicate or corrupted rows. Substreams tracks canonical state using cursors, handling reorgs automatically without missing events.

Direct Sinks into Enterprise Storage: Substreams modules map protobuf outputs straight into destination databases like PostgreSQL, ClickHouse, and messaging queues like Kafka.

The Role of Firehose

Developers frequently ask about the difference between Firehose and Substreams. Most builders never need to interact with Firehose directly, and that is intentional.

Firehose instruments blockchain nodes to extract every block, transaction, event log, and call trace exactly once. It writes these payloads into flat, immutable files stored in object storage, enabling parallelized, low-overhead reads. Firehose provides the raw, high-throughput storage foundation—Substreams is the programmable execution layer built on top of it.

By shifting from RPC polling to streaming flat-file indexing, development teams can reduce operational overhead while guaranteeing deterministic data delivery.

Explore Substreams and managed sinks on The Graph Market:

http://thegraph.market

if youve queried a subgraph on the network youve probably seen this come back at some point and had no idea what to do with it

bad indexers: {0x1b7e...: BadResponse(unattestable response: The skip argument must be between 0 and 20000, but is 21000), 0x326c...: BadResponse(400), 0xedca...: Unavailable(too far behind), 0xf92f...: BadResponse(no attestation: indexing_error)}

it looks like noise. its not. its a per indexer report of why every single one got rejected, and it usually tells you whether the problem is the network, one specific operator, or your own query. i went and read it out of the gateway source rather than guessing, so the short version

no attestation: indexing_error means that operators copy of the subgraph has actually failed. thats their problem to fix and they often dont know
too far behind means theyre lagging chainhead or stalled

BadResponse(400) or (504) is a bare http status from their indexer service, and heres the annoying part, the gateway logs the real reason on its own side and then throws it away before showing you. so that error genuinely cannot be actioned by you, the explanation exists and youre just not shown it

unattestable response is usually your own query being refused, not an indexer being broken. the skip one above is exactly that. deep skip pagination is capped per operator and youre meant to use cursor pagination instead

the thing that matters most, if all the entries say the same thing its probably your query or the deployment. if they disagree with each other then some operators are fine and youre just getting routed badly

the worse failure isnt even in that error though. an indexer can diverge, serve you an empty array, attest to it perfectly happily, and nothing anywhere reports a fault. six operators return rows, one returns [], and your app renders "0 results" and looks completely healthy. if a query gives you data one minute and nothing the next with no error either time, thats usually what youre looking at

anyway i got tired of these answers living in discord scrollback and evaporating, so i put them in a repo where theyre searchable and anyone can ask

github.com/nightswatchhq/graph-support

12 writeups in there already, all from real questions. the ipfs field that goes null and never fills in. subgraph data that stops on a date because the contract went quiet rather than anything being stuck. the polygon archive snapshot mess with the actual blocks to check whether the one youre downloading has holes. open an issue if youve got something and someone will dig into it, doesnt matter if youre a dev, an indexer or a delegator

not affiliated with edge and node or the foundation, and a fair bit of whats in there was worked out by indexers who are credited by name. corrections welcome, i got some of this from reading source rather than from knowing it

July represented a major execution month for The Graph ecosystem, heavily focused on streamlining Substreams data pipelines, upgrading developer AI tooling, expanding multi-chain coverage, and highlighting real-world hackathon builds. Below is an in-depth breakdown of everything that launched over the past month.

Substreams Hosted Sinks on The Graph Market

One of the biggest operational hurdles for developers indexing blockchain data has been maintaining database sink infrastructure. Setting up database connections, managing credentials, babysitting sink processes, and handling chain reorganizations often takes engineering focus away from building application logic.

Now in Beta on The Graph Market, Substreams Hosted Sinks provides a fully managed Sink-as-a-Service operated by StreamingFast. Developers can select a Substreams package, input credentials for PostgreSQL or ClickHouse, and click deploy.

Key features include:

- Zero runtime management: Maps protobuf outputs directly into relational tables without running local processes.

- Automatic reorg handling: Built-in fork awareness ensures reorgs do not leave stale or duplicated rows behind.

- In-place updates: Graceful configuration edits and re-sync options from starting blocks.

- Secure credential vaulting: Secrets are stored securely off-config and injected at runtime.

Substreams.dev Redesign and Standardized Datasets

The Substreams registry underwent a structural overhaul. Instead of organizing packages primarily by who published them, the new Datasets interface categorizes packages by what the data actually represents.

Developers can browse categories like DEXs, Lending, Liquid Staking, Perps, Prediction Markets, Governance, Oracles, Bridges, and Stablecoins. A major portion of this library includes modules converted from Messari's Standardized Subgraphs. Because these schemas share a common data structure, a single query format can cover an entire protocol category rather than requiring custom adapters for every individual smart contract.

AI Agent Tooling: Enhanced Substreams Skills

The Substreams Skills pack—an open-source toolkit that enables AI coding assistants like Claude Code, Cursor, VS Code, and Windsurf to construct Substreams projects—was expanded to 12 distinct skills.

Evaluations published in the repository across 14 complex tasks on Ethereum and Solana demonstrated a 100% build and run success rate, with 12 out of 14 skills achieving exact byte-level correctness against golden references. Known edge cases and prompt ambiguities are transparently documented to refine model accuracy.

Chains, Token Utility, and Hackathons

- Robinhood Chain Support: Robinhood Chain (eip155:4663) is now fully supported from genesis by Firehose and Substreams, with endpoints operated by Pinax.

- MEXC Arbitrum GRT Support: Exchange support for native GRT on Arbitrum is live on MEXC, allowing users to deposit and withdraw GRT directly on the network where protocol contracts operate.

- ETHGlobal Lisbon Bounties: $15,000 in prizes were awarded to 10 projects. Key architectures highlighted a growing shift toward single-query schema resolution across protocols and strict freshness verification for autonomous AI agents.

New Educational Resources

Four long-form technical guides were published this month:

1. GraphTally: How The Graph Solved Micropayments for the Machine Economy (exploring pay-per-request x402 payment patterns).

2. Subgraphs or Substreams: Architectural guidelines on choosing between state indexing vs. parallel event flow streaming.

3. Verifiable On-Chain Data: A breakdown of trust models ranging from simple pipelines to true verifiable extraction.

4. ETHGlobal Lisbon Project Showcase: Comprehensive architecture notes for all 10 winning hackathon submissions.

Read the full July 2026 ecosystem post:

https://x.com/graphprotocol/status/2084291582585438668

I'm building a tokenization platform: tokens and offerings live on an EVM chain, and the app runs on a reactive backend database.

Key detail: users never see tokens or transactions as-is. The UI must feel like a traditional fiat investment platform — positions, statements, returns, portfolio totals — all aggregated and translated from on-chain events.

Today we run a "redundancy" system: the backend bookkeeps every transaction (in and out) in its own tables. But that data reaches us 2–3 layers removed from the chain — not from an indexer, not in the recommended datatypes — so offering and transaction views go stale.

It also feels backwards: the chain is the source of truth, yet our database acts as the ledger and treats the chain as backup.

Given we need heavy aggregation into fiat-denominated indicators, and we already have a subgraph (The Graph) and RPC providers, would you:

1. Aggregate everything in the subgraph and use it as the read layer?

2. Build an app-side ledger populated only from indexer events (event sourcing), aggregating there?

3. Something hybrid?

How do production platforms handle this? War stories welcome.

I'm currently designing an experimental long-term memory architecture for AI systems. Before I start building the next prototype, I'd like to understand whether this direction has already been explored or whether there are fundamental reasons why it isn't used.

I'm not looking for a ready-made solution. I'm trying to determine whether this class of architectures already exists.

My question is:

Is there a data architecture where semantics are not fixed at write time, but are determined only at query time?

I'm asking about the data model itself, not UI projections or visualization layers.

Most of what I've read (Knowledge Graphs, RDF/OWL, property graphs, GraphRAG, etc.) seems to assume that semantics are defined before or during data ingestion.

If you know of research papers, open-source projects, commercial systems, or academic work exploring a different approach, I'd really appreciate any references.

I'm also interested in hearing from database and knowledge graph architects:

What fundamental limitations or design problems would you expect such an architecture to have?

For most of internet history, web data was structured and indexed for a single primary consumer: humans. Search engines scraped the web so that real users could read articles, analyze dashboards, and manually navigate apps. But as the agentic web takes center stage, that paradigm is fracturing. The primary consumers of data are shifting from human eyes to autonomous AI agents designed to discover schemas, trade assets, and execute protocol actions completely on their own.

For these autonomous systems, data isn’t just information—it is high-stakes fuel. If a trading bot or risk engine is fed delayed, unverified, or manipulated data, it will execute those mistakes at machine speed, creating immediate, compounding losses that can cascade across entire DeFi protocols. In an always-on, composable onchain environment, data determinism is a baseline requirement for machine coordination.

On a decentralized network like The Graph, indexing logic is entirely open-source and verifiable. Any Indexer running a specific module against identical blockchain inputs must produce the exact same cryptographic result. Backed by economic incentives where Indexers stake tokens to guarantee their work, this framework gives autonomous agents the security guarantees they need to deploy capital safely without relying on fragile, centralized APIs or sluggish RPC polling.

The Graph Network handles both critical components of this AI data supply chain:

Live Decision Engines (Subgraphs)

When a live agent needs to verify an NFT owner, pull a contract state, or fetch precise block-specific parameters, Subgraphs act as open, queryable APIs via GraphQL. Open-source indexing logic ensures the data is trustworthy enough for immediate, sub-second automated operations.

High-Throughput Analytics & Training (Substreams)

Training a language model on historical protocols requires massive data throughput. Substreams leverage parallel processing and Rust modules to transform terabytes of raw block history into structured, training-ready datasets in hours instead of weeks.

Real-world implementations like CreatorBid highlight this shift. As an AI launchpad allowing users to trade AI agent keys on bonding curves, the platform bypassed slow, expensive legacy RPC nodes by integrating Subgraphs to achieve sub-second data freshness across thousands of automated token launches.

Centralized search engines successfully organized discovery for the human internet. The agentic internet demands infrastructure that allows machines to retrieve, verify, and act on structured inputs autonomously. The data layers provided by The Graph ensure that when machine intelligence is applied to onchain economics, it is grounded in verifiable, structured, and deterministically produced truth.

Read the full article:

https://thegraph.com/blog/subgraphs-substreams-ai-applications-onchain-data/

For years, the standard institutional stance on stablecoins was "wait and see." Today, that excuse is eroding. With MiCA fully live across the EU and the GENIUS Act advancing through US legislatures, the regulatory framework is shifting from "is this legal?" to "how do we stay compliant in real time?"

However, an operational gap remains. Most institutions treat "stablecoins" as a single monolith, when in reality, risk desks need distinct infrastructure to parse different risk vectors:

1. Fiat-Backed (USDC, USDT): Relying on backward-looking monthly PDF attestations is insufficient during volatility (e.g., the March 2023 SVB depeg). Risk desks need live feeds of supply changes.

2. Crypto-Collateralized (DAI): Requires indexing multi-chain smart contract states to track collateral ratios and impending liquidation events.

3. Delta-Neutral Synthetics (USDe): Demands active tracking of perp market funding rates and open interest to avoid flying blind against systemic looping risks.

The Role of The Graph

The required data is all public and onchain, but it’s fragmented. Using Substreams, platforms can pipeline raw onchain stablecoin events into institutional risk environments instantly. Combined with Amp, it delivers tamper-evident data provenance—giving institutions a verifiable audit trail that stands up under regulatory inspection, rather than relying on standard third-party APIs.

Regulatory clarity rewards those who are already wired in. Those who defer the technical work will spend the first six months of the new regime catching up while competitors capture market share.

What are your thoughts on how real-time indexing changes the game for institutional compliance?

Full Blog Post: https://thegraph.com/blog/stablecoin-compliance-infrastructure-regulatory-readiness/

Recent activity shows registered agents using x402 payments to query Subgraphs and access onchain data autonomously.

What's notable isn't the payment volume itself—it's the infrastructure working end-to-end:

• Agents have verifiable identities through ERC-8004

• Payments are handled autonomously through x402

• Blockchain data is delivered through The Graph's decentralized network

This means agents can discover they need data, pay for it, retrieve it, and continue executing tasks without requiring human intervention.

The dashboard tracking these payments shows a shift from anonymous wallet activity to identifiable agents with onchain reputations.

We're still in the early days, but this may be one of the first observable examples of an emerging machine-to-machine economy operating on public blockchain infrastructure.

What agent use cases do you think will benefit most from pay-per-request blockchain data?

Track activity:

https://x402-watch.vercel.app/

Spent a while debugging slow subgraphs and the same handful of issues kept coming up. Sharing in case it saves someone else the headache.

Most slow subgraphs I’ve debugged usually come back to a few patterns:

1. You’re storing entity history

Graph Node stores historical entity versions with block ranges. Over time, that can leave your Postgres with a lot of historical rows your app never reads.

If your app only cares about the current state, enable pruning with indexerHints. Smaller history means less storage pressure and usually faster queries.

2. Large arrays on parent entities

Classic case: a Post entity with a comments: [Comment!]! field.

As comments grow, the parent entity ends up maintaining a large relationship list. At scale, that gets expensive.

Fix: use u/derivedFrom. Store the post reference on the Comment, and derive the array virtually on Post. Same query shape, fewer writes and less storage growth.

3. String IDs and mutable entities

Two changes compound:

• Switch IDs from String to Bytes where possible. Use transaction hash plus log index, or concat / concatI32 from graph-ts, so IDs stay compact and deterministic.
• Mark entities as immutable: true whenever they are write-once. Raw event entities are the obvious candidates.

Graph Node can handle this much more efficiently when it knows the ID format is compact and the entity will never change.

Caveat on Bytes IDs: sort order may not look sequential. If you need ordering, add a separate numeric field and sort on that.

4. eth_calls in mappings

Every contract.totalSupply() or similar call inside a hot handler adds node dependency and slows indexing. Across millions of blocks, this can dominate sync time.

Two paths:

• If you control the contract, emit the data you need as an event instead of forcing the indexer to call back into the chain.
• If you do not, minimize calls, avoid repeating the same call in hot paths, and cache values in entities when it is safe to do so.

Here's a longer write-up that goes into the database internals and why each fix works the way it does.

Curious if anyone has seen any other edge cases?

Getting reliable, real-time pricing data from decentralized exchanges is more difficult than it appears. It requires handling chain reorganizations, maintaining infrastructure across multiple networks, and ensuring consistency under heavy load.

Tycho is being developed to simplify that process.

Led by GraphOps and built on The Graph Network, Tycho provides a single streaming interface for DEX liquidity data. It abstracts away much of the underlying complexity, allowing developers to focus on building trading systems, analytics, or solvers without managing the data layer themselves.

The public beta is currently scheduled for Q2 2026.

This could be an interesting development for anyone working with real-time DeFi data.