DEV Community: Envio

Envio Developer Update September 2026

Envio — Tue, 29 Sep 2026 00:00:00 +0000

Solana support in HyperIndex is now stable. The API is final and follows semver. Config and handlers look much like they do on EVM, with the same GraphQL server on top.

We put out five HyperIndex releases, v3.10.0 to v3.13.0. Indexers can now split across worker processes, the RPC source is written in Rust, and a rollback on one chain can stay on that chain. On top of that we published tutorials for Arc, Robinhood Chain, HyperEVM and Solana stablecoins, added docs for Envio Cloud troubleshooting and trace decoding, moved HyperPipe to community support, and put up a page comparing Envio with other indexers.

Let's dive in!

HyperIndex v3.10.0 -> v3.13.0

Most of this month's work went into speed and keeping chains apart in multichain indexers.

Highlights

4x faster in many cases with automatic multiprocess indexing
RPC source rewritten in Rust, 2 to 17x faster on our open benchmark
Solana support is stable and follows semver
Each chain can run in its own process
A rollback on one chain no longer rolls back the others

HyperIndex v3.13.0: Multiprocess Indexing and a Rust RPC Source

Automatic Multiprocess Indexing

When every entity is isolated per chain and ENVIO_PG_MAX_CONNECTIONS is large enough, the indexer now splits itself into up to 4 worker processes on its own.

It uses more resources, and in return it is 4x faster in many cases and more reliable. On Envio Cloud it is available on demand for Dedicated plans.

RPC Source Rewritten in Rust

If you index over your own RPC, upgrade. The RPC source is now written in Rust, with reworked logic and concurrency, and it handles bad provider responses without crashing. It is 2 to 17x faster on the Open Indexer Benchmark cases.

It also adds the accessList and authorizationList transaction fields, so the RPC source now selects the same transaction fields as the HyperSync source.

HyperIndex v3.12.0: One Process Per Chain

Run Chains in Separate Processes

envio start --chain <CHAIN_ID> lets several processes index different chains of the same indexer in parallel.

envio local db-migrate upENVIO_INDEXER_PORT=8080 envio start --chain 1ENVIO_INDEXER_PORT=8081 envio start --chain 137 --chain 5042

Create the database once with envio local db-migrate up, give each chain to exactly one process, and give each process its own port. Every process runs independently of the others. It needs a schema where every entity is per chain, with no @crossChain entities, and it can't be combined with --restart.

Real Head Lag With Progress Block Time

The new envio_progress_block_time_seconds metric, also exposed as _meta.progressBlockTime, gives the timestamp of the block each chain has processed up to. now() - progress_block_time is your real lag, even when a data source reports itself at the head while sitting behind the chain.

Chains that reach their endBlock freeze the value, so leave them out of alerts.

Every Account a Solana Transaction Touches

accountKeys now includes addresses resolved through Address Lookup Tables, so handlers see every account a versioned transaction touches. The envio init Solana templates are replaced by usdc-transfers, which indexes SPL Token transfers on mainnet.

v3.12.1 rounded the release out with 4x faster getWhere in handlers and more reliable progress block time reporting at the head.

HyperIndex v3.11.0: Solana Goes Stable

Solana Support Is Now Stable

The HyperIndex API for Solana is final and follows semver from here, so you can build on it without expecting breaking changes between minor versions. More on where Solana is at below.

Start From the Latest Block

The start block now accepts "latest". The indexer checks the chain height on startup and starts from there, so there's no block number to look up first. You can see it in the Solana config below.

HyperIndex v3.10.0: Per-Chain Rollbacks and Rust ClickHouse Storage

Rollbacks Stay on Their Own Chain

With disable_default_cross_chain: true and no entities marked @crossChain, a rollback now applies only to the chain that triggered it. Multichain indexers get better isolation, better performance and lower latency.

ClickHouse Storage in Rust

The ClickHouse storage backend is now written in Rust. It's faster and more reliable.

Choose How Bytes Are Stored

Bytes fields used to be a plain alias for the GraphQL String type. You can now switch them to Uint8Array in your handlers, which also makes the Postgres column bytea. Hex strings stay the default. Solana indexers always use uint8array.

bytes_type: uint8array # default is hex

More Reliable Head Tracking

HyperIndex streams new block heights from the HyperSync SSE endpoint by default, with RPC WebSocket as an option and polling as the fallback. The stream now stays alive more reliably and falls back to polling without the 10 to 20 second gap, which lowers latency and keeps new block tracking steady. Two new Prometheus metrics come with it:

envio_source_height_stream_connects_totalenvio_source_height_stream_disconnects_total{reason}

Solana Instruction Filtering

Solana instruction handlers now take where filters on named accounts, inner or outer instructions, and a minimum slot. Discriminators can be any byte length, and more than one instruction can share a discriminator.

See full release notes

Star us on GitHub

Solana Is Stable, Here's Where We're At

Configuration, handlers and payload types now follow semver like the rest of HyperIndex, so what you build on Solana today keeps working as HyperIndex moves forward.

Start with pnpx envio init and pick a Solana template. HyperSync is the data source by default, and the config looks like this:

# yaml-language-server: $schema=./node_modules/envio/svm.schema.jsonname: usdc-transfersdescription: USDC Token Transfersecosystem: svmchains: - id: solana start_slot: "latest"programs: - name: SplToken program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA idl: ./idls/spl-token.codama.json

And a handler for it:

import { indexer } from "envio";const USDC_MINT = "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v";indexer.onInstruction( { program: "SplToken", instruction: "transferChecked", fields: { instruction: ["accounts", "args", "path"], transaction: ["signature"], accountActivity: ["token.mint"], block: ["time"], }, where: { accounts: { mint: USDC_MINT } }, }, async ({ instruction, context }) => { context.Transfer.set({ id: `${instruction.transaction.signature}:${instruction.path.join(".")}`, amount: instruction.args.amount, source: instruction.accounts.source.address, destination: instruction.accounts.destination.address, signer: instruction.accounts.authority.address, txSignature: instruction.transaction.signature, checked: true, slot: instruction.block.slot, timestamp: instruction.block.time, }); });

