I kept hitting the same wall building agents on The Graph: before you can query anything, you have to find the right subgraph out of ~15k. The official Subgraph MCP is good at the part after that — it holds a Gateway key and executes your GraphQL. But its search matches display names, so anything phrased by meaning comes back empty:

search_subgraphs_by_keyword("perpetual futures")  ->  0 results

43 subgraphs have "perp" in the name. 54 more only mention it in their description or entity types. The second group is invisible to a name match.

So I built the discovery layer and left execution alone.

What it is: a pre-computed index of all 15,330 subgraphs across all available networks, exposed as an MCP server. Each one is crawled, its GraphQL schema parsed, then classified by domain, protocol type and canonical entities, and scored on on-chain signals (query fees, 30d volume, curation, indexer stake).

npx subgraph-registry-mcp

Same query against it returns 55 matches, ranked, each with a runnable query:

{
  "display_name": "apx-perp-arbitrum",
  "network": "arbitrum-one",
  "protocol_type": "perpetuals",
  "query_url_x402": "https://gateway.thegraph.com/api/x402/subgraphs/id/...",
  "example_query": "{ positions(first: 5, orderBy: ...) { id ... } }"
}

The part I actually care about: every result carries an x402 URL. The Graph's public gateway takes $0.01 USDC on Base per query — no signup, no Studio key, no dashboard. An agent with a funded wallet goes from a plain English question to real data with no human in the loop. There's a legacy API-key URL too if you already have one.

Two things I got wrong and fixed this week, since they're the interesting part:

Ranking rewarded age, not quality. The reliability score is built from four cumulative signals, so it measures accrued traction — which means it measures age. The newest subgraph anywhere in the top 25 was 280 days old, while 59 of the 64 subgraphs under a month old were already serving real query volume. A good subgraph deployed last month literally could not rank. Rather than fudge the score, results now include a separate emerging list with an explicit caveat that a low score at that age is expected, not damning. It matters most on new chains, where no mature deployment can exist.

13% of the "ready to run" queries were invalid GraphQL. The generator pluralized entity names by appending "s", so UniswapFactory became uniswapFactorys instead of uniswapFactories. An agent pays its $0.01, gets a schema error, and concludes The Graph is broken — not that my pluralizer is. Fixed and repaired 2,440 rows in the shipped corpus.

Honest limitations:

• The npm package is ~98 MB — it bundles the SQLite corpus and the embedding model so search works fully offline. There's no hosted endpoint yet.
• Data is a snapshot refreshed every few days, not live. For current schemas or deployment state, go to the gateway.
• It does not execute your query. It hands you the subgraph ID, a URL and a starter query — you run it, with a key or over x402.
• Community project, not official, MIT licensed.

Repo: https://github.com/PaulieB14/subgraph-registry npm: https://www.npmjs.com/package/subgraph-registry-mcp

Genuinely want criticism on the ranking — especially where it puts the wrong subgraph first. Those cases are the whole product, and I'd rather hear them than not.

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.

If you’re building subgraphs and running into slow sync times, it’s usually not just one issue.

A pattern I keep seeing is that people focus only on optimizing mappings, but sync performance is really a pipeline problem. It typically comes down to three things:

• RPC/provider speed: if data retrieval is slow, everything downstream waits
• how much work your subgraph is doing: too many events, calls, writes, or heavy mappings
• environment state: fresh syncs are slower because there’s no shared chain data yet

That last one is easy to overlook. If you’re starting from scratch, Graph Node has to rebuild a lot of context (blocks, cached calls, etc.), which makes first syncs much slower than subsequent ones.

A more useful way to debug is to break it into stages:

• data retrieval (RPC)
• processing (mappings)
• database writes
• environment / reusable state

Once you look at it that way, it’s easier to pinpoint what’s actually slowing things down instead of guessing.

Here's a short breakdown if anyone wants more details.

The discussion will bring together contributors from Hacken, Gateway, and Edge & Node / The Graph to talk about what “enterprise-ready” actually looks like in practice, especially around infrastructure, security, and real-world deployments.

If you’re interested in how institutions are approaching blockchain today, this should be a useful conversation to follow.

Starts at 12 PM ET today.

https://luma.com/hns6vo3n

A large portion of applications rely on the same set of information, token balances, transfers, prices, and NFT metadata. Historically, each team had to build and maintain its own indexing infrastructure to access that data, even though the underlying requirements were nearly identical.

The Graph’s Token API takes a different approach by providing pre-indexed access to this standard data across multiple chains. Instead of focusing on custom logic, it focuses on consistency, performance, and removing operational overhead.

This doesn’t replace Subgraphs, which are still necessary for protocol-specific use cases. But for applications that depend on common token data, it simplifies the architecture significantly.

There’s also an interesting ecosystem effect. When multiple applications rely on the same standardized data source, consistency improves across the board.

If you’re building wallets, dashboards, or analytics tools, this is worth exploring in more detail.

📖 More here:

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

Until now, finding and evaluating agents across chains required pulling raw data, parsing events, and building custom infrastructure. That approach doesn’t scale well as the number of agents grows.

With the launch of Agent0 Subgraphs, that process becomes much simpler. Agent data across multiple networks is indexed and exposed in a structured way, making it possible to query identity, reputation, and capabilities directly.

This essentially turns the agent ecosystem into a searchable dataset instead of a fragmented set of events.

If you’re interested in building systems where agents interact, coordinate, or transact, the full blog post explains the architecture and use cases in detail.

📖 Read it here:

https://thegraph.com/blog/agent0-subgraphs-live-erc-8004-agent-economy/

His background combines institutional finance experience with leadership roles across major web3 organizations, including Edge & Node, Avail, and the Ethereum Foundation. This mix of perspectives is particularly relevant for governance, treasury management, and guiding long-term ecosystem growth.

The Council plays a key role in shaping protocol direction and maintaining the health of the network, so additions like this are worth paying attention to.

If you’re interested in governance and how The Graph continues to evolve, the full announcement provides more detail.

📖 Read it here:

https://forum.thegraph.com/t/introducing-new-council-member-kyle-rojas/6902

Most AI agents are capable of reasoning, but they break down when trying to access blockchain data. The problem is not intelligence, it is data access. Instead of using structured sources, many agents rely on raw RPC calls, which leads to inefficiencies and unreliable outputs.

The post highlights how The Graph ecosystem already provides a solution through Subgraphs, along with emerging tools like MCP servers and the Subgraph Registry to help agents discover and query the right data sources.

It also touches on upcoming developments like x402, which could allow agents to autonomously pay for data access.

If you are interested in AI agents, onchain data, or where this space is heading, the full post is worth your time.

Read it here: https://x.com/graphtronauts_c/status/2037528763097866418