HyperIndex, Envio's multichain indexer built on a batched query layer

An indexer whose selling point is the query layer underneath

HyperIndex is described as Envio's full-featured blockchain indexing framework, and what it does is transform onchain events into structured, queryable databases with GraphQL APIs, built for developers who care about performance and a clean local experience.

The interesting part is that the indexer is not the product. The product is HyperSync, which the documentation calls Envio's proprietary data engine, and the README states that it delivers up to 2000x faster data access than traditional RPC endpoints, which it describes as the difference between syncing in minutes instead of days.

The mechanism it describes is straightforward. Instead of making individual RPC calls per block, HyperSync retrieves multiple data points per round trip with advanced filtering. HyperSync is a purpose-built, Rust-based query layer, and the README attributes the speed to cutting out the overhead of per-block requests.

The claim about where indexers are usually bottlenecked is worth noting. The README says most blockchain indexers are bottlenecked by RPC, and that HyperIndex is not, and describes HyperSync as making historical backfills genuinely fast.

The audience is a developer building a DeFi dashboard, protocol analytics product, block explorer, stablecoin monitor, liquidation tracker, oracle comparison, or NFT explorer, and the README lists a set of applications already running in production. v4.xyz is the hub for Uniswap V4 data across 10 chains, Stable Volume monitors stablecoin transactions across more than 10 chains, Stable Radar is a USDC transaction dashboard, Liqo tracks liquidations for DeFi lending protocols, Safe Stats covers Safe multisig activity, Oracle Wars compares oracle prices, Chain Density does transaction and event density analysis for an address across more than 70 chains, and LogTUI is a terminal UI for monitoring blockchain events in real time.

The last push to the repository was on 2026-10-22, the recorded releases are v3.14.1 from 2026-10-08, v3.14.0-subgraph from 2026-10-06 and v3.14.0 from 2026-10-05, and the homepage is envio.dev.

The performance numbers, and who ran them

The README leads with the claim that HyperIndex is the fastest independently benchmarked multichain blockchain indexer, and it gives two specific comparisons from benchmarks run by Sentio.

For the Uniswap V2 Factory, measured in May 2025, the README states HyperIndex completed in 1 minute, which it describes as 15x faster than the nearest competitor, Subsquid, 143x faster than The Graph and 158x faster than Ponder. For the LBTC Token with RPC calls, measured in April 2025, the README states HyperIndex completed in 3 minutes against 3 hours 9 minutes for The Graph.

Two things to note about how to read these. The comparison is attributed to Sentio rather than to the project, which is why the documentation uses the phrase independently benchmarked, and the benchmark page and the full results are linked from the README. And every figure is a wall-clock sync time for a specific historical workload, so the ratio depends on the chain, the contract and the amount of history. A token with RPC calls, which is the second benchmark, is the case where the gap is largest, and that is also the case where a naive implementation is slowest.

The feature list adds the other performance claims. Historical backfills at 25,000+ events per second, up to 2000x faster than traditional RPC via HyperSync which is enabled by default with no configuration required, and sync times reduced from days to minutes. It also lists fallback RPC support for reliability without touching your indexer code.

That last item is the one to pay attention to. The 2000x figure is a property of HyperSync, and HyperSync has a supported network list. On a chain where it is not available, or on a chain that is having a bad day, your indexer falls back to RPC, and the speed you bought is the speed of the fallback. The README says you can switch between HyperSync and RPC at any time, and lists 79+ EVM chains with first-class HyperSync support plus any EVM chain via RPC, so the fallback is a normal operating mode rather than an edge case.

Three files define an indexer

The getting started flow is one command, and the scaffolding it produces is three files.

pnpx envio init

The documentation states that this scaffolds your entire indexer project, config, schema and handler functions in seconds, and that you can generate from a contract address, choose from templates, or start from an existing example. The requirements are Node.js, with Docker needed only for local development.

The three files are the whole model.

`config.yaml` holds networks, contracts, events and indexing behaviour. `schema.graphql` is the shape of your indexed data. And `src/handlers` is your handler logic, written in TypeScript, JavaScript, or ReScript.

That is the design decision worth understanding. The GraphQL schema is the contract, and the handlers write into it. So your indexer is not a program that queries a database, it is a program that maintains a database whose shape you declared, and a GraphQL API is generated automatically from that schema. The indexer is a derived artifact of the schema, and the API is a derived artifact of the same schema.

The language choice follows from the same idea. The primary language of the repository is ReScript, and handlers can be TypeScript, JavaScript or ReScript, so a team picks the one its people are quickest in without giving up the generated API.

