Stories by ENVIO on Medium

Envio vs The Graph

ENVIO — Fri, 10 Jul 2026 00:00:32 GMT

TL;DR

Envio HyperIndex and The Graph take different approaches to indexing EVM data. This is a sourced, head-to-head comparison of the two.
Sync speed is the clearest gap. In the independent Sentio benchmark, HyperIndex finished the Uniswap V2 Factory workload in 8 seconds against 19 minutes for The Graph, 142x faster.
HyperIndex handlers are standard TypeScript in Node with any npm package. The Graph uses AssemblyScript compiled to WebAssembly.
HyperIndex indexes every chain from one config.yaml. The Graph deploys one subgraph per chain.
If you do decide to switch, migration is a documented flow, your existing subgraph queries keep working through Envio’s query converter, and teams like Katana, Revert Finance, and Sablier have already moved. For the wider field, see Best Blockchain Indexers in 2026.

Most teams reach for The Graph first, because subgraphs are the incumbent way to index EVM data, the approach most developers already know. The questions tend to start later, when syncs drag, a schema change means a long backfill, or you need the same data across several chains. That is usually when Envio HyperIndex comes up.

This is a direct comparison of the two. We put them head to head on what actually separates them, sync speed, the language you write handlers in, multichain support, and reorg handling, then cover what switching involves. For the wider field of indexers, our 2026 indexer comparison ranks Envio, The Graph, Goldsky, SubQuery, Subsquid, Ormi, and Ponder side by side.

Sync Speed

Speed is the clearest difference, and it is well documented. HyperIndex pulls data through HyperSync, Envio’s Rust data engine, which delivers up to 2000x faster data access than standard RPC. HyperIndex can also index over a standard RPC endpoint, either for chains HyperSync does not yet support or if you would rather not use it. The Graph reads through standard RPC only.

In the independent Sentio Uniswap V2 Factory benchmark, HyperIndex finished in 8 seconds against 19 minutes for The Graph, 142x faster. On the Sentio LBTC workload, it finished in 3 minutes against 3 hours 9 minutes. Full methodology is on the benchmarks page, with the raw runs in the open-indexer-benchmark repo. Fast sync matters beyond backfills, because a schema change means re-syncing in hours rather than days.

Handler Language, TypeScript vs AssemblyScript

The Graph’s mappings are written in AssemblyScript, a strict subset of TypeScript that compiles to WebAssembly. The syntax looks familiar, but the runtime is not. Standard npm packages do not run, common idioms like optional chaining and class inheritance are restricted, and numbers use AssemblyScript BigInt rather than native JS BigInt.

HyperIndex handlers are standard TypeScript executed in Node. Any npm package works, generated types come from both your GraphQL schema and your contract ABIs, and there is no WebAssembly step. For teams already writing TypeScript across their stack, this is the difference felt every day.

Multichain Indexing

A subgraph is deployed per chain. Indexing the same protocol on Ethereum and Base means two subgraphs, and cross-chain reads happen in your application layer.

HyperIndex declares every chain under a single chains array in one config.yaml. Adding a chain is one more entry with a chain ID and address, reusing the same contract definition and event signatures, and cross-chain queries run at the database layer behind one GraphQL endpoint. Sablier runs a single indexer across 27 chains this way.

Read more about multichain indexing in our docs.

Reorg Handling

Reorgs are the most common chain-level event a production indexer has to survive. On The Graph, graph-node reverts affected entities automatically when a reorg is detected, bounded by its reorg threshold and prune settings, and because each chain is its own subgraph, multichain coverage means handling that across several deployments.

HyperIndex tracks per-entity state history for every unfinalised block at the framework level, with rollback on by default. When a reorg happens, the framework rolls each entity back to its pre-reorg state and reprocesses forward against the canonical chain, then prunes history once a block finalises. No handler code is required. The details are in Reorgs Support.

Head-to-Head at a Glance

Comparison PointEnvio HyperIndexThe GraphHandler languageTypeScript in Node, any npm packageAssemblyScript compiled to WebAssemblyMultichainEvery chain in one config.yamlOne subgraph per chainData sourceHyperSync, up to 2000x faster than RPC, or standard RPC for chains it does not coverStandard RPCReorg handlingFramework-level, rollback on by defaultAutomatic via graph-node, bounded by prune settingsQuery languageStandard GraphQL, plus a converter for subgraph queriesCustom GraphQL dialectHosted runtimeEnvio Cloud, GitHub-native deploy, or self-host via DockerSubgraph Studio and the decentralised network

Switching From The Graph

If the comparison points you toward Envio, moving is a documented flow rather than a rewrite. It comes down to three steps, convert subgraph.yaml to config.yaml, bring your schema across (close to copy and paste, with the @entity directive removed), and port your handlers from AssemblyScript to TypeScript. Running pnpx envio init scaffolds the config and schema, your existing subgraph queries keep working through Envio's query converter tool, and the Indexer Migration Validator checks both endpoints field-by-field before you cut over.

Because AssemblyScript is a subset of TypeScript, most of the handler work is mechanical, which is why many teams now let an AI assistant do the rewrite. Our AI migration guide walks Cursor or Claude Code through the port, and AI-Assisted Subgraph Migration with Claude shows it end to end.

Katana moved two production SushiSwap subgraphs off The Graph entity-for-entity. Revert Finance had a PancakeSwap V3 subgraph stuck at 70 percent sync on BNB Smart Chain for over two years, and HyperIndex synced it to 100 percent in 10 days across 1.7 billion events. The Polymarket reference indexer consolidated 8 subgraph domains into one indexer that synced 4 billion Polygon events in 6 days. Envio also offers full white-glove migration help.

The Bottom Line

For most EVM teams, HyperIndex is the stronger choice with faster syncs, TypeScript handlers, multichain from a single config, and a documented path off a subgraph. The one case where The Graph still fits is if you need to consume its existing network of public subgraphs, which is its own ecosystem. For building and running your own indexer, Envio is the better tool.

Get Started

Frequently Asked Questions

Do My Existing Subgraph GraphQL Queries Work After Switching to Envio?

You do not have to rewrite them by hand. HyperIndex serves standard GraphQL rather than The Graph’s dialect, and Envio provides a query converter tool and conversion guide to translate existing subgraph queries. After switching, the Indexer Migration Validator compares your new endpoint against the original subgraph field-by-field so you can confirm the data matches before cutting over.

Can I Keep My Subgraph Schema When Moving to HyperIndex?

Largely yes. Schema migration is close to copy and paste. You remove the @entity directive, and there are small nuances around enums and BigDecimals documented in the schema docs. HyperIndex generates its types from the same GraphQL schema and your contract ABIs, so entity definitions and relationships carry across with minimal rework.

How Long Does a The Graph to Envio Migration Take?

It depends on handler complexity, but the shape is fixed at three steps, config, schema, and handlers. Pure handler logic often copies straight across because AssemblyScript is a subset of TypeScript, and pnpx envio init scaffolds the config and schema for you. Teams also use AI-assisted migration for the rewrite, and Envio offers white-glove help via Discord.

Can One Envio Indexer Replace Several Per-Chain Subgraphs?

Yes, and it is a common outcome. Because every chain lives in one config.yaml, teams routinely consolidate multiple subgraph deployments into a single indexer. Sablier replaced 12 deployments with one indexer across 27 chains, and the Polymarket reference unified 8 subgraph domains into one indexer syncing 4 billion events in 6 days.

Does Moving to Envio Mean I Lose Access to The Graph’s Public Subgraphs?

Yes, and that is the main reason to stay on The Graph. Its decentralised network hosts the largest set of community-maintained subgraphs for major protocols. Envio indexes your own contracts into your own schema, so if your dependency is on consuming those public subgraphs rather than running your own indexer, The Graph is still the right home for that.

Is HyperIndex Faster Than The Graph in Independent Benchmarks?

Yes. In the independent Sentio Uniswap V2 Factory benchmark, HyperIndex finished in 8 seconds against 19 minutes for The Graph, 142x faster, and on the Sentio LBTC workload it finished in 3 minutes against 3 hours 9 minutes. The gap comes from HyperSync, Envio’s Rust data engine, which delivers up to 2000x faster data access than the standard RPC that The Graph reads through. Full methodology is on the benchmarks page and the raw runs are in the open-indexer-benchmark repo.

Build With Envio

Envio is a real-time multichain blockchain indexer that turns onchain events into a queryable GraphQL API. Supports any EVM chain, plus Solana and Fuel. Use Envio Cloud or self-host. If you’re building onchain, come talk to us about your data needs.

Subscribe to our newsletter 💌

Originally published at https://docs.envio.dev on July 10, 2026.

How to Build an Open Source RWA Stablecoin Dashboard | Envio

ENVIO — Fri, 10 Jul 2026 00:00:01 GMT

TL;DR

The RWA dashboard is open source and backed by an indexer you can run yourself, starting with stablecoins, with the live dashboard at rwaradar.io.
On the stablecoin side it surfaces total supply, transfer count, transfer amount and volume, mint and burn amounts, and daily snapshots of each.
Every metric falls out of Transfer events, since mints and burns show up as transfers to and from the zero address.
USDT is the exception, so the indexer reads its Issue and Redeem events directly for clean mint and burn numbers.
The transfer and mint/burn logic lives in shared handlers, so every token reuses the same paths.

Real-world assets have gone from a niche thing a few companies were poking at to one of the biggest sectors in crypto over the last few years. This post isn’t a market take, though. At Envio, my job is to build technical demos that actually use our products, so I decided to build something real, an open-source RWA dashboard backed by a HyperIndex metrics indexer you can run yourself. If you want to check whether the data lines up, or you want to build something similar, the whole thing is there to fork.

Why stablecoins first

RWA is a huge bucket, so I had to pick a starting point. Stablecoins were the obvious one.

The goal for the stablecoin side of the dashboard is to surface the metrics that actually tell you something. Total supply, transfer count, transfer amount and volume, mint and burn amounts, and daily snapshots of all of it. Nothing exotic, just the numbers you’d want if you were tracking how a stablecoin is actually being used onchain.

