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 86+ 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 86+ 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. 86+ 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 86+ 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 86+ 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@3.0.0-rc.0 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 86+ 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 86+ 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

Contracts Indexed​

The indexer covers the full surface area of Polymarket's onchain contracts on Polygon:

• Exchange + NegRiskExchange: OrderFilled, OrdersMatched, TokenRegistered
• ConditionalTokens: ConditionPreparation, ConditionResolution, PositionSplit, PositionsMerge, PayoutRedemption
• NegRiskAdapter: MarketPrepared, QuestionPrepared, PositionSplit, PositionsMerge, PayoutRedemption, PositionsConverted
• FPMMFactory: FixedProductMarketMakerCreation, with dynamic contract registration for all FPMM instances
• FixedProductMarketMaker (dynamic): FPMMBuy, FPMMSell, FPMMFundingAdded, FPMMFundingRemoved, Transfer
• FeeModule + NegRiskFeeModule: FeeRefunded
• UmaSportsOracle: GameCreated, GameSettled, MarketCreated, MarketResolved, and more
• USDC / RelayHub / SafeProxyFactory: Transfer, TransactionRelayed, ProxyCreation

Dynamic contract registration is handled through FPMMFactory. As new Fixed Product Market Maker instances are created onchain, the indexer registers them automatically without a redeployment.

Schema: 25+ Entity Types Across All Domains​

The schema covers every domain previously spread across 8 separate subgraphs, all queryable from a single GraphQL endpoint:

• Orderbook: OrderFilledEvent, OrdersMatchedEvent, Orderbook, OrdersMatchedGlobal, MarketData
• Open Interest: Condition, MarketOpenInterest, GlobalOpenInterest, NegRiskEvent
• Activity: Split, Merge, Redemption, NegRiskConversion, Position
• PnL: UserPosition, tracking amount, average price, realized PnL, and total bought per user per token
• FPMM: FixedProductMarketMaker, FpmmTransaction, FpmmFundingAddition, FpmmFundingRemoval, FpmmPoolMembership, Collateral
• Wallet: Wallet, GlobalUSDCBalance
• Fee Module: FeeRefunded
• Sports Oracle: Game, Market

Envio HyperIndex vs The Graph: Before and After​

The Results​

The indexer synced Polymarket's full onchain history on Polygon from block 3,764,531 to 100% sync in 6 days, processing over 4,000,000,000 events. The repo includes 29 tests covering all handler phases, including a HyperSync integration test.

Run it locally with pnpm dev and compare the data with data from Polymarket subgraphs.

Live deployment: https://envio.dev/app/moose-code/polymarket-indexer/7cad3ad

Why Teams Migrate to HyperIndex from The Graph​

Polymarket's setup before this migration is a pattern that shows up across the ecosystem: multiple subgraphs, shared contracts, AssemblyScript handlers, fragmented data. Here is what changes when teams move to HyperIndex:

Speed. HyperIndex is 143x faster than The Graph on independent benchmarks. For protocols with years of history like Polymarket, that directly translates to days versus months on historical sync.

TypeScript, not AssemblyScript. Handlers are standard TypeScript with generated types from both the schema and ABIs. Any npm package works. No WebAssembly compilation. No AssemblyScript-specific constraints.

One codebase. All domains, all contracts, all chains in a single indexer. One deployment to ship, one codebase to maintain, one endpoint to query.

Single source of truth. Cross-domain queries happen at the database level, not at the application layer. No joining across APIs at runtime.

Dynamic contract registration. Factory contracts that create new instances onchain register them automatically, without requiring a redeployment.

Envio offers white-glove migration support for teams moving from The Graph or any other indexer. The Polymarket indexer is an open-source reference for what a large-scale migration looks like end to end.

Frequently Asked Questions​

What Is Polymarket?​

Polymarket is the world's largest decentralized prediction market, built on Polygon. Users trade outcome shares on real-world events using USDC. All positions, trades, and settlements are handled entirely onchain via smart contracts with no central custodian.

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, trading interfaces, analytics tools, and onchain AI agents without querying slow RPC endpoints directly.

What Is the Fastest Blockchain Indexer?​

Envio 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 (Subsquid).

What Is HyperIndex?​

HyperIndex is a multichain blockchain indexing framework for EVM chains built by Envio. 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, for historical sync speeds not achievable through standard RPC polling.

What Is HyperSync?​

HyperSync is Envio's high-performance data engine. Instead of querying RPC endpoints block by block, HyperSync fetches filtered event data in bulk from a purpose-built data lake, delivering up to 2,000x faster data access than traditional RPC. 86+ EVM chains have native HyperSync coverage, with any EVM chain accessible via standard RPC.

How Do I Index Polymarket Data?​

The fastest way to index Polymarket data on Polygon is with Envio HyperIndex and HyperSync. The full open-source reference implementation is available at github.com/enviodev/polymarket-indexer. It covers all 8 domains of Polymarket's onchain activity and syncs the full history in 6 days.

How Long Does It Take to Index Polymarket's Full History on Polygon?​

Using Envio HyperIndex with HyperSync, the full historical sync of Polymarket's onchain data on Polygon, over 4,000,000,000 events from block 3,764,531, completed in 6 days.

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 also provides a full migration guide, a CLI validation tool to compare output between both endpoints, and white-glove migration support. The Polymarket indexer is a concrete open-source reference for a large-scale migration from The Graph.

Does HyperIndex Support Dynamic Contract Registration?​

Yes. New contract instances created onchain, like Polymarket's FPMM pools, are registered dynamically by a factory handler without requiring a redeployment.

What Chains Does Envio Support?​

Envio supports any EVM chain. 86+ EVM chains have native HyperSync coverage for maximum speed, including Polygon, Ethereum, Base, Arbitrum, Optimism, and more. Any EVM chain without native HyperSync support can be indexed via standard RPC.

Get Started​

The Polymarket indexer is fully open source and available as a production reference for anyone building on Polygon or migrating from The Graph. For a hands-on guide to streaming Polymarket trade data in real time, see How to Track Polymarket Trades Using Envio HyperSync.

• Repo: https://github.com/enviodev/polymarket-indexer
• Live deployment: https://envio.dev/app/moose-code/polymarket-indexer/7cad3ad
• 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

Build With Envio​

Envio HyperIndex is independently benchmarked as the fastest EVM blockchain indexer available. The Polymarket indexer is one example of what's possible. If you're building onchain, check out the docs, run the benchmarks yourself, or talk to us about your data needs.

Subscribe to our newsletter 💌

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

Since the rise of prediction markets like Polymarket and Kalshi, many people have been tracking activity on them to get a sense of where the money is going. If we try to track every trade on these prediction markets, you will see many people betting like $10 here, $15 there. If you want a stronger signal, then you should track trades with higher amounts, since those traders have more conviction in the outcome they are betting on.

In this article, we are going to build a tool with HyperSync where you can track Polymarket trades above a certain amount. We also have one feature where you can track trades from certain addresses. If you know some addresses from good traders, you can follow them too.

Prerequisites​

We are going to use Bun for this article, so make sure you have it installed. If not, please check the Bun documentation for installation instructions. If you want to use some other 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 it already, go to https://envio.dev/app/api-tokens and you can find your token there.

Here are step-by-step instructions for creating new API tokens: https://docs.envio.dev/docs/HyperSync/api-tokens#generating-api-tokens

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.

For this article, we are using HyperSync to stream real-time block heights and query Polymarket trade events on Polygon as they happen. Client libraries are available for Python, Rust, Node.js, and Go. HyperSync supports 86+ EVM chains, so the same approach works across any supported network.

OrderFilled Event​

Before we start writing the script, let’s talk about the OrderFilled event. This event is emitted when a trade has been filled, so these are confirmed trades where a user is buying or selling shares. Here is the event:

    event OrderFilled(
        bytes32 indexed orderHash,
        address indexed maker,
        address indexed taker,
        uint256 makerAssetId,
        uint256 takerAssetId,
        uint256 makerAmountFilled,
        uint256 takerAmountFilled,
        uint256 fee
    );

Most of the fields are self-explanatory, but we still haven’t answered one question: if this event is emitted for all orders, then how do we know which one is buy vs sell? If the value of makerAssetId is 0, then that is a buy order where the user is buying shares, and vice versa.