You get automatic decoding and filtering, Anchor and Codama IDLs, writes to Postgres and ClickHouse, a GraphQL server on top of your Solana data, and hosting on Envio Cloud.

Where We're At With Solana

HyperIndex on Solana is stable. The API has been final since v3.11.0 and follows semver.
Solana HyperSync is live on mainnet at https://solana.hypersync.xyz, serving slots, transactions, instruction calls, logs and account activity from one endpoint.
History starts around slot 391,000,000 , not at genesis. We keep extending it backwards as we backfill.
It runs end to end. Local dev, Postgres or ClickHouse, the GraphQL API and hosting on Envio Cloud all work the same as on EVM.
One ecosystem per indexer. An indexer covers Solana or EVM chains, not both at once.

This month also added where filters on instructions, account keys resolved through Address Lookup Tables, and a USDC Transfers starter template in envio init. For a worked example, our Solana stablecoin tutorial indexes a full day of USDC, USDT, PYUSD and USDG transfers.

On the Solana USDC transfers scenario on our compare page, HyperIndex was the fastest indexer in the latest run.

If you're building on Solana, we highly recommend testing it against the programs you want to index. Reach out to the team on Discord with your use case and we'll test it with you. Any feedback you have shapes what we prioritise next.

Read the docs: Indexing on Solana and Solana HyperSync

Why HyperSync Checks Blocks Against Their Roots

A node can drop logs and still hand you a response that looks completely fine. There's no error, and nothing in the JSON tells you anything is missing.

Block headers commit to every transaction and receipt through Merkle roots, but you need the whole block to check them. Because HyperSync ingests whole blocks, it recomputes both roots before serving anything and refetches from another source if they don't match. That way missing logs tend to get caught early, rather than turning up later in your database.

More here: https://docs.envio.dev/blog/nodes-silently-miss-events

What HyperEVM Sends to HyperCore

We wanted to know how much of Hyperliquid an EVM indexer can actually see, so we built one that tracks everything HyperEVM sends to HyperCore, every action, HYPE transfer and spot token transfer, and ran it from genesis. The biggest CoreWriter user isn't a trading bot or a DEX. It's Circle's USDC deposit wallet, behind 57.5% of all the actions we indexed.

One thing worth knowing going in is that the data only flows one way. Anything HyperEVM sends to HyperCore leaves a log, but what comes back from HyperCore doesn't. The tutorial walks through what you can and can't see, how to check what HyperCore actually did with each request, and how to index your own HyperEVM contract with three small files.

Read the full tutorial: https://docs.envio.dev/blog/index-hyperevm-data

Envio Side by Side With Other Indexers

The compare page puts Envio side by side with the other popular indexers, and every claim links to its source.

Indexing isn't one workload, so one number can't rank it. The benchmark section runs several scenarios from the Open Indexer Benchmark, with each tool on the EVM scenarios running in GitHub CI and started the way its own docs recommend for production. The tables refresh automatically.

The head-to-heads cover things like speed, chain coverage, pricing and self-hosting, and each one says plainly when the other tool is the better choice. There are also migration paths, from moving a subgraph to migrating with AI, plus an FAQ.

Check it out: https://envio.dev/compare

Every Tokenised Stock on Robinhood Chain, From One Contract

We wanted to know which tokenised stocks exist on Robinhood Chain and which ones people actually trade. It turns out every stock is deployed by the same factory contract, so we built an indexer that reads its deploy events, picks up each token (including any Robinhood adds later) and indexes their transfers. Twenty of those tokens carry 90.9% of all transfers.

Want to build on Robinhood Chain yourself? HyperSync, HyperRPC and HyperIndex all work there out of the box, and the chain page has the connection details.

Read the full tutorial: https://docs.envio.dev/blog/index-robinhood-chain-data

Most Solana Stablecoin Transfers Aren't Top-Level

Tracking stablecoin transfers on Solana sounds like one filter, but we had a feeling a lot was being missed. So we built an indexer for USDC, USDT, PYUSD and USDG transfers and ran it over a full day. Only 23.3% of those transfers were top-level instructions, and the rest happened inside other programs like swaps and lending deposits.

That matters because a transfer on Solana can come through any of three instructions on two different token programs. If your indexer only handles some of them, nothing breaks, your numbers are just quietly incomplete. The tutorial has the mint addresses and an indexer that catches all of them.

Learn more here: https://docs.envio.dev/blog/index-solana-stablecoin-transfers

Why USDC on Arc Gets Logged Twice

We noticed something odd about USDC on Arc. It's both the gas token and an ERC-20, which means a transfer can be logged twice. A system address logs every transfer, native sends included, and the USDC contract logs ERC-20 calls again on top.

So we indexed a 100,000 block sample to see how much it matters. Indexing both sources would have double counted 48.3% of transfers, and indexing only the contract would have missed 51.7%. The tutorial shows which one to index, and the three-file indexer in it matched HyperSync's count exactly.

We provide first-class support for Arc on Envio, so you can backfill its history and follow new blocks with HyperSync, query it through HyperRPC, or spin up a HyperIndex indexer with a GraphQL API on top. Arc Testnet is supported as well, and the chain page has everything you need to get connected.

Read the full tutorial: https://docs.envio.dev/blog/index-arc-usdc-transfers

Which Apps Are Actually Live on Robinhood Chain

Robinhood lists plenty of ecosystem partners, but a listing doesn't tell you what's actually running. So we checked each app against its own docs and its contracts on Robinhood Chain, and wrote up the ones that are live, with the contracts to index and a week of onchain activity for most of them. Uniswap is the busiest by a long way, with 2,552,298 transactions from 321,551 wallets in a single week.