Now that we’ve covered what the dashboard is supposed to do, let’s get into the indexer and the logic behind it. That’s the part that matters.

The indexer

Wiring up the handlers

I’m tracking a set of major stablecoins across a dozen chains to start. The full list lives in the config.yaml if you want to see exactly which ones.

For most of them, tracking Transfer events is enough. Every metric we care about falls out of transfers, including mints and burns, since those show up as transfers from or to the zero address. USDT is the exception. Its issue and redeem don't emit Transfers, so the indexer tracks its Issue and Redeem events directly. Bridged USDT on other chains does emit zero-address Transfers, so the Transfer handler covers it.

indexer.onEvent(
  { contract: "Stablecoins", event: "Transfer" },
  async ({ event, context }) => {
    await handleTransfer(event, context);
  },
);

indexer.onEvent(
  { contract: "USDT", event: "Transfer" },
  async ({ event, context }) => {
    await handleTransfer(event, context);
  },
);

indexer.onEvent(
  { contract: "USDT", event: "Issue" },
  async ({ event, context }) => {
    await handleSupplyChange(event, context, "mint");
  },
);

indexer.onEvent(
  { contract: "USDT", event: "Redeem" },
  async ({ event, context }) => {
    await handleSupplyChange(event, context, "burn");
  },
);

The point of pulling the logic out into handleTransfer and handleSupplyChange is reuse. Every token shares the same transfer logic, and the mint/burn path is shared too. The handlers themselves stay thin and just call into the abstracted functions.

handleTransfer

This is the workhorse. It updates everything tied to a transfer.

First it does the fetching and parsing. It pulls the event params to derive the IDs, and grab the current state of the entities it’s about to touch.

async function handleTransfer(
  event: {
    chainId: number;
    srcAddress: string;
    block: { timestamp: number };
    params: { from: string; to: string; value: bigint };
  },
  context: EvmOnEventContext,
) {
  const { from, to, value } = event.params;
  const chainId = event.chainId;
  const tokenAddress = event.srcAddress;
  const timestamp = event.block.timestamp;
  const currentDayId = Math.floor(timestamp / 86400);
  const midnightTimestamp = currentDayId * 86400;

  const isMint = from === ZERO_ADDRESS;
  const isBurn = to === ZERO_ADDRESS;

  const tokenId = `${chainId}_${tokenAddress}`;
  const dayDataId = `${tokenId}_${currentDayId}`;
  const fromBalanceId = `${tokenId}_${from}`;
  const toBalanceId = `${tokenId}_${to}`;
  const activeAddrId = `${tokenId}_${currentDayId}_${from}`;

  const [
    existingToken,
    existingDayData,
    fromBalance,
    toBalance,
    existingActiveAddr,
  ] = await Promise.all([
    context.Token.get(tokenId),
    context.TokenDayData.get(dayDataId),
    !isMint
      ? context.HolderBalance.get(fromBalanceId)
      : Promise.resolve(undefined),
    !isBurn
      ? context.HolderBalance.get(toBalanceId)
      : Promise.resolve(undefined),
    !isMint
      ? context.DailyActiveAddress.get(activeAddrId)
      : Promise.resolve(undefined),
  ]);

  // continue the snapshot logic
}

The snapshot logic is where the only real trick is. Blocks give us a UTC timestamp, so to know whether a transfer belongs to a new day we just check whether its timestamp crossed midnight relative to the last day I recorded. If it’s a new day, I start tracking a fresh TokenDayData entity. Everything else is the same shape as before: if it's a mint, bump supply up; if it's a burn, bump it down.

const lastDayId = existingToken?.lastDayId ?? currentDayId;
const isNewDay = currentDayId > lastDayId;

if (isNewDay) {
  const stale = await context.DailyActiveAddress.getWhere({
    token_id: { _eq: tokenId },
  });
  for (const entry of stale) {
    context.DailyActiveAddress.deleteUnsafe(entry.id);
  }
}

const isNewActiveAddr = !isMint && (isNewDay || !existingActiveAddr);

let newTotalSupply = existingToken?.totalSupply ?? 0n;
if (isMint) newTotalSupply += value;
if (isBurn) newTotalSupply -= value;

context.Token.set({
  id: tokenId,
  chainId,
  address: tokenAddress,
  totalSupply: newTotalSupply,
  lastDayId: currentDayId,
});

context.TokenDayData.set({
  id: dayDataId,
  token_id: tokenId,
  chainId,
  date: midnightTimestamp,
  dailyTotalSupply: newTotalSupply,
  dailyMintAmount:
    (existingDayData?.dailyMintAmount ?? 0n) + (isMint ? value : 0n),
  dailyBurnAmount:
    (existingDayData?.dailyBurnAmount ?? 0n) + (isBurn ? value : 0n),
  dailyTransferAmount: (existingDayData?.dailyTransferAmount ?? 0n) + value,
  dailyTransferCount: (existingDayData?.dailyTransferCount ?? 0) + 1,
  dailyActiveAddresses:
    (existingDayData?.dailyActiveAddresses ?? 0) + (isNewActiveAddr ? 1 : 0),
});

if (!isMint) {
  context.HolderBalance.set({
    id: fromBalanceId,
    token_id: tokenId,
    chainId,
    holder: from,
    balance: (fromBalance?.balance ?? 0n) - value,
    firstTransferTimestamp:
      fromBalance?.firstTransferTimestamp ?? BigInt(timestamp),
    lastTransferTimestamp: BigInt(timestamp),
  });
}

if (!isBurn) {
  context.HolderBalance.set({
    id: toBalanceId,
    token_id: tokenId,
    chainId,
    holder: to,
    balance: (toBalance?.balance ?? 0n) + value,
    firstTransferTimestamp:
      toBalance?.firstTransferTimestamp ?? BigInt(timestamp),
    lastTransferTimestamp: BigInt(timestamp),
  });
}

if (isNewActiveAddr) {
  context.DailyActiveAddress.set({
    id: activeAddrId,
    token_id: tokenId,
    chainId,
    date: currentDayId,
    address: from,
  });
}

One thing worth calling out: on a new day I clear out the stale DailyActiveAddress entries for the token. Active addresses are a per-day count, so they don't carry over. Skipping mint senders from the active-address count is deliberate too, since the zero address isn't a real participant.

handleSupplyChange

This one only exists for USDT’s Issue and Redeem. The logic is mostly a slimmer version of handleTransfer, with one extra input, direction. The events themselves just hand you an amount, so the handler is the thing that decides whether it's a mint or a burn and passes that down.

async function handleSupplyChange(
  event: {
    chainId: number;
    srcAddress: string;
    block: { timestamp: number };
    params: { amount: bigint };
  },
  context: EvmOnEventContext,
  direction: "mint" | "burn",
) {
  const { amount } = event.params;
  const chainId = event.chainId;
  const tokenAddress = event.srcAddress;
  const timestamp = event.block.timestamp;
  const currentDayId = Math.floor(timestamp / 86400);
  const midnightTimestamp = currentDayId * 86400;

  const tokenId = `${chainId}_${tokenAddress}`;
  const dayDataId = `${tokenId}_${currentDayId}`;

  const [existingToken, existingDayData] = await Promise.all([
    context.Token.get(tokenId),
    context.TokenDayData.get(dayDataId),
  ]);

  const lastDayId = existingToken?.lastDayId ?? currentDayId;
  const isNewDay = currentDayId > lastDayId;

  if (isNewDay) {
    const stale = await context.DailyActiveAddress.getWhere({
      token_id: { _eq: tokenId },
    });
    for (const entry of stale) {
      context.DailyActiveAddress.deleteUnsafe(entry.id);
    }
  }

  let newTotalSupply = existingToken?.totalSupply ?? 0n;
  if (direction === "mint") newTotalSupply += amount;
  else newTotalSupply -= amount;

  context.Token.set({
    id: tokenId,
    chainId,
    address: tokenAddress,
    totalSupply: newTotalSupply,
    lastDayId: currentDayId,
  });

  context.TokenDayData.set({
    id: dayDataId,
    token_id: tokenId,
    chainId,
    date: midnightTimestamp,
    dailyTotalSupply: newTotalSupply,
    dailyMintAmount:
      (existingDayData?.dailyMintAmount ?? 0n) +
      (direction === "mint" ? amount : 0n),
    dailyBurnAmount:
      (existingDayData?.dailyBurnAmount ?? 0n) +
      (direction === "burn" ? amount : 0n),
    dailyTransferAmount: existingDayData?.dailyTransferAmount ?? 0n,
    dailyTransferCount: existingDayData?.dailyTransferCount ?? 0,
    dailyActiveAddresses: existingDayData?.dailyActiveAddresses ?? 0,
  });
}

Notice it leaves the transfer fields untouched and only moves supply, mint, and burn. Issue and Redeem aren’t transfers, so they shouldn’t inflate transfer counts.

What’s next

That’s the first step of the RWA dashboard, one indexer, with the logic and setup laid out. Tokenised US Treasuries, with NAV and yield tracking, are already in the same indexer, and I’ll walk through those next.

If you want to dig into the code, the stablecoins indexer is here, and the live dashboard is at rwaradar.io. If you’re building in the RWA space and want to compare notes, reach out.

Frequently Asked Questions

How does the indexer track stablecoin mints and burns?

For most of the stablecoins, tracking Transfer events is enough. Mints and burns fall out of transfers, since they show up as transfers from or to the zero address, so total supply moves up on a mint and down on a burn without needing dedicated events.

Why is USDT handled differently from the other stablecoins?

USDT is the exception. To get clean mint and burn numbers for it, the indexer tracks its Issue and Redeem events directly through handleSupplyChange, which reads the amount and decides whether it’s a mint or a burn. It leaves the transfer fields untouched and only moves supply, mint, and burn, since Issue and Redeem aren’t transfers and shouldn’t inflate transfer counts.

How does the indexer decide when a new day begins for the snapshots?

Blocks give a UTC timestamp, so the handler checks whether a transfer’s timestamp crossed midnight relative to the last day it recorded, deriving the current day as Math.floor(timestamp / 86400). When it’s a new day, it starts tracking a fresh TokenDayData entity.

