DEV Community: Envio

Indexing and Reorgs

Envio — Thu, 17 Sep 2026 14:42:41 +0000

Author: Denham Preen, Co-Founder at Envio

TL;DR

Chain reorganizations (reorgs) affect any indexer processing data near the chain head. Stateful indexers (those using updates and deletes) require rollback logic. Stateless ones (create-only) just need orphaned entities deleted.
Multichain indexers face additional complexity: a reorg on one chain may require rolling back state that was affected by events from other chains.
Envio handles reorg detection and rollback automatically, so developers do not need to implement rollback logic themselves.

In this article, we unpack the implications of chain reorganizations on consuming and aggregating onchain data, considerations in a multichain environment, and how to design for them.

We assume you have a strong understanding of what a chain reorganization is. If you want a refresher, skip to the bottom.

Note: Handling reorgs is only important if you are indexing at the head, or handling data within the range of the head and the network's finalized block.

Chain reorgs and independent data

Independent data is data that does not require the previous state in order to process the current state. In an indexer, this means only "create" operations. If the only CRUD operations your handlers perform are writing entities, your indexer is handling stateless data, and handling reorgs is straightforward: delete all entities from orphaned blocks and re-ingest them with the canonical block's data. This is possible because stateless data allows for parallel processing.

In practice, we usually need to perform some aggregation on data to turn it into meaningful information. In that context, our indexer is dealing with stateful data.

Side tangent: Stateless indexing can be handled incredibly fast by parallelization, such as indexers like Flair that achieve impressive speed with only RPC.

Chain reorgs and stateful data

Stateful data is data that depends on the previous state (think update and delete operations) in order to process the current state. When handling stateful data, your indexer needs to account for the current state of entities, and reorgs become notably more complex.

During a chain reorg, rather than simply replacing orphaned data, you need to revert previous operations or changes and ensure that the entity state is rolled back correctly. This requires tracking the history of changes to each entity so that when a reorg occurs, you can accurately undo or adjust state based on the adopted canonical chain's data.

Note: We can periodically prune the entity history, retaining only the changes relevant to unfinalized blocks.

Reorgs and multichain indexing

When it comes to multichain indexing, we face additional complexity because we process events from multiple sources that interact and update the same entity state. When one chain undergoes a reorg, we need to roll back the state to a known correct point and reprocess any events from all chains that affected the state after the reorg on the affected chain.

Reorgs in the wild

In practice, different networks exhibit varying levels of exposure to reorgs based on their design. Some networks, like Base and the OP stack, are largely reorg-resistant with block finality occurring at the head, though exceptions do exist. On the other hand, networks like Polygon frequently experience deeper reorgs, where forked chains can extend over 10 blocks deep. One notable instance involved a reorg of 157 blocks. Both Etherscan and Blockscout provide data on reorg occurrences. According to Ethereum Mainnet Etherscan, roughly 1% of blocks undergo reorgs, meaning that, assuming a 50/50 chance of a transaction being included in either the orphaned or canonical chain, about 1 in 200 transactions is likely to be in a reorged block.

Conclusion

Reorgs are a crucial consideration in blockchain indexing. Understanding their implications and designing with flexibility allows you to properly account for them in your indexer. Envio handles reorg detection and state rollback automatically, so developers building on HyperIndex get correct data at the head without needing to implement rollback logic themselves.

What are chain reorgs?

In order to understand reorgs, let's break down the fundamental concepts and build up to a definition.

Fundamental concepts:

Block
Chain
Miners
Chain fork
Orphaned chain
Canonical chain
Block finality

Block

A container that stores transactions.

Chain

A series of sequential blocks.

Miners

Actors that try to submit the next valid block.

Chain fork

A chain fork occurs when more than one miner submits a valid block at the same time, causing a split where two valid chains exist simultaneously.

Orphaned chain and canonical chain

When a chain forks, eventually one chain becomes accepted as the valid chain, known as the canonical chain. The forked chain that is not accepted becomes the orphaned chain. Orphaned blocks cease to exist, and transactions that occurred in those blocks cease to exist as well.

Orphaned chain: The forked chain that is dropped
Canonical chain: The chain adopted as the valid chain

Info: We do not know which fork will be orphaned and which will become canonical until after the fact.

Block finality

The minimum number of blocks needed to confirm that blocks will not become part of an orphaned chain.

Info: Block finality is the reason bridges and centralized exchanges require a confirmation delay after a transaction is confirmed, to ensure blocks will not become orphaned.

Reorg

A reorg is a set of events that results in a chain rolling back to a previous point in time.

Frequently asked questions

Does every blockchain indexer need to handle reorgs?

Not necessarily. If your indexer only processes finalized blocks (past the finality threshold), reorgs are not a concern. Reorg handling is only important if you are indexing at the head or within the range between the head and the network's finalized block.

What is the difference between stateless and stateful indexing in the context of reorgs?

A stateless indexer only creates new entities. On a reorg, you delete orphaned entities and re-ingest from the canonical chain. A stateful indexer also updates and deletes entities based on previous state, which requires tracking the history of changes so that state can be accurately rolled back when a reorg occurs.

Which networks experience the most frequent or deepest reorgs?

Polygon is known for frequent and sometimes deep reorgs (a 157-block reorg has been recorded). Base and OP stack chains are largely reorg-resistant due to single-slot finality. Ethereum mainnet sees roughly 1% of blocks affected by reorgs. Networks with faster block times and probabilistic finality tend to have more reorg activity.

How does Envio handle reorgs automatically?

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

How do reorgs affect multichain indexers?

In a multichain indexer, events from multiple chains may update the same entity. If one chain reorgs, any state changes that depended on post-reorg events from that chain must also be rolled back and reprocessed, even if those changes involved events from other chains. This makes multichain reorg handling significantly more complex than single-chain reorg handling.

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 💌

Blockchain Indexer For Application Backends

Envio — Thu, 17 Sep 2026 14:42:35 +0000

TL;DR

Blockchain indexers sit between the chain and your application backend, transforming raw events into structured, queryable data your app can depend on.
Without an indexer, backends must reconstruct state from history, handle reorgs, and translate raw logs. This complexity compounds as projects scale.
Envio handles this with a single config.yaml, TypeScript event handlers, HyperSync for fast historical sync, and a hosted GraphQL API that works across multiple chains.

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

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

Subscribe to our newsletter 💌

Exploring Real-time Oracle Behavior and Push Based Feeds

Envio — Thu, 17 Sep 2026 14:42:29 +0000

Co-authors: Jordyn Laurier, Head of Marketing, and Jonjon Clark, Co-Founder at Envio

TL;DR

Oracle Wars is a live dashboard that visualizes real-time oracle behavior on MegaETH, built with Envio HyperIndex in under two hours.
Push oracles use heartbeat intervals and deviation thresholds to trigger updates. A 0.5% deviation threshold does not mean consecutive onchain prices only differ by 0.5%.
HyperIndex makes building real-time monitoring tools for high-throughput chains like MegaETH straightforward, with no RPC rate limit concerns.