Read it here: https://docs.envio.dev/blog/robinhood-chain-ecosystem

Monad Metropolis Hackathon

Monad's Metropolis hackathon runs from September 1st to October 13th with $250,000+ in prizes, and there's a dedicated track for the best use of Envio.

We've put up $1,000 for the best use of Envio, and winning teams get $5,000 of free Envio Cloud hosting. If your build has reached the onchain data part, reach out to our team with your contract address and we'll help you get it indexed.

Check out the video above to learn how an indexer fits into your build, and why your frontend shouldn't have to query the blockchain for everything.

Find the Envio track here: https://hackathon.monad.xyz/tracks/best-use-of-envio

New in the Docs

Fixing Common Envio Cloud Deploy Issues

A new page answers the questions we get most about deploying on Envio Cloud. Why an indexer builds locally but fails on Envio Cloud, why a push didn't start a deployment, why an organisation or repository is missing, how to add or remove people, and why an indexer is paused.

Read it here: https://docs.envio.dev/docs/HyperIndex/envio-cloud-troubleshooting

Seeing What a Transaction Actually Did

Traces show what a transaction did once it started running, including internal ETH transfers, calls that emit no event and calls that reverted. None of that is in the logs. The new HyperSync tutorial queries traces and decodes the call data with viem, and ends with a prompt you can hand to your coding agent.

Read the tutorial: https://docs.envio.dev/docs/HyperSync/tutorial-decoding-traces

Uniswap v4 Walkthrough

The Uniswap v4 page now has a walkthrough for building a minimal swap indexer yourself, alongside the production indexer that powers v4.xyz.

More here: https://docs.envio.dev/docs/HyperIndex/example-uniswap-v4-multi-chain-indexer

HyperPipe Is Now Community-Supported

HyperPipe has been open source for a while, and from here it's a community-supported project rather than something we develop in-house. The core is solid and works end to end, so it's in good shape to build on.

If you're running WASM data pipelines on HyperSync, or want to add a processor, sink or feature, PRs are welcome. We'll keep reviewing and merging contributions, we just won't be driving the roadmap ourselves.

Check it out on GitHub: https://github.com/enviodev/hyperpipe

Current & Upcoming Events & Hackathons

Monad Metropolis: September 1st -> October 13th
Devcon 8 - Mumbai: November 3rd -> 6th
Solana Breakpoint - London: November 15th -> 17th

Featured Developer: deif

This month's featured developer is deif, lead developer at Paintswap and a jack-of-all-trades software engineer with around 20 years of experience. Crypto caught their interest with the promise of trustless applications, composability between them and user-centric values.

When Paintswap released Estfor Kingdom, an idle RPG browser game, deif got hooked, started building third-party tools for its players and was eventually hired by Paintswap. Now lead developer, they work across the whole stack to keep improving the game and push what's possible for onchain games.

What deif had to say about Envio:

"Before Envio Estfor ran on legacy The Graph and considering we had tens of millions of tracked events it would take over a day to release new features or fix bugs due to the extremely lengthy backfill times. I decided to give Envio a go to see if the speed improvements that they advertised could be remotely achieved internally in Estfor. Our expectations were surpassed not only in terms of speed, but in migration ease, developer support by the Envio team, and developer tooling to help diagnose bottlenecks and better optimise our data handling methods. After the latest optimisation pass our custom deployment using Envio's HyperSync processes >10k events per second, allowing us to backfill 2 years of historical data in under an hour (over 30x speed improvement)! I would not hesitate to recommend Envio to anyone that needs to track onchain event data."

- deif, Lead Developer at Paintswap on Estfor Kingdom

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

Playlist of the Month

Open Spotify

Build With Envio

Envio is a multichain blockchain indexer for EVM chains and Solana, for querying real-time and historical data. If you're building something that needs reliable onchain data, check out our docs, join the community, and tell us what you're working on.

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

Subscribe to our newsletter

Robinhood Chain Ecosystem: Live Apps and How to Index Them

Envio — Fri, 25 Sep 2026 00:00:00 +0000

TL;DR

We checked the apps Robinhood lists as ecosystem partners, plus others we found onchain and in other ecosystem lists. Each had to pass two tests. Its own docs say it's on Robinhood Chain mainnet (chain ID 4663), and its contracts are deployed there.
They cover trading, launchpads, lending, stablecoins and bridges. Each one comes with the contracts to index, and most with a week of onchain activity.
After Uniswap, the most wallets went to USDG (108,678), Relay (101,360) and Pons (55,370).
The biggest single vault is Steakhouse's steakUSDG on Morpho. It reported about 499 million USDG, roughly 72% of all USDG on Robinhood Chain when we read it onchain.
Every activity count here came from one HyperSync script you can rerun. To go further, clone our indexer for four of these apps, or hand the job to your coding agent with our prompt.

Uniswap took 2,552,298 transactions from 321,551 wallets on Robinhood Chain in one week. It's the busiest app we confirmed live, from each app's own docs and from onchain data.

This blog is for builders. It shows which apps are deployed, which contracts they use, how busy those contracts are and how to utilise Envio to get their data.

We started from Robinhood's ecosystem page, then added apps we found onchain and in other ecosystem lists. A listing doesn't tell you what's running, so we checked each app. This blog only covers apps with their own contracts on Robinhood Chain. For connection details and a full tokenized stock indexer, see How to Index Every Tokenized Asset on Robinhood Chain.

How We Checked Each App

An app had to pass two checks.

Its own source says it's live on mainnet. That means the project's docs, API, GitHub or blog, or Robinhood's chain docs. Third-party roundups didn't count.
Its contracts are deployed. We confirmed contract code at each published address, then counted a week of activity with HyperSync.