Why are mint senders skipped in the daily active address count?

Active addresses are a per-day count, so they don’t carry over, and on a new day the stale entries for the token are cleared. Mint senders are skipped deliberately, since a mint comes from the zero address, which isn’t a real participant and would otherwise misrepresent daily activity.

Why are handleTransfer and handleSupplyChange pulled into shared functions?

The point is reuse. Every token shares the same transfer logic, and the mint and burn path is shared too, so the event handlers stay thin and just call into the abstracted functions.

What metrics does the stablecoin dashboard surface?

It surfaces total supply, transfer count, transfer amount and volume, mint and burn amounts, and daily snapshots of all of it, which are the numbers that show how a stablecoin is actually being used onchain.

Build With Envio

Subscribe to our newsletter

Originally published at https://docs.envio.dev on July 10, 2026.

How to Stream Onchain Events to an AI Trading Agent

ENVIO — Wed, 01 Jul 2026 00:00:43 GMT

TL;DR

A trading agent is only as good as its feed. It needs a data source that is as fast and as accurate as possible, including staying correct through reorgs. Raw RPC gives you none of that out of the box.
One layer does the work. HyperIndex indexes onchain events into GraphQL entities, and it ingests through HyperSync internally with reorg detection built in, so you get speed and rollback safety from a single layer.
HyperIndex exposes a single GraphQL endpoint. The agent polls it for new events as they land, and queries the same endpoint for historical state: an address’s track record, a market’s running volume, open positions. No rebuilding history inside the context window.
Reorgs are a normal part of consensus. HyperIndex rolls entity state back automatically when a chain reorgs, but state at the very head is provisional, so for anything that moves money, the conservative path is to act on events from finalized blocks.
The schema and queries below come from the published Polymarket reference indexer.

The interesting question about AI trading agents is not the model, it is the feed. An agent reasoning over markets needs to see events with as little latency as possible after they land onchain, in a shape it can reason about, from a source it can trust after a reorg. This guide builds that feed with one layer, then shows where the agent plugs in.

The Architecture in One Paragraph

One layer, accessed two ways. HyperIndex turns a contract’s events into structured entities served over GraphQL. Under the hood, it streams from HyperSync for fast ingestion, while HyperIndex detects reorgs and rolls entity state back when one happens. The agent talks to a single GraphQL endpoint: it polls for new trades as they land, and queries the same endpoint for state, market totals, an address’s history, and open positions. There is no separate ingestion pipeline to run and no in-memory state to rebuild.

Step 1: Index the events once

This is the indexing setup from our Polymarket reference indexer, which watches OrderFilled events from the Polymarket Exchange contracts on Polygon. You define the contract and event once in config.yaml:

# yaml-language-server: $schema=./node_modules/envio/evm.schema.json
name: polymarket-indexer
field_selection:
  transaction_fields:
    - hash
contracts:
  - name: Exchange
    abi_file_path: ./abis/Exchange.json
    events:
      - event: "OrderFilled(bytes32 indexed orderHash, address indexed maker, address indexed taker, uint256 makerAssetId, uint256 takerAssetId, uint256 makerAmountFilled, uint256 takerAmountFilled, uint256 fee)"
chains:
  - id: 137 # Polygon
    start_block: 33605403
    contracts:
      - name: Exchange
        address:
          - "0x4bFb41d5B3570DeFd03C39a9A4D8dE6Bd8B8982E"
          - "0xC5d563A36AE78145C45a50134d48A1215220f80a"

You define the entities once in schema.graphql. One entity for the raw trade the agent reacts to, one aggregate the agent reads for context:

type OrderFilledEvent
  @index(fields: ["maker", ["timestamp", "DESC"]])
  @index(fields: ["makerAssetId", ["timestamp", "DESC"]]) {
  id: ID!
  transactionHash: String!
  timestamp: BigInt! @index
  orderHash: String! @index
  maker: String! @index
  taker: String! @index
  makerAssetId: String! @index
  takerAssetId: String! @index
  makerAmountFilled: BigInt!
  takerAmountFilled: BigInt!
  fee: BigInt!
}

type Orderbook {
  id: ID!
  tradesQuantity: BigInt!
  buysQuantity: BigInt!
  sellsQuantity: BigInt!
  collateralVolume: BigInt!
  scaledCollateralVolume: BigDecimal!
}

And you map the event to those entities once in the handler. Every field comes straight off the OrderFilled event, and the running totals are computed at indexing time so the agent never has to aggregate at query time:

import { indexer } from "envio";

indexer.onEvent({ contract: "Exchange", event: "OrderFilled" }, async ({ event, context }) => {
  context.OrderFilledEvent.set({
    id: `${event.chainId}_${event.block.number}_${event.logIndex}`,
    transactionHash: event.transaction.hash,
    timestamp: BigInt(event.block.timestamp),
    orderHash: event.params.orderHash,
    maker: event.params.maker,
    taker: event.params.taker,
    makerAssetId: event.params.makerAssetId.toString(),
    takerAssetId: event.params.takerAssetId.toString(),
    makerAmountFilled: event.params.makerAmountFilled,
    takerAmountFilled: event.params.takerAmountFilled,
    fee: event.params.fee,
  });
});

The same pattern works for DEX swaps, liquidations, or any event family on any HyperSync-supported chain by changing the contract, the event signature, and the chain ID.

Wake the agent on new trades

A GraphQL subscription is the agent’s trigger. The agent holds an open subscription to the endpoint and gets pushed each new OrderFilledEvent as it lands, within a block of it happening, already decoded into the fields you defined:

subscription LatestTrades {
  OrderFilledEvent(order_by: { timestamp: desc }, limit: 1) {
    maker
    taker
    makerAssetId
    makerAmountFilled
    takerAmountFilled
    timestamp
  }
}

If a long-lived subscription does not fit your runtime, the same query polled on a short interval gives you the same trigger with simpler plumbing. Either way the agent reacts to structured trades, not raw logs.

Step 2: Give the Agent State, Not Just Ticks

A trigger tells the agent what just happened. Trading decisions usually need what has been happening, and rebuilding that from raw events inside a context window wastes tokens and invites errors. Because the handler already wrote the history and the running totals, the agent’s pre-decision check is a query, not a computation. Pull a maker’s recent track record:

query MakerHistory($maker: String!) {
  OrderFilledEvent(
    where: { maker: { _eq: $maker } }
    order_by: { timestamp: desc }
    limit: 100
  ) {
    makerAmountFilled
    takerAmountFilled
    timestamp
  }
}

Or read the market’s running volume straight off the aggregate, with no runtime aggregation:

query MarketVolume {
  Orderbook {
    tradesQuantity
    scaledCollateralVolume
  }
}

Computing aggregates at indexing time rather than query time is the recommended pattern, and it is what keeps these reads fast at scale. The Navigating Hasura guide covers the full query reference.

Step 3: Take Reorgs Seriousl

Reorgs are a normal part of consensus, not an Envio thing and not an edge case you can design away. A chain can fork at the head and resolve to a different set of blocks, and any event read from those orphaned blocks describes something that, as far as the canonical chain is concerned, never happened. This is true of every data source, raw RPC included.

HyperIndex handles the database side for you. Reorg support is on by default, and as long as HyperIndex ingests through HyperSync, reorg detection is guaranteed. When a reorg is detected, entity state is rolled back automatically to the canonical chain, with no rollback logic in your handlers. The full mechanics are in Understanding and Handling Chain Reorganizations.

The caveat that matters for a trading agent is this. Rollback corrects the database, it cannot recall a trade. There is a short window at the head where the indexed state can reflect a block that later gets orphaned. An agent that reads in that window and acts on it has already sent the order by the time the rollback fires. The data corrects, the trade does not. A dashboard showing a stale number is harmless; an agent trading on one is not.

So treat the head-of-chain state as provisional. HyperIndex considers a block safe from reorganization once it sits below the confirmation threshold, which defaults to 200 blocks below the head and is configurable per chain via max_reorg_depth. For anything that moves money, the conservative path is to act on events from finalized blocks and let the freshest head data inform analysis rather than execution. None of this is specific to Envio. Any trading agent on any stack faces the same finality question, regardless of where its data comes from.

A Note on the Trading Part

Everything above is the data layer, and it is the part worth automating first. Order execution is where agent autonomy should stop being the default. Keep execution behind explicit limits, position caps, and human-controlled keys, and let the agent’s edge be that it sees and understands the market faster, not that it can spend unsupervised.

This blog is an example of what you can build on HyperIndex, not a trading strategy and not financial advice. Whatever you ship on top of it is your own research and your own decision.

Get Started

Frequently Asked Questions

Should my agent subscribe to the indexer or query it?

Both, for different questions. A GraphQL subscription is the trigger that wakes the agent within a block of an event landing. A GraphQL query is the memory that answers aggregate questions like an address’s trade history or a market’s running volume without rebuilding state in the agent’s context. The stream wakes the agent, the query informs the decision, and both hit the same endpoint.

What happens if my agent acts on an event that later gets reorged?

That is the failure mode to design against, because the rollback fixes data but cannot recall a trade. HyperIndex rolls indexed entity state back to the canonical chain automatically when a reorg is detected, but an agent that read head-of-chain state and traded on it in the window before detection has already acted. HyperIndex considers a block safe from reorganization at a confirmation threshold that defaults to 200 blocks below the head and is configurable per chain via max_reorg_depth. For stateful actions that move money, prefer events from finalized blocks.

What chains can I stream trading events from?

Any HyperSync-supported network works with the same indexer and a one-line chain change in config.yaml. Chains without native HyperSync coverage are reachable through HyperIndex over standard RPC. The same schema and handler carry across chains unchanged.

How do I handle high-frequency events without overwhelming the agent?

Compute and store aggregates in your handlers at indexing time, then have the agent read those precomputed entities rather than fetching raw rows and summarising inside the context window. Field selection keeps each response small, and the running totals on an aggregate entity like Orderbook give the agent market context in a single cheap read.

Build With Envio