Oracles are the connection between blockchains and real-world data, enabling smart contracts to interact with off-chain events like asset prices, market rates, or real-time sports scores. Visualizing how they behave in practice offers a new level of clarity for developers building onchain apps.

Oracle Wars is a live feed of onchain oracle data that shows how different providers behave in real time. It helps developers visualize and better understand how oracles function under different market conditions, so they can design more reliable and secure smart contracts.

Please note: The multi-oracle comparison dashboard shown in earlier versions is no longer live on the site. Oracle Wars currently displays live ETH/USD price oracle updates from the Redstone Bolt oracle feed on MegaETH. Oracle Wars remains an educational and experimental tool for surfacing real-time data from various oracle providers.

What is a blockchain oracle?

In simple terms, oracles allow smart contracts to react to external data sources. Whether it is the latest price of an asset or the outcome of a sporting event, oracles are how the blockchain sees the world.

Over time, oracle architectures have evolved, giving rise to push-based oracles, pull-based oracles, and many more. Each design has trade-offs. This post focuses on push oracles and how they behave from a data perspective.

Push oracles in practice

A push oracle periodically pushes data onto the blockchain. Your contract reads that data and responds accordingly, whether it is executing a trade, adjusting a loan-to-value ratio, or triggering another onchain action.

Most push oracles use two primary mechanisms:

Heartbeat intervals: Regular updates (e.g., every 24 hours)
Deviation thresholds: Immediate updates when data shifts significantly (e.g., 0.5% price movement)

Visualizing real-time oracle activity with Oracle Wars

Wonder what happens in live conditions during periods of high volatility? That is where Oracle Wars came in. The earlier version of the dashboard showed a live comparison between price feeds from different oracle providers such as Chainlink and RedStone. Oracle Wars now focuses on Redstone Bolt ETH/USD updates on MegaETH, but the patterns below still apply to the earlier multi-oracle view.

You will notice that updates are not always evenly spaced. That is the deviation threshold kicking in: when markets get volatile, updates come in fast. When things are calm, fewer updates appear. This is a valuable pattern to observe if you are designing a protocol that depends on accurate and real-time data.

Understanding the limitations of deviation thresholds in push oracles

Oracle Wars also shows the maximum deviation between any two consecutive price points over 24 hours. Every DeFi protocol relies on timely and accurate price data, and large shifts between updates can lead to exploit risk, broken assumptions, or cascading failures. This metric gives developers a real-world view of how much price movement can actually occur between updates, even when using well-known oracle providers.

This brings us to a common misunderstanding: deviation thresholds are not strict limits.

Take Chainlink and RedStone, for instance. Both use a 0.5% deviation threshold for price feeds. That should mean the oracle updates whenever the price moves more than 0.5%. But here is the catch:

A 0.5% deviation threshold does not mean consecutive onchain prices will only differ by 0.5%.

In practice, you might see larger deviations. Over 24 hours alone, Oracle Wars recorded deviations of around 0.67% for both providers. This does not mean the oracles were broken. It means they are working as designed. The threshold is more of a trigger condition than a strict upper bound.

If you are competing in security audits on platforms like Sherlock, Code4rena, or CodeHawks, these edge cases are worth thinking through. Your protocol logic needs to account for potentially higher-than-expected changes, especially in volatile markets.

Is a super-fast push oracle now better than a pull oracle?

With the advent of high-speed chains like MegaETH and Monad, we are starting to see ultra-fast push oracles that update data with each block. This near-instantaneous data feed challenges traditional push oracles, offering freshness comparable to pull oracles, provided transaction costs remain manageable.

On Oracle Wars, you can observe how these super-fast push oracles behave in real time, with feeds like the ETH/USD price on MegaETH. The data is continuously updated, providing a new level of insight into how push oracles might evolve to rival the responsiveness of pull models.

One aspect that remains intriguing is the frequent occurrence of multiple price updates at the same timestamp. This raises questions about whether these oracles are pushing multiple updates within the same block and the rationale behind this granularity.

While Redstone's Bolt push oracle is an exciting development, it is still early days. It will be interesting to see how other oracle providers and chains approach the super-fast push model. The key question remains: can ultra-fast push oracles maintain the freshness and reliability of pull oracles without significant cost overhead?

Oracle Wars: powered by Envio's HyperIndex

Oracle Wars was built in under two hours using Envio's HyperIndex, which made indexing real-time oracle data smooth and straightforward. No custom RPC infrastructure was needed, and no rate limit concerns applied.

If you are building dashboards, simulations, or monitoring tools, it is worth checking out. Need help getting started? Feel free to reach out in our Discord or on Telegram.

Helpful resources

Background posts on X that kicked this off:

Frequently asked questions

What is the difference between a push oracle and a pull oracle?

A push oracle periodically writes updated data directly to the blockchain. A pull oracle does not write data proactively. Instead, it allows consumers to request data on demand, usually with a small fee. Pull oracles can offer fresher data per request, but push oracles are simpler to integrate since the data is already onchain when your contract needs it.

Why can the actual price deviation between oracle updates exceed the stated deviation threshold?

Deviation thresholds are trigger conditions, not strict caps. When the threshold is set at 0.5%, the oracle updates whenever the price moves 0.5% from the last onchain price. However, by the time the update transaction is confirmed, the actual market price may have moved further. During high volatility, you can observe deviations larger than the configured threshold.

How was Oracle Wars built so quickly using Envio?

Oracle Wars was built in under two hours because Envio HyperIndex handles all data ingestion, storage, and GraphQL API generation automatically. The developer only needed to define the oracle contract's ABI, configure the events of interest in config.yaml, and write event handlers to store price updates. Envio handles the rest.

Can HyperIndex handle the data throughput of high-frequency oracle feeds on MegaETH?

Yes. HyperIndex is designed for high-throughput chains and uses HyperSync as its data retrieval layer, which bypasses RPC entirely for historical data and keeps up with real-time blocks efficiently. Oracle Wars on MegaETH demonstrates this with continuous ETH/USD price streaming at sub-millisecond block times.

Should I use Oracle Wars for production smart contract design decisions?

Oracle Wars is an educational and experimental tool, not a production monitoring service. It is useful for understanding how push oracles behave under real market conditions and for informing your protocol design. For production systems, use the oracle provider's official documentation and run your own analysis of historical deviation data.

Build With Envio

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

Subscribe to our newsletter 💌

Optimizing Blockchain Indexers on AWS

Envio — Thu, 17 Sep 2026 14:42:01 +0000

TL;DR

Running blockchain indexers on AWS has three main cost drivers: networking (NAT Gateway, cross-AZ data transfer), compute (instance sizing, spot instances), and storage (RDS vs Aurora I/O-Optimized).
Practical strategies like single-AZ deployment, Bottlerocket OS, and Aurora I/O-Optimized can cut costs significantly without sacrificing reliability.
These are the same optimizations Envio uses internally to power its Hosted Service, so teams using Envio Cloud get these benefits without configuring them manually.

When running any application on cloud infrastructure, one of the first questions that comes up is: where did all the money go? In the AWS ecosystem, expenses like hidden EC2 charges, complex data transfer costs, or the confusing Aurora pricing model can quickly add up.