Txs counts transactions sent straight to the listed contracts, with the unique wallets behind them in brackets. Events counts logs those contracts emitted. Apps that are usually reached through a router or an aggregator can show few direct transactions and plenty of events, so read the two together. Neither is trading volume, and wallet counts include bots.

We left out any project we couldn't confirm from its own source. Being listed here isn't a recommendation from us, just a record of what's deployed.

What Stands Out

Unique wallets sending transactions straight to each app's contracts over one week. Wallet counts include bots.

Uniswap is about three times bigger than anything else. 321,551 wallets called its contracts in the week. The next biggest, USDG, had 108,678.
One vault is worth about 72% of all USDG. There were 691 million USDG on Robinhood Chain when we read it, and steakUSDG reported 499 million in assets.
Most lending sits in one market. Morpho's USDG market backed by USDe collateral had 331.6 million USDG supplied and 299.6 million borrowed, about 90% used, according to the Morpho API.
Trading venues hold a lot of USDG too. Lighter's contract held 91 million and Uniswap's v4 pool manager held 69 million.

Trading and DEXs

App	What it does	Contracts	Txs (wallets)	Events
Uniswap	Swaps across v2, v3 and v4 pools, plus UniswapX	v4 pool manager, Universal Router	2,552,298 (321,551)	21,221,501
0x	Swap API used inside other apps and wallets	allowance holder	224,772 (34,944)	0
1inch	Swap aggregator	Router	49,060 (12,980)	2,899
Lighter	Perpetuals and spot, on its own Lighter instance for Robinhood Chain	Lighter contract	34,171 (3,969)	64,241
Rialto	Spot exchange quoted by market makers (PropAMM)	active router	1,664 (433)	63,632
Meridian	Prediction markets and perpetuals	prediction escrow, perps	1,492 (15)	5,339
Ekubo	AMM with TWAMM orders and MEV capture	Core	0	73,347
PancakeSwap	Swaps on PancakeSwap Infinity and v3 pools	CL pool manager, Universal Router	38 (19)	64,286

Ekubo is reached through other contracts, which is why it shows events but no direct transactions. 0x's allowance holder emits no events of its own, and its swaps show up as token transfers instead.

Native is live too, supplying RFQ liquidity for aggregators through its RFQPool. Arcus also lists Robinhood Chain as a supported chain.

Launchpads and NFTs

App	What it does	Contracts	Txs (wallets)	Events
Pons	Token launchpad with a bonding curve	V2 factory, fee escrow	118,057 (55,370)	2,237,675
OpenSea	NFT marketplace	Seaport	121,560 (22,825)	394,556
Doppler	Token launch protocol that other launchpads build on	Airlock	4,468 (2,562)	19,073
Pools	Token launchpad built by Uniswap Labs	Liquidity Launcher, instant launch strategy	825 (573)	5,957
Bankr	Token launches through Doppler, with BNKR onchain	BNKR	170 (81)	5,000

Pons was the busiest launchpad we measured. Virtuals runs its AI agent launchpad on Robinhood Chain too, through its bonding curve. hood.fun, a fair-launch memecoin protocol, is also deployed on Robinhood Chain.

Lending, Yield and Stablecoins

App	What it does	Contracts	Txs (wallets)	Events
USDG by Paxos	Dollar stablecoin issued by Paxos	USDG token	442,570 (108,678)	30,187,268
Morpho	Lending markets and vaults	Morpho core	1,953 (372)	147,033
Steakhouse Financial	Curates steakUSDG, a USDG vault on Morpho	steakUSDG	518 (62)	197,919
Merkl	Reward campaigns for other protocols	Distributor	1,649 (432)	7,946

steakUSDG held 499,361,949 USDG when we called totalAssets(), the largest of the vaults we checked.

Also live on Robinhood Chain are Spark with its USDG savings vault (spUSDG), Maple with syrupUSDG and syrupUSDC, ether.fi with weETH, Mellow with its rUSDG vault and Midas with mGLO.

Bridges, Messaging and Oracles

App	What it does	Contracts	Txs (wallets)	Events
Relay	Fast bridging and swaps across chains	Depository	231,257 (101,360)	1,362,053
LI.FI	Bridge and swap aggregator, also behind Jumper	Diamond	59,895 (17,227)	455,393
Across	Intent-based bridge	SpokePool	57,948 (6,915)	134,699
LayerZero	Cross-chain messaging and OFT tokens	EndpointV2	764 (47)	17,725

Chainlink runs price feeds, CCIP and Data Streams on Robinhood Chain, with a CCIP Router and a Data Streams verifier. Its ETH/USD feed at 0x78F3…d3A9 was updating normally when we read it. Hyperlane (Mailbox), Pyth (Pyth Pro) and Polymer also have contracts deployed on Robinhood Chain.

For moving funds with Robinhood's own canonical bridge, see Robinhood's bridging docs.

What You Can Build With This Data

Each of these is one contract and a couple of events, which makes for a small indexer.

Swap volume by pool. Uniswap's v4 pool manager emits a Swap event for every trade in every v4 pool, with the pool ID and both token amounts. Index it and you have volume by pool, by hour or by wallet.
Vault flows. steakUSDG emits Deposit and Withdraw with the assets and shares involved, so you can chart money moving in and out of the largest vault on Robinhood Chain.
Token launches. The Pons factory emits TokenLaunched for every new token and PoolGraduated when a token graduates from its bonding curve into a pool. That's a live feed of launches and which ones make it.
Bridge traffic. Across's SpokePool emits FundsDeposited when funds leave Robinhood Chain and FilledRelay when they arrive. Together they show what's moving where.

All four are in one tested indexer you can clone from GitHub. The agent prompt below builds your own version using Envio.

Measuring Any App Yourself

New to Envio?

Grab a free Envio API token first. Quickstart with AI covers the rest of the setup.

