The agentic-onchain conversation in 2026 has settled into two camps. One says agents need a reconciled SQL warehouse to make sense of raw blockchain data. The other says agents need a programmable indexer that lets them act, not just analyse. Both are right about the diagnosis. Raw RPC is unworkable for an agent. The disagreement is about what replaces it.

This blog is the case for indexers, not warehouses. A SQL warehouse lets an agent ask questions. An indexing framework lets an agent build, deploy, and own new data pipelines mid-session. The first is a query tool, the second is infrastructure. Agents acting onchain need the second. HyperIndex ships it today.

Why Raw Blockchain Data Breaks Agents​

An agent reading from RPC directly hits four problems within minutes.

1. Reorgs. A recent block can be reorged. An agent that wrote a record based on an unfinalized block has to either lag the chain head (and miss real-time signals) or roll its own rollback logic (and get it wrong on the next edge case). Neither is acceptable for an agent running in a production environment.

2. Schema. RPC returns logs and transactions. It does not return entities, relationships, or aggregations. The agent has to assemble the schema in memory on every query. Cross-contract state, factory pattern instances, and anything time-windowed have to be rebuilt from scratch.

3. Throughput. An agent that wants to know the last 1,000 trades on a market has to issue 1,000 eth_getLogs calls or hand-tune a paginated request. A historical sweep across a year of activity can take hours to query from RPC.

4. Multichain. Most agents that matter operate across at least two chains. Each chain is a separate RPC, separate quirks, separate rate limits. The application code that joins those RPCs is exactly the indexing code an indexer would write for you.

The standard response to "raw RPC is unworkable for agents" is to put a SQL warehouse in front of it. That works for read-only analytical queries. It does not work for an agent that needs to spin up a new product on top of the data within a session.

What HyperIndex Provides Instead​

HyperIndex addresses all four problems by being a blockchain indexing framework rather than a query layer.

• Reorg safety at the framework level. Entity state history, automatic rollback, no reorg logic required in handlers. Learn more in Indexing and Reorgs.
• Structured GraphQL output. Entities, relationships, aggregations, time-windowed views, all queryable from one endpoint. Agents read GraphQL, not raw logs.
• HyperSync historical throughput. Up to 2,000x faster than RPC. The Polymarket reference indexer synced its first 4,000,000,000 events in 6 days and has indexed over 6,500,000,000 to date.
• Multichain in one config. 87+ have native HyperSync coverage, any EVM chain accessible via standard RPC, all in a single config.yaml.

That is the read side. The act side is what makes HyperIndex an agent's infrastructure, not just an agent's data layer.

The Three Things That Make It Programmable for Agents​

1. The Envio Docs MCP Server​

The docs MCP server exposes the entire Envio docs site as two MCP tools:

• docs_search for semantic search across the docs
• docs_fetch to retrieve a docs page by ID

Endpoint: https://docs.envio.dev/mcp. Transport: Streamable HTTP.

Setup is one command for Claude Code:

claude mcp add --transport http envio-docs https://docs.envio.dev/mcp

Cursor and VS Code use the JSON config form on the same page. Once added, every agent session in that workspace grounds its answers about HyperIndex in the live docs rather than stale training data.

This matters because agents writing indexer code typically hallucinate APIs that do not exist. The MCP server gives the agent a fresh source of truth on every request, so it cites real HyperIndex syntax instead of guessing.

2. Auto-Discovered Skills in .claude/skills/​

When a HyperIndex project is initialised, it scaffolds a .claude/skills/ directory pre-populated with skill definitions. Cursor, Claude Code, and Codex all auto-discover skills from this directory at session start. The descriptions load up front, full skill content loads on demand. Confirmed in the public Polymarket reference repo's CLAUDE.md:

Skills in .claude/skills/ are auto-discovered — descriptions load at startup, full content on demand.

HyperIndex projects scaffolded with v3 rc ship 14 skill definitions:

.claude/skills/
  indexer-blocks/
  indexer-configuration/
  indexer-external-calls/   # Effect API for fetch / RPC / async I/O
  indexer-factory/          # Dynamic contract registration
  indexer-filters/
  indexer-handlers/
  indexer-multichain/
  indexer-performance/
  indexer-schema/
  indexer-testing/          # Vitest patterns for handler tests
  indexer-traces/
  indexer-transactions/
  indexer-wildcard/
  migrate-from-subgraph/    # AssemblyScript-to-TypeScript conversion

The canonical skill set lives at github.com/enviodev/hyperindex/tree/main/packages/cli/templates/static/shared/.claude/skills and ships into every new HyperIndex project.

These skills encode the patterns that make a HyperIndex project work. A developer running Claude Code, Cursor, or Codex in a HyperIndex project does not need to teach the agent what HyperIndex is. The skills do that, scoped to the actual conventions the framework expects.

3. The envio-cloud CLI​

The envio-cloud CLI is the GitHub-native deploy surface for HyperIndex indexers running on Envio Cloud. The three core agent-facing commands are:

• envio-cloud login to authenticate via GitHub
• envio-cloud indexer add to register a new indexer
• envio-cloud deployment status to check sync state

Every command supports -o json for parseable output. Install with npm install -g envio-cloud.

The full CLI reference is in the docs.

The deploy model is GitHub-native. An agent commits the indexer code to a GitHub repo, pushes to the envio branch (the default deploy branch), and registers the indexer with envio-cloud indexer add. The Envio GitHub App handles deployments from there. No deploy button, no dashboard step.

The published agentic demo did exactly that for a wstETH indexer on Monad Mainnet. 400,000 events indexed in approximately 20 seconds. The agent reads the contract, scaffolds the project from the ERC20 template, configures config.yaml for Monad, runs codegen and a type check, pushes to GitHub, and registers the indexer. End to end, no human in the loop after the first prompt. Loom walkthrough. Live deployment.

That is the act in "programmable infrastructure for agents that need to act, not just query."

A Concrete Example: The Published wstETH-on-Monad Demo​

The agentic indexing blog documents the full end-to-end flow an agent ran from scaffold to live deployment. This is not a hypothetical. The live deployment and the Loom walkthrough are both public.

The commands the agent ran (from the published blog):

Step 1: Scaffold from the ERC20 template

pnpx envio@3.0.0-rc.0 init template -t erc20 -l typescript -d ./my-indexer --api-token ""

The --api-token "" makes the init non-interactive. No token is needed at scaffold time; auth is handled at deploy.

Step 2: Configure for the target chain

The agent edits config.yaml to target the wstETH contract on Monad Mainnet. From the published blog: chain ID 143, contract 0x10Aeaf63194db8d453d4D85a06E5eFE1dd0b5417, start_block: 0.

Then runs codegen and a type check:

pnpm codegen
pnpm tsc --noEmit

Step 3: Push to GitHub on the deploy branch

Envio Cloud deploys from the envio branch by default:

gh repo create wsteth-monad-indexer-demo --public
git init && git add . && git commit -m "init"
git push -u origin main
git checkout -b envio && git push -u origin envio

Step 4: Connect the Envio GitHub App to the repo

A one-time install at github.com/apps/envio-deployments. The app handles the actual deployment when commits land on the envio branch.

Step 5: Register and deploy

pnpx envio-cloud login
pnpx envio-cloud indexer add \
  --name wsteth-monad-indexer-demo \
  --repo wsteth-monad-indexer-demo \
  --description "wstETH ERC20 indexer on Monad" \
  --branch envio \
  --skip-repo-check \
  --yes

Step 6: Verify

pnpx envio-cloud indexer get wsteth-monad-indexer-demo {org}
pnpx envio-cloud deployment status wsteth-monad-indexer-demo <commit-hash> {org}

Once synced, the indexer is at https://envio.dev/app/{org}/{indexer-name}/{commit-hash}.

Result: 400,000 events indexed in ~20 seconds.

Every command above is taken directly from the published blog. Every flag exists. The flow is what this whole blog is arguing for, an agent that scaffolds, configures, deploys, and verifies an indexer end to end, with no human stepping in. The Polymarket reference indexer is the production-scale reference for what this stack produces at full scale. The wstETH demo is the documented one-prompt run.

Why This Beats a SQL Warehouse for Agentic Workflows​

A SQL warehouse fronted by an LLM is excellent for analysts. The agent reads a question, writes SQL, returns a number. The agent does not change the warehouse, does not deploy new ingestion, does not branch the schema.

An agent acting onchain needs the opposite. It needs to:

• Add a new contract to its data ingestion mid-session
• Branch the schema to add a new entity type for a workflow it is exploring
• Spin up a brand-new indexer for an opportunity it just discovered
• Deploy to a hosted runtime and stream results back

HyperIndex gives the agent that ability. The indexer is a project the agent owns, not a warehouse it queries. The same agent can have ten indexers running at any time, each tracking a different market. None of that is possible if the only interface is read-only SQL.

For analysts: SQL warehouses are the right tool. For agents acting on the data: an indexing framework is the right tool. Both can coexist. The case here is for the agent side, which is the side under-served by the current SQL-warehouse-plus-LLM consensus.

Get Started​

• HyperIndex Quickstart with AI
• Envio docs MCP server
• Agentic indexing case (400k events, 20s)
• envio-cloud CLI reference
• Polymarket production reference

Frequently Asked Questions​

Why do AI agents acting onchain need an indexer at all?​

Raw RPC has four problems for an agent: reorgs, no schema, low throughput, and per-chain quirks at multichain scale. An indexer addresses all four. HyperIndex addresses them at the framework level, with reorg-safe storage, structured GraphQL output, HyperSync throughput, and a single multichain config.

What is the Envio docs MCP server?​

A Model Context Protocol server at https://docs.envio.dev/mcp that exposes the Envio docs as two tools, docs_search and docs_fetch. Configured into Claude Code, Cursor, or VS Code with one setup command. Announcement blog: Introducing the Envio Docs MCP Server.

What skills ship with HyperIndex?​

HyperIndex projects scaffold a .claude/skills/ directory that auto-discovers for Cursor, Claude Code, and Codex. The canonical templates ship 14 skill definitions covering indexer-configuration, indexer-schema, indexer-handlers, indexer-factory (dynamic contracts), indexer-external-calls (Effect API), indexer-multichain, indexer-performance, indexer-blocks, indexer-transactions, indexer-traces, indexer-filters, indexer-wildcard, indexer-testing, and migrate-from-subgraph. The full list lives at the canonical skills directory.

How fast can an AI agent deploy a HyperIndex indexer?​

The agentic indexing blog documents a single-prompt flow that scaffolds, deploys, and runs an indexer covering 400,000 events on Monad in roughly 20 seconds.

Does the envio-cloud CLI support agent-driven deploys?​

Yes. The CLI surface includes envio-cloud login, envio-cloud indexer add, envio-cloud deployment status, envio-cloud deployment metrics, envio-cloud deployment promote, with -o json on any command for parseable output. Deployments are GitHub-native: an agent commits to the envio branch and the registered indexer deploys automatically.

How does HyperIndex differ from a SQL warehouse for agents?​

A SQL warehouse is a read-only query layer. HyperIndex is a programmable indexer the agent can own, branch, and deploy. Both have a place. SQL warehouses suit analytical workflows. Indexers suit agents that need to act, not just query.

What chains does HyperIndex support for AI agents?​

Any EVM chain. 87+ have native HyperSync coverage for maximum speed. Any EVM chain without native HyperSync is accessible via standard RPC.

How does HyperIndex handle reorgs for agents?​

At the framework level. Entity state history is persisted for unfinalized blocks. The framework rolls back automatically on reorg. No handler code is required.

Build With Envio​

Envio is the fastest independently benchmarked EVM blockchain indexer for querying real-time and historical data. If you are building onchain and need indexing that keeps up with your chain, check out the docs, run the benchmarks yourself, and come talk to us about your data needs.

Stay tuned for more updates by subscribing to our newsletter, following us on X, or hopping into our Discord.

Subscribe to our newsletter

Website | X | Discord | Telegram | GitHub | YouTube | Reddit

This is a practical, end-to-end walkthrough of building a HyperIndex indexer with Claude as a pair programmer. Every command is from the published Envio docs. Every code shape is taken directly from the public Polymarket reference indexer. The aim is to show the shortest reliable path from a blank project to a deployed multichain indexer that an engineer (or an agent) can actually run today.

What You're Building​

A multichain HyperIndex indexer that tracks ERC20 transfers across two chains (Ethereum and Base) and exposes the data through a GraphQL endpoint. Two contracts, one schema, one config, deployed to Envio Cloud and queryable in roughly 30 minutes if you are reading along, or roughly 5 minutes if Claude is driving.

The structure of the project will be three files plus generated TypeScript:

my-erc20-indexer/
  config.yaml          # Networks, contracts, events
  schema.graphql       # Entity model
  src/EventHandlers.ts # The handler logic

Source for the three-file structure: docs.envio.dev/docs/HyperIndex/quickstart-with-ai.

Step 0: Wire Up Claude​

Once. Then never again. The Envio docs MCP server exposes the live docs to any MCP-capable agent. From the docs MCP server reference, the setup commands are:

For Claude Code:

claude mcp add --transport http envio-docs https://docs.envio.dev/mcp

For Cursor or VS Code, drop this into the MCP config:

{
  "mcpServers": {
    "envio-docs": {
      "url": "https://docs.envio.dev/mcp",
      "transport": "http"
    }
  }
}

After this, Claude has two tools available in any session: docs_search (semantic search) and docs_fetch (retrieve a page). The agent uses these instead of guessing at API surface from training data.

Step 1: Scaffold the Project​

Use the template flow to scaffold an ERC20 indexer in one non-interactive command.

pnpx envio@3.0.0-rc.0 init template -t erc20 -l typescript -d ./my-indexer --api-token ""

This pulls the current HyperIndex v3 release candidate, which ships with the V3 testing framework, the built-in .claude/skills/ directory, and the current CLI flags. The current release is tracked at github.com/enviodev/hyperindex/releases.

The --api-token "" flag tells the init to run non-interactively, with no prompt for an Etherscan-style API token. If an agent is driving, every interactive prompt is a failure mode.

The init produces the three files plus a package.json, tsconfig.json, an AGENTS.md and CLAUDE.md documenting the conventions, and an auto-discovered .claude/skills/ directory. Every project scaffolded with v3 rc ships these skills out of the box, encoding the indexing patterns Claude needs to write idiomatic HyperIndex code without improvising.

Step 2: Make It Multichain​

The init scaffolds for one chain. Adding a second is a config edit, not a fresh project. Open config.yaml and add a second chain entry. The shape mirrors the public Polymarket config. HyperIndex uses two-tier declaration. Top-level contracts: for global event signatures, then a chains: array for per-chain addresses and start blocks.

# Pattern from: https://github.com/enviodev/polymarket-indexer/blob/main/config.yaml
# yaml-language-server: $schema=./node_modules/envio/evm.schema.json
name: erc20-multichain

contracts:
  - name: USDC
    events:
      - event: "Transfer(address indexed from, address indexed to, uint256 value)"

field_selection:
  transaction_fields:
    - hash
    - from
    - to

chains:
  - id: 1
    start_block: 17000000
    contracts:
      - name: USDC
        address: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"
  - id: 8453
    start_block: 2000000
    contracts:
      - name: USDC
        address: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"

Three things to call out:

• chains: is the keyword, not networks:. Per the AGENTS.md generated into every HyperIndex project: "Uses chains (not networks)." If your editor or an AI agent suggests networks:, the schema validation will fail.
• The handler: field is optional. Handlers auto-register from src/handlers/. Same AGENTS.md.
• field_selection controls which transaction fields HyperSync ships down. Asking for fewer fields is faster and uses less memory.

For the current set of supported config options including per-contract start_block and environment variable interpolation, the full configuration reference lives in the docs.

Step 3: The Schema​

Edit schema.graphql to model entities the application will query. The shape uses a chainId-first pattern (per-chain entities plus aggregated entities) for clean cross-chain queries:

# Pattern from: https://github.com/enviodev/polymarket-indexer/blob/main/schema.graphql
type Transfer
  @index(fields: ["from", ["timestamp", "DESC"]])
  @index(fields: ["to", ["timestamp", "DESC"]])
{
  id: ID!
  from: String! @index
  to: String! @index
  value: BigInt!
  chainId: Int!
  blockNumber: Int!
  timestamp: Int!
}

type AccountBalance {
  id: ID!
  account: String! @index
  chainId: Int!
  balance: BigInt!
  lastUpdated: Int!
}

type AggregateBalance {
  id: ID!
  account: String! @index
  totalAcrossChains: BigInt!
  lastUpdated: Int!
}

Two HyperIndex-specific things worth noting in this schema:

• No @entity decorator. From the project's AGENTS.md: "Unlike TheGraph, schema types have no decorators." Subgraphs put @entity on every type. HyperIndex does not.
• @index is composable. The Polymarket schema uses both per-field @index and per-type composite indexes like @index(fields: ["from", ["timestamp", "DESC"]]) to drive the queries the application needs.

Transfer carries every transfer event with chainId first-class. AccountBalance is per-chain. AggregateBalance is the cross-chain rollup. The same indexer writes to all three.

After editing the schema, run pnpm codegen to regenerate the typed bindings. The project's AGENTS.md is explicit that codegen is required after any schema or config change. Types go stale otherwise.

Step 4: The Handler​

In v3 rc, types come from the envio package directly. The handler imports indexer plus any entity types it needs, then registers handlers as indexer.onEvent({ contract: "CONTRACT_NAME", event: "EVENT_NAME" }, handler).

import {
  indexer,
  type Transfer,
  type AccountBalance,
  type AggregateBalance,
} from "envio";

indexer.onEvent(
  { contract: "USDC", event: "Transfer" },
  async ({ event, context }) => {
    const transferId = `${event.chainId}_${event.block.number}_${event.logIndex}`;

    const transfer: Transfer = {
      id: transferId,
      from: event.params.from,
      to: event.params.to,
      value: event.params.value,
      chainId: event.chainId,
      blockNumber: event.block.number,
      timestamp: event.block.timestamp,
    };
    context.Transfer.set(transfer);

    const fromKey = `${event.chainId}_${event.params.from}`;
    const toKey = `${event.chainId}_${event.params.to}`;

    const fromBal: AccountBalance = (await context.AccountBalance.get(fromKey)) ?? {
      id: fromKey,
      account: event.params.from,
      chainId: event.chainId,
      balance: 0n,
      lastUpdated: event.block.timestamp,
    };
    context.AccountBalance.set({
      ...fromBal,
      balance: fromBal.balance - event.params.value,
      lastUpdated: event.block.timestamp,
    });

    const toBal: AccountBalance = (await context.AccountBalance.get(toKey)) ?? {
      id: toKey,
      account: event.params.to,
      chainId: event.chainId,
      balance: 0n,
      lastUpdated: event.block.timestamp,
    };
    context.AccountBalance.set({
      ...toBal,
      balance: toBal.balance + event.params.value,
      lastUpdated: event.block.timestamp,
    });

    const fromAgg: AggregateBalance = (await context.AggregateBalance.get(event.params.from)) ?? {
      id: event.params.from,
      account: event.params.from,
      totalAcrossChains: 0n,
      lastUpdated: event.block.timestamp,
    };
    context.AggregateBalance.set({
      ...fromAgg,
      totalAcrossChains: fromAgg.totalAcrossChains - event.params.value,
      lastUpdated: event.block.timestamp,
    });

    const toAgg: AggregateBalance = (await context.AggregateBalance.get(event.params.to)) ?? {
      id: event.params.to,
      account: event.params.to,
      totalAcrossChains: 0n,
      lastUpdated: event.block.timestamp,
    };
    context.AggregateBalance.set({
      ...toAgg,
      totalAcrossChains: toAgg.totalAcrossChains + event.params.value,
      lastUpdated: event.block.timestamp,
    });
  },
);

Three project-enforced conventions visible in this snippet, all spelled out in the AGENTS.md generated into every HyperIndex project:

• Spread operator for updates. Entities returned by context.Entity.get() are read-only. Always spread: context.Entity.set({ ...existing, field: newValue }). Direct mutation throws.
• Composite IDs for cross-chain uniqueness. ${event.chainId}_${event.block.number}_${event.logIndex} is the Polymarket pattern. Without chainId in the ID, two chains writing the same (block, logIndex) collide.
• Effect API for any external call. If the handler needs to fetch Gamma metadata, call an RPC, or hit any other async I/O, use createEffect plus context.effect(). Never call external services directly. The Polymarket TokenRegistered handler shows the pattern with context.effect(getMarketMetadata, token0Str).

This is the structure an agent with the indexer-handlers and indexer-external-calls skills produces when asked to "write the Transfer handler that updates per-chain and aggregate balances." The skills encode these conventions so the agent does not improvise them wrongly.

Step 5: Run It Locally​

pnpm install
pnpm codegen          # regenerate types from schema + config
pnpm tsc --noEmit     # type-check without emitting
TUI_OFF=true pnpm dev # run indexer (TUI_OFF gives AI-friendly stdout)

Source for these exact commands: polymarket-indexer/AGENTS.md.

The local dev environment spins up a Postgres and a Hasura GraphQL instance. The indexer starts pulling events from both chains via HyperSync. Sync rates of 25,000 events per second on historical backfill are standard. The Polymarket case study documents 4,000,000,000 events synced in 6 days on Polygon; the indexer has since indexed over 6,500,000,000 in total.

The Hasura GraphQL endpoint is available locally. Once the indexer is at chain head, queries like:

query AggregateBalanceForAccount {
  AggregateBalance(where: { account: { _eq: "0xabc..." } }) {
    account
    totalAcrossChains
    lastUpdated
  }
}

return live data.

Step 6: Deploy to Envio Cloud​

Envio Cloud uses a GitHub-native deploy model. An agent commits the indexer to a GitHub repo, pushes to the envio branch (the default deploy branch), and registers the indexer with envio-cloud indexer add. The Envio GitHub App handles deployments from there. No deploy button, no dashboard step.

Install the CLI and authenticate:

npm install -g envio-cloud
envio-cloud login

Push the project to GitHub on the envio branch:

gh repo create my-erc20-indexer --public
git init && git add . && git commit -m "init"
git push -u origin main
git checkout -b envio && git push -u origin envio

Connect the Envio GitHub App to the repo (one-time install at github.com/apps/envio-deployments), then register the indexer:

envio-cloud indexer add \
  --name my-erc20-indexer \
  --repo my-erc20-indexer \
  --description "Multichain ERC20 indexer" \
  --branch envio \
  --skip-repo-check \
  --yes

The verified CLI surface (from the agentic indexing blog) includes:

• envio-cloud login authenticates via GitHub
• envio-cloud indexer add registers a new indexer pointing at a GitHub repo and branch
• envio-cloud indexer get fetches indexer details
• envio-cloud deployment status returns the current sync state of a deployment
• envio-cloud deployment metrics returns runtime metrics
• envio-cloud deployment promote promotes a deployment to production
• -o json on any command for parseable output

Track sync progress with envio-cloud deployment status and envio-cloud deployment metrics. Full reference at docs.envio.dev/docs/HyperIndex/envio-cloud-cli.

Step 7: Test It​

pnpm test runs the project's Vitest suite. In v3 rc, tests import createTestIndexer and TestHelpers from the envio package directly, so tests use the same types as handlers. The indexer-testing skill in .claude/skills/ encodes the current API surface (mock event factories, test indexer setup, assertion patterns) and the testing reference docs cover it end to end.

What the Stack Looks Like End to End​

[Claude Code or Cursor]
         |
         | (reads docs via MCP server, applies built-in Claude skills)
         v
[HyperIndex Project (config.yaml + schema.graphql + handlers)]
         |
         | (pnpm dev locally, or push to GitHub envio branch)
         v
[HyperIndex Runtime + HyperSync]
         |
         | (live indexes EVM chains natively, any EVM via RPC)
         v
[Postgres + Hasura GraphQL endpoint]
         |
         | (queried by application, dashboard, agent, or downstream service)
         v
[Your AI-Powered Onchain App]

Each layer is a piece you have full control over. None of them require black-box assumptions about how an indexer behaves under reorgs, source outages, or scale. The reliability blog covers what HyperIndex provides at the framework level.

Get Started​

• HyperIndex Quickstart with AI
• Envio docs MCP server
• envio-cloud CLI reference
• config.yaml reference
• Testing docs (V3 framework)
• Polymarket production reference
• Companion: AI-assisted subgraph migration

Frequently Asked Questions​

What does an AI-powered onchain app stack look like?​

The stack is: Claude Code (or another MCP-aware editor) as the development surface, a HyperIndex project with an auto-discovered .claude/skills/ directory shipped by v3 rc, the HyperIndex runtime with HyperSync as the data engine, Postgres plus Hasura for GraphQL, and the application or agent on top. Every layer is real and shipping today.

How do I deploy a HyperIndex indexer programmatically?​

Install the envio-cloud CLI with npm install -g envio-cloud and authenticate with envio-cloud login. Push the indexer code to a GitHub repo on the envio branch, connect the Envio GitHub App to the repo, then register with envio-cloud indexer add. Track sync state with envio-cloud deployment status and envio-cloud deployment metrics. Every command supports -o json for parseable output. Full reference at docs.envio.dev/docs/HyperIndex/envio-cloud-cli.

Can I add a chain to a HyperIndex indexer without redeploying?​

Adding a chain requires a config change and a redeploy because the indexer needs to start a new HyperSync stream. The redeploy itself is one CLI command. Adding a contract on an existing chain that uses the factory pattern can be done dynamically without a redeploy. See the indexer-factory skill in the project.

How does HyperIndex compare to subgraphs for an AI workflow?​

Subgraphs use AssemblyScript handlers, single-chain config per subgraph, and matchstick for testing. HyperIndex uses TypeScript handlers, multichain config in one file, and Vitest for testing. The TypeScript surface is what makes Claude's involvement straightforward. The migration story is covered in AI-assisted subgraph migration.

What are the built-in HyperIndex skills?​

HyperIndex projects scaffolded with v3 rc ship a .claude/skills/ directory pre-populated with 14 skills covering the core indexing patterns: indexer-configuration, indexer-schema, indexer-handlers, indexer-factory, indexer-multichain, indexer-external-calls, indexer-performance, indexer-testing, indexer-blocks, indexer-filters, indexer-traces, indexer-transactions, indexer-wildcard, and migrate-from-subgraph. Claude Code auto-discovers them at session start.

Is HyperIndex faster than other indexers in benchmarks?​

In Sentio's independent Uniswap V2 Factory benchmark, HyperIndex completed in 8 seconds, 142x faster than The Graph and 15x faster than the nearest competitor.

What chains are supported?​

Any EVM chain. 87+ have native HyperSync coverage for maximum speed. Any EVM chain without native HyperSync is accessible via standard RPC. The current chain count is published on envio.dev.

Where can I see a public production reference?​

The Polymarket reference indexer. Synced its first 4,000,000,000 events from block 3,764,531 in 6 days, replacing 8 separate subgraphs, and has indexed over 6,500,000,000 to date. Live at envio.dev/app/moose-code/polymarket-indexer/7cad3ad.

Build With Envio​

Envio is the fastest independently benchmarked EVM blockchain indexer for querying real-time and historical data. If you are building onchain and need indexing that keeps up with your chain, check out the docs, run the benchmarks yourself, and come talk to us about your data needs.

Stay tuned for more updates by subscribing to our newsletter, following us on X, or hopping into our Discord.

Subscribe to our newsletter

Website | X | Discord | Telegram | GitHub | YouTube | Reddit

The hardest part of migrating off The Graph to HyperIndex has always been the AssemblyScript rewrite. Subgraphs run handler code in WebAssembly, which means handlers are written in AssemblyScript, a stricter subset of TypeScript with its own constraints, its own tooling, and its own foot-guns. Teams who otherwise live in TypeScript every day end up maintaining one codebase in a language they touch only when their indexer breaks.

The HyperIndex reference indexer for Polymarket demonstrates the consolidation pattern at scale, 8 subgraphs' worth of logic rewritten as a single TypeScript indexer. The full reference is public on GitHub and is documented in our Polymarket case study.

This blog is about how you can leverage Claude (or any coding agent) to migrate your subgraphs to HyperIndex. The agent does the AssemblyScript-to-TypeScript rewrite; a developer reviews the diff, runs the tests, and ships the indexer.

What HyperIndex Is and Why the Migration Story Changed​

HyperIndex is Envio's multichain blockchain indexing framework for EVM chains. HyperIndex handlers are written in regular TypeScript. Unlike AssemblyScript, which restricts which npm packages handlers can use, HyperIndex lets you bring in any npm package you want. Since handlers are TypeScript, there is no WebAssembly compilation step and no AssemblyScript-specific syntax to learn, you write handlers in the language you already use every day.

Two things changed in the last six months that turned subgraph migration into a tractable AI-assisted workflow:

1. The HyperIndex docs MCP server went live, exposing the entire docs site as two tools (docs_search and docs_fetch) over Streamable HTTP at https://docs.envio.dev/mcp. Any IDE or assistant that speaks MCP, including Claude Code, Cursor, Codex, and VS Code, can now ground answers about HyperIndex in the live docs rather than stale training data.
2. HyperIndex projects ship a .claude/skills/ directory that auto-discovers for Cursor, Claude Code, and Codex. The Polymarket reference repo's directory currently ships 14 skills, including a dedicated migrate-from-subgraph skill purpose-built for this workflow, plus indexer-configuration, indexer-schema, indexer-handlers, indexer-factory (dynamic contracts), indexer-external-calls (the Effect API), indexer-multichain, indexer-performance, indexer-testing, indexer-blocks, indexer-filters, indexer-traces, indexer-transactions, and indexer-wildcard. The full list lives at the canonical skills directory.

Combined, these mean a developer can hand the agent a subgraph repo and a working HyperIndex project shell and ask for a migration. The agent has live docs, a project-resident migration skill, and its own validation tooling.

The Polymarket case study is the production reference for what the end state looks like. The rest of this post walks the AI-assisted version of that same migration on a smaller surface area, anchored to real artifacts in the Polymarket repo.

The Four Files Claude Needs to See​

Every subgraph has the same four primary inputs. Claude reads them in this order.