The repository layout supports the picture. There is a `packages/` directory, a `scenarios/` directory, a `Cargo.toml` whose workspace has a single member, `packages/cli`, and a `rust-toolchain.toml`. So the Rust in this repository is the CLI, and the indexer logic itself is in the scenarios and packages, which is a detail worth noticing if you expected a Rust indexer.

The `scenarios/` directory is also where the test story lives. The root package manifest runs the whole suite: a script that changes into `packages/envio-tests` and runs its tests, then the CLI tests, then a loop over the scenario directories, running `envio codegen` and the tests in each, including `test_codegen`, `fuel_test`, `svm_test`, `cross_chain_test` and `e2e_test`. The presence of a cross-chain scenario and separate SVM and Fuel scenarios tells you the multichain claim is exercised in CI rather than only asserted.

The features that go beyond a plain indexer

Beyond the performance story, the feature list has several items that are specific and unusual.

Auto-generation of an indexer directly from a smart contract address or ABI, with no manual setup required. Wildcard topic indexing, which means indexing by event signature across any contract rather than only the addresses you list. Factory contract support for one million or more dynamically registered contracts, which is the difference between indexing a protocol and indexing a protocol that deploys a new contract per user. Reorg handling built in, so a chain reorganisation does not corrupt the state. Onchain and off-chain data integration. External API actions triggered by blockchain events, so an indexer can call out to a service when something happens. And detailed logging and error reporting, which matters when a sync has been running for hours.

The multichain claim is stated as index EVM, SVM and Fuel blockchains from a single indexer. EVM, SVM and Fuel are three different virtual machine families, and a framework that indexes all three from one configuration is doing more than wrapping an EVM client.

The agentic development section is the newest claim and the one to treat most carefully. The README says HyperIndex is the default indexing framework for AI-assisted and agentic workflows via Envio's hosted service CLI, `envio-cloud`, and Claude skills, and that an agent can scaffold, configure and deploy a production-ready indexer without touching a config file, with a figure of 400,000 events indexed in about 20 seconds. It also describes a built-in testing framework purpose-built for AI-driven development, where agents write, run and iterate on handler tests in a tight feedback loop.

The repository has a `.claude/` directory and a `CLAUDE.md` at the top level, alongside a `CLAUDE.md` in the tree listing, so the agent-facing claim is backed by committed configuration rather than being only a marketing line.

Deployment is a three-way choice. A managed hosted service with static endpoints, built-in alerts and production-ready infrastructure, or self-hosted via Docker, and the README states there is no vendor lock-in because you can switch between HyperSync and RPC at any time.

The trade you are making, and where it stops

The honest way to assess this project is to separate the framework from the engine, because they have different licences and different constraints.

HyperIndex itself is the open part. The configuration file, the GraphQL schema, the handlers, the generated API and the local Docker development environment are all in this repository, and the test suite covers the scenarios. If you want to write an indexer, this is a good framework to write it in.

HyperSync is the closed part. The documentation calls it Envio's proprietary data engine, and it is where the 2000x and the 25,000 events per second come from. The consequence is straightforward. Your indexer is fast while the engine is reachable and covering your chain, and it is a normal RPC indexer when it is not. The fallback is supported and you can switch at any time, which is the right engineering answer, but it means the headline number describes a subset of the chains rather than all of them.

The second limit is the hosted service. The agentic development story, the `envio-cloud` CLI, the Claude skills and the managed deployment are all Envio services, and the repository includes a `.env.example` with a single line, `ENVIO_API_TOKEN=your-api-token-here`, which is the extent of the configuration surface the open repository expects you to touch for that path. The Rust CLI in `packages/cli` is the self-hosted path.

The third limit is the licence. The repository's licence type is not classified by GitHub, and the tree contains a `licenses/` directory, so the terms for the framework and for anything else in the tree are worth reading directly. That is the case where a commercial team should look before committing, because the distinction between the open framework and the proprietary engine has consequences for what you can redistribute.

What the project does well is the part that is hard to copy. Batch-fetching several blocks per round trip with filtering is a different query pattern from RPC, and the benchmark figures suggest it is a real one rather than a tuning exercise. For a team whose problem is a multi-year backfill, that difference is the entire value.

Editorial conclusion

HyperIndex suits a team building a DeFi dashboard, protocol analytics tool or block explorer that needs historical backfills to finish in minutes rather than days, and that wants the indexer written in TypeScript, JavaScript or ReScript against a GraphQL schema. It does not suit a team that needs the whole data path to be open source, because the performance comes from HyperSync, which the documentation calls proprietary. Verify first that the chains and contracts you need are in the supported list, that the fallback to RPC gives you an acceptable worst case, and that the licence terms in the repository cover the hosted service you intend to depend on.

Frequently asked questions

Official sources

1. enviodev/hyperindex on GitHub
2. Issues
3. Project website
4. README
5. Releases