Subscribe to our newsletter 💌

Originally published at https://docs.envio.dev on July 1, 2026.

Envio Developer Update June 2026

ENVIO — Tue, 30 Jun 2026 00:00:52 GMT

Author: Jordyn Laurier — June 30, 20267 min read

June was one of our biggest months yet. HyperIndex advanced, delivering up to 2.5x faster and 2x cheaper indexing alongside multi-field getWhere filtering, multi-storage defaults, snake_case column naming, and expanded experimental Solana support. We also sponsored and attended ETHConf New York, continued migrating performance-critical paths to Rust, and saw teams ship a range of production-grade, real-time applications on Envio, spanning real-world asset tracking and x402 payment analytics.

Alongside the releases, we published new technical guides on agentic indexing, scaling subgraph-style workloads to millions of requests, choosing between HyperIndex and HyperSync, and much more.

Let’s dive in!

HyperIndex v3.1 & v3.2: Faster, Cheaper, and More Flexible

Building on May’s V3 launch, June delivered two substantial releases focused on speed, cost, and flexibility, followed by a patch release and the start of work on v3.3.

v3.1

v3.1 cut HyperSync queries during backfill by up to 2x and made many indexing cases up to 2.5x faster. It also added string descriptions for entities, fields, and relationships that surface directly in the GraphQL API, rate-limit information in the TUI and logs, a skip option to exclude chains from indexing and migrations, and support for startups with 4.5M+ contracts. We also improved the agentic development experience with new envio tools search-docs and envio tools fetch-docs commands, plus an envio metrics runtime subcommand.

Up to 2.5x faster indexing, with up to 2x fewer HyperSync queries during backfill.

v3.2

v3.2 followed with multi-field filtering in getWhere, so you can match on several entity fields at once, plus a performance boost for single _eq and _in lookups. Multi-storage got easier with default storages, so you no longer need a @storage directive on every entity, and you can now auto-convert database column names to snake_case while keeping the original names in GraphQL and handler types. We also expanded experimental Solana support with HyperSync-powered instruction handlers. Reach out to us if you are interested in becoming an early tester.

Multi-field filtering with getWhere

Match on several entity fields at once:

await context.Account.getWhere({
  id: { _eq: "0x123..." },
  balance: { _gte: 1_000_000n, _lte: 10_000_000n },
});

Multi-storage defaults

Mark a storage as default, so you no longer need a @storage attribute on every entity in schema.graphql:

storage:
  postgres:
    default: true
  clickhouse:
    default: true

snake_case column names

Auto-convert database column names to snake_case, while GraphQL and handler types keep the original names from schema.graphql:

storage:
  postgres:
    column_name_format: snake_case

v3.2.1

v3.2.1 rounded out the month with a smoother envio init experience for agents and non-interactive runs, ClickHouse nullable array validation, and faster indexing through topic filtering by address. We have also started work on v3.3.0 in alpha, focused on faster backfills for large multichain indexers.

See the full release notes

Star us on GitHub ⭐

Just-in-Time Indexing: Using Agents to Answer Onchain Questions

Just-in-Time Indexing shows how an AI agent can use Envio to answer one-off onchain questions without maintaining permanent infrastructure. The agent builds the indexer on demand, queries it once, and deletes it.

See how Curve Finance has been using Envio to answer one-off onchain questions with just-in-time indexing.

Read it here: https://docs.envio.dev/blog/just-in-time-indexing-agents-onchain

RWA Radar: Real-World Assets Onchain in Real Time

RWA Radar tracks real-world assets onchain in real time, covering stablecoins, credit, stocks, securities, and more, with sector breakdowns, volume, and history across chains in a single view, and exports to CSV, PDF, or XLSX. Ingestion is powered by HyperIndex.

Explore it here: https://rwaradar.io

When to Use HyperIndex vs HyperSync

This guide breaks down the two layers of the Envio stack, HyperSync as the data engine and HyperIndex as the framework built on top of it, with working v3 code and production examples to help teams choose the right tool for the job.

Read the full breakdown: https://docs.envio.dev/blog/hyperindex-vs-hypersync

x402stats Analytics Explorer

x402stats surfaces real-time stats for the x402 payment protocol on Base, including USDC volume, payment counts, active services, and buyers across 24h, 7d, 30d, and all-time, plus leaderboards for top services and facilitators.

Check it out here: https://x402stats.ai

Why Blockchain Indexers Hit Rate Limits at Scale

Why Blockchain Indexers Hit Rate Limits at Scale explains why RPC-based indexers throttle, and how HyperSync’s bulk-read architecture handles high traffic, with production-scale numbers.

More here: https://docs.envio.dev/blog/hypersync-under-load-no-throttling

How to Scale Subgraphs to Millions of Requests

This one tackles the two halves of the problem, sync speed and query latency, and how HyperIndex handles both while keeping your data model intact.

Read the full guide: https://docs.envio.dev/blog/scale-subgraphs-millions-of-requests

How to Index Sei Smart Contract Data in Minutes

This step-by-step guide walks through indexing a Sei ERC20 contract, streaming USDC Transfer and Approval events into Postgres and serving them through a GraphQL API.

Read the tutorial: https://docs.envio.dev/blog/index-sei-smart-contracts-envio

ETHConf New York

We sponsored ETHConf in New York from June 8th to 10th. The team set up a booth, handed out the (back by popular demand) “low maintenance” caps and fresh stickers, and spent the week talking fast indexing, HyperSync, and pulling onchain data without the wait.

Thank you to the ETHGlobal and ETHConf teams for having us, and to everyone who stopped by to talk data.

Featured Developer: Bazhar

This month’s featured developer is Bazhar, a developer and analyst focused on blockchain data, indexing, and building tools that make onchain activity easier to understand and query. Lately they have been working on approval discovery across chains, finding which wallets have approved a given contract, like a router, bridge, or Permit2-style spender, and turning that into a fast API and query layer, with most of the work centred on ERC20 approvals, spender contracts, and multichain data fast enough for production.

What Bazhar had to say about Envio:

“My experience with Envio has been really good. I came in with a fairly specific use case around discovering ERC20 approvals by spender contract across chains, and the team helped me think through the right architecture instead of just giving a generic answer. What stood out to me was how practical the support was. They explained where an indexer makes sense, where HyperSync can be used directly, and also clarified the important limitation around “live” allowances that Approval events alone don’t always reflect the remaining allowance after transferFrom calls. That helped me understand the trade-offs between preindexing everything, querying HyperSync on demand, and using RPC checks only where needed. Overall, Envio feels very developer-friendly. The team was responsive, honest about the technical and cost trade-offs, and helped turn a rough idea into a much clearer implementation path.”

Well done, Bazhar. Be sure to check out their GitHub to stay up to date with their latest developments.

Playlist of the Month

▶ Open Spotify

Build With Envio

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

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

Subscribe to our newsletter 💌

How to Scale Subgraphs to Millions of Requests

ENVIO — Fri, 26 Jun 2026 00:00:59 GMT

TL;DR

“Scale my subgraphs” is two separate problems. Sync speed is how fast events become rows. Query latency is how fast reads return once they are rows. Fixing one does not fix the other.
On sync speed, HyperIndex is the best indexer in independent testing. See the Sentio benchmarks for the numbers.
On query latency, HyperIndex serves reads from a dedicated Postgres database through your own GraphQL endpoint, not through a shared gateway, so read performance is predictable under load.
You keep the data model. Katana moved two production SushiSwap subgraphs entity-for-entity: 23 entity types, carried across without schema redesign. Polymarket replaced 8 subgraphs with one indexer that has processed over 6.5 billion events.
For high-throughput production workloads, Envio Cloud’s production plans add higher resource and query rate limits plus zero-downtime deployments, and Dedicated plans carry custom SLAs and SQL access alongside GraphQL.

Subgraphs are usually adopted when an app is small and queries are light. The pain starts later, when the frontend is making millions of requests, and the dashboard needs fresh data under load. At that point, teams search for how to scale their subgraphs, and most of the advice they find addresses the wrong half of the problem.

Scaling Is Two Problems, Not One

Sync speed and query latency are different bottlenecks with different fixes.

Sync speed determines how quickly onchain events land in your database, which sets data freshness and how painful a re-deploy or backfill is. Query latency determines how fast your API answers once the data is already indexed, which is what your users actually feel.

A subgraph at scale typically hurts on both ends. Backfills take hours or days, and reads route through shared serving infrastructure you do not control and cannot provision for your traffic.

Sync Speed

HyperIndex pulls data through HyperSync, Envio’s Rust data engine, rather than paginated RPC reads. Independent benchmarks put it at 8 seconds for the Uniswap V2 Factory workload, 142x faster than The Graph on the same test. See the full benchmark methodology. Fast sync at this layer is what makes everything downstream cheap, because a schema change means re-syncing in hours rather than weeks.

Query Latency: The Half Nobody Benchmarks

HyperIndex processes events into Postgres and serves them through an auto-generated GraphQL API on your own endpoint. Your reads hit a relational database provisioned for your indexer, not a shared gateway. That is what keeps read latency predictable as request volume grows.

The Hasura-powered endpoint supports the full filter and ordering syntax your users need. A dashboard showing a specific address’s trade history looks like this:

query AddressActivity($address: String!) {
  Trade(
    where: { maker: { _eq: $address } }
    order_by: { blockNumber: desc }
    limit: 100
  ) {
    id
    maker
    amountIn
    amountOut
    blockNumber
  }
}

Full query reference at docs.envio.dev/docs/HyperIndex/navigating-hasura.

For traffic in the millions of requests, Envio Cloud production plans are sized for high-throughput indexers, with zero-downtime deployments so a new indexer version promotes to the production endpoint without consumers seeing a change. Dedicated plans add custom SLAs and SQL access alongside GraphQL when an ORM or direct queries fit your backend better.

You Keep the Data Model

The reason teams hesitate to leave subgraphs is the rebuild. With HyperIndex, the schema migration is close to copy-paste, the migration guide covers the differences, and handlers move from AssemblyScript to plain TypeScript.