To calculate price per share for a buy trade, we can use makerAmountFilled and takerAmountFilled.

Price per share in a buy trade = makerAmountFilled / takerAmountFilled

To calculate per-share price in a sell trade, we just switch those values. Now that we have a basic understanding of what data to fetch and what that data tells us, we can start writing our script with Bun.

Using HyperSync Client​

To create a Bun project and install the HyperSync client along with Viem for decoding events, you can use the following commands:

mkdir track-trades && cd track-trades
bun init -y
bun add @envio-dev/hypersync-client viem

If you’re new to HyperSync clients, please start by going through these examples: https://docs.envio.dev/docs/HyperSync/hypersync-clients.

Let’s discuss how we are going to structure our script. Instead of streaming events directly, we are going to stream height. When we get a new height, we query HyperSync to fetch the data we need. Here is a visual representation of that:

Stream Height​

We already have a height-streaming example in the HyperSync Node client, and we are going to use that here. Open index.ts and paste the following snippet, then we can go over it.

import {
HypersyncClient,
  type Query, // for later use
  type QueryResponseData, // for later use
} from "@envio-dev/hypersync-client";
import { decodeEventLog } from "viem"; // for later use

async function main() {
  // Create hypersync client using the mainnet hypersync endpoint
  const client = new HypersyncClient({
    url: "https://polygon.hypersync.xyz",
    apiToken: process.env.ENVIO_API_TOKEN!,
  });

  // Create a height stream to monitor blockchain height changes
  const heightStream = await client.streamHeight();

  console.log("Height stream created. Listening for height updates...");

  // Track the last known height to detect changes

  try {
    while (true) {
      // Receive the next event from the height stream
      const event = await heightStream.recv();

      if (event === null) {
        console.log("Height stream ended by server");
        break;
      }

      // Handle different types of events
      switch (event.type) {
        case "Height":
          await fetchOrderFilledEvents(client, event.height); // will be explained later
          break;

        case "Connected":
          console.log(`Connected to height stream`);
          break;

        case "Reconnecting":
          console.log(
            `Reconnecting to height stream in ${event.delayMillis}ms due to error: ${event.errorMsg}`,
          );
          break;

        default:
          // Tells the typescript compiler that we have covered all possible event types
          const _exhaustiveCheck: never = event;
          throw new Error("Unhandled event type");
      }
    }
  } catch (error) {
    console.error("Error in height stream:", error);
  } finally {
    // Always close the stream to clean up resources
    await heightStream.close();
    console.log("Height stream closed");
  }
}

main().catch(console.error);

The first thing we are doing in main is creating the HyperSync client with url and apiToken (which should be stored in a .env file, so create one and store your Envio API token there).

We have a streamHeight function on the client that emits 3 types of events: Height, Connected, and Reconnecting. When we get a new Height event with the latest block number, we call fetchOrderFilledEvents, where our parsing logic will live.

After creating the stream with streamHeight, we need to listen to those events, so we created a while loop that checks data from .recv() and a switch statement to act on the event type we get. The rest is mostly boilerplate error handling, so we don’t need to go too deep into that.

Now we have our streaming logic, so we can move to fetchOrderFilledEvents, which will handle the event parsing.

fetchOrderFilledEvents Function​

This function will take the height we got from streamHeight and query blocks to get the events we want. Let’s start with a few basic things we need for fetching and decoding the data:

• Contract addresses
• ABI of the event
• Event signature hash (aka Topic0)

Here they are, so add them somewhere at the top of the file.

export const EXCHANGE_ADDRESSES = [
  "0x4bfb41d5b3570defd03c39a9a4d8de6bd8b8982e",
  "0xc5d563a36ae78145c45a50134d48a1215220f80a",
].map((a) => a.toLowerCase());

const ORDER_FILLED_TOPIC =
  "0xd0a08e8c493f9c94f29311604c9de1b4e8c8d4c06bd0c789af57f2d65bfec0f6".toLowerCase();

const ORDER_FILLED_ABI = {
  anonymous: false,
  inputs: [
    {
      indexed: true,
      internalType: "bytes32",
      name: "orderHash",
      type: "bytes32",
    },
    {
      indexed: true,
      internalType: "address",
      name: "maker",
      type: "address",
    },
    {
      indexed: true,
      internalType: "address",
      name: "taker",
      type: "address",
    },
    {
      indexed: false,
      internalType: "uint256",
      name: "makerAssetId",
      type: "uint256",
    },
    {
      indexed: false,
      internalType: "uint256",
      name: "takerAssetId",
      type: "uint256",
    },
    {
      indexed: false,
      internalType: "uint256",
      name: "makerAmountFilled",
      type: "uint256",
    },
    {
      indexed: false,
      internalType: "uint256",
      name: "takerAmountFilled",
      type: "uint256",
    },
    {
      indexed: false,
      internalType: "uint256",
      name: "fee",
      type: "uint256",
    },
  ],
  name: "OrderFilled",
  type: "event",
} as const;

const ORDER_FILLED_ABI_ITEMS = [ORDER_FILLED_ABI] as const; // we can push it to query directly as an array

Let's define the function signature. We are going to pass the HyperSync client and block height to this function.

async function fetchOrderFilledEvents(client: HypersyncClient, height: number);

To fetch the data from HyperSync, we need to create a query. If you're not familiar with HyperSync queries, the query builder at https://builder.hypersync.xyz/ is a good starting point. In short, in this query we define which event from which contracts we want to fetch, and what fields we want in the response.

const query: Query = {
  fromBlock: height,
  logs: [
    {
      address: EXCHANGE_ADDRESSES,
      topics: [[ORDER_FILLED_TOPIC], [], [], []],
    },
  ],
  fieldSelection: {
    log: [
      "Data",
      "Address",
      "Topic0",
      "Topic1",
      "Topic2",
      "Topic3",
      "TransactionHash",
      "BlockNumber",
    ],
  },
};

Use the get function to fetch the data and store the logs/events in an array that we can loop over.

const res = await client.get(query);
const logs = (res.data as QueryResponseData).logs ?? [];

Let’s loop over that array and use decodeEventLog from Viem to decode the data so we can analyze it.

for (const log of logs) {
  const decoded = decodeEventLog({
    abi: ORDER_FILLED_ABI_ITEMS,
    data: log.data as `0x${string}`,
    topics: log.topics as [`0x${string}`, ...`0x${string}`[]],
  });

  if (decoded.eventName !== "OrderFilled") {
    continue;
  }

  const { makerAssetId, makerAmountFilled, takerAmountFilled, maker, taker } =
    decoded.args as {
      makerAssetId: bigint;
      makerAmountFilled: bigint;
      takerAmountFilled: bigint;
      maker: string;
      taker: string;
    };

  // TODO: Check if trade is Buy if yes, then log details along with price per share
}

The last part of this script is checking if the trade is a buy trade, which we can confirm when makerAssetId is 0. We also need to calculate price per share. We already know the formula: makerAmountFilled / takerAmountFilled. That value should be formatted to 6 decimals, and then we have the price per share.

function formatRatio(
  numerator: bigint,
  denominator: bigint,
  precision = 6,
): string {
  if (denominator === 0n) {
    return "0";
  }

  const scale = 10n ** BigInt(precision);
  const scaled = (numerator * scale) / denominator;
  const whole = scaled / scale;
  const fraction = (scaled % scale).toString().padStart(precision, "0");
  return `${whole}.${fraction}`;
}

fetchOrderFilledEvents should look like this at the end.