Whether you are running Envio's HyperIndex on your own AWS setup or are curious about how Envio optimizes cloud resources to deliver its Hosted Service, this guide walks through practical techniques to maximize your blockchain indexer's performance while keeping costs as low as possible.

Challenges of running indexers on AWS

Understanding these challenges helps you prepare and optimize your setup effectively:

Cost management: Navigating AWS pricing is complex. Hidden charges, especially for data transfer and compute, can lead to unexpected bills if not carefully monitored.
Configuration complexity: Setting up an efficient architecture requires a solid understanding of AWS services. Misconfigurations lead to increased costs and reduced reliability.
Performance tuning: Indexers handle fluctuating workloads. Balancing performance with cost-effectiveness requires constant monitoring and adjustments.
High availability: Achieving true high availability without significant costs requires careful trade-offs between cost and redundancy.
Data management: As indexers scale, managing large volumes of data efficiently becomes critical for maintaining performance while keeping costs low.

The costs of running an indexer

The cost of running an indexer breaks down into three key areas:

1. Networking

Avoid NAT Gateway

At the core of every indexer is fetching data from external sources (like HyperSync or an RPC provider) and indexing it into a storage layer (PostgreSQL). If you are running your indexer in an AWS private subnet, network traffic passes through a NAT Gateway, costing $0.045/GB (US-East) for both requests and responses.

Think of a NAT Gateway as a hotel doorman: it handles your packages and ensures your privacy, but it comes at a cost. If you have carefully assessed your security needs and set up proper security groups, running your indexer in a public subnet is a perfectly acceptable option. In that case, you can bypass the NAT Gateway entirely and use an Internet Gateway, allowing communication with the outside world without the added cost of NAT traffic.

Transferring data within a region

When deploying an indexer in Kubernetes (EKS) or on an EC2 instance, it is easy for your indexer and storage layer to end up in different availability zones (AZs). AWS charges $0.01/GB (US-East) for data transferred between AZs, both in and out. To minimize costs, deploy both your indexer and storage layer within the same AZ.

You might wonder: does this compromise high availability? Somewhat. If one AZ goes down, both your indexer and storage layer go down together. But since these two components are tightly coupled, if one fails the other is effectively unusable anyway.