Katana migrated two production SushiSwap subgraphs from The Graph with the data model carried over entity-for-entity, all 23 entity types, tracking the Uniswap V3 factory, position manager, and every pool it deploys. Same entities, same shape. Their SushiSwap V3 indexer synced in about two hours. The Sushi staker was done in under 20 seconds. Read the full case study on our blog.

The Indexer Migration Validator compares both endpoints field by field, so you can prove parity before switching traffic.

Where to Start

If your subgraph is hitting its ceiling, the path is short. Scaffold an indexer, port the schema, migrate your handlers and config across, following the migration guide, then point the migration validator at both endpoints:

pnpx envio init

Envio also offers white-glove migration support for production teams. Reach out on Discord.

Frequently Asked Questions

Why Is My Subgraph Slow at High Request Volume?

Usually for two unrelated reasons. Historical sync is slow because data arrives over paginated RPC-style reads. Query latency is variable because reads route through shared serving infrastructure sized for the network rather than your traffic. Diagnose which one you are hitting before paying to fix the wrong one.

Can a HyperIndex Endpoint Handle Millions of GraphQL Requests?

HyperIndex serves queries from a dedicated Postgres database behind your own GraphQL endpoint, and Envio Cloud production plans are sized for high-throughput workloads, with Dedicated plans adding custom SLAs. The endpoint is yours, not a shared gateway, so read performance does not degrade when your app gets busy.

Do I Lose My Subgraph Schema When Moving to HyperIndex?

No. The schema migration is close to copy-paste, with small differences like dropping the @entity directive. Katana's SushiSwap V3 migration carried 23 entity types across without schema redesign, and the open-source Indexer Migration Validator verifies that both endpoints return matching data before you cut over.

Does Fast Indexing Actually Improve My API Response Times?

Not directly. Anyone who tells you otherwise is skipping a step. Indexing speed sets data freshness and backfill cost. Response times depend on the serving layer, which for HyperIndex is your own Postgres-backed GraphQL endpoint rather than a shared gateway. You need both halves to scale.

What Envio Cloud Plan Do I Need for High-Traffic Production Workloads?

For production workloads, use one of the paid plans rather than the dev tier. Paid production plans include zero-downtime deployments, higher limits, and higher query rate limits. Dedicated plans additionally include custom SLAs, isolated infrastructure, and SQL access alongside the GraphQL endpoint. Current pricing and plan details can be found in our docs.

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 💌

Website | X | Discord | Telegram | GitHub

Originally published at https://docs.envio.dev on June 26, 2026.

Why Blockchain Indexers Hit Rate Limits at Scale

ENVIO — Fri, 26 Jun 2026 00:00:47 GMT

TL;DR

Throttling is a symptom of the per-request RPC model. Providers meter calls because every eth_getLogs request costs them node time, so traffic spikes get rate-limited.
HyperSync replaces thousands of RPC calls with one filtered bulk query. High traffic produces fewer, larger reads instead of a flood of small ones, so the rate-limit problem does not arise in the same form.
For chains with native HyperSync coverage, HyperIndex developers do not need to manage RPCs or rate limiting at all.
If a configured data source degrades, HyperIndex fails over to a fallback within seconds and recovers to the primary automatically.

Ask developers why they are shopping for a new blockchain data provider, and a recurring answer is throttling. The dashboard spikes, the app gets popular for an afternoon, and the data layer starts returning 429s exactly when the data matters most.

This blog explains why that happens, why HyperSync’s architecture sidesteps it, and what the behaviour looks like at production scale.

Why Providers Throttle in the First Place

The standard data path is JSON-RPC. Every read is a request, every request hits a node, and nodes are expensive to run. Providers meter usage per request and enforce rate limits to protect shared infrastructure. That is a reasonable response to the economics of RPC. It is also why high traffic and throttling arrive together, the busier your app gets, the more requests you issue, and the closer you run to the ceiling.

The deeper problem is that RPC makes you ask for data in tiny pieces. Reading a year of events for one contract means paginating eth_getLogs over block ranges, thousands of calls for one logical question. Your "high traffic" is mostly overhead imposed by the interface.

What HyperSync Does Differently

HyperSync is Envio’s high-performance data retrieval layer, built in Rust as an alternative to JSON-RPC. You describe what you want once, a block range, a filter across logs, transactions, traces, or blocks, and a field selection that returns only the columns you need. The engine streams the result back.

The shape of the load changes completely. One HyperSync query does the work of the thousands of RPC calls it replaces, and field selection keeps each response small. Under high traffic, you issue fewer, larger reads, which is the access pattern the engine is built for. Scanning Arbitrum for sparse log data takes 2 seconds over HyperSync, a task that can take hours to days over RPC.

This is also why we can make a claim that no RPC-based indexer makes, for chains with native HyperSync coverage, HyperIndex uses it as the default data source, and developers do not additionally need to worry about RPCs or rate limiting. The problem is removed at the data layer rather than managed in application code.

What It Looks Like at Production Scale

The Polymarket reference indexer processes over 6 billion events on Polygon. ChainDensity runs chain-wide scans, the heaviest read pattern there is, and returns density maps in seconds. Every one of those workloads would be a sustained rate-limit fight on a per-request provider.

For repeatable numbers, the Sentio independent benchmarks measured HyperIndex processing 100,000 Ethereum blocks with metadata extraction in 7.9 seconds, against 10 minutes for The Graph on the same workload. The full case suite is in the sentio-benchmark repo, and the open-indexer-benchmark repo gives you templates to run the same tests yourself.

And When Something Upstream Does Fail

No data source has perfect uptime, so the honest version of “does not throttle” includes what happens when a source degrades. HyperIndex ships multi-data-source recovery. Indexers configured with a fallback fail over automatically when a primary stops returning new blocks, and the indexer attempts to recover to the primary 60 seconds later without a restart. The source selection logic is built for resilience, and data-source activity surfaces in the Prometheus metrics before downstream consumers notice.

Throttling resilience is an architecture property. Failure resilience is a framework property. You want both.

Test It on Your Heaviest Query

The fastest way to test the claim is to throw your worst read at it. Build a filtered query visually at builder.hypersync.xyz, or scan a chain from your terminal with zero setup:

pnpx logtui aave arbitrum

If you would rather have the full framework, schema, handlers, and a GraphQL API on top of the same engine, scaffold an indexer, and deploy it to Envio Cloud:

pnpx envio init

Frequently Asked Questions

Does HyperSync Rate-Limit Queries During High Traffic?

HyperSync is built for bulk retrieval, so the request-flood pattern that triggers rate limiting on RPC providers does not occur in the same form. One filtered query replaces the thousands of paginated RPC calls it would otherwise take, and for chains with native HyperSync coverage, developers do not need to manage RPCs or rate limiting.

Why Do RPC Providers Throttle During Traffic Spikes?

Because the JSON-RPC model prices and provisions per request. Every read hits node infrastructure, so providers enforce rate limits to protect shared capacity, and those limits bind exactly when your application is busiest. The interface also forces large reads to be split into thousands of small paginated calls, which further inflates request volume.

What Is the Largest Workload HyperSync Has Handled in Production?

At the time of writing this, the public reference is the Polymarket indexer, which processes over 6 billion events on Polygon.

What Happens to My Indexer if a Data Source Goes Down Mid-Spike?

HyperIndex fails over to a configured fallback source when a primary stops returning new blocks and attempts to recover to the primary 60 seconds after the primary returns, with no restart required. The source selection logic is built for resilience, and degradation surfaces in the standard Prometheus metrics endpoint.

How Do I Benchmark HyperSync Against My Current Provider?

Reproduce your heaviest production query in the visual query builder at builder.hypersync.xyz, or run the open benchmark suite at the open-indexer-benchmark repo. Both are public.

Build With Envio

Subscribe to our newsletter

Originally published at https://docs.envio.dev on June 26, 2026.

Migrating From The Graph Without a Rewrite

ENVIO — Fri, 26 Jun 2026 00:00:26 GMT

TL;DR

Migrating from The Graph to HyperIndex is not an AssemblyScript rewrite. AssemblyScript is a subset of TypeScript, so your event parsing and business logic copy across verbatim.
Three things change in a well-defined way. subgraph.yaml becomes config.yaml, your schema sheds the @entity decorator, and handlers swap Entity.save() for context.Entity.set() with async/await.
HyperIndex supports multichain in a single config, full TypeScript with any npm package, and framework-level reorg handling with no handler code required.
In the Sentio Uniswap V2 Factory benchmark (April 2025), HyperIndex completed in 8 seconds. The Graph took 19 minutes, 142x slower on the same workload.
The Indexer Migration Validator CLI diffs entity state between your subgraph endpoint and your HyperIndex endpoint before you cut over.

Most teams stay on The Graph longer than they want to because of one belief, that moving means rewriting every handler in a new language. It does not.

AssemblyScript is a subset of TypeScript. The event parsing, the conditional logic, the arithmetic, and the helper functions are all valid TypeScript, and they carry across directly. What changes when you migrate to HyperIndex is a small, well-defined set of API calls. Not the logic. The wiring.

This is not theoretical. Katana migrated two production SushiSwap subgraphs exactly this way, entity-for-entity, and now serves its app from Envio. The walkthrough below uses before-and-after code from the canonical migration guide, and ends with what that migration looked like in production.

Prefer an assistant-led migration?

HyperIndex ships AI-friendly docs and a guided AI migration workflow that works in both Cursor and Claude Code. The steps below are the same either way, this is what the assistant is doing under the hood.

What actually changes (and what does not)

It helps to be specific about the surface area before touching any code.

Carries across without change:

Your event parsing logic
All conditional logic and arithmetic
Helper functions that do not use @graphprotocol/graph-ts types directly
Your entity model, the fields, the relationships, and the ID conventions

Changes during migration:

ConcernThe GraphHyperIndexConfig formatsubgraph.yamlconfig.yamlSchema@entity on every typedecorator removedHandler registrationContractName.EventName.handler(...)indexer.onEvent(...)Entity writesEntity.save()context.Entity.set(...)Entity readssynchronous Entity.load(id)await context.Entity.get(id)Imports@graphprotocol/graph-ts"envio" generated typesTransaction fieldsavailable by defaultopt-in via field_selection