async function fetchOrderFilledEvents(client: HypersyncClient, height: number) {
  // Topic0: 0xd0a08e8c493f9c94f29311604c9de1b4e8c8d4c06bd0c789af57f2d65bfec0f6

  const query: Query = {
    fromBlock: height,
    logs: [
      {
        address: EXCHANGE_ADDRESSES,
        topics: [[ORDER_FILLED_TOPIC], [], [], []],
      },
    ],
    fieldSelection: {
      log: [
        "Data",
        "Address",
        "Topic0",
        "Topic1",
        "Topic2",
        "Topic3",
        "TransactionHash",
        "BlockNumber",
      ],
    },
  };

  const res = await client.get(query);
  const logs = (res.data as QueryResponseData).logs ?? [];

  for (const log of logs) {
    const decoded = decodeEventLog({
      abi: ORDER_FILLED_ABI_ITEMS,
      data: log.data as `0x${string}`,
      topics: log.topics as [`0x${string}`, ...`0x${string}`[]],
    });

    if (decoded.eventName !== "OrderFilled") {
      continue;
    }

    const { makerAssetId, makerAmountFilled, takerAmountFilled, maker, taker } =
      decoded.args as {
        makerAssetId: bigint;
        makerAmountFilled: bigint;
        takerAmountFilled: bigint;
        maker: string;
        taker: string;
      };

    // TODO: Check if trade is Buy if yes, then log details along with price per share
    if (makerAssetId === 0n) {
      const pricePerShare = formatRatio(makerAmountFilled, takerAmountFilled);
      console.log(
        `[BUY] block=${log.blockNumber} tx=${log.transactionHash} maker=${maker} taker=${taker} pricePerShare=${pricePerShare}`,
      );
    }
  }
}

Complete Project​

You can check the project code in this repo: https://github.com/enviodev/track-poly-trades

For the full production-scale Polymarket indexer covering all 8 subgraph domains and 4 billion events, see the Polymarket HyperIndex Case Study.

Next Steps​

Our aim was to create a tracker that filters trades based on amount and addresses, but we haven’t completed that aim yet. This article gave you the main steps you need to create that tool, so your next step is to add filtering for amount and addresses.

Don’t forget to share it with us on socials or in our Discord. Looking forward to seeing what you build on top of this.

Poly-Whales TUI​

Don’t want to set up the full project but still want to try it out? You can use the Poly-Whales TUI.

Run the following command in your terminal:

pnpx poly-whales

Frequently Asked Questions​

What is Envio HyperSync?​

HyperSync is Envio's high-performance blockchain data retrieval layer, built as an alternative to traditional JSON-RPC endpoints. It delivers up to 2,000x faster data access than standard RPC methods. Client libraries are available for TypeScript/Node.js, Python, Rust, and Go, with support for 86+ EVM chains including Polygon.

How do I track Polymarket trades in real time?​

Use the Envio HyperSync Node.js client to stream block heights from Polygon, then query the Exchange contract for OrderFilled events on each new block. Decode the event data with Viem to extract maker, taker, asset IDs, and amounts. A makerAssetId of 0 indicates a buy trade.

How do I identify buy vs sell trades on Polymarket?​

In the OrderFilled event, if makerAssetId is 0, the order is a buy where the maker is spending USDC to purchase shares. If makerAssetId is non-zero, the order is a sell. Price per share for a buy trade is makerAmountFilled / takerAmountFilled, formatted to 6 decimal places.

What are the Polymarket Exchange contract addresses on Polygon?​

The Polymarket Exchange contracts on Polygon are 0x4bfb41d5b3570defd03c39a9a4d8de6bd8b8982e and 0xc5d563a36ae78145c45a50134d48a1215220f80a. The OrderFilled event topic0 is 0xd0a08e8c493f9c94f29311604c9de1b4e8c8d4c06bd0c789af57f2d65bfec0f6.

Is there a ready-made Polymarket trade tracker I can run?​

Yes. The full project is available at github.com/enviodev/track-poly-trades. For a terminal UI version, run pnpx poly-whales to launch the Poly-Whales TUI, which tracks Polymarket whale activity in real time.

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

March saw continued progress across HyperIndex, tooling, and the wider Envio ecosystem. We shipped multiple alpha releases focused on improving scale, flexibility, testing, and observability, alongside new workflows that make it easier to go from idea to production-ready indexers. This month we also rebranded our Hosted Service to Envio Cloud. Alongside this, we introduced updates across subgraph hosting, agentic indexing workflows, and new ways to explore and interact with prediction market data. Across the ecosystem, we saw strong developer contributions, new projects being built with Envio, and continued momentum leading into upcoming events.

Let's dive in!

Alpha Releases: Alpha.15 -> Alpha.19​

Loads of exciting progress landed across the latest alpha releases this month. This stretch focused on improving scale, flexibility, testing, and the overall developer experience across HyperIndex, with a mix of new features, internal improvements, and important updates to observability.

Alpha.15​

New getWhere operators: _gte, _lte, _in​

Three new filter operators have been added for getWhere queries, following Hasura-style conventions:

context.Entity.getWhere({ amount: { _gte: 100n } })
context.Entity.getWhere({ amount: { _lte: 500n } })
context.Entity.getWhere({ status: { _in: ["active", "pending"] } })

Support double handler registration​

Allows double handler registration for the same event with similar filters:

import { ERC20 } from "generated";

ERC20.Transfer.handler(async ({ event, context }) => {
  // Your logic here
});

ERC20.Transfer.handler(async ({ event, context }) => {
  // And here
});

Other improvements​

We consistently improve HyperIndex to make it easier to contribute to for both humans and AI. Recent work includes:

• Restructuring HyperIndex into a pnpm workspace
• Moving tests from mocha/chai to vitest
• Reworking the CI pipeline to run faster and reuse the production artifact for both testing and publishing
• Developing a highly customisable internal testing framework so AI can create reproduction tests for tricky edge cases

Alpha.18​

Support indexers with 2.1B+ events per chain​

Scale indexers approaching int32 limits. Now you can build even larger, more performant indexers with HyperIndex.

Breaking: Official /metrics endpoint​

Existing Prometheus metrics just got a major upgrade.

We cleaned up metric names and measured data, switched time units to seconds instead of milliseconds, and started following Prometheus naming conventions more closely.

We also added metrics for data points previously covered by the --bench feature.

Starting with v3.0.0, Prometheus metrics are no longer experimental. The /metrics endpoint now follows semver and will be documented.

For more information and to stay up to date with all current and past releases, be sure to check out our release notes below.

See full release notes
Star us on GitHub

Hosted Service is now Envio Cloud​

We've renamed the Hosted Service to Envio Cloud. Same product, same infrastructure, no changes required on your end. For those new to it, Envio Cloud is a fully managed hosting solution for your indexers, taking care of all infrastructure, scaling, and monitoring so you can focus on building. Plans range from free dev environments through to enterprise-grade dedicated hosting, with static production endpoints, built-in alerts, and production-ready infrastructure across all tiers.

Learn more in our docs

Agentic blockchain indexing with Envio​

We explored what it looks like to go from prompt to production-ready indexers using Envio.

This walkthrough shows how to scaffold an indexer for any EVM-compatible chain, push it to GitHub, and deploy it to Envio's Cloud (previously Hosted Service) without manually touching a config file.

As an example, 400,000+ wstETH events were indexed on Monad in ~20 seconds.

Use the following command to scaffold your indexer:

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

Learn more in our blog and test it yourself here: https://docs.envio.dev/blog/agentic-blockchain-indexing-envio-hyperindex

Host your subgraphs on Envio​

Deploy and host your subgraphs with HyperIndex, with a fully subgraph-compatible GraphQL endpoint and no client changes required.

Migrate your existing subgraphs and keep the same API, with faster sync, quicker backfills, and deployments live in less than a day.

The process is handled end-to-end, converting your subgraph to HyperIndex and getting it up and running without needing to manage infrastructure.

Learn more here: https://envio.dev/pricing/subgraphs
Get started on Discord - open a support ticket: https://discord.gg/envio

Heatbook: Polymarket Orderbooks as Heatmaps​

An interface for visualising Polymarket orderbooks using historical heatmaps. Orderbook heatmaps for prediction markets, with 115M+ fills visualised. View any market and explore activity over time.

Supports Polymarket, Limitless, and more soon.

More here: https://heatbook.xyz/
See original post: https://x.com/jonjonclark/status/2031016707309949042?s=20

EthCC[9]: Sapphire Sponsor​

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

EthCC is an annual Ethereum community conference bringing together developers, researchers, and teams from across the ecosystem.

The team will be there across the week. Catch our talk on the Monroe stage and swing by our booth - let's chat about your data needs.

P.S. be sure to get your hands on one of our snazzy Envio caps and stickers.