For true HA with low costs, consider AWS Aurora. Aurora replicates data across multiple AZs at no extra cost (baked into Aurora's pricing), and your indexer can connect to an Aurora instance within its own AZ. If one AZ fails, your indexer can redeploy in another AZ where another Aurora instance is ready.

2. Compute

Figuring out the right amount of compute power for your indexer requires balancing two distinct phases. When first deployed, your indexer processes historical data. Once caught up, it only needs to handle real-time indexing. The compute resources required for these two stages are quite different: historical indexing demands more resources while real-time indexing requires less.

To optimize costs, use different EC2 instance types for each stage. Start with a larger, more powerful instance to process historical data as quickly as possible, then switch to a smaller, cheaper instance once you are caught up. Since AWS charges by the hour, find the smallest instance that can sync historical data quickly enough, then downsize for real-time indexing.

Spot instances

Spot instances can save up to 90% on EC2 costs. They are unused EC2 capacity offered at a discount but can be terminated when AWS needs the capacity. For HyperIndex indexers, which are stateless by nature, this is less of an issue since moving an indexer from one instance to another is straightforward. If staying close to real-time is critical, the interruptions of spot instances may be a headache.

Using Bottlerocket OS for EC2 instances

One way to minimize downtime when using spot instances, especially if running your indexer in EKS, is to use Bottlerocket OS for your EC2 instances. Bottlerocket is a lightweight, container-optimized operating system that boots up much faster than Ubuntu or Amazon Linux. By using Bottlerocket, you can significantly cut downtime when a spot instance gets replaced. Since it is lightweight, more of your resources are dedicated to the indexer itself.

Tip: when using spot instances with tools like EKS and Karpenter, specify as many EC2 instance types as possible. If one type runs out of spot capacity, Karpenter can try another before falling back to an on-demand instance.

3. Storage

When hosting indexers on AWS, your primary options for PostgreSQL are AWS RDS and Aurora.

IOPS

Indexers are high-IOPS applications that handle a relentless stream of inserts and updates, meaning they need a storage solution that can support high IOPS. Serverless options will not cut it for indexers, as they cannot manage the constant load.

For indexers on Aurora, Aurora I/O-Optimized is worth considering. Released in May 2023, this configuration eliminates IOPS charges, allowing you to avoid significant I/O costs that can make up 50% of expenses on standard Aurora. By switching to Aurora I/O-Optimized, you effectively get unlimited IOPS. The higher storage costs are offset by the elimination of per-IOPS billing, making it a more predictable and potentially cheaper option for high-I/O workloads.

Storage requirements

With RDS, you provision storage upfront, which can lead to over-provisioning. Aurora offers a pay-as-you-go storage option that scales automatically as your data grows. This flexibility can result in significant savings, especially when dealing with historical indexing or unpredictable storage growth.

Resource requirements

A key component of Aurora is its separation of compute and storage. Unlike RDS, where storage is tightly coupled with compute, Aurora allows you to scale these independently. This is particularly useful when your indexer's compute and storage requirements fluctuate at different stages of the indexing process.

In short: since indexers are high-I/O applications that scale up and down over time, Aurora I/O-Optimized can provide significant cost savings while delivering the performance you need. RDS remains a more affordable option for smaller indexers or a more hands-on approach to storage management.

Conclusion

Running indexers on AWS does not have to be expensive. By understanding the key cost drivers in networking, compute, and storage and using the right AWS tools and configurations, you can significantly reduce your cloud bill while maintaining high performance. Whether you are optimizing your network with a single-AZ setup or taking advantage of spot instances for compute savings, there is always a smart way to balance performance and cost.

These are the same optimizations Envio uses to power its Hosted Service. Teams using Envio Cloud get these benefits automatically, without needing to configure them manually.

What is AWS?

AWS (Amazon Web Services) is a cloud computing platform providing on-demand services including computing power, storage, and networking. It allows businesses to scale their infrastructure without owning physical servers, offering flexibility and cost efficiency. Whether you are running a simple website or a complex application like a blockchain indexer, AWS helps you manage resources while paying only for what you use.

Frequently asked questions

Should I run my blockchain indexer in a public or private AWS subnet?

For most indexers, a public subnet with well-configured security groups is a perfectly acceptable and cost-effective option. It avoids NAT Gateway charges ($0.045/GB) while still maintaining security through security groups. Private subnets add privacy but add cost and complexity that may not be justified for an indexer.

Is Aurora always cheaper than RDS for blockchain indexers?

Not always, but for high-IOPS indexers Aurora I/O-Optimized is typically more cost-effective. Standard Aurora and RDS charge per I/O operation, which adds up fast for indexers doing constant inserts and updates. Aurora I/O-Optimized eliminates per-IOPS billing in favor of higher storage costs, which is usually a net win for indexing workloads.

Can I use spot instances for a production blockchain indexer?

Yes, with caveats. HyperIndex indexers are stateless, so recovering from a spot termination is straightforward. If you need to stay as close to real-time as possible, spot interruptions may cause brief gaps. Using Bottlerocket OS and specifying multiple instance types in Karpenter minimizes downtime when instances are replaced.

How does Envio's hosted service compare to self-managing on AWS?

Envio's Hosted Service applies the same optimizations described in this post (single-AZ networking, Aurora I/O-Optimized, Bottlerocket OS on EKS) internally. Self-managing on AWS gives you more control but requires engineering time to configure and maintain these optimizations yourself. For most teams, the hosted service is faster and cheaper to operate.

What is the biggest hidden cost when running indexers on AWS?

NAT Gateway charges and cross-AZ data transfer fees are the most commonly overlooked costs. A single indexer processing large volumes of HyperSync data through a NAT Gateway can generate hundreds of dollars per month in transfer fees. Deploying in a public subnet or consolidating your indexer and database in the same AZ eliminates most of this cost.

Build With Envio

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

Subscribe to our newsletter 💌

How Envio Simplifies Data Retrieval for Multichain dApps

Envio — Thu, 17 Sep 2026 14:41:55 +0000

TL;DR

Deploying a dApp across multiple chains creates a fragmented data problem. Each chain has its own events, its own state, and no native way to query across them together.
Envio HyperIndex solves this with a single indexer instance that reads events from multiple networks and exposes everything through one GraphQL endpoint.
Configuration is a single config.yaml file. No separate deployments, no cross-service data joins.

The multichain future is already here. Protocols like Uniswap, Aave, and Compound are deployed across Ethereum, Arbitrum, Optimism, Base, Polygon, and more. Reaching users on multiple chains means accepting the data fragmentation that comes with it.

For developers, this fragmentation is a real infrastructure problem. Traditional indexing approaches require a separate indexer and database per chain. Aggregating that data in your frontend means either stitching together multiple API calls or building additional backend logic to consolidate it. Both approaches add complexity and maintenance overhead.

The Multichain Data Problem

When a dApp is deployed across multiple chains, every interaction that matters (swaps, transfers, liquidations, mints) is emitted as an event on each respective chain. There is no native cross-chain view of this data.

The conventional approach requires:

One indexer deployment per chain
One database per chain
Custom aggregation logic in the frontend or a separate backend layer

This compounds quickly. A protocol on five chains needs five indexer deployments to maintain, five databases to keep in sync, and aggregation logic that breaks every time a new chain is added.

Multichain Indexing with Envio HyperIndex

Envio HyperIndex handles multichain indexing from a single indexer instance. All networks are defined in one config.yaml. All indexed data lands in one database. Everything is queryable through one GraphQL endpoint.

Other indexers require a separate subgraph or pipeline per chain. With Envio, adding a new chain is a config change, not a new deployment.

Example: Greeter Contract on Polygon and Linea

The following example walks through a multichain Greeter indexer that listens for NewGreeting events from contracts deployed on both Polygon and Linea.

config.yaml

name: Greeter
description: Greeter indexer
networks:
  - id: 137 # Polygon
    start_block: 45336336
    contracts:
      - name: Greeter
        abi_file_path: ./abis/greeter-abi.json
        handler: ./src/EventHandlers.ts
        events:
          - event: NewGreeting
  - id: 59144 # Linea
    start_block: 367801
    contracts:
      - name: Greeter
        abi_file_path: ./abis/greeter-abi.json
        handler: ./src/EventHandlers.ts
        events:
          - event: NewGreeting

Both networks share the same handler and ABI. Adding a third chain means adding another network block. The handler logic stays unchanged.

schema.graphql

type User {
  id: ID!
  greetings: [String!]!
  latestGreeting: String!
  numberOfGreetings: Int!
}

Event handler

A single TypeScript handler processes NewGreeting events from both chains:

import { Greeter } from "generated";

Greeter.NewGreeting.handler(async ({ event, context }) => {
  const currentUser = await context.User.get(event.params.user.toString());

  context.User.set({
    id: event.params.user.toString(),
    latestGreeting: event.params.greeting,
    numberOfGreetings: (currentUser?.numberOfGreetings ?? 0) + 1,
    greetings: [...(currentUser?.greetings ?? []), event.params.greeting],
  });
});

The handler runs identically for events from any network in the config. Chain-specific context (like event.chainId) is available if you need it for cross-chain logic.

For the full multichain indexing documentation, see the Envio docs. For a more complex multichain example, see the Uniswap V4 Multichain Indexer.

Frequently asked questions

How does Envio handle events from multiple chains in one indexer?

All networks are defined in a single config.yaml. HyperIndex processes events from each network in parallel and writes them to a shared database. Your GraphQL API reflects the combined state of all indexed chains.

Do I need separate deployments for each chain?

No. A single HyperIndex instance handles all configured networks. One deployment, one database, one GraphQL endpoint.

Can the same handler logic run across different chains?

Yes. A single handler function processes matching events from all networks in your config. If you need to apply chain-specific logic, event.chainId is available in the handler context.

How many chains does Envio support?

HyperSync natively supports 80+ EVM chains. Any supported chain can be added to your config.yaml. For chains not yet covered by HyperSync, you can fall back to an RPC endpoint without changing your handler code.

Where can I see a full multichain indexing example?

The Greeter tutorial in the Envio docs walks through multichain indexing step by step. The Uniswap V4 Multichain Indexer is a more complex real-world example covering many chains.

Build With Envio

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

Subscribe to our newsletter 💌

Dedicated Hosting for Blockchain Indexers

Envio — Thu, 17 Sep 2026 14:41:50 +0000

TL;DR

Running a blockchain indexer in production requires a database, a GraphQL API layer, uptime monitoring, and infrastructure that scales with your data.
Envio Cloud handles all of this as a managed service, so teams can focus on handler logic rather than infrastructure.
Self-hosting via Docker is also supported for teams that want full infrastructure control.

Deploying a blockchain indexer locally is straightforward. Keeping one running reliably in production is a different problem. You need a database, a GraphQL API layer, uptime guarantees, and a deployment process that does not require manual intervention every time your handler logic changes.

This article covers what a dedicated hosted indexer service provides, how Envio Cloud works, and how to decide between managed hosting and self-hosting.

What a Hosted Indexer Service Provides

A hosted indexer service takes your indexer configuration, schema, and handler code and runs the full stack for you. This includes:

Database: Storing indexed events and entity tables
GraphQL API: Auto-generated from your schema via Hasura, queryable by your frontend
Uptime: The service monitors availability and handles restarts automatically
Deployment: Syncing from your repository so new versions deploy without manual steps

Without a hosted service, each of these components needs to be provisioned, maintained, and scaled independently. For teams focused on building a product rather than managing infrastructure, this is significant overhead.

How Envio Cloud Works

Envio Cloud is the managed hosting option for HyperIndex. It runs on AWS infrastructure with Kubernetes orchestration and Hasura for the GraphQL layer.

Deployment is integrated with GitHub. An Envio GitHub bot monitors your repository and triggers new deployments when changes land in your specified branch. There is no manual deploy step once the integration is configured.

The stack Envio Cloud manages:

AWS: Cloud infrastructure and compute
Kubernetes: Container orchestration and scaling
Hasura: Real-time GraphQL API generation from your schema
HyperSync: The data engine powering historical sync, up to 2000x faster than standard RPC

For local development, the full stack runs with a single pnpm dev command using Docker Desktop. The same handler logic runs locally and in production without modification.

Managed Hosting vs Self-Hosting

HyperIndex supports both options:

	Envio Cloud	Self-hosted (Docker)
Infrastructure setup	Handled by Envio	You manage
Uptime monitoring	Included	You manage
Deployment	GitHub bot auto-deploy	Manual or custom CI
Cost	Free tier and paid plans	Your infrastructure costs
Control	Standard configuration	Full control

For most teams, Envio Cloud is the faster path to production. For teams with specific compliance requirements or existing infrastructure preferences, self-hosting via Docker gives full control without changing any handler code.

Getting Started

Deploy to Envio Cloud from the hosted service docs. If you do not have an indexer yet, the contract import quickstart generates a working indexer from any deployed contract address in under 5 minutes:

pnpx envio init

Frequently asked questions

What infrastructure does Envio Cloud run on?

Envio Cloud uses AWS for compute, Kubernetes for orchestration, and Hasura for the GraphQL API layer. HyperSync powers historical data retrieval for all supported networks.

How does deployment work with Envio Cloud?

Envio Cloud integrates with GitHub via a bot that monitors your repository. When changes land in your configured branch, a new deployment is triggered automatically.

Can I self-host HyperIndex instead of using Envio Cloud?

Yes. HyperIndex can be self-hosted using Docker. The same handler logic and schema work identically in both environments. See the hosting docs for setup instructions.

What is included in the free tier?

See the Envio Cloud docs for current plan details and limits.

Does Envio Cloud support multichain indexers?

Yes. A single HyperIndex instance can index multiple networks and all data is queryable through one GraphQL endpoint, whether hosted on Envio Cloud or self-hosted.

Build With Envio

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

Subscribe to our newsletter 💌

Agentic Blockchain Indexing with Envio Cloud

Envio — Thu, 17 Sep 2026 14:41:21 +0000

TL;DR

Envio HyperIndex and the envio-cloud CLI enable end-to-end agentic deployment of blockchain indexers with no manual config.
An AI agent scaffolded, configured, pushed to GitHub, and deployed a wstETH indexer on Monad Mainnet from a single prompt.
400,000 events indexed in approximately 20 seconds.
Every step is CLI-driven and scriptable, with JSON output for downstream agent logic.

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 init template -t erc20 -l typescript -d ./my-indexer

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 init template -t erc20 -l typescript -d ./my-indexer

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 8 seconds, 142x faster than The Graph and 15x faster than the nearest competitor (Subsquid). 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 80+ 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 init template -t erc20 -l typescript -d ./my-indexer. 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 💌

Envio Now Supports 70+ Blockchains

Envio — Thu, 17 Sep 2026 14:41:14 +0000

TL;DR

Envio's HyperSync now supports over 70 EVM-compatible networks plus Fuel, providing reliable real-time data access at speeds up to 2000x faster than standard RPC.
HyperIndex adds full multichain indexing with a single config.yaml and a single GraphQL endpoint, making it structurally simpler than The Graph or Goldsky for cross-chain data.
If your network is not yet supported, you can request HyperSync support directly in the Envio Discord.

Envio's HyperSync supports over 70 EVM-compatible networks along with Fuel, providing reliable real-time data access across the Web3 ecosystem. This milestone advances the goal of making decentralized data more efficient and accessible for developers and analysts building across multiple blockchains.

What is HyperSync?

HyperSync is Envio's advanced data node, built in Rust to dramatically speed up blockchain data retrieval. It operates as a real-time, high-speed query layer, offering a low-level API compatible with Python, Rust, Node.js, and Go. With HyperSync, you can query millions of events in seconds, delivering sync speeds up to 2000x faster than traditional RPC methods.

HyperSync is well suited for performance-heavy applications like block explorers, data analytics platforms, and blockchain bridges. Traditional syncing methods can be slow and resource-intensive, especially across multiple networks. HyperSync optimizes these processes with intelligent caching and efficient data retrieval, giving you faster access to both real-time and historical blockchain data.

Multichain indexing support

Envio HyperIndex provides multichain indexing support, enabling you to efficiently index and query multiple blockchains with a single indexer. This eliminates redundant tools, streamlines workflows, and ensures high performance at scale.

Unlike The Graph (which requires a separate subgraph per chain with separate endpoints) or Goldsky (which requires separate pipelines per chain), Envio uses a single config.yaml to define all networks and exposes a single GraphQL endpoint. This makes cross-chain data access significantly simpler to build and maintain.

Supported networks

Envio supports any EVM chain and Fuel with an expanding list of networks, including Arbitrum, Base, Blast, Celo, Chiliz, Citrea, Darwinia, Ethereum, Gnosis, Metis, Monad, Morph, Optimism, Polygon, Rootstock, Scroll, and many more.

See the full list of supported networks in the documentation.

We are rapidly adding new supported networks. If your network is not listed or you would like HyperSync support added, pop us a message in our Discord.

Why use Envio?

Envio HyperIndex offers a developer-centric blockchain data indexing solution, empowering you to efficiently access and process both real-time and historical smart contract data served via GraphQL API:

Flexible language support: Configure your event handling in JavaScript, TypeScript, or ReScript.
HyperSync: Delivers up to 2000x faster indexing than standard RPC for historical onchain data. Use of RPC is optional.
No-code quickstart: Autogenerate the key boilerplate for an entire indexer project from single or multiple smart contracts. Deploy within minutes.
Multichain support: Aggregate data across multiple networks into a single database. Query all your data with a unified GraphQL API.
Factory contracts: Automatically register and process events emitted by all child contracts created by a specified factory or dynamic contract.
Hosted service: A managed service platform for building, hosting, and querying Envio's Indexers with guaranteed uptime and performance service level agreements.

Useful resources

Conclusion

Envio is a powerful alternative to traditional blockchain indexing methods. Its single-config multichain approach simplifies cross-chain data access and eliminates the per-chain overhead that comes with The Graph subgraphs or Goldsky pipelines.

Frequently asked questions

How do I check if my network is supported by Envio HyperSync?

Visit the HyperSync supported networks page in the documentation. If your network is not listed, you can request support by opening a message in the Discord.

Can I use Envio on a network that HyperSync does not yet support?

Yes. For networks without HyperSync support, Envio HyperIndex falls back to standard RPC for data retrieval. You provide an RPC URL in your config, and the indexer works the same way, just without the HyperSync speed boost. HyperSync support is added regularly.

What languages can I use with the HyperSync API?

HyperSync exposes a low-level API with clients for Python, Rust, Node.js, and Go. You can retrieve data in JSON, Arrow, or Parquet formats depending on your pipeline needs.

How does Envio's multichain support compare to The Graph?

The Graph requires a separate subgraph deployment for each chain, with separate GraphQL endpoints per network. Envio uses a single config.yaml to define all networks and a single GraphQL endpoint for all chains. This means less boilerplate, fewer deployments to manage, and simpler cross-chain queries.

Is HyperSync available as a standalone API, or only through HyperIndex?

HyperSync is available both as the underlying data layer for HyperIndex and as a standalone API. Data analysts can query HyperSync directly using the Python, Rust, Node.js, or Go clients for custom data pipelines, analytics, and research use cases.

Build With Envio

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

Subscribe to our newsletter 💌

How to Track Polymarket Trades Using Envio's HyperSync

Envio — Thu, 17 Sep 2026 14:41:10 +0000

TL;DR

Build a real-time Polymarket trade tracker using Envio HyperSync and TypeScript with Bun.
Stream block heights from Polygon and query OrderFilled events from the Polymarket Exchange contracts on each new block.
Decode events with Viem, identify buy vs sell trades by checking makerAssetId, and calculate price per share.
Extend with filters for trade amount or specific wallet addresses to track high-conviction traders.

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 80+ 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

Why use HyperSync for Polymarket trade tracking instead of RPC?

HyperSync provides up to 2,000x faster data access than standard RPC and exposes a streaming interface tailored to filtered event queries. For Polymarket's high-throughput Exchange contracts on Polygon, this avoids the RPC rate limits and polling overhead that constrain real-time trade trackers built on standard JSON-RPC. Polygon is one of 80+ EVM chains with native HyperSync coverage, and HyperSync client libraries are available for TypeScript/Node.js, Python, Rust, and Go.

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

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

Subscribe to our newsletter 💌

Migrate from Alchemy to Envio

Envio — Thu, 17 Sep 2026 14:41:04 +0000

Migrate from Alchemy to Envio

Migrating Alchemy subgraphs to Envio’s HyperIndex is a simple and developer-friendly process. Alchemy subgraphs follow The Graph’s model and HyperIndex uses a very similar structure, so most of your existing setup can carry over cleanly.

If you're familiar with The Graph’s libraries, the migration process should be straightforward. You can also utilize tools like Cursor to speed things up. If you are new to HyperIndex, we strongly recommend starting with our Quickstart guide before you begin your migration from Alchemy. If you are new to the category entirely, see what a blockchain indexer is for the wider context.

Why Migrate to Envio’s HyperIndex?

High-Speed Performance: 142x faster than subgraphs
Lower Costs: Reduced infrastructure requirements and operational expenses
Better Developer Experience: Simplified configuration and deployment
Multichain Native: Index data across multiple EVM chains through a single HyperIndex project
Local Development: Run your indexers locally for fast iteration and easier debugging
White Glove Migration Support: Get direct support from the Envio team for a smoother migration.
GitOps Ready Deployments: Link your GitHub repo and manage multiple deployments in a clean unified workflow
Advanced Features: Access to features like external calls and block handlers
Seamless Integration: Easily integrate existing GraphQL APIs and applications

How to Migrate from Alchemy to Envio in 4 easy steps

This Migration consists of 4 major steps:

Create a HyperIndex Project
subgraph.yaml Migration to config.yaml
schema.graphql Migration
Event Handler Migration

Create a HyperIndex Project

Start by spinning up a basic HyperIndex project with this command:

pnpx envio init template --name alchemy-migration --directory alchemy-migration --template  greeter --api-token "YOUR_ENVIO_API_KEY"

Once the project is created, drop your API key into the .env file and you’re good to go.

subgraph.yaml Migration to config.yaml

In HyperIndex, all project configuration lives in config.yaml. This is where you define contract addresses, the networks you want to index, and the specific events you want to track from those contracts.

Below is an example showing how a Uniswap V4 subgraph.yaml maps to a HyperIndex config.yaml in a real migration.

The Graph - subgraph.yaml

specVersion: 0.0.4
description: Uniswap is a decentralized protocol for automated token exchange on Ethereum.
repository: https://github.com/Uniswap/v4-subgraph
schema:
  file: ./schema.graphql
features:
  - nonFatalErrors
  - grafting
  - kind: ethereum/contract
    name: PositionManager
    network: mainnet
    source:
      abi: PositionManager
      address: "0xbD216513d74C8cf14cf4747E6AaA6420FF64ee9e"
      startBlock: 21689089
    mapping:
      kind: ethereum/events
      apiVersion: 0.0.7
      language: wasm/assemblyscript
      file: ./src/mappings/index.ts
      entities:
        - Position
      abis:
        - name: PositionManager
          file: ./abis/PositionManager.json
      eventHandlers:
        - event: Subscription(indexed uint256,indexed address)
          handler: handleSubscription
        - event: Unsubscription(indexed uint256,indexed address)
          handler: handleUnsubscription
        - event: Transfer(indexed address,indexed address,indexed uint256)
          handler: handleTransfer

HyperIndex - config.yaml

# yaml-language-server: $schema=./node_modules/envio/evm.schema.json
name: uni-v4-indexer
chains:
  - id: 1
    start_block: 21689089
    contracts:
      - name: PositionManager
        address: "0xbD216513d74C8cf14cf4747E6AaA6420FF64ee9e"
        events:
        - event: Subscription(uint256 indexed tokenId, address indexed subscriber)
        - event: Unsubscription(uint256 indexed tokenId, address indexed subscriber)
        - event: Transfer(address indexed from, address indexed to, uint256 indexed id)

If you hit any issues, check the Configuration File docs or reach out to our team in Discord.

schema.graphql Migration

This step is simple. You keep the entire file as is, with one small change: remove all @entity directives from your entities. Everything else stays the same.

Event Handler Migration

This is the final step of the migration which consists of two parts:

Moving from AssemblyScript to TypeScript
Updating Subgraph syntax to HyperIndex syntax

AssemblyScript to TypeScript

HyperIndex uses TypeScript instead of AssemblyScript. Since AssemblyScript is a subset of TypeScript, you can simply copy most of your code over without worrying about major syntax changes.

Subgraph to HyperIndex

The HyperIndex workflow is very similar to Subgraphs, but there are a few important differences to keep in mind:

Replace ENTITY.save() with context.ENTITY.set(VALUES)
Handlers need to be async
Use await when loading entities

As you start using HyperIndex, you’ll pick up the differences quickly.

Here is a code snippet to give you a sense of what these changes look like in practice.

The Graph - eventHandler.ts

export function handleSubscription(event: SubscriptionEvent): void {
const subscription = new Subscribe(event.transaction.hash + event.logIndex);

subscription.tokenId = event.params.tokenId;
subscription.address = event.params.subscriber.toHexString();
subscription.logIndex = event.logIndex;
subscription.blockNumber = event.block.number;
subscription.position = event.params.tokenId;

subscription.save();
}

HyperIndex - eventHandler.ts

import { indexer } from "envio";

indexer.onEvent(
  { contract: "PoolManager", event: "Subscription" },
  async ({ event, context }) => {
    const entity = {
      id: event.transaction.hash + event.logIndex,
      tokenId: event.params.tokenId,
      address: event.params.subscriber,
      blockNumber: event.block.number,
      logIndex: event.logIndex,
      position: event.params.tokenId,
    };

    context.Subscription.set(entity);
  },
);

For a few extra tips on migrating from Alchemy to Envio, check out our other migration guide in our docs.

Share Your Learnings

If you come across anything useful during your migration, please feel free to contribute. Simply open a PR to this guide and help future developers.

Getting Help

Join our Discord if you need support. It is the fastest way to get direct help from the team and the community.

Building Visualizers & Dashboards on Monad using Envio

Envio — Thu, 17 Sep 2026 14:40:28 +0000

TL;DR

As part of Mission 4 from the Monad Developers community, builders created real-time dashboards and visualizers on Monad using Envio, demonstrating what is possible with a fast chain and a high-performance indexer.
Envio's HyperSync and HyperIndex power all submissions, handling real-time data streaming with no RPC rate limit concerns and minimal latency.
All Envio indexers use three core files (config.yaml, schema.graphql, EventHandlers.ts) and deploy to Envio's hosted service via a GitHub push.

As part of Mission 4 from the Monad Developers community, builders were challenged to create real-time dashboards and visualizers on Monad using Envio. The results were exceptional, showcasing not only creative visualizers and dashboards but also what is possible with Envio's indexing stack on a high-throughput chain.

Monad's rapid growth has created a strong need for scalable, real-time data infrastructure. Whether tracking protocol activity, analyzing transaction flows, or building live analytics dashboards, a high-performance indexer is critical. These submissions highlight how Envio simplifies data indexing on Monad, enabling rich, real-time applications with speed, accuracy, and ease.

Monad Super Visualizer

By @monadicoo

This immersive dashboard allows users to explore live activity across the entire Monad chain, with deep visibility into data from specific protocols, contracts, or addresses. Envio powers two core functionalities: streaming live, chain-wide activity to the homepage, and offering a filtered data feed for targeted protocol analysis.

Check it out here

Monad Genki Dama

By @sifu_lam

A Dragon Ball Z-inspired visual experience that depicts each Monad testnet block as energy contributing to a Genki Dama. Monanimals generate power balls representing transaction types, visually charging the Monad mainnet. Envio's HyperSync ensures real-time accuracy and high throughput with minimal latency.

Check it out here

LendHub Stats Page

By @bossonormal1

LendHub's dashboard presents real-time analytics for a peer-to-peer NFT lending protocol. It tracks metrics such as loans listed, funded, repaid, claimed, and withdrawn. Custom-built with Envio's config.yaml, schema.graphql, and event handlers, this tool uses a GraphQL endpoint to update dynamically based on key smart contract events.

Check it out here

Miris

By @velkan_gst

Miris is a fully featured chain visualizer offering insights into blocks, transactions, and overall network health. Envio handles the indexing of core protocols like Wormhole and Apr Labs, and the Explorer page uncovers activity from additional Monad projects. Built using Apollo Client and Next.js.

Monad Frens

By @WagmiArc

Monad Frens delivers real-time and historical chain insights in a visually engaging format, including a pizza-themed chain status display. Envio's HyperSync feeds accurate block and transaction data, while a custom API calculates cumulative transactions since Block 0. The dashboard filters transactions by timestamp, ensuring comprehensive tracking.

Check it out here

MonLake

By @YOUZYPOOR

An aquarium-themed visualization of the Monad testnet where Monanimals represent blocks and treasure chests symbolize various transaction types. Failed transactions appear as jellyfish. Real-time metrics like gas price and transaction distribution are updated using Envio, which indexes all relevant data without stressing RPC endpoints.

Check it out here

Animonad

By @Samruddhi_Krnr

Animonad tracks live transactions per second across Monad-based dApps like Magma, PancakeSwap, and Narwhal Finance. Each transaction is categorized by address and function signature. Envio's HyperSync facilitates rapid data retrieval to update the UI every second, powering dynamic graphs and protocol rankings.

Check it out here

NadMetrics

By @yomax75

Built with React, TypeScript, Node.js, and WebSockets, NadMetrics is a robust analytics platform offering real-time and historical data for Monad. The dashboard is ideal for developers and analysts monitoring chain volume, transaction flow, and usage trends. Envio serves as the foundation for its high-speed data ingestion.

Check it out here

Monalytics

By @gabriell_santi

An interactive dashboard for real-time visualization of activity on the Monad testnet. It leverages Envio for continuous onchain event streaming and HyperRPC for fast, low-latency data access. The platform delivers both a global view of the network, including metrics like TPS, gas usage, and block entropy, and protocol-specific panels for apps like MonTools, Castora, Ambient, and more.

Check it out here

Monanimals Blast Mayhem

By @Pradeeppilot2k5 and @vidit_0

A gamified dashboard transforming real-time blockchain stats into interactive graphics. Monanimals symbolize block numbers, and animated graphs display key metrics such as gas usage, TPS, and block peers. Envio's HyperRPC ensures seamless data delivery for a high-performance user experience.

Check it out here

Indexing Monad data using Envio

Envio offers a modular indexing solution for developers and analysts seeking to build scalable, real-time applications on Monad. Whether you are building visual dashboards or analytics platforms, Envio's indexing stack provides the essential building blocks to transform raw blockchain data into accessible, actionable insights.

HyperIndex

A full-featured blockchain indexing framework that transforms onchain events into structured, queryable databases with GraphQL APIs. It offers Monad developers a complete indexing solution with schema management and event handling, making data on Monad easily accessible and developer-friendly.

Learn more

HyperSync

A high-performance data retrieval layer that gives developers unprecedented access to data on Monad. It directly replaces traditional RPC endpoints, delivering up to 2000x faster data access. HyperSync enables rapid and cost-effective retrieval of both real-time and historical blockchain data and can be used directly for custom data pipelines and specialized applications.

Learn more

HyperRPC

A local RPC proxy that supercharges blockchain data access by mapping standard RPC requests to HyperSync's ultra-fast data engine. HyperRPC accepts typical RPC calls and translates them into HyperSync queries, dramatically reducing latency and eliminating the bottlenecks of traditional RPC endpoints.

Learn more

Envio makes it easy to define events, build handlers, and deploy powerful indexers that power dashboards, data tools, analytics platforms, and more at scale.

Frequently asked questions

How do I get started building a dashboard on Monad with Envio?

Run pnpx envio init to scaffold a new indexer from your contract address or ABI. Define your entities in schema.graphql, configure your network and events in config.yaml, and write your event handlers in TypeScript. Then run pnpm dev locally or deploy to Envio's hosted service.

Do I need to manage RPC endpoints or infrastructure to build a real-time dashboard on Monad?

No. When using Envio HyperIndex, HyperSync is the default data source and handles all data retrieval automatically, with no RPC URL configuration needed for supported chains. Envio's hosted service manages all infrastructure on your behalf.

What is the difference between using HyperSync and HyperRPC for building dashboards?

HyperSync is the underlying data layer used by HyperIndex for fast historical backfills and real-time event processing. HyperRPC is a drop-in RPC replacement that maps standard JSON-RPC calls to HyperSync queries, useful when your frontend or tooling is already wired to use RPC. For indexer-based dashboards, you typically use HyperIndex, which uses HyperSync internally.

Can these dashboards handle Monad's 10,000 TPS throughput without falling behind?

Yes. Envio's HyperSync and HyperIndex are designed for high-throughput chains. The submissions in Mission 4 demonstrate real-time tracking of chain-wide activity on Monad without RPC rate limit issues, using Envio as the indexing layer.

Can I deploy my Monad dashboard indexer for free with Envio?

Yes. Envio's hosted service includes a free development tier. You connect your GitHub repository, and the Envio Deployments bot auto-deploys on every push. For production workloads requiring SLA guarantees, production tiers are available.

Build With Envio

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

Subscribe to our newsletter 💌

How to Index MegaEth Data Using Envio

Envio — Thu, 17 Sep 2026 14:40:23 +0000

TL;DR

MegaETH is a high-performance EVM chain with sub-millisecond block times and 100,000+ TPS, purpose-built for real-time applications that demand scale and speed.
Envio supports MegaETH with HyperIndex (full GraphQL indexing), HyperSync (up to 2000x faster than RPC for historical data), and HyperRPC (standard RPC proxy backed by HyperSync).
Oracle Wars, built in under two hours using Envio HyperIndex on MegaETH, demonstrates how quickly developers can build real-time monitoring tools on high-throughput chains.

Envio supports developers and data analysts building on MegaETH with a performant real-time indexing stack designed for high-throughput environments. Get fast, reliable access to both real-time and historical data without the usual bottlenecks.

MegaETH combines sub-millisecond block times with support for over 100,000 transactions per second, built for next-generation applications that demand scale, speed, and reliability. In this blog, we walk through how to index, sync, and query millions of events on MegaETH using Envio.

What is MegaETH?

MegaETH is a high-performance EVM chain purpose-built for real-time applications. It combines sub-millisecond block times with over 100,000 transactions per second, giving developers a foundation to build real-time, responsive, production-grade apps.

Unlike other chains that trade off EVM compatibility for speed, MegaETH keeps your Solidity code, dev tools, and mental models intact. You get Ethereum's programming experience with significantly reduced latency. Whether you are powering data analytics, an onchain game, or a reactive dashboard, MegaETH ensures your stack stays responsive.

Key features

Mini Blocks + EVM Blocks: Fast mini-blocks (~10 ms) combined with full EVM block finality offer real-time latency and standard blockchain guarantees.
High-Throughput Sequencing + Parallel Execution: MegaETH achieves high TPS through a centralized sequencer architecture and parallel execution across node types.
Realtime API Access: The Realtime API surfaces mini-block data via standard JSON-RPC methods, allowing near-instant visibility into state and transaction outcomes.
EigenDA-Powered Data Availability: By integrating EigenDA, MegaETH enables scalable, secure data access without burdening Ethereum's onchain storage.
Full EVM Support: MegaETH supports Solidity, EIP-1559, EIP-7702, large contract sizes, and existing Ethereum tooling out of the box.

These core features make MegaETH a robust environment for building real-time DeFi, high-frequency trading bots, streaming onchain gaming, and on-demand NFT mints.

How to index data on MegaETH

HyperIndex

A full-featured blockchain indexing framework that transforms onchain events into structured, queryable databases with GraphQL APIs. It offers MegaETH developers a complete indexing solution with schema management and event handling, making data on MegaETH easily accessible and developer-friendly.

Learn more

HyperSync

A high-performance data retrieval layer that gives developers unprecedented access to data on MegaETH. It directly replaces traditional RPC endpoints for raw block data, delivering up to 2000x faster data access. HyperSync enables rapid and cost-effective retrieval of both real-time and historical blockchain data and can be used directly for custom data pipelines and specialized applications.

Learn more

HyperRPC

A local RPC proxy that supercharges blockchain data access by mapping standard RPC requests to HyperSync's ultra-fast data engine. HyperRPC accepts typical RPC calls and translates them into HyperSync queries, dramatically reducing query time and eliminating the bottlenecks of traditional RPC endpoints.

Learn more

MegaETH moves fast, and your indexing stack should too. Envio gives you the infrastructure to match that speed, so you can build applications that are responsive, reliable, and ready for scale.

Additional features for MegaETH indexers built using Envio

Envio offers a range of advanced capabilities that make it easy to build rich, flexible data pipelines on MegaETH:

Flexible language support: Configure your event handling in JavaScript, TypeScript, or ReScript.
No-code quickstart: Autogenerate the key boilerplate for an entire indexer project based on single or multiple smart contracts. Deploy within minutes.
Multichain support: Aggregate data across multiple networks into a single database and query everything through a unified GraphQL API.
Join onchain and off-chain data: Connect indexed blockchain data with off-chain data to create a flexible API that goes beyond simple onchain event logs, such as integrating external NFT metadata.
Factory contracts: Automatically register and process events emitted by all child contracts created by a specified factory or dynamic contract.
Hosted service: The simplest way to deploy production-ready indexers on MegaETH. A managed service platform for building, hosting, and querying Envio's Indexers with guaranteed uptime and performance service level agreements.

Existing use cases on MegaETH utilizing Envio

Oracle Wars

Oracle Wars is an experimental dashboard built with Envio's HyperIndex that visualizes real-time oracle behavior on MegaETH. It showcases how push-based oracles like RedStone Bolt behave under live market conditions by tracking heartbeat intervals, deviation thresholds, and latency patterns. The project helps developers understand how oracles operate in volatile environments and the potential risks of delayed or unexpected updates. Built in under two hours, Oracle Wars demonstrates how Envio enables rapid development of real-time monitoring tools on high-throughput chains like MegaETH.

Take a deeper dive in the full Oracle Wars blog.

This is just one of many examples of what Envio is powering in the MegaETH ecosystem. For more, explore the Envio Explorer.

Relevant resources

Frequently asked questions

Does Envio support MegaETH mainnet and testnet?

Yes. Envio HyperSync and HyperIndex support both MegaETH mainnet and testnet. You configure the network in your config.yaml using the appropriate chain ID, and the indexer handles data retrieval automatically.

How fast is HyperSync on MegaETH compared to standard RPC?

HyperSync can deliver up to 2000x faster historical data retrieval than standard RPC on MegaETH by bypassing the JSON-RPC layer entirely. This means syncing large datasets that would take hours via RPC completes in minutes.

Can I index MegaETH alongside other chains in a single Envio indexer?

Yes. Add MegaETH and any other EVM chains to the networks section of your config.yaml. The indexer processes all chains and exposes a single GraphQL endpoint for all data, making cross-chain queries straightforward from one deployment.

How does Envio handle MegaETH's mini-block architecture?

Envio's HyperSync is designed for high-throughput chains and handles MegaETH's high block frequency efficiently. For indexing purposes, HyperIndex processes full EVM blocks. If you need mini-block granularity, use the MegaETH Realtime API alongside HyperSync for full-block historical data.

Is Envio better than The Graph for MegaETH indexing?

The Graph does not natively support MegaETH. Envio has dedicated HyperSync support for MegaETH and provides the full HyperIndex framework for building GraphQL APIs on MegaETH data. Envio's single-config multichain approach also makes it easier to combine MegaETH data with other EVM chains in one indexer.

Build With Envio

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

Subscribe to our newsletter 💌