Every row is a mechanical swap. The handler body, the part that is the most work to write and the hardest to get right, is the part that does not change.

Step 0: bootstrap the project

Start by generating a fresh HyperIndex project shell using your existing contract addresses, ABIs, and events as the source of truth:

pnpx envio init

Follow the prompts. The init generates config.yaml, schema.graphql, and handler stubs. At any point during the migration, validate your changes with:

pnpm envio codegen   # validate config + schema, regenerate types
pnpm dev             # run the indexer locally

Step 1: subgraph.yaml to config.yaml

The config conversion is a restructure. HyperIndex consolidates contracts and chains into two top-level sections.

The Graph, subgraph.yaml:

specVersion: 0.0.4
schema:
  file: ./schema.graphql
dataSources:
  - kind: ethereum/contract
    name: PositionManager
    network: mainnet
    source:
      abi: PositionManager
      address: "0xbD216513d74C8cf14cf4747E6AaA6420FF64ee9e"
      startBlock: 21689089
    mapping:
      kind: ethereum/events
      apiVersion: 0.0.7
      language: wasm/assemblyscript
      entities:
        - Position
      abis:
        - name: PositionManager
          file: ./abis/PositionManager.json
      eventHandlers:
        - event: Transfer(indexed address,indexed address,indexed uint256)
          handler: handleTransfer
        - event: Subscription(indexed uint256,indexed address)
          handler: handleSubscription

HyperIndex, config.yaml:

name: uni-v4-indexer
contracts:
  - name: PositionManager
    abi_file_path: ./abis/PositionManager.json
    events:
      - event: Transfer(address indexed from, address indexed to, uint256 indexed id)
      - event: Subscription(uint256 indexed tokenId, address indexed subscriber)
chains:
  - id: 1
    start_block: 21689089
    contracts:
      - name: PositionManager
        address: "0xbD216513d74C8cf14cf4747E6AaA6420FF64ee9e"

One thing that trips teams up consistently, HyperIndex uses chains: (not networks:).

Transaction and receipt fields

In a subgraph, you opt into receipt data with receipt: true in subgraph.yaml. In HyperIndex, receipt-level fields like status and gasUsed are accessed via field_selection in config.yaml:

field_selection:
  transaction_fields:
    - hash
    - status
    - gasUsed

Note that event.transaction.hash is not available by default, add it to transaction_fields before referencing it in a handler.

Step 2: schema, near copy-paste

Your existing schema.graphql carries across almost unchanged. The only required edit is removing the @entity decorator from every type.

The Graph:

type Transfer @entity {
  id: ID!
  from: String!
  to: String!
  amount: BigInt!
  timestamp: Int!
}

HyperIndex:

type Transfer {
  id: ID!
  from: String! @index
  to: String!
  amount: BigInt!
  timestamp: Int!
}

Field types, ID! primary keys, @derivedFrom relations, nullable vs non-nullable, and enums all carry across unchanged. After any schema edit, run pnpm envio codegen to regenerate the typed bindings before touching handler code.

Step 3: handlers, four API changes

This is the step teams worry about most, and it is the smallest. Here is the same handler in both frameworks, using the Uniswap V4 Subscription event:

The Graph (AssemblyScript):

export function handleSubscription(event: SubscriptionEvent): void {
  const subscription = new Subscribe(
    event.transaction.hash.toHex() + "-" + event.logIndex.toString()
  );
  subscription.tokenId = event.params.tokenId;
  subscription.subscriber = event.params.subscriber.toHexString();
  subscription.logIndex = event.logIndex;
  subscription.blockNumber = event.block.number;
  subscription.save();
}

HyperIndex (TypeScript v3):

import { indexer } from "envio";

indexer.onEvent(
  { contract: "PositionManager", event: "Subscription" },
  async ({ event, context }) => {
    context.Subscribe.set({
      id: `${event.transaction.hash}_${event.logIndex}`,
      tokenId: event.params.tokenId,
      subscriber: event.params.subscriber,
      logIndex: event.logIndex,
      blockNumber: event.block.number,
    });
  },
);

The token ID parsing, the field assignments, and the ID construction are all identical. What changed is the import, the handler registration, entity.save() becoming context.Subscribe.set(), the async function signature, and .toHexString() becoming unnecessary because addresses arrive as strings.

The one rule that catches every team

Entities returned by context.Entity.get() are read-only. When updating an existing entity, always spread the existing object and override fields:

const token = await context.Token.get(event.params.to);
if (token) {
  context.Token.set({
    ...token,
    balance: token.balance + event.params.value,
  });
}

Factory contracts (dynamic data sources)

Where The Graph uses templates: in subgraph.yaml, HyperIndex uses indexer.contractRegister:

indexer.contractRegister(
  { contract: "Factory", event: "PairCreated" },
  ({ event, context }) => {
    context.chain.Pair.add(event.params.pair);
  },
);

Validating the migration

After running locally against a block range, use the Indexer Migration Validator CLI to diff entity state between your subgraph endpoint and your HyperIndex endpoint. It generates entity configs automatically from your GraphQL schema and gives field-level analysis of any discrepancies. Running both in parallel over the same block range is the fastest way to confirm correctness before cutting over production traffic.

GraphQL queries

HyperIndex uses standard GraphQL. The Graph uses a custom dialect with some non-standard filter and ordering syntax. For queries that use Graph-specific syntax, the Query Conversion Guide covers the differences. For backwards compatibility, Envio’s subgraph-compatible endpoint accepts The Graph’s query syntax. Katana’s production migration ran against this endpoint, allowing their existing app queries to work without changes while they transitioned to the native endpoint.

What it looks like in production

Katana migrated two production SushiSwap subgraphs from The Graph to Envio, carrying the data model across entity-for-entity, all 23 entity types, tracking the Uniswap V3 factory, the position manager, and every pool it deploys. Same entities, same shape.

SushiSwap V3 indexer: 11,473,382 events synced in about two hours
Sushi staker indexer: 68,201 events synced in under 20 seconds

Full case study: How Katana migrated SushiSwap data from The Graph to Envio.

Why bother, the performance case

From the Sentio Uniswap V2 Factory benchmark (April 2025):

IndexerTimevs HyperIndexEnvio HyperIndex8 secondsbaselineSubsquid (SQD)2 minutes15x slowerThe Graph19 minutes142x slowerPonder21 minutes157x slower

The pattern holds every time. Your logic is already TypeScript, so it moves. The wiring changes in a handful of well-defined places, the validator confirms the output matches your old subgraph, and you cut over. That is the whole migration.

Get started

Frequently asked questions

Is the AssemblyScript-to-TypeScript conversion really just a copy-paste?

For pure logic functions, yes. AssemblyScript is a subset of TypeScript, so any function that does not import from @graphprotocol/graph-ts is valid TypeScript and carries across without changes. The parts that require translation are the imports, the entity save calls, the entity load calls (synchronous becomes async/await), and the handler registration syntax. The event parsing logic, the business logic, and the arithmetic are identical.

Do I need to handle reorgs in my HyperIndex handlers?

No. HyperIndex handles reorgs at the framework level by tracking entity state history for every unfinalized block and rolling back automatically. You write forward-only handler logic and the framework manages rollback.

Can I keep my existing GraphQL queries after migrating?

Most queries carry across without change. Envio’s subgraph-compatible endpoint accepts The Graph’s query syntax as a drop-in, so existing app queries keep working while you transition to the native endpoint. The Query Conversion Guide covers the syntax differences.

How long does a subgraph migration take?

For a single-contract subgraph with straightforward handlers, the mechanical migration is typically a few hours. Katana migrated two production SushiSwap subgraphs with entity-for-entity parity and had both syncing on Envio within a working session. For multi-subgraph setups, the consolidation into one TypeScript codebase adds time but reduces ongoing maintenance.

What is the Indexer Migration Validator and how do I use it?

The Indexer Migration Validator is an open-source CLI tool that diffs entity state between a subgraph endpoint and a HyperIndex endpoint. It generates entity configs from your GraphQL schema automatically, runs both endpoints over the same block range in parallel, and produces field-level analysis of any discrepancies.

Can I run multiple chains in one HyperIndex indexer?

Yes. A single config.yaml declares all chains under a chains: array. Multichain indexing is the default in V3, with no opt-in required. Each chain-specific entity ID should include event.chainId to prevent collisions across chains.

Build With Envio

Subscribe to our newsletter

Just-in-Time Indexing: Using Agents to Answer Onchain Questions

ENVIO — Wed, 03 Jun 2026 00:00:02 GMT

Just-in-time indexing is a way of using an AI agent to answer one-off questions about onchain data without maintaining permanent infrastructure or finding a pre-indexed data point. Rather than building an indexer in advance and keeping it running, the dataset is built on demand when a question comes up, read once, and deleted afterward.

How it Works

One user, Michael K from Curve Finance, uses it for ad hoc analysis of pool activity. The flow starts with a plain-language prompt to Claude, for example: “Use Envio to parse all the trades from this pool.”

Claude, using Envio’s tooling, generates the indexer: the config, schema, and event handlers, scoped to the specific contract and events in the question. It deploys to Envio’s free development plan cloud service with envio-cloud, the CLI, and the indexer backfills from scratch. After 5 to 10 minutes, the data is ready to query. Once the researcher has pulled what they need, they delete the indexer.

“One of the simplest ways to get large datasets of onchain data for our research purposes.” — Michael K, Researcher at Curve Finance

Why the Free Tier Covers it

The workflow runs on Envio’s free hosted cloud tier. The requests are one-off, so a single repo is enough: the agent manages it and deploys each question as a branch. A backfill of 5 to 10 minutes is acceptable for ad hoc work, where the alternative is building a pipeline by hand.

The Pattern

Traditional indexing requires deciding what data is needed, building the pipeline, and then querying it, which limits the user to questions planned for in advance. Just-in-time indexing reverses the order: the question comes first, and the dataset is built to answer it.