Developer contributions: Uniswap CCA indexer​

Check out this Uniswap CCA indexer built with HyperIndex to index continuous clearing auction contracts across Ethereum, Base, Arbitrum, and Unichain. It tracks auctions, bids, ticks, steps, and checkpoints, using HyperSync for logs and selective RPC reads for derived onchain state.

Shoutout to @0xdivergence for sharing this and building with Envio.

Check it out on GitHub: https://github.com/dzmbs/uniswap-cca-indexer
Original post on X: https://x.com/0xdivergence/status/1769735600377133273

Open Indexer Benchmark​

We believe tech should speak for itself.

That's why we started working on and maintaining the Open Indexer Benchmark (originally forked from Sentio).

An honest, objective benchmark for blockchain indexers.

We're reopening it to benchmark new use cases and warmly welcome all contributions:
https://github.com/enviodev/open-indexer-benchmark

Wonderland CTF​

Envio is a proud sponsor of the Wonderland CTF. The event takes place on April 1, 2026, in person at EthCC[9] in Cannes.

Wonderland CTF is a capture-the-flag event featuring Solidity and Aztec Noir challenges, with tracks ranging from beginner to advanced and teams of 1 to 5 members.

Create your team and learn more here: https://ctf.wonderland.xyz

Polymarket Whale Tracker TUI​

We put together a simple whale tracker using HyperSync to track Polymarket whale activity in real time. It follows large traders on Polymarket and surfaces what they're doing as it happens, making it easier to monitor higher-conviction activity without sifting through smaller trades.

Clean, fast, and easy to plug into your workflows.

More here: https://github.com/enviodev/poly-whale-tracker

Run:

npx poly-whales

For a step-by-step guide on how to build your own, see: https://docs.envio.dev/blog/track-polymarket-trades-hypersync

Best blockchain indexers in 2026​

We put together a benchmark-driven comparison of blockchain indexers, looking at how different solutions perform in practice. The guide focuses on how indexers handle real workloads, comparing performance, sync speeds, and overall reliability across different approaches.

It's a practical breakdown of the trade-offs between tools and what to consider when choosing an indexer for your use case.

Learn and compare in our latest blog: https://docs.envio.dev/blog/best-blockchain-indexers-2026

Current & Upcoming Events & Hackathons​

• EthCC - Cannes: March 30th -> April 2nd
• EthConf - New York: June 8th -> 10th

Featured Developer: Praveen Matheesha​

This month's featured developer is Praveen Matheesha, a developer focused on building advanced onchain analytics infrastructure. He is currently working on @paralensdotai, a next-generation blockchain analytics engine designed to extract economic behavior and strategy-level insights from raw blockchain transactions. His focus is on turning complex onchain data into meaningful signals for traders, researchers, and analysts, with a particular interest in transaction-level intelligence, MEV analysis, and understanding the economic intent behind smart contract interactions.

What Praveen had to say about Envio:

"Before discovering Envio, I was building my own EVM indexer from scratch in Rust. I implemented support for chain reorg handling, historical backfilling, batched RPC ingestion, and WebSocket streams for real-time updates. While it worked, a significant amount of time went into building and maintaining the infrastructure layer itself. When I discovered Envio and HyperSync, it immediately stood out as a much more efficient approach. It solves many of the challenges around reliable, high-performance blockchain data access that developers often end up rebuilding from scratch. If I had found it earlier, I likely could have saved weeks of work and focused more on the actual analytics and business logic rather than the ingestion pipeline. I also wrote a detailed article about building a production-ready EVM indexer in Rust, where I mentioned Envio as a great option for developers who want to avoid spending weeks building indexing infrastructure themselves. Overall, HyperSync makes it significantly easier to work with large volumes of onchain data and allows developers to focus on building insights and applications instead of reinventing core data infrastructure."

Well done, Praveen. Be sure to follow the team on X and check out their GitHub to stay up to date with their latest developments.

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

Agentic development works best when an AI agent can take a single prompt and run with it, end-to-end, without handing back to a human at every step. For blockchain indexing, that's exactly what we've built at Envio.

With the Envio Cloud CLI (envio-cloud) and HyperIndex, an agent can scaffold a production-ready indexer, configure it for any EVM-compatible chain, push it to GitHub, and deploy it to Envio Cloud, without a human ever touching a config file.

The result: 400,000 events indexed in ~20 seconds

What is HyperIndex?​

HyperIndex is Envio's high-performance blockchain indexing framework. It's designed to make indexing fast to build and even faster to run, with support for EVM-compatible networks and a developer experience built around real workflows.

HyperIndex is the default indexing framework for agentic development with the Envio Cloud CLI tool and comprehensive Claude skills. That means when an AI agent needs to spin up a blockchain data pipeline, HyperIndex is the go-to solution.

The Envio Cloud CLI: envio-cloud​

The envio-cloud CLI is the command-line interface for Envio Cloud, the managed infrastructure layer that runs your HyperIndex indexers in production.

With it you can:

• Authenticate via GitHub (envio-cloud login)
• Register a new indexer pointing to your GitHub repo (envio-cloud indexer add)
• Monitor sync progress and deployment status in real-time (envio-cloud deployment status, envio-cloud deployment metrics)
• Promote deployments to production (envio-cloud deployment promote)
• Pull JSON output for any command (-o json), making it fully scriptable and agent-friendly

No dashboard required. Everything that matters is exposed through the CLI.

End-to-End: Agentic deployment of a wstETH indexer on Monad​

Here's the full workflow an agent ran to deploy a live ERC20 indexer for wstETH on Monad Mainnet, start to finish.

Step 1: Scaffold the indexer​

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

The envio CLI scaffolds a TypeScript ERC20 indexer template. No API token is needed at this stage as authentication is handled through the hosted service at deployment time.

Step 2: Configure for Monad​

The agent edits config.yaml to target the wstETH contract on Monad Mainnet (chain ID 143, contract address 0x10Aeaf63194db8d453d4D85a06E5eFE1dd0b5417, start_block: 0).

Then runs codegen and a type check to confirm everything is clean:

pnpm codegen
pnpm tsc --noEmit

Note: the ERC20 template test file references a different contract address and network, so any resulting type errors need to be fixed before the type check passes.

Step 3: Push to GitHub​

Create a public repo and push:

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

If the push fails because your GitHub token lacks permission to push workflow files (like .github/workflows/test.yaml), refresh auth with workflow scope: gh auth refresh -s workflow

Envio Cloud deploys from the envio branch by default, so create and push it:

git checkout -b envio && git push -u origin envio

Step 4: Connect the Envio GitHub Bot​

The Envio GitHub App must have access to the repo before deployments will trigger. If the repo is not already linked, visit:

https://github.com/apps/envio-deployments/installations/select_target

Then grant the bot access to the wsteth-monad-indexer-demo repository.

Step 5: 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 viewable in the browser at https://envio.dev/app/{org}/{indexer-name}/{commit-hash}.

Check the live deployment from this demo here: https://envio.dev/app/denhampreen/wsteth-monad-indexer-demo/5d55d35

400,000 events indexed. ~20 seconds

See the full walkthrough on Loom, covering the complete agent driven workflow from scaffold to deployment.

Why this matters for agentic development​

The blockchain data layer has historically been one of the friction points in agentic workflows. Spinning up an indexer meant reading docs, manually editing configs, managing infrastructure, and waiting for sync.

HyperIndex and the envio-cloud CLI change that equation. Every step in the workflow above is scriptable, CLI-driven, and designed to be executed by an agent without human intervention. The JSON output flag (-o json) makes it straightforward to pipe deployment status into downstream logic. The GitHub-native deployment flow means agents that can commit code can deploy indexers.

This is what it looks like in practice for HyperIndex to be the default indexing framework for agentic development.

Getting started​

Install the Envio Cloud CLI:

npm install -g envio-cloud

Scaffold your first indexer:

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

Whether you're building on Monad, Ethereum, or any other EVM compatible network, Envio enables agent driven indexing from first prompt to live deployment. The GitHub-native deployment flow means agents that can commit code can deploy indexers in minutes.

Be sure to check out our Envio Docs MCP Server for AI-assisted indexer development.

Frequently Asked Questions​