One script produced every activity count above. Give it an app's contracts and a block range, and it counts the direct transactions, the unique wallets behind them and the events those contracts emitted. It reads your token from ENVIO_API_TOKEN.

Show the script

import os, json, urllib.request, collectionsTOKEN = os.environ["ENVIO_API_TOKEN"]URL = "https://robinhood.hypersync.xyz/query"def query(body): req = urllib.request.Request( URL, data=json.dumps(body).encode(), headers={"Content-Type": "application/json", "Authorization": f"Bearer {TOKEN}"}, ) with urllib.request.urlopen(req, timeout=300) as r: return json.loads(r.read())# Morpho on Robinhood Chain, from docs.morpho.orgCONTRACTS = ["0x9D53d5E3bd5E8d4Cbfa6DB1ca238AEA02E651010"]START, END = 65_779_486, 71_782_334 # one week of blockswanted = {a.lower() for a in CONTRACTS}txs, events, senders = 0, 0, set()block = STARTwhile block < END: d = query({ "from_block": block, "to_block": END, "transactions": [{"to": CONTRACTS}], # calls made straight to it "logs": [{"address": CONTRACTS}], # events it emitted "field_selection": {"transaction": ["from", "to"], "log": ["address"]}, "join_mode": "JoinNothing", # don't pull extra rows }) for batch in d.get("data", []): for tx in batch.get("transactions", []): if (tx.get("to") or "").lower() in wanted: txs += 1 senders.add(tx["from"]) events += len(batch.get("logs", [])) nxt = d.get("next_block") if not nxt or nxt <= block: break block = nxtprint(f"{txs:,} transactions from {len(senders):,} senders, {events:,} events")

For Morpho over our week it printed this, in about 30 seconds.

1,953 transactions from 372 senders, 147,033 events

Swap in any contracts from the tables above. join_mode matters for busy contracts. Without it, HyperSync also returns the transaction behind every event, which for USDG means pulling millions of extra rows.

Replicate This With Your Own Agent

To get an app's events into a database you can query, build a HyperIndex indexer for it. The prompt below hands that job to a coding agent.

Give the agent our current docs first, so it works from the latest syntax instead of whatever it remembers.

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

Agents with shell access can use envio tools search-docs instead. Both are covered on the MCP server page.

Show the full prompt