This works because backfilling takes minutes rather than days, and because an agent can stand up the indexer from a natural-language prompt without anyone writing config by hand. The same pattern applies to any agent or user asking one-off onchain questions.

“We use Envio regularly to parse all kinds of data from all kinds of contracts across dozens of chains.” — Michael K, Researcher at Curve Finance

Build With Envio

Subscribe to our newsletter 💌

Originally published at https://docs.envio.dev on June 3, 2026.

Envio Developer Update May 2026

ENVIO — Fri, 29 May 2026 00:00:22 GMT

May was our biggest month yet. After five months of alpha and release candidates, HyperIndex V3 officially shipped, production-ready, faster, and the foundation for everything we build next. Alongside it we went live on Katana, published four large-scale case studies (Polymarket, Revert Finance, Privacy Pools, and Katana’s SushiSwap migration off The Graph), and shipped a stack of deep-dive guides on HyperSync, production reliability, and building onchain with AI.

We also joined Monad’s Devrel livestream to talk HyperIndex, started rolling out HyperSync rate limits ahead of paid plans, and confirmed our ETHConf New York sponsorship in June.

Let’s dive in!

HyperIndex V3 Is Here

After five months of alpha, HyperIndex V3 officially shipped. This is the biggest release in the framework’s history, a full modernisation that bundles five months of work into a stable, production-ready release. A unified handlers API, ESM with top-level await, a purpose-built testing framework, 3x faster historical sync, Solana support, ClickHouse as a second storage backend, and a much smaller package. With V3 we are back to following SemVer and set up for the next year of features.

To upgrade an existing project, follow the Migrate to V3 guide. For the complete rundown, see What’s New in V3.

Unified Handlers API

All handler registrations now flow through a single indexer value. Contract-specific exports are replaced by indexer.onEvent, indexer.contractRegister, and indexer.onBlock.

import { indexer } from "envio";

indexer.onEvent(
  {
    contract: "ERC20",
    event: "Transfer",
    wildcard: true,
    where: ({ chain }) => ({
      params: [
        { from: chain.Safe.addresses },
        { to: chain.Safe.addresses },
      ],
    }),
  },
  async ({ event, context }) => {
    // Handler logic
  },
);

3x Faster Historical Backfill

We added chunking logic to request events across multiple ranges at once, removed overfetching for contracts with a much later start block, and sped up dynamic contract registration.

25k events per second is now standard.

A Purpose-Built Testing Framework

HyperIndex now ships its own testing framework powered by createTestIndexer(). You write tests against the same indexer that runs in production, with no database, no Docker, and no manual mock wiring. It integrates with Vitest, includes snapshot testing out of the box, and gives you three ways to feed events (auto-exit, explicit block range, or simulate).

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

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

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

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

ESM and Top-Level Await

We migrated HyperIndex from CommonJS to ESM. That unlocks the latest versions of libraries that dropped CommonJS long ago, and lets you use await directly at the top of your handler files.

Solana Support (Experimental)

HyperIndex now supports Solana with RPC as a source. Spin up a Solana project with pnpx envio init svm. Solana exposes its block-stream handler as indexer.onSlot rather than onBlock, matching Solana's slot-based model.

ClickHouse as an Additional Storage Backend (Experimental)

HyperIndex can now run with multiple storage backends side by side. Postgres remains the primary database, and entities can additionally be written to a ClickHouse database that is restart and reorg resistant. Enable it in config.yaml and route each entity via the @storage directive in schema.graphql.

storage:
  postgres: true
  clickhouse: true

Envio Cloud supports ClickHouse on the Dedicated Plan.

A Much Smaller Package and Bun Support

You can run HyperIndex on Bun with bun --bun envio dev, and we removed the runtime ReScript compiler from the published package by eliminating dynamically generated ReScript code.

The envio npm package shrank from 141MB to 53MB.

Agentic Mode in envio init

envio init now ships an agentic mode. When an AI coding assistant runs the command, it produces an AI-readable guiding prompt instead of a TTY error, so the agent knows exactly how to scaffold an indexer end to end.

Welcome to Envio Indexer! Let's set up an indexer that will become a reliable blockchain backend you trust, love, and own.

Leave the rest to your favorite agent:

  1. Prompt the user for the project intent if it is missing from context (what should the indexer track and surface?).
  2. Determine the chain, contract, and addresses needed to produce that result. Use web search or block-explorer tool calls when the user hasn't supplied them.
  3. To continue, call:

       pnpx envio init contract-import explorer \
         -n ${indexer-name} \
         -c ${address} \
         -b ${chainId} \
         --single-contract \
         --all-events \
         -d ${directory}

Then `cd ${directory}` and run `pnpm test`. Don't hand the project off yet -- keep iterating on the indexer with a TDD loop (extend tests, run them, fix handlers) until the user's goal is met.

See the full release notes

Star us on GitHub ⭐

Envio is Live on Katana

We launched production-grade indexing on Katana, the DeFi-first chain built where liquidity concentrates and real yield flows back to users. Developers can now access real-time and historical onchain data on Katana, up to 2000x faster than RPC.

Easy, fast, and fully customisable.

Original post on X: https://x.com/katana/status/2056389958303441051

Indexing 4 Billion Polymarket Events

We replaced Polymarket’s eight production subgraphs, four years of fragmentation across separate AssemblyScript codebases on The Graph, with a single HyperIndex indexer written in TypeScript. Over 4 billion events synced in 6 days on Polygon.

The unlock is handler merging. A shared contract event like ConditionalTokens.PositionSplit previously fired across three or four separate subgraphs. In the unified indexer, one handler fires once and updates open interest, activity, and PnL together. That is 25+ entity types behind a single GraphQL endpoint, and one deployment to maintain instead of eight. The full indexer is open source as a reference for any team migrating from The Graph.

Read the case study: https://docs.envio.dev/blog/polymarket-hyperindex-case-study

Revert Finance Fixed 2 Years of Unsynced PancakeSwap V3 Data

Revert Finance builds analytics and management tools for AMM liquidity providers. Their PancakeSwap V3 subgraph on BNB Smart Chain had been stuck at 70% sync for over two years, unable to reach chain head, because the chain’s throughput outpaced what RPC-based indexing could sustain.

We built a HyperIndex indexer covering the full PancakeSwap V3 contract surface on BNB Smart Chain. 1,711,569,200 events synced to 100% in 10 days.

Read the case study: https://docs.envio.dev/blog/revert-finance-pancakeswap-bnb-hyperindex

Privacy in Public, Indexing Privacy Pools

Privacy Pools is a privacy primitive co-authored by Vitalik Buterin that pairs a zero-knowledge proof of pool membership with an off-chain compliance layer. We indexed every deposit, withdrawal, ragequit, ASP root update, and relayer fee across all 21 live pools on four chains (Ethereum, Optimism, BSC, and Arbitrum) with a single HyperIndex indexer using dual Postgres and ClickHouse storage.

Full multichain sync to head in roughly 30 seconds, and 91% of withdrawals use the privacy-preserving relayed path. The full stack, including the indexer, the analytics queries, and the BI report generator, is open source under MIT license. It is a great example of multichain coverage and an analytics-grade columnar store as first-class features.

Read the case study: https://docs.envio.dev/blog/privacy-in-public-case-study

Katana Migrates SushiSwap Off The Graph

Katana migrated two production subgraphs, SushiSwap V3 and the Sushi staker, from The Graph to Envio HyperIndex without disrupting the app surfacing the data. Katana’s existing subgraph-style queries kept working through Envio’s subgraph-compatible endpoint, and for the full GraphQL feature set its app needed, Katana moved onto Envio’s native endpoint, with our team supporting the move directly.

SushiSwap V3 synced 11,473,382 events in about two hours, and the Sushi staker synced 68,201 events in under 20 seconds.

Read the case study: https://docs.envio.dev/blog/case-study-katana-sushiswap

What is HyperSync?

Reading onchain data over standard JSON-RPC breaks down the moment you need fast, filtered, or multichain historical data. HyperSync is our high-performance data retrieval layer built to fix exactly that. It is written in Rust, uses optimised binary encoding and parallel fetching, and exposes a single query interface across every supported chain.

Scanning Arbitrum for sparse log data takes 2 seconds with HyperSync, up to 2000x faster than RPC. HyperSync is the engine behind HyperIndex. Client libraries are available for TypeScript, Python, Rust, and Go. This blog covers what it is, how it works, and how to use it in your own application.

Learn more here: https://docs.envio.dev/blog/what-is-hypersync

Production Indexer Reliability with HyperIndex

Speed wins benchmarks, but reliability is what keeps an indexer running for years. This post walks through the four reliability guarantees HyperIndex provides at the framework level, so any indexer built on it inherits them without writing operational code. Those guarantees are built-in reorg handling with automatic rollback, restart-resistant operation, HyperSync data validation, and multi data-source recovery.

Reorgs are handled automatically by tracking entity state history for every unfinalized block and rolling back without any custom handler logic. Multi data-source recovery fails over to a fallback within seconds and recovers to the primary 60 seconds later. Observability comes through a semver-stable Prometheus endpoint.

More here: https://docs.envio.dev/blog/production-indexer-reliability-hyperindex

Why AI Agents Acting Onchain Need an Indexer

SQL warehouses let agents ask. Indexers let them act. An agent reading raw RPC hits four walls quickly, namely reorgs, no schema, low throughput, and per-chain quirks at multichain scale. A SQL warehouse fronted by an LLM solves the read side, but an agent acting onchain needs to build, deploy, and own new data pipelines mid-session, not just query existing ones.

This post makes the case for a programmable indexer over a query layer, backed by the docs MCP server, the auto-discovered .claude/skills/ directory, and the GitHub-native deploy flow.

One prompt, roughly 20 seconds, 400,000 events indexed on Monad.

Read the full breakdown: https://docs.envio.dev/blog/ai-agents-acting-onchain-indexer

AI-Assisted Subgraph Migration to HyperIndex with Claude