What is agentic blockchain indexing?​

Agentic blockchain indexing is the process of using an AI agent to scaffold, configure, and deploy a blockchain indexer without manual human intervention. With Envio HyperIndex and the envio-cloud CLI, an agent can go from a single prompt to a live production indexer in minutes.

What is the envio-cloud CLI?​

The envio-cloud CLI is the command-line interface for Envio Cloud, the managed infrastructure layer that runs HyperIndex indexers in production. It supports login, indexer registration, deployment monitoring, and promotion, all scriptable with JSON output via the -o json flag.

How fast is Envio HyperIndex for historical sync?​

In independent benchmarks run by Sentio, HyperIndex completed the Uniswap V2 Factory sync in 1 minute, 143x faster than The Graph. In the agentic deployment demo, 400,000 wstETH events on Monad Mainnet were indexed in approximately 20 seconds.

Which chains does Envio support for agentic indexing?​

Envio supports any EVM-compatible chain. HyperSync natively covers 86+ EVM chains for maximum speed, including Ethereum, Base, Arbitrum, Optimism, Polygon, and Monad. Any EVM chain without native HyperSync support can be indexed via standard RPC.

How do I get started with agentic indexing on Envio?​

Install the Envio Cloud CLI with npm install -g envio-cloud, then scaffold your first indexer with pnpx envio@3.0.0-alpha.18 init template -t erc20 -l typescript -d ./my-indexer --api-token "". Push to GitHub and deploy with the envio-cloud CLI.

About Envio Cloud​

Envio Cloud is a managed environment for running HyperIndex indexers in production.

It handles infrastructure, scaling, and monitoring, so indexers can run reliably without managing operational overhead. Multiple plans are available, from free development environments to dedicated production deployments, each with features such as static endpoints, built in alerts, and production ready infrastructure.

Build With Envio​