my-subgraph/
  subgraph.yaml          # contracts, networks, event handlers, start blocks
  schema.graphql         # entity types and relations
  src/mappings/*.ts      # AssemblyScript handler logic (despite the .ts extension)
  abis/*.json            # contract ABIs the handlers parse logs against

subgraph.yaml carries the network, the contract addresses, the start blocks, and the event-to-handler mapping. schema.graphql carries the entity model. The mappings carry the actual logic. The ABIs carry the signatures for the events mappings parse.

HyperIndex needs the same four kinds of input, restructured. The Polymarket reference shows the target shape. From the canonical config.yaml (selected events shown for brevity):

# Source: https://github.com/enviodev/polymarket-indexer/blob/main/config.yaml
# yaml-language-server: $schema=./node_modules/envio/evm.schema.json
name: polymarket-indexer
description: Unified Polymarket HyperIndex

contracts:
  - name: Exchange
    abi_file_path: ./abis/Exchange.json
    events:
      - event: "OrderFilled(bytes32 indexed orderHash, address indexed maker, address indexed taker, uint256 makerAssetId, uint256 takerAssetId, uint256 makerAmountFilled, uint256 takerAmountFilled, uint256 fee)"
      - event: "OrdersMatched(...)"
      - event: "TokenRegistered(...)"
  - name: ConditionalTokens
    abi_file_path: ./abis/ConditionalTokens.json
    events:
      - event: "PositionSplit(...)"
      - event: "PositionsMerge(...)"
      - event: "PayoutRedemption(...)"

field_selection:
  transaction_fields:
    - hash
    - from
    - to

chains:
  - id: 137 # Polygon
    start_block: 3764531
    contracts:
      - name: Exchange
        address:
          - "0x4bFb41d5B3570DeFd03C39a9A4D8dE6Bd8B8982E"
          - "0xC5d563A36AE78145C45a50134d48A1215220f80a"
        start_block: 33605403
      - name: ConditionalTokens
        address: "0x4D97DCd97eC945f40cF65F87097ACe5EA0476045"
        start_block: 4023686

Three small differences from subgraph YAML to know up front: HyperIndex uses chains: (not networks:), declares contracts once at the top level with addresses supplied per-chain, and auto-registers handlers from src/handlers/<ContractName>.ts (subgraphs require explicit handler-to-event mapping).

This single file replaces what would otherwise be eight separate subgraph.yaml files. Every shared event (PositionSplit, PositionsMerge, PayoutRedemption) is declared once and routed to a single TypeScript handler that updates every relevant entity in one pass. That architectural detail, "handler merging," is the structural win of the consolidation pattern.

schema.graphql carries across with two specific rewrites. Subgraph schemas decorate every type with @entity. HyperIndex schemas have no decorators, per the AGENTS.md: "Unlike TheGraph, schema types have no decorators." Subgraph relations like @derivedFrom are kept; ID conventions stay; the type body is otherwise identical. The built-in indexer-schema skill knows the diffs and applies them.

Handlers are where the migration work happens. The Polymarket reference repo's Exchange.ts shows the canonical TypeScript shape and the conventions the migrate-from-subgraph skill applies (simplified for the post, helper functions inlined):

// Source: https://github.com/enviodev/polymarket-indexer/blob/main/src/handlers/Exchange.ts
import { Exchange, type Orderbook } from "generated";
import {
  parseOrderFilled,
  updateUserPositionWithBuy,
  updateUserPositionWithSell,
} from "../utils/pnl.js";
import { COLLATERAL_SCALE } from "../utils/constants.js";
import { scaleBigInt, ZERO_BD } from "../utils/fpmm.js";
import { getMarketMetadata } from "../effects/marketMetadata.js";

const TRADE_TYPE_BUY = "Buy";
const TRADE_TYPE_SELL = "Sell";

Exchange.OrderFilled.handler(async ({ event, context }) => {
  const side = event.params.makerAssetId === 0n ? TRADE_TYPE_BUY : TRADE_TYPE_SELL;
  const tokenId = side === TRADE_TYPE_BUY
    ? event.params.takerAssetId.toString()
    : event.params.makerAssetId.toString();

  // 1. Persist the OrderFilled event (chainId in ID prevents cross-chain collisions)
  context.OrderFilledEvent.set({
    id: `${event.chainId}_${event.block.number}_${event.logIndex}`,
    transactionHash: event.transaction.hash,
    timestamp: BigInt(event.block.timestamp),
    orderHash: event.params.orderHash,
    maker: event.params.maker,
    taker: event.params.taker,
    // ... rest of the event
  });

  // 2. Read-then-write Orderbook (spread mandatory, returned entities are read-only)
  const orderbook = (await context.Orderbook.get(tokenId)) ?? defaultOrderbook(tokenId);
  context.Orderbook.set({
    ...orderbook,
    tradesQuantity: orderbook.tradesQuantity + 1n,
    collateralVolume: orderbook.collateralVolume + size,
  });

  // 3. PnL update. Handler merged with what was previously a separate pnl subgraph
  const order = parseOrderFilled(event.params);
  if (order.side === "BUY") {
    await updateUserPositionWithBuy(context, order.account, order.positionId, price, order.baseAmount);
  } else {
    await updateUserPositionWithSell(context, order.account, order.positionId, price, order.baseAmount);
  }
});

The same handler file also processes OrdersMatched and TokenRegistered. The TokenRegistered handler fetches Polymarket Gamma API metadata via the Effect API:

// Same source file, TokenRegistered handler
const metadata = await context.effect(getMarketMetadata, token0Str);

createEffect plus context.effect() is the documented pattern for any external call (fetch, RPC, async I/O). From the project's AGENTS.md: "All fetch, RPC, or other async I/O must use createEffect + context.effect(). Never call external services directly in handlers."

The comparable AssemblyScript handler on The Graph would be split across three subgraph repos, each parsing the same OrderFilled log independently, each writing to its own subgraph database, with cross-domain joins happening at query time. Handler merging is the architectural reason the Polymarket reference consolidates 8 subgraphs into 1. It is also the thing that makes AssemblyScript handlers straightforward for an agent to translate: the event parsing is mechanical, the entity writes are explicit, and the conventions are documented in the project-resident skills.

How the AI-Assisted Migration Workflow Runs​

The flow assumes a developer with Claude Code or Cursor installed, the Envio docs MCP server configured, and the HyperIndex CLI on their machine. From the HyperIndex Quickstart with AI the MCP setup is one command for Claude Code:

claude mcp add --transport http envio-docs https://docs.envio.dev/mcp

Cursor or VS Code uses the JSON config form on the same page. Once added, every Claude session in that workspace can query the live docs.

Step 1: Scaffold a HyperIndex project from a template​

Scaffold a fresh HyperIndex project using the template flow. Pass --api-token "" so the init runs non-interactively when an agent is driving:

pnpx envio@3.0.0-rc.0 init template -t erc20 -l typescript -d ./my-indexer --api-token ""

This produces a working HyperIndex project shell with config.yaml, schema.graphql, handler stubs, an AGENTS.md, and the auto-discovered .claude/skills/ directory (including the migrate-from-subgraph skill). The current release is tracked at github.com/enviodev/hyperindex/releases.

Step 2: Hand Claude the AssemblyScript mappings​

You: I just initialised a HyperIndex project and the /XYZ folder has my subgraph
could you help me migrate that to my HyperIndex project. The generated
config.yaml and schema.graphql are in place. The original AssemblyScript
mappings are in ../old-subgraph/src/mappings/. Use the migrate-from-subgraph
skill to translate them into TypeScript handlers under src/handlers/. Apply the
project conventions in AGENTS.md: spread operator for entity updates, Effect
API for any external calls, entity_id fields for relationships. Flag anything
that uses nested entity loads or AssemblyScript-specific helpers so I can
review.

Claude opens the migration skill, walks the mapping files in dependency order, and produces TypeScript handlers under src/handlers/. Every entity load and write is explicit. Every BigInt operation uses native JavaScript BigInt rather than the AssemblyScript BigInt class. Imports come from the auto-generated types, not from @graphprotocol/graph-ts.

Step 3: Run the indexer locally and compare​

pnpm install
pnpm dev

The indexer comes up against a local Postgres and a Hasura GraphQL endpoint. The deployed subgraph endpoint and the local HyperIndex endpoint can be queried side by side for any entity at any block height. Claude knows how to write the comparison queries because the indexer-testing skill ships in the project.

Step 4: Ship to Envio Cloud​

Envio Cloud uses a GitHub-native deploy model. Push the indexer to a GitHub repo on the envio branch, connect the Envio GitHub App, and register the indexer with envio-cloud indexer add. The full flow from the agentic indexing blog:

npm install -g envio-cloud
envio-cloud login

# push the migrated indexer to the envio branch
git checkout -b envio && git push -u origin envio

# install the Envio GitHub App on the repo
# https://github.com/apps/envio-deployments/installations/select_target

# register the indexer
envio-cloud indexer add \
  --name my-migrated-indexer \
  --repo my-migrated-indexer \
  --description "Subgraph migrated to HyperIndex" \
  --branch envio \
  --skip-repo-check \
  --yes

# track sync state
envio-cloud deployment status my-migrated-indexer <commit-hash> {org}

Every command supports -o json for parseable output. The Polymarket reference indexer is live at envio.dev/app/moose-code/polymarket-indexer/7cad3ad. Full CLI reference at docs.envio.dev/docs/HyperIndex/envio-cloud-cli.

What the AI Catches and What It Doesn't​

After running this workflow on smaller subgraphs internally, here is the honest split.

Claude is reliably good at:

• Translating event parsing and entity writes (the bulk of any handler)
• Replacing AssemblyScript BigInt with native JS BigInt
• Replacing @graphprotocol/graph-ts imports with the HyperIndex generated types
• Stripping the @entity decorator from every schema type (HyperIndex schemas have no decorators per AGENTS.md)
• Applying the spread operator pattern on entity updates (mandatory in HyperIndex, returned entities are read-only)
• Wrapping any external call from a mapping in createEffect plus context.effect() (the Effect API)
• Generating the matching test cases against the Vitest framework HyperIndex ships with

Claude needs human review on:

• Cross-handler shared state. Subgraphs sometimes encode shared state in entity IDs in ways that look fine until two handlers race at the same block. Handler merging in HyperIndex usually fixes this, but the migration is the moment to redesign it consciously.

A migration that runs all four steps with Claude driving and a developer reviewing typically turns a multi-week AssemblyScript rewrite into a one or two day exercise. The Polymarket reference is the upper bound: 8 subgraphs' worth of logic, 50+ entities, four years of handler history. Smaller subgraphs are correspondingly faster.

Why Migrate at All: The Numbers​

The reason teams move off The Graph is performance and developer experience. From the public benchmarks:

Full benchmark comparison at docs.envio.dev/docs/HyperIndex/benchmarks.

Polymarket's full historical sync, 4,000,000,000 events on Polygon, completed in 6 days, and the indexer has since indexed over 6,500,000,000 events in total. The same workload on a single subgraph in the Polymarket setup would have been measured in months and would still leave eight separate APIs to query.

Speed is one half of the story. Developer experience is the other. TypeScript handlers, native npm package use, generated types, real test runners, multichain configuration in a single file, dynamic contract registration without redeployment. Once a team has been on HyperIndex for a sprint, the subgraph workflow stops feeling like a viable alternative.

Frequently Asked Questions​

How long does an AI-assisted subgraph migration to HyperIndex take?​

For a single-domain subgraph with one or two contracts, the AI-assisted workflow with Claude typically runs in a few hours. For a complex multi-domain setup at the scale of the Polymarket reference (8 subgraphs' worth of logic, 50+ entities, four years of handler history), the migration with Claude assistance runs in days, not weeks. The bulk of the time is human review, not generation.

Does HyperIndex support every subgraph schema directive?​

Most directives carry across. @derivedFrom and ID-based relations have direct HyperIndex equivalents. The biggest difference is decorators: HyperIndex schemas have no @entity decorator at all. Per the project's AGENTS.md: "Unlike TheGraph, schema types have no decorators." The indexer-schema skill knows the translations and the migrate-from-subgraph skill applies them. Anything without a direct equivalent gets flagged for manual handling.

Can I migrate an Alchemy subgraph the same way?​

Yes. Alchemy Subgraphs are technically subgraphs, and the same AI-assisted migration flow described in this blog applies, scaffold a HyperIndex project from a template, hand Claude the AssemblyScript mappings, validate locally, and ship.

What if my subgraph uses dynamic contracts (factory pattern)?​

HyperIndex supports dynamic contract registration as a first-class feature. Polymarket uses it for FPMM pools created by FPMMFactory. The indexer-factory skill in .claude/skills/ handles the translation. See the Polymarket reference handler at github.com/enviodev/polymarket-indexer/blob/main/src/handlers/FPMMFactory.ts.

How do I validate that the migrated indexer matches the original subgraph?​

Run both endpoints side by side and query the same entity at the same block. The indexer-testing skill in .claude/skills/ generates the comparison queries. For production migrations, Envio also provides a CLI validation tool that diffs entity state across both endpoints over a block range. The Polymarket reference repo is the public production example to compare your migrated output against.

Does the AI workflow work without Claude?​

Yes. Skills in .claude/skills/ auto-discover for Cursor, Claude Code, and Codex per the project's CLAUDE.md. The docs MCP server is MCP-standard so any MCP-capable agent works. The setup commands on the Quickstart with AI page cover Claude Code, Cursor, and VS Code explicitly.

What does HyperIndex do that subgraphs do not?​

Single multichain config (subgraphs are single-chain). Native TypeScript handlers (subgraphs require AssemblyScript). 142x faster sync on the Sentio Uniswap V2 Factory benchmark. Framework-level reorg handling with no handler logic required. Self-hostable or deployed to Envio Cloud with a GitHub-native flow (envio-cloud indexer add against an envio branch).

Where is the production reference for a large subgraph migration?​

The Polymarket HyperIndex reference indexer. 8 subgraphs' worth of logic consolidated into one indexer, with the first 4,000,000,000 events synced in 6 days and over 6,500,000,000 indexed to date. The full repo is public on GitHub and the case study can be found in our blog.

Get Started​

Migration starts with two things: an existing subgraph (deployed or local) and a Claude Code or Cursor session pointed at a fresh HyperIndex project.

• HyperIndex Quickstart with AI
• HyperIndex docs MCP server
• Polymarket reference indexer
• Migration guide (manual reference)
• Envio Cloud CLI

For larger migrations, the Envio team supports the planning and review pass directly. Reach out via Discord or Telegram.

Build With Envio​

Envio is the fastest independently benchmarked EVM blockchain indexer for querying real-time and historical data. If you are building onchain and need indexing that keeps up with your chain, check out the docs, run the benchmarks yourself, and come talk to us about your data needs.

Stay tuned for more updates by subscribing to our newsletter, following us on X, or hopping into our Discord.

Subscribe to our newsletter

Website | X | Discord | Telegram | GitHub | YouTube | Reddit

A production indexer fails in three ways. The chain reorgs and the indexer either misses the rollback or hand-rolls bespoke logic that breaks at the next edge case. The data source goes down and the indexer either stalls silently or fails over and never comes back to primary. The indexer hits a counter ceiling, a memory leak in a long-running handler, or another silent failure, and the operator finds out from a downstream outage instead of an alert.

HyperIndex is Envio's multichain blockchain indexing framework for EVM chains. Reliability lives at the framework level so that any indexer built on it inherits the behaviour without writing operational code. Four guarantees compound to keep an indexer production-correct: framework-level reorg handling, restart-resistant operation, HyperSync data validation, and multi data-source recovery. Observability through Prometheus layers on top.

Why These Four Reliability Pillars Reinforce Each Other​

Reorg handling guarantees your indexer doesn't carry corrupt state forward when a chain rolls back. Restart-resistant operation means a failed indexer process doesn't leak that corruption into a stuck or amnesiac state. HyperSync validation means the data feeding both is the canonical chain, not a stale or partial fork. Multi-source recovery keeps the whole stack live when upstream sources fail. Each pillar protects the rest.

Reorg Handling at the Framework Level​

The reorg architecture is the deepest piece of work HyperIndex's reliability story rests on. To understand why "framework-level" matters, it helps to be precise about what a reorg actually does to an indexer.

A reorg is a chain rolling back to a previous point in time. A recent block (or several) is no longer canonical, and the new canonical chain has different events at those heights. The implications for an indexer split along a single axis, stateless versus stateful.

Stateless indexers only create entities. On a reorg, the fix is mechanical. Delete the entities written from orphaned blocks, re-ingest from the canonical chain, move on. Stateless indexing parallelises well and is fast.

Stateful indexers also update and delete entities based on previous state. An order book's running volume, an account's balance, a market's open interest, all of these aggregate prior state into current state. On a reorg, you cannot just delete and replay. You have to revert previous operations to the entity state at the pre-reorg point, then replay forward against the canonical chain. Doing that correctly requires tracking the history of every change to every entity for the entire unfinalized window.

HyperIndex's framework keeps that entity history for you.

"Envio HyperIndex tracks entity state history for all unfinalized blocks. When a reorg is detected, it rolls back entity state to the correct point and reprocesses events from the canonical chain. This happens automatically and does not require any custom rollback logic in your event handlers."

Denham Preen, Envio Co-founder

Learn more in our Indexing and Reorgs blog.

Three architectural details worth knowing about that mechanism:

1. History is per-entity, not per-block. The framework persists the prior state of each entity each time a handler writes to it within the unfinalized window. On a reorg, the rollback walks the per-entity history backwards to the pre-reorg state, applies it, and reprocesses forward. This is what lets time-travel queries work against unfinalized blocks.

2. History is pruned automatically. Once a block is finalised, its entries in the entity history are no longer needed. The framework prunes them. The unfinalized window is the only window that ever carries history overhead, which keeps the storage cost bounded regardless of total chain length.

3. Multichain reorg handling is harder than single-chain, and the framework does it. When a single entity's state is updated by events from multiple chains, a reorg on chain A may force the framework to also reprocess events on chain B that were applied after the reorg point but depended on the rolled-back state. The reorg blog calls this out explicitly. Hand-rolling correct multichain reorg logic is the kind of thing you do not want any application engineer to have to write.

Reorgs in the Wild​

These are not theoretical edge cases. From the same reorg blog:

• Polygon has frequent and sometimes deep reorgs. The forum has documented a single 157-block reorg at block height 39,599,624. Polymarket runs on Polygon. Polymarket's reference indexer at github.com/enviodev/polymarket-indexer has stayed correct through every Polygon reorg, including the deep ones, because the framework does the work.
• Ethereum mainnet sees roughly 1% of blocks affected by reorgs. Assuming a 50/50 chance of a transaction landing in the orphaned versus canonical fork, that's about 1 in 200 transactions ending up in a reorged block. An indexer that does not roll back state is silently wrong for ~0.5% of the transactions it ingests.
• Base and OP-stack chains are largely reorg-resistant due to single-slot finality, with documented exceptions.

Why this matters operationally:

• No bespoke per-handler logic. The most common subgraph reliability bug is a handler that does not handle a reorg correctly because the dev forgot to. With HyperIndex that bug class does not exist.
• No "wait for N confirmations" delay. Some indexers paper over reorgs by lagging behind the chain head by N blocks. HyperIndex stays at chain head and rolls back if needed.
• Entity state history is queryable. Time-travel queries against the unfinalized window work because the history is persisted, not discarded.
• Multichain stays correct. A multichain indexer with one chain reorging does not corrupt the cross-chain aggregates. The framework rolls back the dependent state on every other chain too.

Multi Data-Source Recovery​

HyperIndex's multi data-source recovery is documented in the dev update archive and tracked in the GitHub releases.

The feature has three concrete pieces.

1. Smarter source selection​

Indexers configured with multiple data sources (a primary plus one or more fallbacks) route requests using selection logic that weights source health. A flapping fallback does not win the rotation purely because it answered fastest.

2. Automatic failover within seconds​

When the primary source goes down, the indexer fails over to a fallback within seconds. When the primary comes back, HyperIndex attempts to recover to it 60 seconds later. The indexer does not need to be restarted to return to its preferred source.

3. Live mode enforcement​

Live mode means the indexer is at chain head and processing new blocks as they arrive. HyperIndex enforces live mode strictly: if the indexer's effective progress is stalling on a degraded source, metrics surface it. Operators see the degradation before downstream consumers do.

This pillar is the one operators feel daily. Most indexer outages in 2025 were not chain outages. They were data-source outages that the indexer did not handle gracefully. Multi data-source recovery removes the operator pager from that loop.

Resumes Cleanly Across Restarts​

A production indexer runs for months. The host will restart. Configs will change. The reliability question isn't whether restarts happen, it's what state the indexer is in when they do.

HyperIndex persists indexer state across restarts. On reboot, state is restored from the database, including dynamically registered contracts. The indexer resumes from the last committed block, not from chain head and not from genesis. Application code does not have to track checkpoints or persist offsets, the framework handles it.

Handler-side failures are caught at the framework level too. If a handler throws an unhandled exception, the indexer restarts automatically without data loss. Application code does not have to wrap handlers in try/catch, implement custom retry logic, or rebuild offsets after a crash. The framework does this for you.

The dev environment also preserves data by default. envio dev no longer wipes the database on incompatible config or schema changes; the explicit opt-in is envio dev -r. For some config changes (RPC configuration is the first to land), the indexer can continue indexing through the change without erroring out at all.

This complements the reorg story. Reorg handling protects against chain-side rollbacks; restart persistence protects against indexer-side restarts. Together they cover the failure surface a production indexer actually faces.

HyperSync Data Validation​

The data feeding the indexer matters as much as the indexer itself. A reorg-aware framework with restart safety is still only as correct as the events that arrive at the handler.

HyperIndex pulls historical data through HyperSync, Envio's data engine. HyperSync ships a robust set of validation features that raw RPC does not, block parent hash verification, fork detection, automatic re-sync on detected forks. The validation runs at ingestion, not in your handler. The framework's confidence is that no events are silently missed by the data layer.

Raw RPC does not give the same guarantee. A standard RPC endpoint will serve whatever the upstream node currently considers canonical, and a slow rotation between forks (or a single RPC sitting on an orphaned tip) can quietly hand stale events to a downstream indexer. With HyperSync as the data layer, that class of silent corruption is removed before any handler sees it.

For application teams: events that reach your handler are canonical-chain events. For AI agents acting on indexer state: the data they reason over is validated upstream, not a best-effort RPC read.

Why Data Validity Matters for AI​

When an agent acts on indexer data, the agent is only as correct as the data it queries. A missing or stale event in a derivative pricing agent, a position tracker, or a governance bot is not a logging error, it's a financial event. The premise of the AI-onchain stack is that the data layer underneath gives the agent verified, canonical state.

HyperIndex's framework-level guarantees (reorg-aware, restart-persistent, parent-hash-validated upstream) are what let an agent treat indexer output as a stable source of truth rather than a feed to second-guess. The companion blog on agentic blockchain indexing covers the agent-side story end to end.

Observability Through Prometheus​

HyperIndex exposes a standard Prometheus /metrics endpoint with three properties operators rely on.

• Semver-stable contract. Metric names and labels do not change between minor versions. Grafana dashboards built against this endpoint do not need to be rebuilt every release.
• Time units in seconds. Every duration metric is in seconds, matching Prometheus convention. Histograms use second-based buckets.
• Benchmark data points in the standard endpoint. The data points historically surfaced under a separate benchmark mode are part of the standard /metrics output. Continuous benchmarking against a production deployment does not require a separate run mode.

For self-hosted deployments, the endpoint plugs into existing Prometheus infrastructure. For Envio Cloud deployments, alerts are exposed through the standard alert channels (Discord, Slack, Telegram, and Email).

What This Looks Like in a Real Configuration​

The Polymarket reference indexer's config.yaml is the public production example. The structural pieces below are drawn from the canonical file (selected events shown for brevity):

# Source: https://github.com/enviodev/polymarket-indexer/blob/main/config.yaml
# yaml-language-server: $schema=./node_modules/envio/evm.schema.json
name: polymarket-indexer
description: Unified Polymarket HyperIndex

contracts:
  # Phase 1A: Fee Module
  - name: FeeModule
    abi_file_path: ./abis/FeeModule.json
    events:
      - event: "FeeRefunded(bytes32 indexed orderHash, address indexed to, uint256 id, uint256 refund, uint256 indexed feeCharged)"

  # Phase 2B: Orderbook
  - name: Exchange
    abi_file_path: ./abis/Exchange.json
    events:
      - event: "OrderFilled(bytes32 indexed orderHash, address indexed maker, address indexed taker, uint256 makerAssetId, uint256 takerAssetId, uint256 makerAmountFilled, uint256 takerAmountFilled, uint256 fee)"
      - event: "OrdersMatched(bytes32 indexed takerOrderHash, address indexed takerOrderMaker, uint256 makerAssetId, uint256 takerAssetId, uint256 makerAmountFilled, uint256 takerAmountFilled)"

  # Phase 3: Open Interest + Activity
  - name: ConditionalTokens
    abi_file_path: ./abis/ConditionalTokens.json
    events:
      - event: "PositionSplit(address indexed stakeholder, address collateralToken, bytes32 indexed parentCollectionId, bytes32 indexed conditionId, uint256[] partition, uint256 amount)"
      - event: "PositionsMerge(address indexed stakeholder, address collateralToken, bytes32 indexed parentCollectionId, bytes32 indexed conditionId, uint256[] partition, uint256 amount)"
      - event: "PayoutRedemption(address indexed redeemer, address indexed collateralToken, bytes32 indexed parentCollectionId, bytes32 conditionId, uint256[] indexSets, uint256 payout)"

field_selection:
  transaction_fields:
    - hash
    - from
    - to

chains:
  - id: 137 # Polygon
    start_block: 3764531
    contracts:
      - name: FeeModule
        address:
          - "0xE3f18aCc55091e2c48d883fc8C8413319d4Ab7b0"
          - "0xB768891e3130F6dF18214Ac804d4DB76c2C37730"
        start_block: 75253526
      - name: Exchange
        address:
          - "0x4bFb41d5B3570DeFd03C39a9A4D8dE6Bd8B8982E"
          - "0xC5d563A36AE78145C45a50134d48A1215220f80a"
        start_block: 33605403
      - name: ConditionalTokens
        address: "0x4D97DCd97eC945f40cF65F87097ACe5EA0476045"
        start_block: 4023686

Three details worth pointing at in this config:

1. Two-tier declaration. The top-level contracts: block declares the contract name, ABI, and event signatures globally. The chains: block (per chain ID) supplies addresses and per-contract start_block overrides. This is how the same contract definition gets reused across multiple deployed addresses (Exchange has two production addresses, FeeModule has two) without duplicating the event signatures.
2. field_selection controls which transaction fields HyperSync ships down to the handler. Polymarket asks for hash, from, and to only. Smaller per-event payload, faster sync, lower memory pressure. Available on every config.
3. No reorg block. There is no rollback_on_reorg flag set in the config because rollback is the framework default. The handlers in src/ do not contain reorg logic. They write entities, the framework manages history, the database stays consistent.

The full file declares 9 V1 contracts (FeeModule, UmaSportsOracle, RelayHub, SafeProxyFactory, USDC, Exchange, ConditionalTokens, NegRiskAdapter, FPMMFactory) plus a dynamic FixedProductMarketMaker registered at runtime, and 5 V2 contracts (CTFExchangeV2, PolyUSD, Rewards, CtfCollateralAdapter, NegRiskCtfCollateralAdapter), all routed through merged handlers in a single multichain-capable config. For a true multichain deployment, the same chains: array gets additional entries (e.g., id: 8453 for Base) with their own contracts block.

Why Reliability Beats Speed When You Are Picking an Indexer​

Speed is the easier comparison and the one most blog posts lead with. Sentio's independent Uniswap V2 Factory benchmark put HyperIndex at 8 seconds, 142x faster than The Graph and 15x faster than the nearest competitor. Polymarket synced 4 billion events in 6 days. Our agentic indexing blog covers a 400,000-event Monad indexer in roughly 20 seconds.

Reliability is the one that decides whether an indexer stays running for years. The four pillars above (framework reorg handling, restart-resistant operation, HyperSync data validation, and multi data-source recovery) are what separate a production indexer from a benchmark.

Three operational consequences for teams choosing HyperIndex over alternatives:

• One on-call surface, not three. The framework handles reorgs, source failover, restart recovery, and observability. The on-call person reads the Prometheus dashboard and the Envio Cloud alerts. They do not also have to maintain custom reorg or checkpoint code.
• Source diversity without operator overhead. Adding a fallback source is a config change. Multi data-source recovery does the runtime work. The operator does not author retry policies.
• Time-travel queries on unfinalized state. Because entity state history is persisted, the indexer can answer "what was this entity at block N" even when N is in the unfinalized window. Most subgraphs cannot.

Get Started​

• What's new in v3
• HyperIndex quickstart
• Quickstart with AI
• Benchmarks
• Reorg handling reference
• Polymarket reference indexer
• Envio Cloud (alerts, hosted reliability)

Frequently Asked Questions​

How does Envio HyperIndex handle blockchain reorgs?​

HyperIndex tracks entity state history for every unfinalized block at the framework level. When a reorg occurs, the framework walks the per-entity history backwards to the pre-reorg state, applies it, then reprocesses forward against the canonical chain. History is pruned automatically once a block is finalised. No handler code is required.

How does HyperSync guarantee canonical chain data?​

HyperSync ships a robust set of validation features that raw RPC does not, block parent hash verification, fork detection, automatic re-sync on detected forks. The indexer can trust that no events are silently missed by the data layer. The validation runs at ingestion, not in your handler. Raw RPC endpoints serve whatever the upstream node currently considers canonical, which is why a standard RPC-fed indexer can silently ingest stale or orphaned data from a slow-rotating provider.

How often do reorgs actually happen?​

On Ethereum mainnet, roughly 1% of blocks undergo reorgs, meaning approximately 1 in 200 transactions ends up in a reorged block. Polygon experiences deeper reorgs more frequently and has documented a single 157-block reorg at block height 39,599,624. Base and OP-stack chains are largely reorg-resistant due to single-slot finality, with documented exceptions.

What is multi data-source recovery in HyperIndex?​

Multi data-source recovery automatically routes between configured data sources. On primary outage, the indexer fails over to a fallback within seconds. When the primary returns, the indexer attempts to recover to it 60 seconds later, no restart required. Selection logic weights source health, not just first-response. Live mode enforcement surfaces through metrics when forward progress slows on a degraded source.

What happens to the indexer when the process restarts or a handler fails?​

HyperIndex is restart-resistant. State persists to the database; on restart, the indexer restores state (including dynamically registered contracts) and resumes from the last committed block. If a handler fails mid-execution, the framework restarts automatically without data loss. Application code does not have to track checkpoints, persist offsets, or wrap handlers in retry logic.

Is the HyperIndex Prometheus metrics endpoint production-ready?​

Yes. The /metrics endpoint follows semver, uses second-based time units, and exposes the benchmark data points historically surfaced under a separate run mode as part of the standard endpoint.

Where can I see the production-scale HyperIndex reference?​

The Polymarket reference indexer. It synced 4,000,000,000 events from block 3,764,531 on Polygon Mainnet in 6 days, replacing 8 separate subgraphs.

What alert channels does Envio Cloud support?​

Envio Cloud alerts route through the platform's alert channels documented in the hosted service docs.

Does HyperIndex stay at chain head or lag for safety?​

HyperIndex stays at chain head. Reorgs are handled by rollback, not by lag. There is no "wait N confirmations" mode required for correctness.

Is HyperIndex faster than The Graph in production?​

Yes. In the Sentio Uniswap V2 Factory benchmark, HyperIndex completed in 8 seconds. The Graph took 19 minutes on the same workload, 142x slower. Subsquid, the nearest competitor, was 15x slower. Full results on the benchmarks page linked in Get Started.

Build With Envio​

Envio is the fastest independently benchmarked EVM blockchain indexer for querying real-time and historical data. If you are building onchain and need indexing that keeps up with your chain, check out the docs, run the benchmarks yourself, and come talk to us about your data needs.

Stay tuned for more updates by subscribing to our newsletter, following us on X, or hopping into our Discord.

Subscribe to our newsletter

Website | X | Discord | Telegram | GitHub | YouTube | Reddit

Privacy Pools is one of the more ambitious privacy primitives shipped on Ethereum and its L2s. The protocol, co-authored by Vitalik Buterin and others, pairs a zero-knowledge proof of pool membership with an off-chain compliance vetting layer (the Association Set Provider, ASP). The result is a privacy mechanism that gives users cryptographic unlinkability between their deposit and their withdrawal, while still letting an off-chain layer say "we don't think this commitment came from a sanctioned address". Both halves matter, and both halves are working.

This post walks through a fully indexed snapshot of every deposit, withdrawal, ragequit, ASP root update, and relayer fee across all 21 live pools on every chain Privacy Pools runs on (14 on Ethereum, 2 on Optimism, 2 on BSC, 3 on Arbitrum). The headline takeaways are positive: the ZK proof is sound, the relayed-withdrawal path that preserves privacy gets used by 91% of withdrawers, and the largest pool has a genuinely diverse depositor base. The smaller, newer pools are doing what newer pools do: building toward those numbers.

The interesting analytical question, then, is what an outside observer with the public on-chain data can or can't say about who linked to whom. The answer is a clean "very little, and never with certainty". This is by design, and the data shows the design holding.

The full stack (indexer, analytics queries, BI report generator) is open-source at github.com/enviodev/privacy-pools under MIT license.

What is Privacy Pools​

Three on-chain entities matter for indexing:

• The Entrypoint: the singleton each pool registers under. Routes deposits and relays withdrawals.
• PrivacyPool: one contract per asset (ETH, USDC, USDT, fxUSD, BOLD, and so on). Emits Deposited, Withdrawn, Ragequit, LeafInserted, PoolDied.
• Association Set Provider (ASP): off-chain vetting. On-chain footprint is the RootUpdated events from the Entrypoint, each carrying a Merkle root and an IPFS pointer to the approved set.

The deposit/withdraw flow produces a commitment in a per-pool Merkle tree on deposit, and on withdrawal proves "I own some commitment in this pool, and that commitment is in the Association Set approved by the ASP", without revealing which commitment. Ragequit is the escape hatch: a depositor whose commitment has been excluded from a recent ASP root pulls their position out without the ZK-protected withdrawal flow.

The Dataset​

The indexer covers every Entrypoint and every PrivacyPool live across the four supported chains. Headline state at the time of writing (block heights are real-time):

USD TVL across all chains: ~$5.78M. Largest pools:

The mainnet ETH pool: a working anonymity set​

The Ethereum ETH pool is the protocol's flagship deployment, and its numbers tell a clear story:

• 2,320 distinct depositors (the next-largest cohort is 253 on Ethereum USDC).
• 7,889 leaves in the Merkle tree, more than every other pool combined.
• Herfindahl-Hirschman Index of 132 on depositor-value share, far below the 2,500 threshold considered "highly concentrated". The top depositor controls 8.0% of value, the top five 17.4%, the top ten 24.7%. There is no dominant wallet.

Together those numbers describe a pool with real anonymity. A withdrawal from this pool has thousands of plausible commitments behind it, and no single dominant depositor for an analyst to single out.

The smaller pools (BNB on BSC, yUSND on Arbitrum, BOLD on Ethereum, and the rest of the long tail) are at much earlier points in the same curve. With anywhere from 1 to ~250 leaves, the long tail is in early-cohort phase. Concentration is high there because the pools are young, not because the protocol is broken.

Anonymity-set growth​

Each commitment lives as a leaf in the per-pool Merkle tree. Both deposits and the ZK-replacement leaves emitted on withdrawal contribute, so the leaf count keeps climbing as the pool gets used.

The Ethereum ETH pool dominates by volume, but every active pool shows steady growth. There is no sign of pool abandonment.

Activity patterns​

Aggregating deposits and withdrawals by hour-of-day and day-of-week (UTC) reveals a global usage pattern: activity is roughly continuous, with a mild ramp through European and US business hours and a softer Asia-Pacific tail. Privacy Pools is being used as a steady utility, not as an event-driven product.

The lack of strong timezone clustering is itself a privacy positive: a sharply timezone-skewed user base would be an inadvertent fingerprint. This data shows a globally distributed user set.

Relayed-withdrawal share​

Withdrawals can be self-submitted (the recipient submits their own proof, paying gas with their own address) or relayed (a relayer submits on the recipient's behalf, taking a fee). Self-submitted withdrawals link the recipient address to the gas-paying address; relayed withdrawals don't.

Across all chains:

• 5,148 withdrawals were relayed.
• 482 were self-submitted (~8.6%).

91.4% of withdrawals took the privacy-preserving relayed path. That's a strong positive signal: users understand the privacy model and use it.

The relayer market on Ethereum is currently concentrated, with one relayer (0xec15c200…) processing ~77.7% of relayed flow and 0x855b4a60… taking 19.9%. The relayer doesn't see the deposit side, so they can't break the ZK link, but the concentration is worth watching as the relayer ecosystem matures. New relayers entering the market would distribute that observability and is a natural maturation step for the protocol.

Linkability: the public-data heuristic, and why it can never be proof​

Take every (deposit, withdrawal) pair in the same pool with the same on-chain value, and a time gap of 60 seconds to 2 hours. Treat the withdrawal as possibly linkable to that deposit by an external observer.

This is a heuristic. There is no proof the same actor controls both addresses, only that the visible flow is consistent with that.

About one in ten Ethereum ETH withdrawals fits this shape. On the smaller pools, the share is higher because there are fewer deposits to lose oneself in. These are upper bounds on what a naive heuristic can flag, and they are not proofs. The next section shows why.

Decoy withdrawals: how the protocol absorbs the heuristic​

The same-amount heuristic has a known counter, and it is a feature of the privacy model rather than a workaround.

An existing depositor whose funds have been in the pool for weeks or months sees a fresh deposit hit the contract. They withdraw an equivalent amount within the heuristic's time window, to a fresh address that has nothing to do with the new depositor. An outside observer running the same-amount analysis links the new deposit to that withdrawal address.

From outside, the pair looks like "Alice deposited and Alice (the withdrawal recipient) withdrew shortly after". Inside, Alice and the withdrawal recipient have nothing to do with each other. The withdrawer's funds predate Alice entirely.

Querying for deposits followed within 30 minutes by a same-amount withdrawal where the depositor and the withdrawal recipient are different addresses:

• 393 decoy-candidate pairs across the dataset.
• 163 distinct depositors had a same-amount withdrawal land within 30 minutes from a different address.
• 160 distinct withdrawal addresses received those decoy-shaped withdrawals.

These are candidates, not proven decoys. Every pair could be one of three things, all indistinguishable from public data:

1. The depositor really is the same actor, just routing the receipt through a different address.
2. Two unrelated parties happen to transact for the same round amount within minutes (more likely on busy pools and round denominations).
3. An existing depositor deliberately constructs the match to spoof the heuristic.

Because option (3) is cheap (one extra withdrawal proof) and option (2) is plausible on common amounts, the linkable-share table above is a plausibility upper bound, not a recall figure. An actor who knows the heuristic exists can deliberately produce false matches, and an actor who is genuinely the same person across both addresses will also show up in the same table. This is the verifiability ceiling that the protocol's design relies on, and it does the load-bearing work of converting the cryptographic guarantee into practical anonymity. Plausible deniability is real precisely because it can never be ruled out from public data.

Ragequit: the safety valve doing its job​

Ragequit is the escape hatch. When the ASP excludes a commitment from the latest approved root, the depositor still gets their funds back, just through a path that reveals which commitment they originally made.

The mainnet ETH baseline is 6.0% ragequit-by-count, 9.2% by value. The smaller pools have higher rates:

Three pools (BSC BNB, Arbitrum yUSND, BSC USDT) have seen most of their deposit value exit through the ragequit path rather than ordinary withdrawals. Depositors did not lose funds, they got their money back. What was lost on those specific commitments was the cryptographic privacy property, because ragequit reveals which commitment exited.

This is the ASP doing what it is designed to do: rejecting commitments after the fact when the off-chain compliance check changes its mind, and giving users a way out that doesn't trap their funds. The fact that the escape hatch is being exercised on the edges (small, young pools) is the system's compliance layer working as advertised, and it doesn't affect the privacy of any other depositor. For the mainnet ETH pool, where the bulk of activity sits, the ragequit rate is low and stable.

Where the public-data layer helps​

A privacy protocol's job is to provide cryptographic guarantees that an external observer can't link who deposited what to who withdrew. Privacy Pools does that: the ZK proof is sound, the verifiers are deployed, the on-chain mechanism works.

What the on-chain trail also does is record every deposit value, every withdrawal value, every relayer address, every recipient, and every timestamp. From that an indexed dataset gives you:

• A linkable-share number per pool (5-37% across the indexed pools), constrained by the verifiability ceiling above.
• A concentration index per pool that tells you how mature the anonymity set is.
• A ragequit-rate signal that confirms the ASP layer is active and that the safety valve is functioning.
• A relayed-share number showing 91% of withdrawers using the privacy-preserving path.
• A decoy-candidate count that quantifies how much credibility the plausible-deniability layer has on each pool.

None of these break the protocol. None of these are verifiable. All of them are useful operational metadata that anyone, including the ASP, the protocol team, and end users, can use to track the protocol's health.

The point of indexing the protocol publicly is precisely that this kind of monitoring should be open. The same dataset that enables the heuristics also exposes the limits of those heuristics, and lets honest actors and the protocol team work on the things that actually matter (anonymity-set growth on the long-tail pools, relayer-market diversification, ASP responsiveness) without anyone needing privileged access.

What this isn't​

A few things this analysis explicitly does not show:

• It does not break the ZK proof. Every linkability claim above is heuristic. A withdrawal that matches a deposit by amount and timing is consistent with the same actor controlling both addresses, but it is not proof.
• The decoy-candidate count is not a fraud detector. Many of the 393 decoy-shaped pairs will be coincidence on common round amounts, and some will be the same actor using a fresh address. The count is a ceiling on intentional decoys, not a measurement of them.
• High-ragequit pools aren't broken. Ragequit firing is the system working as designed when the ASP excludes a commitment.
• The fee figures are operator drains, not gross protocol revenue. The Entrypoint emits post-fee deposit values, so we can only observe the cashflow at the FeesWithdrawn step.

Any heuristic an analyst can run, a depositor can game. Anyone can construct decoy patterns at low cost. Anyone can split deposits across rounds, jitter timing, and rotate recipient addresses. Public-data heuristics are a probability surface, not a truth function. Privacy Pools is built for exactly that constraint.

How this was indexed​

The full stack is one Envio HyperIndex v3 indexer running locally with dual Postgres + ClickHouse storage:

• One config, four chains: Ethereum (1), Optimism (10), BSC (56), Arbitrum (42161). Same Entrypoint and PrivacyPool ABIs reused across all four. The L2s share a deterministic 0x44192215… Entrypoint via CreateX, while mainnet has the original 0x6818809E….
• One handler set writes 9 entity types: Pool, Deposit, Withdrawal, Ragequit, MerkleLeaf, AssociationSetRoot, Account, FeeWithdrawal, plus a derived LatestPrice/TokenPrice pair from a thin Uniswap V4 price feed on BSC. All chain-scoped IDs ({chainId}_{address}) so the L2 ETH-pool address collision (0x4626…918ff is the ETH pool on Optimism, BSC, and Arbitrum) doesn't fold rows together.
• Multichain sync to head: ~30 seconds. HyperSync handles 4 chains in parallel; the only non-trivial cost is the V4 price feed, which we keep cheap by starting near BSC's head and filtering Swap events to ~70 hardcoded pricing-pool IDs (see Uniswap V4 deployments). No Initialize handler, no historical V4 backfill, just current prices.
• Analytics on ClickHouse. A Python analytics/ package runs the headline queries through clickhouse-connect, charts them with matplotlib, and assembles a markdown BI report that renders to PDF via reportlab. The full report regenerates in a couple of seconds against the live ClickHouse.

The schema and the SQL queries are designed for this kind of question. Adding a new heuristic, say "deposits whose precommitment hash has a leading-zero prefix", is an .sql file, not a re-index.

Reproducing this​

The full stack lives at github.com/enviodev/privacy-pools under MIT license. One HyperIndex v3 indexer plus a Python analytics package that ships the BI report generator and every saved query.

• config.yaml, schema.graphql, src/EventHandlers.ts, src/v4Pricing.ts, src/v4PoolMeta.ts: the indexer.
• analytics/queries/{health,anonymity,risk,asp,relayers,fees,activity,pricing}/*.sql: every metric in this post.
• analytics/scripts/generate_bi_report.py: assembles the report markdown plus 6 charts.
• analytics/scripts/render_pdf.py: markdown to PDF, including image embedding.

git clone https://github.com/enviodev/privacy-pools
cd privacy-pools
cp .env.example .env  # add your free ENVIO_API_TOKEN from envio.dev
pnpm install
pnpm envio start

# in another shell
cd analytics
cp .env.example .env
uv sync
uv run python scripts/generate_bi_report.py

Multichain sync completes in well under a minute. The BI report regenerates against live ClickHouse in seconds.

If you want to extend the analysis (chain-cross transitive linkability, ASP root vs deposit timing, relayer-collusion graphs, or anything else), every entity carries chainId and blockNumber, and the schema is documented end-to-end in analytics/CLAUDE.md.

Build with Envio​

Envio HyperIndex is independently benchmarked as the fastest EVM blockchain indexer available. The Privacy Pools indexer is one example of what's possible when multichain coverage and an analytics-grade columnar store are first-class features. If you're building onchain (DeFi, prediction markets, gaming, or something nobody has thought of yet), the docs are the starting point.

• Repo: https://github.com/enviodev/privacy-pools
• Docs: https://docs.envio.dev/
• Discord: https://discord.gg/envio
• Telegram: https://t.me/+kAIGElzPjApiMjI0
• X: https://x.com/envio_indexer

Revert Finance builds analytics and management tools for AMM liquidity providers across protocols including PancakeSwap, Uniswap, and others. Accurate, real-time onchain data is the foundation of everything they build.

They run several indexers using Envio, spanning multiple chains and contracts. This case study covers one of them: a PancakeSwap V3 indexer on BNB Smart Chain. Their previous subgraph had been stuck at 70% sync for over 2 years, unable to reach the chain's head.

The subgraph instance can be viewed here: https://thegraph.com/explorer/subgraphs/Hv1GncLY5docZoGtXjo4kwbTvxm3MAhVZqBZE4sUT9eZ?view=Query&chain=bsc

Envio built a HyperIndex indexer for PancakeSwap V3 on BNB Smart Chain. It synced 1,711,569,200 events to 100% in 10 days.

The Problem Revert Finance Needed to Solve​

Revert Finance requires real-time PancakeSwap V3 position and liquidity data to power its analytics and tooling for liquidity providers. A public subgraph on The Graph's decentralized network had been stuck at 70% sync on BNB Smart Chain for over 2 years, unable to reach chain head.

BNB Smart Chain's high throughput has presented well-documented challenges for RPC-based indexing, with teams reporting sync issues going back to 2021. The volume of events per block outpaces what standard indexing infrastructure can sustain, causing subgraphs to fall progressively further behind until they stall entirely.

A subgraph stuck at 70% sync for over 2 years is effectively unusable.

The Solution: Envio HyperIndex on BNB Smart Chain​

Envio HyperIndex is a real-time multichain blockchain indexing framework for any EVM chain. Developers write event handlers in TypeScript and deploy a single indexer covering multiple contracts and chains simultaneously. It uses HyperSync, Envio's proprietary data engine, which serves filtered event data in bulk directly from a purpose-built data lake, replacing having to poll RPC endpoints block by block. This removes the RPC bottleneck entirely, which is precisely what causes subgraph stalls on BNB Smart Chain.

HyperIndex is independently benchmarked as the fastest blockchain indexer available. In the Uniswap V2 Factory benchmark run by Sentio in May 2025, HyperIndex synced in 1 minute, 143x faster than The Graph and 15x faster than the nearest competitor. BNB Smart Chain is one of 87+ EVM chains with native HyperSync coverage.

For a full benchmark breakdown see the complete blockchain indexer comparison.

Envio built a HyperIndex indexer covering PancakeSwap V3 on BNB Smart Chain, tracking Factory, Pool, and NFPM (Non-Fungible Position Manager) contracts from block 26,956,207.

Contracts Indexed​

The indexer covers the full PancakeSwap V3 contract surface on BNB Smart Chain:

• Factory (0x0bfbcf9fa4f9c56b0f40a671ad40e0805a091865): Pool creation and registry
• Pool (dynamic): All Pool events across all dynamically registered pool instances
• NFPM (0x46a15b0b27311cedf172ab29e4f4766fbe7f4364): NFT position management events

Dynamic contract registration handles the Pool contracts. As new PancakeSwap V3 pools are created onchain by the Factory, the indexer registers them automatically without requiring a redeployment.

The Results​

Over 1.7 billion events, fully synced, on a chain where the equivalent subgraph had been stuck for over 2 years. The indexer is hosted on Envio Cloud, Envio's managed hosting platform.

Envio vs The Graph on BNB Smart Chain​

Why High-Throughput Chains Need HyperSync​

BNB Smart Chain is not an edge case. Any high-throughput EVM chain, whether BNB Smart Chain, Polygon, or a high-activity L2, generates event volumes that stress RPC-based indexing. The pattern is the same: subgraph starts syncing, falls progressively further behind, eventually stalls.

HyperSync eliminates this failure mode by removing RPC polling from the historical sync path entirely. Event data is retrieved in bulk from Envio's data lake, meaning sync speed scales with data volume rather than being bottlenecked by RPC rate limits and polling intervals.

For protocols like Revert Finance that require accurate, real-time onchain data to power liquidity analytics, this is the difference between functional infrastructure and a permanently stale data source.

Get Started​

• Quickstart: https://docs.envio.dev/docs/HyperIndex/contract-import
• Envio docs: https://docs.envio.dev
• Discord: https://discord.gg/envio
• Telegram: https://t.me/+kAIGElzPjApiMjI0
• Follow us on X: https://x.com/envio_indexer

Frequently Asked Questions​

What is Revert Finance?​

Revert Finance builds analytics and management tools for liquidity providers in AMM protocols. Its tooling covers position analytics, auto-compounding, and liquidity management across protocols including PancakeSwap, Uniswap, and others.

What is PancakeSwap V3?​

PancakeSwap V3 is the concentrated liquidity version of PancakeSwap, the largest decentralized exchange on BNB Smart Chain. V3 introduces capital-efficient liquidity positions represented as NFTs, managed via the Non-Fungible Position Manager contract.

What is a blockchain indexer?​

A blockchain indexer is a system that listens to onchain events and organises them into a structured, queryable database. Developers use blockchain indexers to build fast backends for DeFi protocols, analytics tools, and trading interfaces without querying slow RPC endpoints directly.

What is HyperIndex?​

Envio HyperIndex is a real-time multichain blockchain indexing framework for EVM chains. Developers write event handlers in TypeScript and deploy a single indexer covering multiple contracts, chains, and domains. It uses HyperSync, Envio's proprietary data engine, to fetch filtered event data in bulk rather than polling RPC endpoints, enabling historical syncs at speeds not achievable through standard RPC.

What is HyperSync?​

HyperSync is Envio's high-performance data engine. Instead of querying RPC endpoints block by block, HyperSync fetches and serves filtered event data in bulk from a purpose-built data lake, delivering up to 2,000x faster data access than traditional RPC. BNB Smart Chain is one of 87+ EVM chains with native HyperSync coverage. Any EVM chain can be indexed via standard RPC.

What is Envio Cloud?​

Envio Cloud is Envio's managed hosting platform for HyperIndex indexers. It handles infrastructure, scaling, and monitoring so teams can run production-ready indexers without managing operational overhead. Revert Finance's PancakeSwap V3 indexer runs on Envio Cloud.

What chains does Envio support?​

Envio supports any EVM chain. 87+ EVM chains have native HyperSync coverage for maximum speed, including BNB Smart Chain, Polygon, Ethereum, Base, Arbitrum, Optimism, and more. Any EVM chain without native HyperSync support can be indexed via standard RPC. See the full list of supported chains at envio.dev/chains.

How do I migrate from The Graph to HyperIndex?​

Because HyperIndex handlers are written in TypeScript and AssemblyScript is a subset of TypeScript, most handler logic can be carried across directly. Envio provides a full migration guide, a CLI validation tool to compare output between both endpoints, and white-glove migration support for teams moving from The Graph.

Build With Envio​

Envio is independently benchmarked as the fastest EVM blockchain indexer available. If you are building onchain and need indexing that keeps up with your chain, check out the docs, run the benchmarks yourself, or come talk to us about your data needs.

Subscribe to our newsletter

Website | X | Discord | Telegram | GitHub | YouTube | Reddit

Reading onchain data is one of the slowest, most expensive parts of building any Web3 product or service. Standard JSON-RPC endpoints work for one-off lookups, but break down the moment you need fast or filtered historical data, multichain coverage, or anything more than a handful of blocks at a time. HyperSync exists to fix that. This post covers what HyperSync is, why Envio built it, how it works, and how to use it in your own application.

The Problem with RPC​

Reading onchain data over JSON-RPC is the default path most teams start with. It also breaks the moment your needs go beyond a single contract on a single chain.

Three things happen as soon as you scale:

• Speed. Backfilling a year of events across an L2 takes hours or days because RPC was designed to serve one request at a time, not stream historical data in bulk.
• Query Flexibility. RPC limits you to small block windows, typically 100 to 1000 blocks per request depending on the provider, with strict rate limits and inconsistent behavior across providers. Anything more sophisticated, like fetching every PoolCreated event across an entire chain, still requires hundreds or thousands of separate calls and bespoke retry logic.
• Cost. Data-intensive workloads on premium RPC providers add up fast, and you are still rate-limited at the moment you most need throughput.

What HyperSync Is​

HyperSync is a purpose-built data retrieval layer that gives developers direct access to blockchain data at speeds RPC cannot match. It is written in Rust, uses optimised binary encoding and parallel fetching, and exposes a query API that is both fast at serving requested data and flexible about how that data can be filtered and shaped.

Where RPC is a single endpoint serving one block of data at a time, HyperSync is a streaming query engine. You describe what you want once, in a single query object, and it streams back exactly that data across whatever block range you asked for.

Performance, Verified​

The numbers below are pulled from the HyperSync overview.

HyperSync is also the data layer powering HyperIndex, the fastest blockchain indexer available. Sentio's independent Uniswap V2 Factory benchmark (May 2025) measured HyperIndex completing the test in 1 minute, 143x faster than The Graph and 15x faster than the nearest competitor (Subsquid).

In production, that translates into projects like the Polymarket reference indexer, which synced 4 billion events in 6 days and replaced 8 separate subgraphs with a single HyperIndex deployment powered by HyperSync.

How HyperSync Works​

There are four primitives you need to understand to use HyperSync.

1. Queries​

A query is a single object that describes the data you want. It includes a block range, a set of filters, and a field selection. You hand it to a HyperSync client and it streams matching results back to you.

Here is a working query in TypeScript that streams every Uniswap v3 event from Ethereum mainnet, starting at genesis. This pattern is taken from the Polymarket trades tutorial and the API Tokens implementation guide.

import { HypersyncClient, type Query } from "@envio-dev/hypersync-client";
import { keccak256, toHex } from "viem";

const event_signatures = [
  "PoolCreated(address,address,uint24,int24,address)",
  "Burn(address,int24,int24,uint128,uint256,uint256)",
  "Initialize(uint160,int24)",
  "Mint(address,address,int24,int24,uint128,uint256,uint256)",
  "Swap(address,address,int256,int256,uint160,uint128,int24)",
];

const topic0_list = event_signatures.map((sig) => keccak256(toHex(sig)));

const client = new HypersyncClient({
  url: "https://eth.hypersync.xyz",
  apiToken: process.env.ENVIO_API_TOKEN!,
});

const query: Query = {
  fromBlock: 0,
  logs: [{ topics: [topic0_list] }],
  fieldSelection: {
    log: ["Data", "Address", "Topic0", "Topic1", "Topic2", "Topic3"],
  },
};

const stream = await client.stream(query, {});

while (true) {
  const res = await stream.recv();
  if (res === null) break;
  if (res.data?.logs) {
    console.log(`Got ${res.data.logs.length} logs`);
  }
  if (res.nextBlock) {
    query.fromBlock = res.nextBlock;
  }
}

2. Filters​

You can filter on logs, transactions, traces, and blocks, alone or in combination. Filters narrow down what HyperSync streams back, so you only pay for the data you actually need.

// TypeScript: every USDC Transfer in a given block range
const logSelection = {
  address: ["0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"],
  topics: [
    ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"],
  ],
};

Trace filters give you access to execution traces and internal transactions, which is the only way to track native ETH transfers since they do not emit event logs. Traces are accessed via a separate trace-enabled endpoint, for example https://eth-traces.hypersync.xyz. The Native ETH Transfers tutorial walks through that pattern end to end.

3. Field Selection​

HyperSync lets you ask for only the fields you need. Smaller responses, less bandwidth, faster downstream processing.

const fieldSelection = {
  block: ["Number", "Timestamp"],
  transaction: ["Hash", "From", "To"],
  log: ["Address", "Topic0", "Data"],
};

4. Output Modes​

HyperSync gives you three ways to consume results:

• client.stream(query, config) for direct in-memory processing.
• client.collect_json(path, query, config) for smaller datasets and debugging.
• client.collect_parquet(path, query, config) for analytical workloads on large datasets.

Streaming is the right default for indexers and real-time applications. Parquet is the right default for ETL pipelines and data science work.

Switching Networks​

Switching chains is a one-line change. The same client works against any of the 87+ supported networks by changing the URL.

// Ethereum
const client = new HypersyncClient({
  url: "https://eth.hypersync.xyz",
  apiToken: process.env.ENVIO_API_TOKEN!,
});

// Arbitrum
const client = new HypersyncClient({
  url: "https://arbitrum.hypersync.xyz",
  apiToken: process.env.ENVIO_API_TOKEN!,
});

// Base
const client = new HypersyncClient({
  url: "https://base.hypersync.xyz",
  apiToken: process.env.ENVIO_API_TOKEN!,
});

The full list of network URLs is on the Supported Networks page.

Try HyperSync in 30 Seconds​

The fastest way to feel HyperSync is to install nothing.

pnpx logtui aave arbitrum

That command launches LogTUI, a terminal-based blockchain event viewer built on HyperSync, and starts streaming Aave events on Arbitrum into your terminal in real time. LogTUI ships with presets for 20+ protocols including Uniswap, Chainlink, Aave, and ENS.

When you are ready for a real client, clone the hypersync-quickstart repo and run one of the included scripts.

git clone https://github.com/enviodev/hypersync-quickstart.git
cd hypersync-quickstart
pnpm install
node run-simple.js

You will need an API token. Set it as an environment variable.

export ENVIO_API_TOKEN="your-api-token-here"

Generate a token from envio.dev/app/api-tokens and read the API Tokens guide for usage and security best practices.

If you are building a full indexer with schema management, event handlers, and a hosted GraphQL API, jump to the HyperIndex Quickstart.

Handling Large Backfills​

A single HyperSync request has a 5-second processing window. For a fresh historical backfill across a high-volume chain, loop through block ranges by feeding the nextBlock from each response back into the next query.

current_block = start_block
while current_block < end_block:
    query.from_block = current_block
    query.to_block = min(current_block + 1_000_000, end_block)
    result = await client.collect_parquet("data", query, config)
    current_block = result.end_block + 1

For most use cases, the streaming client handles this automatically.

Use Cases​

HyperSync makes a class of applications practical that traditional RPC cannot reasonably support.

• Blockchain indexers that build high-performance data pipelines with minimal infrastructure.
• Data analytics that runs complex onchain analysis in seconds instead of days.
• Block explorers that serve responsive UIs with comprehensive historical access.
• Monitoring tools that track blockchain activity with near real-time updates.
• Cross-chain applications that pull unified data across multiple networks from a single query interface.
• ETL pipelines that extract onchain data into data warehouses fast.

What HyperSync Powers​

HyperSync is the data engine underneath a growing set of tools and applications.

HyperIndex is Envio's full indexing framework. It uses HyperSync as its primary data source, then layers on schema management, event handlers, multichain support, automatic reorg handling, and a hosted GraphQL API. HyperIndex is the fastest blockchain indexer available, 143x faster than The Graph and 15x faster than Subsquid on the Sentio Uniswap V2 Factory benchmark (May 2025).

ChainDensity.xyz uses HyperSync to render transaction and event density across any address on any supported chain. It generates insights in seconds that would take hours over RPC.

Scope.sh is an Account Abstraction-focused block explorer that uses HyperSync for ultra-fast historical data retrieval.

LogTUI is the zero-install event viewer mentioned above. Try pnpx logtui --help for the full list of presets.

When to Use HyperSync vs HyperIndex​

A common question. The short answer.

Use HyperSync directly when you want raw blockchain data at maximum speed and you are happy to manage your own pipeline, storage, and downstream API. Good fits include analytics scripts, ETL into a data warehouse, custom alert systems, and anything that needs the absolute thinnest layer between you and the data.

Use HyperIndex when you want a complete indexing framework with schema management, event handlers, GraphQL output, multichain support, automatic reorg handling, and managed hosting on Envio Cloud. Good fits include application backends, dashboards, and anything where you would otherwise reach for The Graph or Subsquid. HyperIndex is itself powered by HyperSync.

Common Patterns​

Three patterns we see most often from teams adopting HyperSync.

Pattern 1. Replace a slow RPC backfill. A team has an existing indexer that takes days to backfill from genesis. Swapping the RPC source for HyperSync brings that down to minutes. The Polymarket case study is the canonical example, with 4 billion events synced in 6 days.

Pattern 2. Query across many chains in one place. A team builds a multichain dashboard and is tired of stitching together a dozen RPC providers. HyperSync exposes the same query interface for every supported chain, so the only thing that changes between Ethereum, Arbitrum, Base, and Optimism is the URL.

Pattern 3. Build a niche analytics tool fast. ChainDensity, Scope, and LogTUI are all examples. HyperSync makes it cheap to ship the kind of tool that would otherwise need a dedicated data team.

Pricing and Access​

HyperSync requires an API token. API tokens have been required since 3 November 2025. Generate a token at envio.dev/app/api-tokens and read the API Tokens documentation for limits, usage tracking (requests and credits), and security best practices. Indexers deployed to Envio Cloud have special access to HyperSync and do not require a custom API token. For production tier options, see the Envio pricing page.

Frequently Asked Questions​

How Fast Is HyperSync Compared to RPC?​

HyperSync is up to 2000x faster than RPC for sparse log scans. Scanning Arbitrum for sparse log data takes 2 seconds with HyperSync, versus hours or days over RPC. Fetching every Uniswap v3 PoolCreated event on Ethereum is roughly 500x faster.

What Chains Does HyperSync Support?​

HyperSync is natively available on 87+ chains, including Fuel, with new networks added regularly. The full list is on the Supported Networks page.

What Client Libraries Are Available?​

HyperSync ships official client libraries in Python, Rust, Node.js, and Go. There is also a curl interface for quick testing.

Do I Need an API Token?​

Yes. API tokens have been required since 3 November 2025. Generate a token at envio.dev/app/api-tokens and pass it as apiToken in TypeScript or bearer_token in Python. Indexers deployed to Envio Cloud have special access and do not need a custom token.

How Is HyperSync Different from HyperIndex?​

HyperSync is the raw data layer. HyperIndex is the full indexing framework built on top of it. Use HyperSync directly when you want maximum speed and full control of your pipeline. Use HyperIndex when you want schema management, event handlers, GraphQL APIs, automatic reorg handling, and managed hosting.

Can I Use HyperSync for Real-Time Data?​

Yes. HyperSync streams data continuously and you can poll for new blocks at the head of the chain. The Polymarket trades tutorial is a worked example of real-time streaming.

Are Traces Supported on Every Chain?​

No. Trace filters are accessed via separate trace-enabled HyperSync endpoints, for example https://eth-traces.hypersync.xyz for Ethereum mainnet. See the Supported Networks page for trace availability.

Build With Envio​

Envio HyperIndex is independently benchmarked as the fastest EVM blockchain indexer available (Sentio benchmark, May 2025). If you are building onchain and need indexing that keeps up with your chain, check out the docs, run the benchmarks yourself, or come talk to us about your data needs.

Stay tuned for more updates by subscribing to our newsletter, following us on X, or hopping into our Discord.

Subscribe to our newsletter

Website | X | Discord | Telegram | GitHub | YouTube | Reddit

April was a big step forward for AI-assisted indexing on Envio. We launched the Envio Docs MCP Server and a new Quickstart with AI guide for building or migrating indexers with Claude, Cursor, and other AI coding assistants. HyperIndex v3.0.0 alpha.21 ships with an experimental ClickHouse Sink, improved multiple data-sources support, and an updated testing framework with three ways to feed events. We also released the Polymarket V2 Indexer, which is now powering a new data-driven series breaking down the actual top-PnL traders on Polymarket. HyperSync added Monad trace support with full history from block 0, Envio went live on Tempo, and much more. The team was also at EthCC[9] in Cannes.

Let's dive in.

HyperIndex v3.0.0 Alpha: alpha.20 & alpha.21​

Continuing steady progress on V3 across indexing resilience, testing, analytics, and developer experience.

Improved Multiple Data-Sources Support​

HyperIndex now handles data source switching more intelligently.

After switching to a fallback source, HyperIndex automatically attempts to recover to the primary source 60 seconds later, rather than staying stuck on the fallback until it goes down or the indexer is restarted. The logic for choosing which source to use next has also been improved, alongside stricter enforcement of source usage configured for live mode.

The result: better indexing resilience, less vendor lock-in, and more predictable failover behaviour in production.

Testing Framework Highlights​

Our testing framework has matured with three ways to feed events, making it easier to write tests against the same indexer that runs in production. No database, no Docker, no manual mock wiring.

• Auto-exit: zero config, processes the first block with matching events
• Explicit block range: deterministic CI snapshots
• Simulate: typed synthetic events, no network needed

import { describe, it } from "vitest";
import { createTestIndexer } from "generated";

describe("ERC20 indexer", () => {
  it("processes the first block with events", async (t) => {
    const indexer = createTestIndexer();

    const result = await indexer.process({ chains: { 1: {} } });

    // Auto-filled by Vitest on first run, just review and commit
    t.expect(result).toMatchInlineSnapshot(`
      {
        "changes": [
          {
            "Transfer": {
              "sets": [
                {
                  "blockNumber": 10861674,
                  "from": "0x0000000000000000000000000000000000000000",
                  "id": "1-10861674-23",
                  "to": "0x41653c7d61609D856f29355E404F310Ec4142Cfb",
                  "transactionHash": "0x4b37d2f343608457ca...",
                  "value": 1000000000000000000000000000n,
                },
              ],
            },
            "block": 10861674,
            "chainId": 1,
            "eventsProcessed": 1,
          },
        ],
      }
    `);
  });
});

Experimental ClickHouse Sink​

HyperIndex V3 Alpha introduces an experimental ClickHouse Sink. Postgres remains the primary database, with your entity data additionally replicated to ClickHouse for analytics workloads.

ClickHouse is a columnar database built for heavy analytical queries on datasets in the 100s of GBs or TBs, a natural fit for onchain data which can easily reach billions of events for a single token. If your indexer is powering a dashboard, leaderboard, historical chart, or any reporting layer on top of a large dataset, ClickHouse is the right tool for that read path.

Enable it on Envio Cloud by setting four environment variables:

• ENVIO_CLICKHOUSE_SINK_HOST
• ENVIO_CLICKHOUSE_SINK_DATABASE
• ENVIO_CLICKHOUSE_SINK_USERNAME
• ENVIO_CLICKHOUSE_SINK_PASSWORD

Currently supported on the Dedicated Plan only, and you need to bring your own ClickHouse instance. Managed ClickHouse is coming to Envio Cloud, fill out this form to be one of the first users.

Read the full walkthrough here: https://docs.envio.dev/blog/clickhouse-storage-hyperindex-v3

See the full release notes. Star us on GitHub ⭐

The Top Hundred Polymarket Traders​

We released the Polymarket V2 Indexer this month, a drop-in reference for teams wanting to collect all v2 market data. It covers the new v2 markets end-to-end, designed to scale alongside Polymarket's growth.

Check it out on GitHub: https://github.com/enviodev/polymarket-v2-indexer

Off the back of the release, we kicked off a data-driven series breaking down the actual top-PnL traders on Polymarket. 2.66 million wallets have traded on the platform, and the top 100 captured $853 million in profit between them. None of them are clicking buttons on a phone app between sips of beer.

Day 1 profiles "Bids On Everything", the wallet ranked #24 by realized PnL with roughly $24 million net profit across 2,698,796 fills, 44,954 simultaneous markets, and 289 active days. The strategy in one sentence: post buy orders on every outcome token of every binary market at every price level, then merge YES + NO pairs for one dollar whenever both fill.

It's a strong example of the kind of analysis you can run when you have full historical and real-time access to v2 market data. Stay tuned for more!

Read the full breakdown: https://x.com/jonjonclark/status/2049067586046816561?s=20

Envio Docs MCP Server​

Envio docs now speak AI. Plug your AI coding assistant (Claude Code, Cursor, Copilot, and more) straight into our docs with the new Envio Docs MCP Server.

• Always up-to-date
• Instant accurate context
• Easy setup

The biggest shift in AI workflows isn't better prompts, it's better context, and that's exactly what the MCP Server solves. Your assistant pulls live documentation on demand instead of relying on stale training data.

Setup guide and more here: https://docs.envio.dev/blog/envio-docs-mcp-server

Quickstart with AI​

Build or migrate an indexer end-to-end using Claude, Cursor, or any other AI coding assistant with our new Quickstart with AI guide.

What's included:

• Live docs via MCP
• Non-interactive init
• Built-in Claude skills
• AI-assisted subgraph migration
• Programmatic deploys via the envio-cloud CLI

This pulls everything together into a single agentic workflow, from scaffolding to deployment, without touching a config file manually.

Get started here: https://docs.envio.dev/docs/HyperIndex/quickstart-with-ai

Concentrated Liquidity on Uniswap v4​

Envio was a Sapphire sponsor of EthCC[9], held at Palais des Festivals in Cannes from March 30 to April 2, 2026.

JonJon took to the Monroe Stage with his talk "From xy=k to Ticks: Seeing Concentrated Liquidity on Uniswap v4 in Real Time", walking through the jump from xy=k to ticks on Uniswap v4, with a real-time visual layer tracking active liquidity and pool behaviour across chains.

Big thanks to the EthCC team, sponsors, organisers, and volunteers for putting on such a great event. Had a great time connecting with some incredible teams and builders across the week, and a special thanks to everyone who swung by our booth.

Monad Traces Live on HyperSync​

Monad traces are live on HyperSync, with full history from block 0.

Stream all Monad trace data in minutes and export it to CSV using our new export tool. Ideal for teams running deep onchain analytics, MEV research, or custom pipelines on top of Monad's execution traces.

Export tool on GitHub: https://github.com/enviodev/export-monad-traces

Envio is Live on Tempo​

Envio is live on Tempo, the blockchain built for stablecoin payments at scale.

Index and query real-time payment data, build fully customisable data pipelines, and query millions of events up to 2000x faster than traditional RPC.

Easy, fast, and fully customisable.

Original post on X: https://x.com/i/status/2042577679380013222

How to Track Native ETH Transfers Using HyperSync​

Tracking native ETH transfers onchain is trickier than ERC-20 transfers. There's no event log to index, so you have to parse traces, which is slow over standard RPC.

Our new tutorial walks through how to use HyperSync's native trace filtering to stream transfers by filtering on call_type=call with a value threshold. It includes a full working example using the Node.js client in a Bun project, streaming results until 10 transfers above 0.005 ETH are collected.

HyperSync trace support is currently available on Ethereum, Base, Arbitrum, Gnosis, and Monad.

Read the full tutorial: https://docs.envio.dev/blog/tracking-native-eth-transfers-hypersync

Current & Upcoming Events & Hackathons​

• ETHConf - New York: June 8th -> 10th (sponsoring)

Featured Developer: Claude​

This month's featured developer is Claude.

A shoutout to Anthropic's Claude, who has become a familiar name in the developer community and a strong collaborator for teams building with AI assistants. With the launch of the Envio Docs MCP Server and Quickstart with AI guide this month, we're excited to see how the community continues to build with AI alongside Envio.

More to come.

Playlist of the Month​

▶ Open Spotify

Build With Envio​

Envio is a multichain EVM blockchain indexer for querying real-time and historical data. If you're working on a Web3 project and want a smoother development process, Envio's got your back(end). Check out our docs, join the community, and let's talk about your data needs.

Stay tuned for more monthly updates by subscribing to our newsletter, following us on X, or hopping into our Discord for more up-to-date information.

Subscribe to our newsletter 💌

Website | X | Discord | Telegram | GitHub | YouTube | Reddit

Why We Built ClickHouse Storage​

Since day one, HyperIndex has used Postgres as its primary database. Postgres is battle-tested, runs well for small and large indexers alike, and gives you GraphQL out of the box through Hasura. It is a solid default for almost every indexer.

But over the last few months, enough teams have asked the same question that we knew we had to do something about it: can we replicate the data to ClickHouse?

Most teams asking were building on DEXes, or DeFi protocols where data volumes are large enough that even a well-tuned Postgres query to do analytics starts to slow down. That is exactly the workload ClickHouse is built for. So in HyperIndex V3, we shipped experimental ClickHouse Storage support.

V3 is in alpha at the time of writing, and ClickHouse Storage is flagged as experimental. Both will be marked stable once V3 reaches its stable launch, at which point you can use ClickHouse Storage in production without the experimental label. If you want to try ClickHouse on Envio Cloud today, fill out this form, it is currently supported only on the Dedicated Plan.

What is ClickHouse?​

ClickHouse is a columnar database designed for analytical workloads. Most transactional databases, including Postgres, store data row by row, which is fast when you are reading or writing a single record by its primary key but slow when you are scanning millions of rows to compute an aggregate. A columnar database flips that around, values for each column are stored together on disk, so aggregations across billions of rows finish in seconds instead of minutes.

This matters a lot for blockchain data. For example, just USDC on Ethereum has hundreds of millions of Transfer events. Add in every other chain USDC is deployed on, and you cross into the billions. Now imagine you want to group those transfers by sender, bucket them by hour, and compute the sum per chain. A row store will struggle no matter how many indexes you throw at it. A columnar engine was built for exactly that kind of query.

Onchain data has three properties that make it a near-perfect match for ClickHouse:

• Append-heavy - once an event is emitted, it rarely changes.
• Highly structured - every event of the same type has the same shape.
• Queried in aggregate - most analytics questions are counts, sums, averages, or time-bucketed views, not single-row lookups.

If your indexer is powering a dashboard, a leaderboard, historical charts, or any kind of reporting layer on top of a large dataset, ClickHouse is the right tool for that read path. Postgres is still great for your day-to-day indexer writes and GraphQL reads, ClickHouse Storage just gives you a second surface that is optimised for the analytical side.

How ClickHouse Storage Works in HyperIndex​

HyperIndex runs two storage layers in parallel. Postgres remains the primary indexed state that your app queries through GraphQL. ClickHouse is a purpose-built analytics mirror, not a fallback. On every batch, events parsed by your handlers are flushed to both: Postgres gets the current state, ClickHouse gets the history.

ClickHouse Storage writes two things:

• Entity history tables - every change to every entity as an INSERT, tagged with a SET or DELETE action and a checkpoint ID linking it to a specific block. ClickHouse never receives an UPDATE, it is optimised for inserts, not mutation.
• Checkpoints table - one row per processed block with block number, block hash, chain ID, and event count.

"Current state" is served by views that sit on top of the history table and select the latest SET row per entity ID. You get a full audit trail for free, and you can query state at any past block just by filtering on checkpoint ID.

Reorgs are handled by a single DELETE per table that removes all rows above the reorg checkpoint, the append only model makes rollbacks trivial, with no partial state to unwind. Schemas are auto-created on startup from your schema.graphql, with type mappings handled for you (BigInt → Decimal, Date → DateTime64, enums → Enum8/Enum16, and so on). No DDL to write.

Both backends are restart- and reorg-resistant, the checkpoints table lets the indexer resume cleanly after a crash, and Prometheus metrics carry a storage-name label so you can monitor Postgres and ClickHouse write paths separately.

How to Enable ClickHouse on Envio Cloud​

To scaffold a new V3 alpha indexer, run:

pnpx envio init

This will set up a fresh project on the latest alpha release. Enable both storage backends in config.yaml:

storage:
  postgres: true
  clickhouse: true

ClickHouse connection is configured via four environment variables, set them in your .env file for local development (envio dev will spin up a ClickHouse Docker container alongside), or from the Envio Cloud dashboard for hosted deployments:

Once those are set, HyperIndex will replicate the same entity data it writes to Postgres into your ClickHouse database. Every entity in your schema.graphql becomes a ClickHouse table with a matching schema, so you can point your analytics queries, BI tools, or dashboards directly at ClickHouse, no extra ETL pipeline needed.

Postgres and GraphQL keep working exactly as they do today. ClickHouse Storage is additive: you get a second read-optimised surface without giving up the one you already have.

Who Can Use ClickHouse Storage?​

Right now, ClickHouse Storage is available on the Dedicated Plan, and you need to bring your own ClickHouse instance. If you are already running ClickHouse (or you are comfortable standing one up), you can plug it into your indexer today using the environment variables above.

We are also working on a managed ClickHouse offering on Envio Cloud so teams won't have to run their own instance. If you want to be one of the first users when that rolls out, fill out this form. Tell us a bit about your indexer and the kind of analytics you are trying to run and we will get you onboarded.

Get Started​

ClickHouse Storage is available today on the Dedicated Plan for teams running their own ClickHouse instance. For teams that want managed ClickHouse on Envio Cloud, fill out the waitlist form to be one of the first users when it rolls out.

• Envio docs: https://docs.envio.dev/
• HyperIndex V3 migration guide: https://docs.envio.dev/docs/HyperIndex/migrate-to-v3
• Managed ClickHouse waitlist: https://forms.gle/P19S7KXYfdHQM8J69
• Discord: https://discord.gg/envio
• Telegram: https://t.me/+kAIGElzPjApiMjI0
• Follow us on X: https://x.com/envio_indexer

Frequently Asked Questions​

ClickHouse vs Postgres: When Should I Use Which?​

Use Postgres for transactional reads, your GraphQL API, single-entity lookups, and anything latency-sensitive that your application serves directly to users. Use ClickHouse for analytical queries: large aggregations, time-bucketed views, leaderboards, historical charts, and BI dashboards. The rule of thumb is that if a query scans millions of rows to compute a result, it belongs on ClickHouse. If a query fetches a specific record by ID, it belongs on Postgres.

Can I Use BI Tools Like Metabase, Superset, or Grafana With ClickHouse Storage?​

Yes. Once ClickHouse Storage is running, your ClickHouse database is a standard ClickHouse instance as far as any external tool is concerned. Any tool with a ClickHouse connector (Metabase, Superset, Grafana, Tableau, Hex, Redash, and most others) can connect directly. Point it at the same host, database, and credentials you configured on Envio Cloud.

Does ClickHouse Storage Slow Down My Indexer?​

ClickHouse Storage writes in the same batches HyperIndex uses for Postgres, so there is some additional write work per batch. In practice, ClickHouse inserts are designed to be fast and writes are batched, so the overhead is small for most workloads. If you are seeing lag, the usual culprit is your ClickHouse instance's write capacity or network latency between the indexer and ClickHouse, not HyperIndex itself.

How Do I Query Past State in ClickHouse?​

Because the history tables store every change with a checkpoint ID tied to a specific block, you can reconstruct state at any historical point by filtering on checkpoint ID. This gives you time-travel queries for free, without needing snapshots or a separate archive. The latest-state views handle the "current state" case automatically, so you only reach for checkpoint filtering when you specifically want a past view.

Can I Add Custom Tables or Indexes to My ClickHouse Database?​

ClickHouse Storage manages its own tables based on your schema.graphql and will create them on startup. You can add your own tables, materialised views, or downstream aggregations in the same database alongside the managed tables, as long as you don't modify or collide with them. A common pattern is to build materialised views on top of the history tables to pre-aggregate heavy queries.

What Happens If My ClickHouse Instance Goes Down?​

Postgres and your GraphQL API keep serving as normal. ClickHouse Storage is additive, so a ClickHouse outage does not stop your indexer from processing events or serving queries from Postgres. Once ClickHouse is back, replication resumes from where it left off using the checkpoints table.

Is There a Cost Difference Between Running With and Without ClickHouse Storage?​

On Envio Cloud, ClickHouse Storage itself is available on the Dedicated Plan. The main cost consideration is your ClickHouse instance, you are bringing your own, so storage, compute, and egress costs depend on your provider (ClickHouse Cloud, self-hosted, Altinity, etc.) and the size of your dataset. Entity history tables grow faster than Postgres state tables because every change is stored rather than just the current value.

Why Did Envio Build This Instead of Just Recommending an ETL Pipeline?​

Running a separate ETL pipeline (CDC from Postgres to ClickHouse, a Kafka connector, a custom script) adds another system to maintain, another place for data to drift, and another source of lag. Building ClickHouse Storage into HyperIndex means entity data lands in ClickHouse as part of the same batch that writes to Postgres, with reorg handling and schema management already solved. One indexer, two read surfaces, no extra pipeline.

Build With Envio​

Envio is the fastest independently benchmarked EVM blockchain indexer for querying real-time and historical data. If you are building onchain and need indexing that keeps up with your chain, plus analytics that keep up with your indexer, check out the docs, run the benchmarks yourself, and come talk to us about your data needs.

Stay tuned for more updates by subscribing to our newsletter, following us on X, or hopping into our Discord.

Subscribe to our newsletter 💌

Website | X | Discord | Telegram | GitHub | YouTube

Tracking native token transfers onchain is trickier than ERC-20 transfers. There's no event log to index, so you have to dig through traces. With a standard RPC node, that means calling eth_traceBlock and iterating every trace in every block, which is slow. HyperSync gives you a faster alternative: a data retrieval layer with native trace filtering.

Prerequisites​

We are going to use Bun for this article, so make sure you have it installed. If you want to use another runtime that supports TypeScript, you can do that too.

You will also need an Envio API token to access HyperSync. If you don't have one, go to envio.dev/app/api-tokens to create one. Step-by-step instructions are at docs.envio.dev/docs/HyperSync/api-tokens.

HyperSync & Queries​

HyperSync is optimized for data retrieval, not consensus, so it's far faster than RPC nodes. To fetch data, you send a query describing what you want and HyperSync returns only that data.

A typical query looks like this:

{
  "fromBlock": 0,
  "transactions": [
    { "from": ["0x5a830d7a5149b2f1a2e72d15cd51b84379ee81e5"] },
    { "to": ["0x5a830d7a5149b2f1a2e72d15cd51b84379ee81e5"] }
  ],
  "fieldSelection": {
    "transaction": ["BlockNumber", "Hash", "From", "To", "Value"]
  }
}

Every query has three main parts: fromBlock, a filter section (one of transactions, blocks, logs, or traces), and fieldSelection. See the full query reference for all available options.

Filtering for Native Transfers​

Native ETH transfers occur only in traces where call_type is call — not staticcall or delegatecall. Filtering on callType directly is more efficient than filtering on trace kind, since it lets HyperSync skip irrelevant trace types upfront.

Building the Fetcher​

Setup​

Create a new Bun project and install the HyperSync client:

bun init -y && bun install @envio-dev/hypersync-client

Add your API token to a .env file. If you don't have one, generate it at envio.dev/app/api-tokens.

ENVIO_API_TOKEN=your_token_here

Note: HyperSync trace support is currently available on Ethereum, Base, Arbitrum, Gnosis, and Monad. Reach out if you need trace support for other chains.

Imports & Helpers​

import { HypersyncClient, type TraceField } from "@envio-dev/hypersync-client";

We'll filter out dust transfers using a minimum threshold and format values as human-readable ETH:

const THRESHOLD_WEI = BigInt("5000000000000000"); // 0.005 ETH
const WEI_PER_ETH = BigInt("1000000000000000000"); // 1 ETH
const DECIMALS = 6;

function weiToEth(wei: bigint): string {
  const whole = wei / WEI_PER_ETH;
  const remainder = wei % WEI_PER_ETH;
  const remainderStr = remainder.toString().padStart(18, "0").slice(0, DECIMALS);
  return `${whole}.${remainderStr}`;
}

Creating the Client​

Use the Ethereum traces endpoint:

const client = new HypersyncClient({
  url: "https://eth-traces.hypersync.xyz",
  apiToken: process.env.ENVIO_API_TOKEN!,
});

Query​

Request only call type traces and select the fields we care about:

const query = {
  fromBlock: 22000000,
  traces: [
    {
      callType: ["call"],
    },
  ],
  fieldSelection: {
    trace: ["From", "To", "Value", "CallType", "BlockNumber"] as TraceField[],
  },
};

Streaming Results​

HyperSync offers two fetch modes: get (single response) and stream (continuous). We'll stream and stop once we've collected 10 transfers above the threshold:

console.log("Fetching native transfers (call_type=call, value > 0.005 ETH)...\n");

const results: { from: string; to: string; valueEth: string }[] = [];

const stream = await client.stream(query, {});

outer: while (true) {
  const res = await stream.recv();

  if (res === null) break; // stream exhausted

  if (res.data?.traces) {
    for (const trace of res.data.traces) {
      if (trace.value === undefined || trace.value === null) continue;
      if (trace.value <= THRESHOLD_WEI) continue;

      results.push({
        from: trace.from ?? "unknown",
        to: trace.to ?? "unknown",
        valueEth: weiToEth(trace.value),
      });

      if (results.length >= 10) break outer;
    }
  }
}

await stream.close();

if (results.length === 0) {
  console.log("No results found.");
} else {
  console.table(
    results.map((r) => ({
      From: r.from,
      To: r.to,
      "Value (ETH)": r.valueEth,
    }))
  );
}

Run it with:

bun run index.ts

Next Steps​

We only used callType as a filter here. From this starting point you can track a specific wallet by adding from or to address filters to the trace selection, narrow further using other TraceSelection fields like sighash or kind, or switch the endpoint to another HyperSync trace-enabled network to run the same query across chains.

See the HyperSync query reference for the full TraceSelection schema and field list.

Frequently Asked Questions​

What Is HyperSync?​

HyperSync is Envio's high-performance blockchain data retrieval layer, built as an alternative to traditional JSON-RPC endpoints. It gives developers direct access to onchain data up to 2000x faster than standard RPC methods, with client libraries for Python, Rust, Node.js, and Go across 87+ EVM chains.

Why Can't I Track Native ETH Transfers Using Event Logs?​

Native ETH transfers don't emit events. The ERC-20 Transfer event is a standard contract event, but native ETH moves at the protocol level and only shows up in transaction traces. To track them, you have to query traces directly.

What's the Difference Between call_type and kind When Filtering Traces?​

kind is the trace type (call, create, suicide, reward). call_type is the sub-type of a call trace (call, delegatecall, staticcall). Native ETH transfers only occur when call_type is call, so filtering on call_type directly is more efficient than filtering on kind and then narrowing down.

Which Chains Support Trace Queries on HyperSync?​

Trace support is currently available on Ethereum, Base, Arbitrum, Gnosis, and Monad. If you need trace support on another chain, reach out at nikhil@envio.dev.

How Fast Is HyperSync Compared to RPC for Trace Queries?​

HyperSync is up to 2000x faster than standard JSON-RPC for data retrieval workloads. For trace queries specifically, the gap is even wider since RPC trace methods like eth_traceBlock are among the slowest calls on most nodes.

Can I Use This Approach for ERC-20 Transfers Too?​

Yes, but for ERC-20 you'd query logs instead of traces since ERC-20 contracts emit a Transfer event. Use the logs filter with the Transfer event signature as topic0. See the HyperSync query reference for details.

Build With Envio​

Envio HyperIndex is independently benchmarked as the fastest EVM blockchain indexer available. If you are building onchain and need indexing that keeps up with your chain, check out the docs, run the benchmarks yourself, or come talk to us about your data needs. Stay tuned for more updates by subscribing to our newsletter, following us on X, or hopping into our Discord. Subscribe to our newsletter 💌

Website | X | Discord | Telegram | GitHub | YouTube | Reddit

Envio now has a hosted MCP server for its documentation. Point your AI coding assistant at it and it can search and read Envio docs on demand. No more copy-pasting links into chat and no more watching your model confidently invent a config field that does not exist.

Whether you are building an indexer, querying onchain data with HyperSync, or just exploring what Envio can do, the MCP server gives your agent a direct line to the real documentation while it works.

What is an MCP server?​

Model Context Protocol (MCP) is an open standard for connecting AI assistants to external tools and data sources. An MCP server exposes a set of capabilities, like searching a knowledge base, fetching a document, or calling an API, that any MCP-compatible client can call on demand.

In practice, this means you can give your AI assistant a stable, structured way to reach into a real system, instead of relying on whatever happened to be in its training data or fumbling around the web trying to find something relevant.

What is the Envio Docs MCP Server?​

The Envio Docs MCP server is a hosted MCP server that gives AI coding assistants direct access to Envio's documentation. It exposes two tools:

The server is hosted at: https://docs.envio.dev/mcp

Why this matters for Envio users​

Without an MCP server, an AI assistant trying to use Envio docs is mostly working blind. It either falls back on whatever it remembers from training, or hops between links and fetches raw HTML pages to parse out the parts it needs. That is slow, noisy, and easy to get wrong: the model ends up sifting through navigation, sidebars, and styling just to find a single config option.

The Envio Docs MCP server replaces that with a structured way for your assistant to ask the docs a question directly. Instead of scraping pages, it can search across all of Envio's documentation and pull back exactly the content it needs.

That means:

• Always up to date. The MCP server reads from the same docs site you read. When the docs change, your assistant sees the change immediately.
• Grounded in source docs. Your agent looks up the exact answer in the documentation instead of guessing.
• Less copy-paste. No more shuttling doc snippets back and forth between your browser and your editor.
• Useful across the whole stack. Whether you are building an indexer, pulling onchain data with HyperSync, or exploring Envio Cloud, your assistant has the right context for the job.

How to connect it​

Claude Code​

claude mcp add --transport http envio-docs https://docs.envio.dev/mcp

Cursor / VS Code​

Add the following to your MCP configuration (.cursor/mcp.json or your VS Code MCP settings):

{
  "mcpServers": {
    "envio-docs": {
      "url": "https://docs.envio.dev/mcp"
    }
  }
}

Other MCP clients​

Point any MCP-compatible client to https://docs.envio.dev/mcp using the Streamable HTTP transport.

For full, always-current setup instructions, see the Envio Docs MCP Server guide.

Once connected, your assistant can search the docs and pull back full pages whenever it needs context, with no extra prompting from you.

Frequently Asked Questions​

What Is an MCP Server?​

An MCP server is a server that implements the Model Context Protocol, an open standard for connecting AI assistants to external tools and data sources. It lets AI coding assistants like Claude Code and Cursor access real, structured information on demand rather than relying on training data.

What Is the Envio Docs MCP Server?​

The Envio Docs MCP server is a hosted server at https://docs.envio.dev/mcp that gives AI coding assistants direct access to Envio's documentation. It supports two operations: searching across all docs and fetching the full content of any documentation page.

Which AI Assistants Does the Envio MCP Server Support?​

The Envio Docs MCP server works with any MCP-compatible client. Setup instructions are available for Claude Code and Cursor / VS Code. Any other client that supports the Streamable HTTP transport can connect using the endpoint URL directly.

Is the Envio MCP Server Always Up to Date?​

Yes. The MCP server reads directly from the live Envio docs site. When documentation is updated, your assistant has access to the latest version immediately.

How Do I Get Started with Envio HyperIndex?​

Run pnpx envio init to scaffold your first indexer in minutes. Write event handlers in TypeScript, configure your chains and contracts in config.yaml, and deploy to Envio Cloud for managed hosting. See the HyperIndex overview and getting started guide for full documentation.

Build With Envio​

Envio HyperIndex is independently benchmarked as the fastest EVM blockchain indexer available. If you are building onchain and need indexing that keeps up with your chain, check out the docs, run the benchmarks yourself, or come talk to us about your data needs.

Stay tuned for more updates by subscribing to our newsletter, following us on X, or hopping into our Discord.

Subscribe to our newsletter 💌

Website | X | Discord | Telegram | GitHub | YouTube | Reddit

Polymarket is one of the most data-intensive protocols in Web3. Every trade, position, fee, liquidity event, and oracle resolution across its entire prediction market ecosystem lives onchain on Polygon. Querying any of it meaningfully requires a serious blockchain indexer.

For years, Polymarket's data infrastructure relied on 8 independent subgraphs on The Graph, each written in AssemblyScript, each tracking a separate domain, all running since 2021. This post documents how all 8 were replaced with a single Envio HyperIndex indexer, syncing over 4,000,000,000 events in 6 days on Polygon Mainnet.

The indexer is fully open source: github.com/enviodev/polymarket-indexer

Envio HyperIndex: The Fastest Blockchain Indexer Available​

Envio is a real-time multichain blockchain indexing framework for EVM chains. Developers write event handlers in TypeScript and deploy a single indexer that covers multiple contracts, chains, and domains simultaneously.

HyperIndex is independently benchmarked as the fastest blockchain indexer available. In the Uniswap V2 Factory benchmark run by Sentio in May 2025, HyperIndex completed in 1 minute, 143x faster than The Graph and 15x faster than the nearest competitor. In the LBTC benchmark (April 2025), HyperIndex completed in 3 minutes versus 3 hours 9 minutes for The Graph.

This performance comes from HyperSync, Envio's proprietary data engine. Instead of querying RPC endpoints block by block, HyperSync fetches filtered event data in bulk directly from a purpose-built data lake, delivering up to 2,000x faster data access than standard RPC. Polygon is one of 87+ EVM chains supported with native HyperSync coverage.

See full list of HyperSync supported networks here: https://docs.envio.dev/docs/HyperSync/hypersync-supported-networks

For a full breakdown of how HyperIndex compares across all major blockchain indexers, see the complete benchmark comparison.

The Problem: 8 Subgraphs, One Protocol, 4 Years of Fragmentation​

Polymarket's indexing infrastructure grew organically alongside the protocol. By the time the architecture was fully established, 8 independent subgraphs were running in parallel on The Graph:

The core problem with this setup is shared contracts. A single ConditionalTokens event was being listened for and processed independently across 3 or 4 separate subgraphs. Every shared event meant redundant processing, redundant infrastructure, and fragmented data that required joining across multiple APIs at query time. Handlers were written in AssemblyScript, a stricter WebAssembly-compiled subset of TypeScript, adding tooling overhead and limiting what logic could run inside a handler.

The Solution: One HyperIndex Indexer on Polygon​

Handler Merging​

The defining architectural decision in this indexer is handler merging. Rather than running separate listeners per domain for the same contract event, a single handler fires and updates all relevant entities simultaneously.

A ConditionalTokens.PositionSplit event previously triggered separate processing across the open-interest, activity, and pnl subgraphs. In the unified HyperIndex indexer, one handler fires once and simultaneously updates open interest, records the split activity, and adjusts user PnL positions. The event is processed once. That's it.

The full handler structure:

src/
  handlers/
ConditionalTokens.ts       # Open interest + activity + PnL (merged from 4 subgraphs)
Exchange.ts                # Orderbook + PnL
NegRiskAdapter.ts          # Open interest + activity + PnL
FixedProductMarketMaker.ts # FPMM analytics + PnL + LP tracking
FPMMFactory.ts             # Dynamic contract registration
FeeModule.ts               # Fee refund tracking
UmaSportsOracle.ts         # Sports oracle
Wallet.ts                  # Wallet creation + USDC balances