The hardest part of moving off The Graph has always been the AssemblyScript rewrite. With the docs MCP server and the dedicated migrate-from-subgraph skill shipped in every HyperIndex project, Claude can handle the AssemblyScript-to-TypeScript translation end to end while a developer reviews the diff, runs the tests, and ships the indexer.

This guide walks the full workflow on a real surface area, anchored to the open-source Polymarket reference. A migration that used to take weeks becomes a one or two day exercise.

Read the full tutorial: https://docs.envio.dev/blog/ai-subgraph-migration-hyperindex-claude

Build an AI-Powered Onchain App with HyperIndex and Claude

A practical, end-to-end walkthrough of building a multichain HyperIndex indexer with Claude as a pair programmer. It covers wiring up the docs MCP server, scaffolding the project, making it multichain, writing the schema and handlers, running locally, and deploying to Envio Cloud through the GitHub-native flow.

Every command is reproducible against the current release, and the patterns come straight from the public Polymarket reference indexer. With Claude driving, you can go from a blank project to a deployed, queryable indexer in minutes.

More here: https://docs.envio.dev/blog/ai-onchain-app-hyperindex-claude

Migrating from Ponder to Envio

Both Ponder and HyperIndex are TypeScript-first and expose a GraphQL API, so migration is mostly mechanical translation. Three things change. ponder.config.ts becomes config.yaml, ponder.schema.ts becomes schema.graphql, and event handlers adapt to the HyperIndex entity API. This guide walks all three steps end to end, with every code block taken from the official migration reference.

Up to 157x faster historical sync via HyperSync, with multichain support by default.

For teams looking for a clear path forward, our team supports the migration end to end, from planning the rewrite to getting the indexer live on Envio Cloud.

Read the full tutorial: https://docs.envio.dev/blog/migrate-from-ponder-to-envio

HyperSync Rate Limits

Throughout May we have been rolling out HyperSync rate limits more aggressively. Limits ratchet down gradually so you get the smoothest possible transition to paid plans without disruption to your services. Keep an eye out for 429 rate limit exceeded errors.

If you are already on a paid HyperSync plan, your normal plan limits apply and no action is needed. If you are not on a paid plan yet, get sorted as soon as possible by opening a Discord ticket to arrange one with the team, or by picking a plan directly.

This affects all HyperSync users and anyone self-hosting HyperIndex with a HyperSync token. Envio Cloud deployments are not affected.

Polymarket’s Top Traders Run on Indexed Data

Co-founder Jonjon Clark published a data-driven series profiling the top 100 Polymarket traders by realised PnL, and the deeper he digs, the clearer it becomes that these operations live or die on fast, real-time access to onchain data, exactly the workload HyperIndex and HyperSync are built for. Here are a few that stand out.

The 95% Win Rate Trader

$23.6M in realised PnL and a 95.4% win rate. It runs a live NBA model that prices games faster than the order book, pre-positions on the cheap side before tip-off, and rides the eventual winner to oracle redemption.

Read the thread

The 15-Minute Bitcoin Loop Trader

7.6 million fills across 32,021 markets in 111 days, about one fill per second, netting $2.38M. It posts resting bids on both sides of Polymarket’s 15-minute BTC binaries and captures the spread off retail flow, completely indifferent to which way Bitcoin moves.

Read the thread

The UMA Gap Trader

Number 26 on the leaderboard with $8M in lifetime realised PnL. Its cleanest mechanism is the settlement sweep, buying near-par winning tokens in the gap between when a result is known and when the UMA oracle finalises payout, for a 98.2% win rate across more than 4,000 positions.

Read the thread

Envio x Monad’s Devrel Livestream

Co-founder Denham joined Monad’s Devrel Livestream to chat HyperIndex on Monad, Monskills, and how to vibecode your way to a production indexer.

Missed it live? Catch the full recording on X.

Current & Upcoming Events & Hackathons

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

Playlist of the Month

▶ Open Spotify

Build With Envio

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 💌

Originally published at https://docs.envio.dev on May 29, 2026.

How Katana Migrated SushiSwap Data from The Graph to Envio

ENVIO — Thu, 28 May 2026 00:00:26 GMT

TL;DR

Katana migrated two production subgraphs, SushiSwap V3 and the Sushi staker, from The Graph to Envio HyperIndex while keeping its existing data model intact.
Katana’s existing subgraph-style queries ran against Envio’s subgraph-compatible endpoint, and for the full GraphQL feature set its app needed, Katana moved its queries onto Envio’s native endpoint. The data model itself carried over unchanged.
Katana forked the indexer and deployed it on Envio Cloud, and the Envio team assisted with the backend configuration, the subgraph-compatible endpoint, and the cache.

Migrating your data infrastructure from one provider to another is rarely simple, mostly because of everything that has to change around it. Katana is a DeFi network, and its app surfaces SushiSwap data such as V3 pools, swaps, fees, positions, and staking to its users. That data was served by two production subgraphs running on The Graph. Katana wanted to move this data layer to Envio HyperIndex without disrupting the apps that depend on it.

Because this was a live production system rather than a greenfield build, the priority was continuity. The existing queries had to keep working and the data had to stay correct. This case study walks through how the migration came together, from the subgraph-compatible endpoint that kept Katana’s queries running to the hands-on support that handled the rest.

The Challenge: Moving a Production Data Layer Without Disrupting It

Katana’s existing subgraph queries were wired into production and had to keep working. Data quality and expected behaviour had to be preserved. And it had to be efficient, a swap, not a multi-week infrastructure project. For DeFi data, correctness and uptime were non-negotiable, because their application and users depended on it.

During development, the team also noticed the existing subgraph data often running around three blocks behind the chain head. For user-facing DeFi data, that kind of freshness gap matters.

The Solution: A Subgraph-Compatible Path off The Graph

The migration came down to two things. Envio’s tooling fit the setup Katana already had, and the support was there at every step.

The foundation was schema parity. The HyperIndex deployment reproduces the original Sushi V3 subgraph entity-for-entity, all 23 entity types, tracking the Uniswap V3 factory, the position manager, and every pool it deploys. Same entities, same shape, so Katana did not have to redesign its data or rebuild against a new model.

Envio exposes two GraphQL endpoints, a subgraph-compatible one that runs existing subgraph-style queries as a drop-in, and a native one with the full query feature set. Katana’s standard queries ran against the compatible endpoint, and for the full feature set its app needed, Katana standardised on the native endpoint, with the Envio team working through the move alongside them.

Contracts Indexed

The SushiSwap V3 indexer runs on Katana mainnet:

The process was a fork-and-deploy flow. Katana forked the indexer, connected it to Envio Cloud, and deployed, while the Envio team handled the backend configuration, set up the subgraph-compatible endpoint, and managed the caching for the deployment. The team could also validate on a fast instance first. With the most RPC-heavy fields turned off, backfill ran about ten times faster, so they could confirm everything looked right before running the full indexer with every field populated.

The Envio team set up the endpoints, configured the caching, and worked through the query migration directly with Katana’s engineers.

The Results

Katana migrated both production subgraphs, SushiSwap V3 and the Sushi staker, from The Graph to Envio. Its existing queries kept working through the subgraph-compatible endpoint, so the app did not need a rewrite. A third subgraph, a pre-staking one with deprecation already planned, was left as-is by design.

The SushiSwap V3 indexer on Envio, fully synced (11,473,382 events) in about two hours.

The Sushi staker subgraph, fully synced (68,201 events) in under 20 seconds on Envio.

With the migration complete, both SushiSwap indexers run on Envio Cloud, serving Katana’s app through the same queries it used before. Where the original subgraph had drifted a few blocks behind, the new indexer indexes in real time at the chain head.

“The comprehensive resources and proactive support provided by the Envio team made our migration from The Graph remarkably smooth and efficient.”

Kirienzo, Senior Software Engineer, Katana

Before and After the Migration

What Carries Over When You Move Off The Graph

A subgraph rarely sits on its own. Queries, dashboards, and app code are all built against its schema, which is what makes moving it feel risky. The part that carries over cleanly is the data model. Because the HyperIndex indexer reproduced the Sushi V3 subgraph entity-for-entity, Katana did not have to redesign its data or rebuild against a new model. On the query side, Envio gives you a subgraph-compatible endpoint for a drop-in start and a native GraphQL endpoint for the full feature set, and Katana’s app runs on the native one.

For a team considering a migration off The Graph, Envio’s subgraph-compatible endpoint is what makes it a swap rather than a multi-week rebuild.

Relevant Resources

Frequently Asked Questions

What is Katana?

Katana is a DeFi-focused blockchain, designed to concentrate liquidity into a small set of core applications instead of spreading it thin across many. SushiSwap V3 is its spot exchange, which is why the Katana app surfaces SushiSwap data such as pools, swaps, fees, and staking to its users.

What is SushiSwap?

SushiSwap is a decentralised exchange (DEX). Its V3 deployment, the concentrated-liquidity version, is Katana’s spot trading venue, and it generates the pools, positions, swaps, and fees that the migrated subgraphs index.

What did Katana migrate?

Two production subgraphs, the SushiSwap V3 subgraph and the Sushi staker subgraph, both from The Graph to Envio HyperIndex. A third, pre-staking subgraph scheduled for deprecation was not migrated.

What did Katana have to change to migrate?

The data model carried over entity-for-entity, so there was no schema rebuild. Katana’s existing queries ran against Envio’s subgraph-compatible endpoint, and for the full GraphQL feature set its app needed, Katana moved its queries onto Envio’s native endpoint, with the Envio team supporting the move.

What is the subgraph-compatible endpoint?

It is an Envio feature that runs existing The Graph subgraph-style GraphQL queries against a HyperIndex deployment, a drop-in path for standard subgraph queries. For the full GraphQL feature set, Envio also exposes a native endpoint, which is what Katana’s app runs on.

How do I migrate from The Graph to HyperIndex?

HyperIndex handlers are written in TypeScript, and AssemblyScript is a subset of TypeScript, so most handler logic carries across directly. Envio provides a migration guide, a subgraph-compatible endpoint that preserves existing queries, and hands-on migration support.

Build With Envio

Subscribe to our newsletter

Originally published at https://docs.envio.dev on May 28, 2026.