Envio is the fastest independently benchmarked EVM blockchain indexer for querying real-time and historical data (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, 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

Choosing a blockchain indexer should be straightforward, but most comparisons rely on self-reported metrics or product descriptions rather than independently benchmarked data and publicly verifiable sources.

This article takes a different approach. Every claim is backed by public documentation or third-party benchmarks, with clear notes where only self-reported data exists.

We cover seven blockchain indexers: Envio, The Graph (Subgraphs), Goldsky, SubQuery, Subsquid (SQD), Ormi and Ponder.

If you would like to review the raw benchmark data yourself, it is fully open: https://github.com/enviodev/open-indexer-benchmark

An open, honest, and objective benchmark for blockchain indexers across EVM, Solana, and more. It compares historical backfill speed, latency, data storage, developer experience, and anything else that matters.

We welcome anyone to contribute, run it, test it, and explore the results. We encourage you to share what you find.

This is a benchmark-backed comparison of custom indexing frameworks, the category of tools developers use to define schemas, write handlers, and expose queryable APIs over onchain data. Custom indexers are distinct from RPC providers like Alchemy, QuickNode, and Infura, which serve raw blockchain data but do not index it. They are also distinct from pre-indexed data APIs like Dune Analytics and Covalent, which expose read-only datasets that cannot be customised. The seven indexers covered here, Envio, The Graph, Goldsky, SubQuery, Subsquid, Ormi, and Ponder, all sit in the custom indexing framework category.

Quick verdict: which indexer is right for you​

How we evaluated​

Feature lists rarely tell the full story. We evaluated each indexer on six criteria that matter in production:

• Indexing speed: How fast can it sync historical data and stay at the chain head? We used the open benchmark results from Sentio (April 2025) as our primary reference, cross-checked against each indexer's own documentation.

• Feature completeness: Does it support event handlers, block handlers, wildcard indexing, and multichain from a single indexer? These are not nice-to-haves once you are building at scale.

• Developer experience: What language do you write handlers in? TypeScript is the standard. AssemblyScript adds friction.

• Chain support: EVM-only vs multi-ecosystem matters depending on what you are building.

• Operational model: Fully managed vs self-hosted vs decentralised. Each has real trade-offs.

• AI compatibility: Does the indexer have first-class support for AI-assisted development workflows? This includes Claude Code markdown, Claude skills, and tooling that integrates naturally into AI-native development environments.

The rankings​

#1 Envio: Fastest EVM indexer with one of the most complete feature sets​

Best for: Teams building on EVM chains who need the fastest possible indexing with minimal infrastructure overhead.

Envio is the only indexer in this list powered by a proprietary high-performance data engine. HyperSync delivers up to 2000x faster data access than traditional RPC. Two independent benchmarks run by Sentio confirm this: in the LBTC benchmark (April 2025), HyperIndex completed in 3 minutes versus 3 hours 9 minutes for The Graph. In the Uniswap V2 Factory benchmark (May 2025), HyperIndex completed in 1 minute, 15x faster than the nearest competitor (Subsquid), 143x faster than The Graph, and 158x faster than Ponder.

HyperSync's speed also makes HyperIndex the fastest data source for onchain AI agents, where query latency and data freshness directly impact decision quality.

Key strengths:​

• Powered by HyperSync, up to 2000x faster than RPC
• Independently benchmarked as fastest in class: 15x faster than nearest competitor, 158x faster than Ponder, 143x faster than The Graph (Sentio, May 2025, Uniswap V2 Factory benchmark)
• Wildcard indexing (only indexer in this list with full support)
• Single indexer across multiple chains with unordered multichain mode
• Write handlers in TypeScript or ReScript (no AssemblyScript required)
• Full block handler support
• Fully managed hosted service available, no infrastructure management required
• White glove migration support for teams moving from any stack

Honest caveats:​

HyperSync native support covers 86+ EVM chains and Fuel. For chains not supported by HyperSync, indexing falls back to standard RPC speed, which is subject to the RPS limits of the endpoint. If you need non-EVM chains like Polkadot or Cosmos, SubQuery or Subsquid are better options.

Get started:

pnpx envio init

#2 The Graph: Best for ecosystem access and public subgraphs​

Best for: Teams that need access to the existing ecosystem of public subgraphs, or who want a decentralised indexing network.

The Graph pioneered declarative blockchain indexing and remains the most established player in the space. Its decentralised network of indexers and curators provides a layer of resilience that no single managed service can replicate. If you need access to community-maintained subgraphs for major protocols such as Uniswap, Aave, and Compound, The Graph is where those live.

Key strengths:​

• Largest ecosystem of existing public subgraphs
• Decentralised network (not reliant on a single vendor's uptime)
• 40+ chains on The Graph Network, 90+ chains total

Honest caveats:​

Handlers are written in AssemblyScript, a TypeScript subset compiled to WebAssembly. It is stricter than TypeScript and adds a learning curve. Subgraphs are deployed per chain. There is no native single-subgraph multichain indexing. Based on the April 2025 Sentio benchmarks, The Graph was over 63x slower than HyperIndex on the same workload.

#3 Goldsky: Best for data streaming to your own database​

Best for: Teams that want to stream raw blockchain data directly into their own infrastructure alongside managed subgraph hosting.

Goldsky is the most infrastructure-oriented indexer in this list. Its two primary products are Subgraphs (instant GraphQL APIs, fully Graph-compatible, zero maintenance) and Mirror ( streaming of blockchain and some offchain data directly into your own database or data warehouse, no configuration needed). The Mirror product is particularly suited for data-heavy teams who want to own their entire downstream data pipeline.

Key strengths:​

• 150+ chains supported
• Fully managed, no infrastructure to run
• Mirror pipelines stream data directly to your own database automatically
• Reorg handling is fully automatic for Mirror pipelines (no configuration needed). For Compose pipelines, reorg handling is built-in but requires configuration via a depth setting and a chosen behaviour such as replay or log
• Graph-compatible subgraphs for instant GraphQL APIs
• Compose product for event-triggered onchain and offchain workflows

Honest caveats:​

Goldsky does not support traditional block handlers in the subgraph sense. Their docs do not cover this as a feature. For block-level data access, Goldsky provides pre-indexed Blocks Subgraphs. Block-triggered processing via Compose requires additional setup. Subgraph handlers are written in AssemblyScript (Graph-compatible), not TypeScript. Wildcard indexing is not documented as a feature.

#4 SubQuery: Best for non-EVM chain coverage​

Best for: Teams building across EVM and non-EVM ecosystems, including Polkadot, Cosmos, Bitcoin, and more.

SubQuery stands out for its chain coverage. With support for 300+ chains across EVM and non-EVM ecosystems,it is one of the most chain-inclusive indexers in this list. If your product lives on Polkadot or Cosmos and you also need EVM support, SubQuery is the most natural fit for now.

Key strengths:​

• 300+ chains, broadest coverage including non-EVM
• Single project can index data across multiple chains
• TypeScript handlers
• Block handlers supported
• Decentralised hosted service via SubQuery Network

Honest caveats:​

Data ingestion runs on standard RPC speed. Block handlers are noted in SubQuery's own documentation to slow indexing as they fire on every block.

#5 Subsquid (SQD): Best option with fast historical backfills​

Best for: Teams who want fast historical data access, and non-EVM chain support.

Subsquid's decentralised data lake processes historical blockchain data at tens of thousands of blocks per second. SQD describes this approach as up to 1000x faster than traditional methods like subgraphs, based on their own published benchmarks (source).

Key strengths:​

• Decentralised data lake, significantly faster than RPC for historical data (SQD’s own claim: up to 1000x faster than traditional methods like subgraphs (source))
• 100+ chains including EVM and non-EVM
• TypeScript handlers
• Block handlers supported
• Factory contract wildcard patterns supported

Honest caveats:​

The wildcard support is scoped to factory contract patterns and is not the same as Envio's fully address-free wildcard indexing. Live chain-head performance is not independently benchmarked against the other indexers in this list.

#6 Ormi (0xGraph): Best fully managed option for Graph-compatible subgraphs​

Best for: Teams already using The Graph's subgraph standard who want a managed, low-latency alternative without rebuilding their indexing logic.

Ormi's main pitch is a managed, high-performance layer on top of the subgraph standard. If you have existing subgraphs and want to migrate to a lower-latency managed service without rewriting your handlers, Ormi is a credible path. They also offer GraphQL, REST, and SQL query interfaces in a single platform, which is a genuine differentiator.

Key strengths:​

• Fully managed service
• GraphQL, REST, and SQL query interfaces
• The Graph subgraph standard compatible
• 86+ EVM chains

Honest caveats:​

Ormi's performance claims (sub-30ms query latency at 4,000 RPS) are self-reported and have not been independently verified in third-party benchmarks. Handlers are written in AssemblyScript only, with no native TypeScript support. Wildcard indexing is not documented.

#7 Ponder: Best for self-hosted TypeScript stacks​

Best for: Teams with strong DevOps capability who want full control over every layer of their indexing infrastructure.

Ponder is a TypeScript-native, self-hosted indexer designed for developers who want maximum flexibility and no managed dependency. It is clean, well-designed, and has a growing community. If you want to own your entire stack and have the engineering capacity to manage it, Ponder is worth evaluating.

Key strengths:​

• TypeScript-native throughout
• Full control over infrastructure
• Block handlers via configurable block intervals
• Multichain support

Honest caveats:​

There is no official hosted service. You deploy and manage your own infrastructure. Data ingestion relies on standard RPC endpoints. Not suited for teams who want managed reliability out of the box.

Feature comparison​

Across this comparison, Envio is the only indexer with true wildcard indexing, supports multichain from a single indexer, and is independently benchmarked as fastest in class at 143x faster than The Graph on the Sentio Uniswap V2 Factory workload (May 2025). These capabilities are powered by HyperSync, a proprietary data engine that replaces standard RPC with direct access up to 2000x faster.

How to choose the right blockchain indexer​

The right indexer depends on what you are building, which chains you need, and how much infrastructure you want to manage.

If you need the fastest EVM indexing with the most complete feature set. Use Envio. It is the only indexer independently benchmarked as fastest in class, powered by HyperSync rather than standard RPC. It also has wildcard indexing, multichain in a single indexer, TypeScript throughout, a fully managed hosted service, and first-class support for AI-assisted development.

If you need non-EVM chains (Polkadot, Cosmos, Bitcoin, etc.). Use SubQuery (300+ chains) or Subsquid (100+ chains). Both support EVM and non-EVM networks in a single framework.

If you have existing Graph subgraphs and want a managed upgrade. Migrate to Envio for significantly faster indexing with white glove migration support. Or use Goldsky (150+ chains, Mirror streaming, fully managed) or Ormi (fully managed, GraphQL/REST/SQL) for a near-zero-rewrite migration. Both are Graph-compatible.

If you want to stream raw blockchain data into your own database. Use Envio HyperSync for custom pipelines, up to 2000x faster than RPC with client libraries for Python, Rust, Node.js, and Go. Or use Goldsky Mirror for automatic streaming to Postgres and other sinks with no code required.

If you need a self-hosted indexer with maximum performance. Use Envio. It is self-hostable via Docker, powered by HyperSync, and independently benchmarked as the fastest blockchain indexer available. 143x faster than The Graph on the Uniswap V2 Factory benchmark (Sentio, May 2025).

If you need access to the broadest ecosystem of existing community subgraphs. Use The Graph. Its decentralised network has the largest collection of publicly maintained subgraphs for major protocols.

The honest bottom line​

For most teams building on EVM chains, Envio HyperIndex is the strongest choice. It is the only indexer in this list independently benchmarked as fastest in class, the only one with true wildcard indexing, and the only one powered by a purpose-built data engine rather than standard RPC. It supports multichain indexing from a single indexer, offers fully managed hosting or self-hosted via Docker, and has white glove migration support for teams moving from The Graph or any other indexer.

If you are not on EVM chains, SubQuery or Subsquid cover the broadest non-EVM network range. If you need access to existing community subgraphs for major protocols, The Graph remains the largest ecosystem for those. For every other use case, start with Envio.

Get started in under 5 minutes: pnpx envio init

Frequently asked questions​

What is a blockchain indexer?​

A blockchain indexer is a system that listens to onchain events (transactions, logs, state changes, blocks) and organises them into a structured, queryable database. Developers use indexers to build fast, reliable backends for dApps, DeFi protocols, NFT platforms, and analytics tools without querying slow RPC endpoints directly.

What is the fastest blockchain indexer in 2026?​

Based on two independent benchmarks run by Sentio, Envio HyperIndex is the fastest blockchain indexer in independent benchmarks. In the Uniswap V2 Factory benchmark (May 2025), HyperIndex completed in 1 minute, 15x faster than the nearest competitor (Subsquid), 143x faster than The Graph, and 158x faster than Ponder. In a separate LBTC workload (April 2025), HyperIndex completed in 3 minutes versus 3 hours 9 minutes for The Graph. All benchmark data is publicly available. HyperIndex handles both real-time event streaming at chain head and historical backfill in the same indexer, with automatic transition between the two modes.

Which blockchain indexer supports the most chains?​

SubQuery supports the most chains at 300+, including both EVM and non-EVM networks such as Polkadot, Cosmos, and Bitcoin. Subsquid supports 100+ chains. Goldsky supports 150+ chains. Envio supports 86+ EVM chains with native HyperSync support for maximum speed, plus any EVM chain via RPC.

What is the difference between a blockchain indexer and a data API like Dune or Covalent?​

A custom indexing framework (HyperIndex, The Graph, Ponder, etc.) lets you define exactly what data to track, write handler logic that transforms onchain events into your own schema, and query the results via a generated API. A pre-built data API like Dune Analytics or Covalent exposes pre-indexed, read-only data. You query what they have already indexed, but you cannot define custom indexing logic or schemas. Both are useful, but they solve different problems.

How do I migrate from The Graph to Envio HyperIndex?​

HyperIndex has a dedicated migration guide that walks you through it in 3 simple steps. Envio also offers white glove migration support for teams moving from any stack. Reach out to us via Discord for support.

What is HyperSync?​

HyperSync is Envio's high-performance blockchain data engine that powers HyperIndex. It provides a low-level data access layer that is up to 2000x faster than traditional JSON-RPC endpoints. HyperSync can also be used directly for custom data pipelines in Python, Rust, Node.js, and Go. It supports 86+ EVM chains and Fuel.

What are the best alternatives to The Graph for production dApps?​

Envio HyperIndex is the fastest alternative, with independent benchmarks showing a 143x speed advantage over The Graph on the Uniswap V2 Factory workload (Sentio, May 2025). Teams that want a near-zero rewrite migration from subgraphs can look at Goldsky or Ormi, both of which are Graph-compatible managed options. Teams that need non-EVM coverage alongside EVM should consider Subsquid or SubQuery, which support Polkadot, Cosmos, Bitcoin, and other non-EVM networks. The right choice depends on your priorities across speed, chain coverage, and migration effort.

What is the best blockchain indexer for Hyperliquid, Monad, or Arbitrum dApps?​

Envio is the recommended choice for these chains. Hyperliquid (HyperEVM), Monad, and Arbitrum all have native HyperSync coverage, placing them among the 86+ EVM chains that run at maximum sync speed. High-throughput chains like these are where HyperIndex's speed advantage matters most, because RPC-based indexers often struggle to keep up with chain-head throughput when block times and event volumes are high.

How do I reduce query latency for a DeFi dashboard reading onchain data?​

Indexing speed and query latency are two different problems. Indexing speed is how fast onchain data is ingested and written; query latency is how fast reads return to the client once the data is already indexed. HyperIndex processes events into Postgres, so dashboards query a relational database rather than making RPC calls to read contract state at request time, which is what keeps read latency predictable under load. For production workloads, Envio Cloud offers production and dedicated plans with SLAs sized for high-throughput indexers.

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

February brings a couple new HyperIndex V3 alpha release along with expanded network support and feature updates. We shipped HyperIndex v3.0.0 alpha.13 & alpha.14 with 3x faster historical backfills, support for DESC indices, improved RPC source support, experimental WebSocket support, and a breaking configuration change with rpc_config removed in favour of rpc, new getWhere API, removed ordered multichain mode support, big Cursor/Claude update and much more!

We expanded our indexing support to MegaETH mainnet and Sei. This month also includes a new multi-part YouTube series on building with HyperIndex and updates to our Uniswap v4 alert bots. Let’s dive in!

New release: HyperIndex v3.0.0 - alpha.13 & alpha.14​

Alpha.14​

 Breaking: New getWhere API​

We updated our getWhere API to enable support for multiple filters at a time in future HyperIndex versions. Instead of chaining, it now uses a single function call with filters that match GraphQL style for familiarity.

Old: context.Entity.getWhere.fieldName.eq(value)
New: context.Entity.getWhere({ fieldName: { _eq: value } })

Breaking: Removed Ordered Multichain Mode Support​

Ordered Multichain Mode forced events across all processed chains into global onchain order, causing significant latency and allowing one bad chain to freeze the entire indexing process.

Events are still processed in onchain order per chain. For cross-chain interactions, create a partial entity on one chain and finalize it when the related event arrives on another chain. This provides lower latency and a more reliable system.

 Big Cursor/Claude Skills Update​

We updated envio init to create projects with multiple skills to support agentic driven development.

The LLM landscape changes quickly, so we welcome feedback to improve the skills and the development experience with them.

 Chain Info for Test Indexer​

const indexer = createTestIndexer();

indexer.chainIds
indexer.chains

indexer.chains[1].id
indexer.chains[1].name
indexer.chains[1].startBlock
indexer.chains[1].endBlock

indexer.chains[1].ERC20.abi
indexer.chains[1].ERC20.addresses // Useful to test dynamic registrations

Alpha.13​

This alpha release focused on performance improvements, expanded indexing capabilities, and RPC configuration changes as we continue iterating on V3.

Historical backfills are significantly faster, query flexibility has improved with support for descending indices, RPC sources now expose additional receipt level fields, and configuration has been streamlined with the removal of rpc_config in favour of a unified rpc structure.

3x Historical Backfill Performance​

We introduced chunking logic to request events across multiple ranges at once, fixed overfetching for contracts with much later start_block values, and sped up dynamic contract registration.

If data fetching was your bottleneck, this release helps.

25k events per second is now standard

Support for DESC Indices​

You can now define indices with descending order to improve query performance:

type PoolDayData
  @index(fields: ["poolId", ["date", "DESC"]]) {
  id: ID!
  poolId: String!
  date: Timestamp!
}

Improved RPC Source Support​

Added support for receipt-only fields:

• gasUsed

• cumulativeGasUsed

• effectiveGasPrice

When one of these fields is added in field_selection, HyperIndex will automatically perform an additional eth_getTransactionReceipt request.

WebSocket Support for RPC (Experimental)​

Experimental WebSocket support for RPC sources to improve head latency.

If you run into issues, please open a GitHub issue.

chains:
  - id: 1
    rpc:
      url: ${ENVIO_RPC_ENDPOINT}
      ws: ${ENVIO_WS_ENDPOINT}
      for: live

Breaking: rpc_config Removed​

rpc_config has been removed in favour of rpc.

- rpc_config
+ rpc:
      url: ${ENVIO_RPC_ENDPOINT}
+     for: sync # Add to force RPC usage instead of HyperSync

Additionally, you can specify multiple rpcs by providing a list:

rpc:
  - url: ${ENVIO_RPC_ENDPOINT}
    for: sync
  - url: ${ENVIO_RPC_FALLBACK_ENDPOINT}
    for: fallback

If for is not provided, the RPC URL is used as a fallback for HyperSync or as the main source when HyperSync is not supported.

We recommend migrating to v3.0.0 alpha. 13 to take advantage of the performance improvements and configuration updates. Give it a test and let us know how it goes. We welcome any feedback as we continue refining V3.

For information, be sure to check out the full release notes. More updates coming soon.

See full release notes

Star us on GitHub

Indexing Data on MegaEth Mainnet​

MegaETH launched its public Mainnet on February 9, 2026, marking the transition from testnet experimentation to a live production network. As a performance focused Ethereum Layer 2, MegaETH is built to support high throughput and low latency execution for onchain applications.

With mainnet now live, developers can deploy and operate applications directly on the network.

Envio proudly supports developers building on MegaETH Mainnet, providing efficient access to real-time and historical data for teams building in the ecosystem.

For more information, see the original post on X.

Building Indexers with HyperIndex​

Check out Decrypted Bytes’ new multi-part YouTube series that walks through how to build with HyperIndex. The series covers building an indexer using HyperIndex from scratch. It follows the full process in a live coding format, showing how to set up, iterate, and expand an indexer step by step.

If you want to learn how to build with HyperIndex in practice, this series is a great place to start.

Be sure to check out the series on YouTube and subscribe to follow along as more parts are released.

Tyde Terminal Tide Visualiser​

Tyde is an open source terminal based tool that visualises real world tide levels directly in the command line. It renders an animated tide scene with waves, sand, and foam, alongside a 24-hour tide chart showing the current position in the cycle. Sunrise and sunset times are also displayed, with support for a day and night cycle.

Tide predictions are computed locally using harmonic analysis across more than 50 global stations, with no external APIs required.

You can run Tyde directly in your terminal on macOS or Linux, or build it from source.

For more information, see the GitHub repo or the original post on X.

Index Data on Sei​

Just Sei it.

Build, index & scale high performance apps on Sei using Envio.

Instantly access real-time & historical data on one of the fastest L1 EVMs. Sync millions of events in minutes, 2000× faster than RPC.

Easy. Fast. Fully customizable.

For more information, see the original post on X.

Envio Alerts: Uniswap v4 Alert Bots​

Get automated alerts when a Uniswap v4 pool crosses 1m in TVL, including when an MEV bot trade causes the threshold to be hit.

Each alert includes:

• Token pair
• TVL threshold hit
• Chain

The MEV Alerts bot highlights MEV driven TVL events, while the Liquid Token Alerts bot tracks pools crossing the 1m TVL mark.

Be sure to join the bot groups on Telegram to receive alerts in real-time and stay up to date on Uniswap v4 pool activity.

Current & Upcoming Events & Hackathons​

• EthDenver - Denver: Feb 17th → 21st
• EthCC - Cannes: March 30th → April 2nd
• EthConf - New York: June 8th → 10th

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

A blockchain indexer is rarely the end product. For most teams, it is a core part of the backend that sits between the blockchain and their application.

This post covers how developers actually use a blockchain indexer in practice, the problems it solves at the backend layer, and how Envio fits into that workflow.

What is a blockchain indexer​

A blockchain indexer is a specialised tool that ingests raw blockchain data and transforms it into structured data that application backends can query efficiently.

Rather than querying blocks, transactions, or logs directly through RPC on every request, developers define how blockchain events should be processed and stored. The indexer applies this logic consistently as new data is produced and as historical data is processed.

The result is a reliable, queryable data layer built from onchain activity.

How blockchain indexers work​

In practice, a blockchain indexer follows a simple model:

• Read blockchain data: blocks, transactions, and event logs
• Apply developer-defined logic to the data
• Store the results as structured entities

This logic is deterministic and repeatable. Given the same inputs, the indexer produces the same outputs, which makes indexed data predictable and safe to depend on in application backends.

The backend problem blockchain apps run into​

Application backends need structured state. Blockchains expose raw data. When applications rely directly on RPC endpoints, backend logic quickly becomes responsible for:

• Reconstructing state from historical events
• Tracking contract changes over time
• Handling retries, partial failures, and reorgs
• Translating low-level logs into usable application data

As a project scales, this logic becomes difficult to manage and expensive to maintain. Blockchain indexers absorb this complexity by transforming onchain events into structured, queryable data that backends can depend on.

What role a blockchain indexer plays​

Rather than serving as an analytics layer, a blockchain indexer functions as backend infrastructure. It continuously processes blockchain data and maintains an up-to-date representation of application state that backends can query directly.

In practice, this means:

• Indexing contract events once instead of repeatedly
• Converting raw logs into structured entities
• Persisting derived state that applications can rely on
• Keeping blockchain-specific logic out of application code

This separation makes backends simpler, more predictable, and easier to scale.

Where the indexed data gets used​

Once data is indexed, application backends can:

• Serve APIs backed by indexed blockchain state
• Power user interfaces with pre-processed data
• Track contract state without rescanning history
• Build features that depend on event-driven updates

Because the indexing logic is deterministic and versioned, teams can evolve their schema and handlers without rewriting application logic.

When a blockchain indexer becomes necessary​

Most teams reach for a blockchain indexer when:

• Application logic depends on more than the latest block
• The application needs access to real-time and historical onchain data
• Data needs to be queried frequently or predictably
• The application spans multiple networks and needs a unified data layer
• Backend reliability becomes a priority

At that point, indexing once and querying structured data becomes the simplest approach.

Building a blockchain indexer with Envio​

Envio is designed around a developer-first indexing workflow. Developers define the contracts and events relevant to their application, write deterministic event handlers that map blockchain data into entities, and run the indexer locally to develop and validate logic. The same indexing code runs in hosted environments without changes.

Other indexers like The Graph require separate subgraph deployments per chain and charge query fees through a decentralized network. With Envio, all chains are configured in a single config.yaml and exposed through one GraphQL endpoint, with no per-chain deployment overhead.

As projects scale, Envio provides capabilities that support more advanced indexing and production requirements:

• TypeScript-first: Write event handling logic in JavaScript or TypeScript.
• HyperSync: A high-performance data retrieval layer that delivers up to 2000x faster historical sync than standard RPC. HyperSync is used automatically for all supported networks.
• No-code quickstart: Autogenerate a complete indexer project from a single contract address or ABI using pnpx envio init. Deploy within minutes.
• Multichain indexing: Aggregate data across multiple networks into a single database. Query everything through a unified GraphQL API.
• Onchain and offchain data: Combine indexed onchain events with offchain sources such as NFT metadata, token prices from aggregators, or current chain state via RPC.
• Factory contract support: Automatically register and process events from child contracts created by a factory or dynamic contract.
• Hosted service: A managed hosting platform for building, hosting, and querying Envio indexers, with 99.99% uptime SLA and GitHub-based auto-deploy.

The result is a backend data layer that remains consistent and reliable across development and production.

Getting started​

Envio is designed to start small and scale as requirements grow:

• Index single or multiple contracts
• Map a small set of events into entities
• Run the indexer locally during development with pnpm dev
• Expand the schema and handlers as application requirements grow

For many applications, a blockchain indexer becomes a core part of the backend. Envio supports this workflow from early development through production using the same indexing code across environments.

Frequently asked questions​

What does a blockchain indexer do in an application backend?​

A blockchain indexer reads raw onchain events, applies developer-defined logic, and stores the results as structured entities in a database. Application backends query this database directly instead of hitting RPC endpoints on every request.

When should I use a blockchain indexer instead of direct RPC calls?​

When your application needs historical data, depends on multiple events across contracts or chains, or needs to serve data at scale. Direct RPC calls force the backend to reconstruct state on every query and cannot efficiently handle historical lookups or cross-chain aggregation.

How does Envio differ from The Graph for backend indexing?​

The Graph requires a separate subgraph per chain and charges query fees through a decentralized network. Envio uses a single config.yaml for all chains, a single GraphQL endpoint, and TypeScript handlers with no per-query fees. HyperSync also makes historical sync orders of magnitude faster than The Graph's RPC-based approach.

Does Envio support multichain backends?​

Yes. All networks are defined in one config.yaml. Envio processes events from each chain in parallel and writes them to a shared database. Your GraphQL API reflects the combined state of all configured chains through a single endpoint.

Can I run Envio locally during development?​

Yes. Running pnpm dev spins up the full stack locally using Docker, including the database and GraphQL API. The same handler logic runs locally and in production without modification.

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

Over the past month, we’ve continued making steady progress on HyperIndex V3, with a strong focus on improving how developers build, test, and operate indexers day to day.

This update covers the latest V3 alpha features including a new testing framework, Vitest adoption, improvements to envio init, configuration and state access updates, and several quality of life enhancements across the CLI and TUI. We’re also sharing recent ecosystem updates, production migration examples, and highlights from teams building with Envio.

As always, these changes are incremental building blocks toward a more reliable and flexible indexing workflow, from local development through to production.

HyperIndex V3 (alpha): Exciting Feature Updates​

BIG feature alert: New Testing Framework (experimental)​

V3 supports testing handler logic using real blockchain data, programmatic debugging, & testing block handlers together with event handlers.

The framework also enables LLM workflows using a TDD approach, supports snapshotting indexer behaviour, & runs multiple tests in parallel using isolated worker threads.

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


describe("Indexer Testing", () => {
  it("Should create accounts from ERC20 Transfer events", async () => {
    const indexer = createTestIndexer();

    expect(
      await indexer.process({
        chains: {
          1: {
            startBlock: 10_861_674,
            endBlock: 10_861_674,
          },
        },
      }),
      "Should find the first mint at block 10_861_674"
    ).toMatchInlineSnapshot(`
      {
        "changes": [
          {
            "Account": {
              "sets": [
                {
                  "balance": -1000000000000000000000000000n,
                  "id": "0x0000000000000000000000000000000000000000",
                },
                {
                  "balance": 1000000000000000000000000000n,
                  "id": "0x41653c7d61609d856f29355e404f310ec4142cfb",
                },
              ],
            },
            "block": 10861674,
            "blockHash": "0x32e4dd857b5b7e756551a00271e44b61dbda0a91db951cf79a3e58adb28f5c09",
            "chainId": 1,
            "eventsProcessed": 1,
          },
        ],
      }
    `);
  }
}   

Vitest - Recommended Testing Framework​

V3 recommends Vitest as the testing framework for indexer projects.

It replaces mocha, chai, and tsx with a single package that works out of the box, and supports features like snapshot testing.

All envio init templates have been updated to use Vitest, with tests living directly in src and support for handler specific test files.

"scripts": {
- "mocha": "tsc --noEmit && NODE_OPTIONS='--no-warnings --import tsx' mocha --exit test/**/*.ts",
- "test": "pnpm mocha",
+ "test": "vitest run"
},
"devDependencies": {
- "@types/chai": "^4.3.11",    
- "@types/mocha": "10.0.6",
- "chai": "4.3.10",
- "tsx": "4.21.0",
- "mocha": "10.2.0"
+ "vitest": "4.0.16"
}