Build me an Envio HyperIndex indexer for one app on Robinhood Chain.The app is: <APP NAME>Its contract on Robinhood Chain is: <CONTRACT ADDRESS>Before writing any code, read the current Envio docs rather than working frommemory. If you have the envio-docs MCP server, use docs_search and docs_fetch.Otherwise run `envio tools search-docs <query>` and `envio tools fetch-docs <url>`.Read the configuration file, event handlers and testing pages first.Robinhood Chain is chain ID 4663 and HyperSync supports it, so the config needsno rpc block.1. Check the address against the app's own docs before using it. Don't trust an address you haven't confirmed from the project itself.2. Scaffold from the verified ABI on the block explorer: envio init contract-import explorer -b robinhood -c <CONTRACT ADDRESS> \ --single-contract --all-events -n <project-name> -l typescript Non-interactive runs need ENVIO_API_TOKEN set.3. If the import fails with "All events have unsupported parameter types", the ABI uses types the generator can't map (Morpho's core contract does this). Write config.yaml and schema.graphql by hand for the events you need instead.4. If the contract is a proxy, check that the imported ABI has the events you expect. If it doesn't, take the implementation's ABI from the explorer.5. The project needs Node.js 22 or newer. On Node 20 the tests fail with "Promises.glob is not a function".6. Run `pnpm test` and make it pass, then `pnpm dev` and let it sync.Report back:- the events you indexed and why- the start block you used and how you picked it- how many of each entity the indexer wrote, with one example row- anything that didn't match these instructionsGive the real numbers you got. Don't assume anything in the blog still holds.

Frequently Asked Questions

What Apps Are Live on Robinhood Chain?

These are the apps we confirmed live on Robinhood Chain mainnet (chain ID 4663), each one checked against its own docs and against its contracts onchain. They include DEXs and aggregators (Uniswap, 0x, 1inch, PancakeSwap, Ekubo, Native, Rialto), perpetuals and prediction markets (Lighter, Meridian), launchpads (Pons, Pools, Doppler, Virtuals, Bankr, hood.fun), OpenSea, lending and yield (Morpho, Steakhouse, Spark, Maple, Merkl, Mellow, ether.fi, Midas), the USDG stablecoin from Paxos, and bridges, messaging and oracles (Relay, LI.FI, Across, LayerZero, Chainlink, Hyperlane, Pyth, Polymer). Robinhood's own ecosystem page also lists infrastructure and data providers that don't run their own contracts.

What Is the Most Used App on Robinhood Chain?

Uniswap, by a wide margin. In the week we measured, its v4 PoolManager and UniversalRouter received 2,552,298 transactions from 321,551 unique wallets and emitted 21,221,501 events. Next by unique wallets were the USDG stablecoin (108,678), the Relay bridge (101,360) and the Pons launchpad (55,370). These count transactions and wallets rather than trading volume, and wallet counts include bots.

Where Can I Lend or Earn Yield on Robinhood Chain?

Morpho is the main lending protocol we found live on Robinhood Chain, and most of the yield products we found sit on top of USDG. The largest is Steakhouse Financial's steakUSDG vault on Morpho, which held 499,361,949 USDG when we read it onchain. Spark (spUSDG), Maple (syrupUSDG and syrupUSDC), Mellow (rUSDG), ether.fi (weETH) and Midas (mGLO) also have contracts deployed, and Merkl runs reward campaigns for several of them. This is a list of what's deployed, not investment advice.

How Do I Bridge to Robinhood Chain?

The trustless route is the canonical Arbitrum bridge, which Robinhood documents on its bridging page. Deposits take around 10 minutes and withdrawals go through the 7-day challenge period. For faster transfers, Relay, LI.FI (and Jumper, which runs on it), Across, LayerZero, Chainlink CCIP and Hyperlane are all live on Robinhood Chain. Relay was the busiest in our week, with 231,257 transactions from 101,360 wallets to its depository contract.

How Can I Check That a Project Is Really Deployed on Robinhood Chain?

Get the contract address from the project's own docs, not from a roundup article, then confirm there's code at that address with eth_getCode on any Robinhood Chain RPC. Code alone doesn't prove the contract is used, so also count its transactions and events over a recent window. The script in Measuring Any App Yourself does that with HyperSync in one pass.

How Do I Track a Robinhood Chain App's Activity in Real Time?

Point a HyperIndex indexer at the app's contracts. It backfills the history through HyperSync, then enters realtime mode and keeps writing new events as Robinhood Chain produces blocks, roughly every 0.1 seconds. If you only need what happens from now on, set start_block: latest in config.yaml and the indexer starts from the chain's current head instead of the full history, as the configuration docs describe. For lower head latency you can also add your own WebSocket RPC for realtime use, covered under WebSocket height streaming.

Can I Index Several Robinhood Chain Apps in One Indexer?

Yes. List each app's contract under contracts in one config.yaml, give each its own events and handlers, and one indexer serves all of them from the same GraphQL API. We tested it with Doppler's Airlock and the Pons launch factory in a single indexer. Over about 700 blocks of real Robinhood Chain data, it picked up one Doppler Create event and three Pons TokenLaunched events. That's the setup for a dashboard that compares launchpads, or DEXs, side by side.

How Do I Index an App's Data on Robinhood Chain?

Use HyperIndex. HyperSync supports Robinhood Chain (chain ID 4663), so an indexer needs no RPC endpoint and backfills from any start block. For verified contracts, envio init contract-import explorer -b robinhood -c <address> scaffolds a project from the explorer's ABI. We tested it on Doppler's Airlock contract and the generated tests passed. If you'd rather not do it by hand, the agent prompt above hands the job to a coding agent. For a full worked example, see our tokenized asset indexer.

Build With Envio

Envio is a real-time multichain blockchain indexer that turns onchain events into a queryable GraphQL API. Robinhood Chain has first-class support, so HyperSync, HyperRPC and HyperIndex all work on it out of the box. Start indexing Robinhood Chain, deploy on Envio Cloud or self-host, and if you're building on Robinhood Chain, come talk to us about your data needs.

Subscribe to our newsletter

How to Index USDC Transfers on Arc

Envio — Thu, 24 Sep 2026 00:00:00 +0000

TL;DR

USDC is Arc's gas token. Every USDC transfer is logged as a standard Transfer from the system address 0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE, in 18 decimals. The USDC contract at 0x3600…0000 logs a second copy of ERC-20 calls, in 6 decimals.
Index the system address and nothing else. In a 100,000 block sample, indexing both would have counted 48.3% of transfers twice, and indexing only the contract would have missed 51.7%.
Arc is chain ID 5042, on HyperSync at https://arc.hypersync.xyz. Endpoints and testnet details are on our Arc chain page.
The indexer below is three files and matched HyperSync's count exactly. Copy it, clone it from GitHub, or hand the build to your coding agent with our prompt.

In a 14 hour sample of Arc blocks, 906,915 USDC transfers were logged, and 469,254 of them never touched the USDC contract. They were native movements, like a plain send from one wallet to another, and on Arc those get a standard Transfer log from a system address.

Arc is an open Layer 1 blockchain that uses USDC as its gas token, so USDC is the native coin and an ERC-20 at the same time. It implements EIP-7708, which logs native movements the same way as token transfers. On a standard EVM chain, a plain native send leaves no log at all. The one thing an indexer has to get right is which stream to count. This guide covers that, then builds a small indexer using Envio's HyperIndex, the base for payment tracking, treasury reconciliation or any USDC dashboard on Arc.

Connecting to Arc

Property	Value
Chain ID	`5042` (mainnet), `5042002` (testnet)
Gas token	USDC
HyperSync (mainnet)	`https://arc.hypersync.xyz`
HyperSync (testnet)	`https://arc-testnet.hypersync.xyz`
HyperRPC (mainnet, read only)	`https://arc.rpc.hypersync.xyz`
HyperRPC (testnet, read only)	`https://arc-testnet.rpc.hypersync.xyz`
Public RPC (mainnet)	`https://rpc.mainnet.arc.io`
Public RPC (testnet)	`https://rpc.testnet.arc.io`
Explorer	explorer.arc.io (mainnet), explorer.testnet.arc.io (testnet)

Arc and Arc Testnet both have first-class support on Envio, so HyperSync serves their data and HyperIndex doesn't need an RPC to index them. The public RPCs and explorers come from Arc's connection docs, and more details are on our Arc and Arc Testnet chain pages.

Blocks come about every half second. Order by block number rather than timestamp, because several blocks can share one. Finality is deterministic, so there are no reorgs to handle.

How Arc Logs USDC Transfers

USDC has one balance on Arc and two ways to move it. Arc's USDC system events reference covers both.

Stream	Emitter	Decimals	What it covers
Native USDC	`0xffff…fFfE`	18	Every USDC transfer, including native sends, mints and burns
ERC-20 USDC	`0x3600…0000`	6	Only calls made through the ERC-20 interface

The system address isn't a contract, just the address Arc's EIP-7708 logs come from. An ERC-20 transfer() on USDC produces a log from both addresses, while a plain native send produces only the system one.

Here's what we counted over blocks 22,477,236 to 22,577,235.

What we counted	Logs	Share of system logs
`Transfer` from the system address	906,915	100%
Also logged by the USDC contract	437,661	48.3%
Only logged by the system address	469,254	51.7%

Matched on transaction hash, sender, receiver and value, with the 6 decimal value scaled up by 10¹². Read through HyperSync.

The USDC contract logged 446,270 transfers in the same window. All but 8,609 matched a system log, and every one of those 8,609 was either a zero value transfer (4,808) or a transfer to yourself (3,801). No USDC moved in any of them, and Arc's docs say the system address skips both.

21.7% of the system transfers, 197,025 of them, carried digits past the sixth decimal place, which a 6 decimal view can't represent. The window also had 1,013 mints and 446 burns, logged as transfers from and to the zero address.

For a USDC total, index the system address and nothing else. If you need to know which transfers went through the ERC-20 interface, join the contract's logs the same way we matched them above, but don't add them to the count.

Build It With Your Coding Agent

The quickest way to build this is to hand it to a coding agent. We wrote the prompt below from the finished indexer, so it already knows the traps. Give the agent our current docs first so it works from live syntax, then paste the prompt. If you'd rather build it by hand, the steps are below.

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

Cursor and VS Code use the same endpoint, and an agent with shell access can use envio tools search-docs instead. Both are on the MCP server page.

Show the full prompt

Build me an Envio HyperIndex indexer that counts every USDC transfer on Arcexactly once.Before writing code, read the current HyperIndex docs rather than working frommemory. Use the envio-docs MCP server (docs_search, docs_fetch) if you have it,otherwise `envio tools search-docs <query>`. Look up the configuration file,schema and event handlers.THE CHAINArc is chain ID 5042. HyperSync is the default data source, so the config needsno rpc block. USDC is Arc's native gas token.WHICH ADDRESS TO INDEXEvery USDC transfer on Arc, including native sends, mints and burns, is loggedas a standard Transfer(address indexed from, address indexed to, uint256 value)from the system address 0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE, with valuesin 18 decimals. Put that address in config.yaml as if it were a contract.Do not also index Transfer from the USDC ERC-20 contract at0x3600000000000000000000000000000000000000. It logs a second copy of everyERC-20 interface transfer, in 6 decimals, so adding it double counts. Never mixthe 6 and 18 decimal values.Mints are transfers from the zero address and burns are transfers to it. Thesystem address never logs zero value transfers or transfers to yourself.WHAT TO STOREPer account, net USDC movement across the indexed window (call it net movement,not balance, because anything held before the start block is invisible), plustransfers in and transfers out. The zero address is not an account, so it getsno row. Per UTC day, transfer count, volume, and the number of mints and burns.SETUP mkdir arc-usdc-indexer && cd arc-usdc-indexer pnpm init pnpm add envio --allow-build=esbuild pnpm add -D typescript @types/node npm pkg set type=moduleHandlers auto-load from src/handlers/. Put an Envio API token fromhttps://envio.dev/app/api-tokens in .env as ENVIO_API_TOKEN and keep .env out ofgit. For a quick first run, set start_block about 100,000 blocks below thecurrent height from https://arc.hypersync.xyz/height. Run `pnpm envio codegen`then `pnpm envio dev`, with Docker running.TRAPS- Use Node.js 22 or newer. Older versions fail to auto-load handlers.- Neither codegen nor dev typechecks. Add a tsconfig.json that includes src and the generated envio-env.d.ts, and run `pnpm exec tsc --noEmit`.- If `envio dev` says the config is incompatible with existing indexer data, the local Postgres holds another indexer. Don't reset it. Run with ENVIO_PG_SCHEMA and ENVIO_INDEXER_PORT set to new values instead.- If you sort or bucket events, use block number, not timestamp. Arc blocks are about half a second apart and can share a timestamp.- On Arc Testnet (5042002), native USDC history from before the Zero5 hard fork uses NativeCoin* events from 0x1800000000000000000000000000000000000000 instead. Mainnet has used the system Transfer log since genesis.REPORT BACKProgress is in the envio_chains table (progress_block, source_block,events_processed). Report the exact block range you indexed, the number ofTransfer events processed, the number of accounts, and mints and burns. Givethe numbers you actually got. Don't assume ours still hold.

Building the Arc USDC Indexer

New to Envio?

Check the prerequisites before running anything below.

The Arc USDC indexer is three files. config.yaml names the chain and the event, schema.graphql defines what gets stored, and one handler file does the work. HyperIndex reads the logs from HyperSync and gives you a GraphQL API over the result. You'll also need a free Envio API token in a .env file as ENVIO_API_TOKEN.

mkdir arc-usdc-indexer && cd arc-usdc-indexerpnpm initpnpm add envio --allow-build=esbuildpnpm add -D typescript @types/nodenpm pkg set type=module

config.yaml

The system address goes in as if it were a contract. Arc is on HyperSync, so there's no rpc block to configure. Start from a recent block so a first run is quick. curl https://arc.hypersync.xyz/height returns the current height, and 100,000 blocks is about 14 hours of chain time. The config below uses the first block of our sample. Set start_block to 0 for everything since genesis, and budget for a much longer sync.

# yaml-language-server: $schema=./node_modules/envio/evm.schema.jsonname: arc-usdc-indexerdescription: Every USDC transfer on Arc (chain 5042)contracts: # Arc's system address logs a standard Transfer for every USDC movement, # with values in 18 decimals. It is not a deployed contract. - name: NativeUSDC events: - event: "Transfer(address indexed from, address indexed to, uint256 value)"chains: - id: 5042 # Arc. HyperSync is the default data source. start_block: 22477236 # the first block of our sample. Use a recent block. contracts: - name: NativeUSDC address: "0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE"

schema.graphql

The schema keeps totals per account and per day. netChange is movement across the indexed window, not a balance, because anything held before the start block is invisible to the indexer.

type Account { id: ID! # account address # Net USDC movement across the indexed window, 18 decimals. Not a balance. netChange: BigInt! transfersIn: Int! transfersOut: Int!}type DailyStat { id: ID! # day index transfers: Int! volume: BigInt! mints: Int! burns: Int!}

The Handler

The handler goes in src/handlers/NativeUSDC.ts. Values stay in 18 decimals, so divide by 10¹⁸ when you display them.

import { indexer } from "envio";const ZERO = "0x0000000000000000000000000000000000000000";const DAY = 86_400;indexer.onEvent( { contract: "NativeUSDC", event: "Transfer" }, async ({ event, context }) => { const { from, to, value } = event.params; const day = String(Math.floor(event.block.timestamp / DAY)); // The system emitter skips self transfers, so from and to always differ. // Mints come from the zero address and burns go to it. const [sender, receiver, stat] = await Promise.all([from === ZERO ? undefined : context.Account.get(from), to === ZERO ? undefined : context.Account.get(to), context.DailyStat.getOrCreate({ id: day, transfers: 0, volume: 0n, mints: 0, burns: 0, }),]); if (from !== ZERO) { context.Account.set({ id: from, netChange: (sender?.netChange ?? 0n) - value, transfersIn: sender?.transfersIn ?? 0, transfersOut: (sender?.transfersOut ?? 0) + 1, }); } if (to !== ZERO) { context.Account.set({ id: to, netChange: (receiver?.netChange ?? 0n) + value, transfersIn: (receiver?.transfersIn ?? 0) + 1, transfersOut: receiver?.transfersOut ?? 0, }); } context.DailyStat.set({ ...stat, transfers: stat.transfers + 1, volume: stat.volume + value, mints: stat.mints + (from === ZERO ? 1 : 0), burns: stat.burns + (to === ZERO ? 1 : 0), }); },);

Running It

pnpm envio codegenpnpm envio dev

envio dev starts Postgres and Hasura in Docker and begins syncing. Over the same 100,000 blocks, our run processed 906,915 events , exactly the number HyperSync returned, across 106,129 accounts.

Once it's running, http://localhost:8080 opens a Hasura console, and the local admin secret is testing. This query returns the accounts with the largest net inflow over the window.

query TopReceivers { Account(order_by: { netChange: desc }, limit: 10) { id netChange transfersIn transfersOut }}

The finished indexer is on GitHub at enviodev/arc-usdc-indexer, along with the script behind the numbers above. For stablecoins on other chains, see how to index and track stablecoin transfers on Solana and how to build an open source RWA stablecoin dashboard.

When you want it online, push the project to GitHub and deploy it on Envio Cloud, which runs the database, the GraphQL API and the syncing for you.

Frequently Asked Questions

Which Address Should I Index for USDC Transfers on Arc?

Index Transfer from the system address 0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE. It logs every USDC transfer, including native sends, mints and burns, in 18 decimals. The USDC contract at 0x3600…0000 only logs ERC-20 interface calls, and those also appear in the system stream. In our 100,000 block sample, indexing only the contract missed 51.7% of transfers, and indexing both double counted 48.3%.

Why Does USDC on Arc Have Both 18 and 6 Decimals?

USDC on Arc has one balance with two interfaces. The native interface, used for gas and plain value transfers, has 18 decimals. The ERC-20 interface at 0x3600000000000000000000000000000000000000 has 6 decimals and is there for things like approve and transferFrom. Raw values differ by 10¹², and the 6 decimal view truncates any digits past the sixth decimal place, which applied to 21.7% of the transfers in our sample.

Why Don't Gas Fees Show Up as USDC Transfers on Arc?

Gas on Arc is paid in USDC, but gas deductions don't emit a Transfer log, so an indexer built on transfer events won't see them. Arc's USDC system events page says to work out gas from the transaction receipt as gasUsed × effectiveGasPrice. If you're reconciling an account's USDC, take gas from receipts separately from the transfers you index.

How Do I Match a Payment Memo to a USDC Transfer on Arc?

Arc's Memo contract at 0x5294E9927c3306DcBaDb03fe70b92e01cCede505 lets a wallet attach a reference, like an invoice ID, to a call such as a USDC transfer. It emits Memo(address indexed sender, address indexed target, bytes32 callDataHash, bytes32 indexed memoId, bytes memo, uint256 memoIndex) in the same transaction. Add the contract to config.yaml with that event, list hash in the fields option of both the Memo and NativeUSDC handlers to read event.transaction.hash, and match memos to transfers on transaction hash. If a transaction holds more than one transfer, compare callDataHash with the hash of the transfer calldata, as Arc's memo docs suggest. Match on the system Transfer log rather than the memo alone, since a memo can also wrap a call that moves no USDC, like a zero value transfer.

How Do I Index USDC on Arc Testnet?

Change the chain ID to 5042002 and set a testnet start_block from https://arc-testnet.hypersync.xyz/height. Arc Testnet logs USDC transfers from the same system address. Before the Zero5 hard fork, testnet logged native USDC movements as NativeCoin* events from 0x1800000000000000000000000000000000000000 instead, so a backfill across that point needs both. Arc's USDC system events page has the event signatures, and testnet USDC comes from Circle's faucet.

How Do I Index EURC or Other Tokens on Arc?

The same way as on any EVM chain. EURC at 0xbEf5f6d51CB62b58e6A8f77868681825C6fe21c1 and other ERC-20 tokens on Arc emit Transfer from their own contract addresses, so you add each contract to config.yaml as usual. Arc's contract addresses page lists the official tokens.

Build With Envio

Envio is a real-time multichain blockchain indexer that turns onchain events into a queryable GraphQL API. Arc has first-class support, so HyperSync, HyperRPC and HyperIndex all work on it out of the box. Start indexing Arc, deploy on Envio Cloud or self-host, and if you're building on Arc, come talk to us about your data needs.

Subscribe to our newsletter

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 💌