Robinhood Chain vs Ethereum Mainnet: Indexing Requirements

Indexing Robinhood Chain is less about transaction volume than about block count: it handles a similar number of transactions per day as Ethereum mainnet, but spread over roughly 100 times more blocks, with a second, slower L1 clock inside contracts and three levels of finality. An indexer built for Ethereum’s 12-second blocks works on Robinhood Chain only after you rethink per-block overhead, timestamp ordering, reorg windows and trace costs.

This post compares the two chains from an indexer’s point of view, using numbers from building and running a full Robinhood Chain index from block 0. If you are deciding whether to index the chain yourself or use an API, it should help you size the job; the REST API vs RPC vs indexed data post covers that decision directly.

The two chains side by side

Sources: the Robinhood Chain row uses the chain’s own data (Crius /stats, October 24, 2026) and its documentation; Ethereum transaction counts are from public reporting on early 2026 (Techjury, Bitcoin.com News). The Ethereum chain height is the L1 block number Robinhood Chain itself reports (l1BlockNumber ≈ 26,262,000 on October 24).

The striking line is chain height. Robinhood Chain passed three and a half times Ethereum’s entire block history less than six months after its genesis block, and most of those blocks came after the July 2026 mainnet launch.

1. Per-block overhead dominates

On Ethereum, an indexer’s cost scales mostly with transactions and logs: a block is a large unit of work, and there are only 7,200 a day. On Robinhood Chain, the same daily transactions arrive in about 820,000 blocks with roughly three transactions each. Anything you do per block (an RPC round trip, a database transaction, a checkpoint, a reorg check) is done over a hundred times more often.

In practice that means:

• Fetch receipts per block, in parallel. eth_getBlockReceipts returns every receipt in a block in one call. Against a local Nitro archive node we measured 2,200–2,900 blocks per second with 32 parallel workers, which is about 10 hours for the full history at ~91 million blocks. One call per transaction would be several times slower.
• Batch writes across blocks. Committing each block separately would mean ten database transactions a second just to keep up. Our ingester batches decoded events from many blocks per write, and the full replay of 91 million blocks took about five hours (roughly 5,000–6,000 blocks per second with 48 workers against a local archive node).
• Don’t poll for heads. At ~10 blocks per second, eth_blockNumber polling either lags or hammers the node. Subscribe to new heads (or the sequencer feed) and fetch in ranges.

2. Two clocks, and timestamps that collide

Robinhood Chain blocks carry a Unix timestamp with one-second resolution, so about ten consecutive blocks share the same timestamp. Here are 12 consecutive blocks from the public RPC:

block      timestamp    l1BlockNumber  txs
96726799   1792840989   26262178       10
96726800   1792840989   26262178        3
96726801   1792840989   26262178        3
96726802   1792840989   26262178        3
96726803   1792840989   26262178       13
96726804   1792840990   26262178        5
96726805   1792840990   26262178        6
…
96726810   1792840990   26262178        2

Two consequences:

• Order by position, never by time. The canonical order of events is (block, transaction index, log index). Sorting trades by timestamp scrambles everything inside the same second. Crius trade and event ids are built exactly this way (96726525-1-2), and cursors use block and log positions.
• Second-level candles are coarse. A 1-second OHLCV candle on Robinhood Chain aggregates about ten blocks. Sub-second analytics need block numbers, not timestamps.

The second clock is Ethereum’s. Every block also records l1BlockNumber, the latest L1 block the sequencer had seen, and inside contracts block.number returns that L1 number, not the L2 block height. The L1 number above stayed at 26,262,178 across all 12 blocks. That matters for any on-chain logic that counts “blocks”: anti-sniping windows, per-block buy limits and vesting schedules move on Ethereum’s 12-second clock. An indexer that evaluates such rules has to use the right clock. The Uniswap v4 hooks used by launchpads are a common case (Uniswap v4 hooks on Robinhood Chain).

3. Finality comes in three steps

On Ethereum, a block is final after about two epochs, and before that small reorgs are possible but rare. On an Arbitrum-based chain, finality is inherited from Ethereum in stages (Arbitrum docs: finality and reorgs):

1. Soft confirmation (latest). The sequencer has ordered and executed the transaction and published it on its feed. Fast, but a promise from the sequencer, not yet backed by Ethereum.
2. Safe. The batch containing the block has been posted to Ethereum and that L1 block is safe.
3. Finalized. That L1 block is finalized; reverting it would require reverting Ethereum.

Measured on the live chain on October 24, 2026: safe trailed the head by about 5,400 blocks (~9.5 minutes) and finalized by about 9,000 blocks (~16 minutes).

For an indexer, that means keeping two horizons:

• serve data from the soft head immediately (users expect live prices), but keep enough state to roll back soft-confirmed blocks if a reorg appears;
• treat data at or below safe as permanent, and expose the level on every record so consumers can choose.

Crius does both: every response’s meta reports block, safe_block and finalized_block, every trade carries finality (latest, safe or finalized), and the stream sends a reorg message followed by the removed events marked removed: true. In the 24 hours before writing, the chain had zero reorgs, which is typical for a single-sequencer chain, but the code path has to exist (finality concepts).

4. Nitro receipts and gas look different

Robinhood Chain speaks standard Ethereum JSON-RPC, with Arbitrum fields added. A real receipt from the public endpoint:

{
  "transactionHash": "0x7deb833a3165851f16932851bbc4e230aaabd121cb4a886c53ad3901d39185fa",
  "blockNumber": "0x5bf0464",
  "from": "0xabb2acd3be814a80e502575d6c1dc5f789e9cd10",
  "to": "0xca11bde05977b3631167028862be2a173976ca11",
  "gasUsed": "0x74ff1",
  "gasUsedForL1": "0x0",
  "effectiveGasPrice": "0x13449e0",
  "l1BlockNumber": "0x190af99",
  "status": "0x1",
  "type": "0x2"
}

Two things an Ethereum indexer won’t expect:

• The fee has two parts. gasUsedForL1 is the share of gas paying for posting the transaction’s data to Ethereum; the rest is L2 execution. A trade’s true cost is both. Crius reports gas per trade as l2_eth, l1_eth and USD.
• The sender is often not the trader. This transaction was sent by an executor to Multicall3 (0xca11…ca11) on behalf of a different wallet, which was the one that actually sold. On a chain with this many bots, routers, solvers and ERC-4337 bundlers (first-class on Robinhood Chain), attributing trades by from is wrong a large share of the time. You have to follow the token transfers inside the transaction (trader attribution).

5. Archive size and tracing

Despite its much larger block count, the chain’s archive is in the same range as a modern Ethereum archive:

Ethereum estimates vary by source; see Dwellir’s archive node cost analysis and Cherry Servers’ hardware requirements.

Tracing is the expensive part. Internal ETH transfers (a contract paying out ETH, a router forwarding it) don’t emit logs; you only see them in call traces. Tracing every block with debug_traceBlockByNumber and the call tracer ran at 227–388 blocks per second against a local node, about 88 hours for the full history, versus about 10 hours for receipts. Hosted support varies: QuickNode lists debug and trace APIs for the chain, while Alchemy lists them as not currently supported (Alchemy network page, QuickNode chain page). Plan for traces as a separate, slower pipeline that runs behind the main one.

6. Many tokens, many pools, many addresses

Robinhood Chain’s launchpads create thousands of tokens a day, and most get a pool. At time of writing the index holds about 2.4 million tokens, 3.1 million pools and well over 26 million addresses. The decoded data comes to about 12 billion rows and 190 GB compressed in ClickHouse (about 990 GB uncompressed), including 1.8 billion token transfers, 450 million trades and 670 million internal ETH transfers.

Three design points follow:

• State that must be in memory has to be compact. Pool reserves, current prices and holder counts are read on every trade. Interning addresses as integer ids keeps tens of millions of them in a few gigabytes.
• Uniswap v4 changes pool discovery. All v4 pools live inside one PoolManager contract and are identified by a 32-byte id, not an address. “Watch the factory for new pair contracts” doesn’t apply; you decode Initialize events and keep per-pool state keyed by id, including hook addresses.
• Prices need a graph. Tokens are quoted in ETH, WETH, USDG or other tokens, including tokenized stocks. Pricing everything in USD means picking each token’s best market and hopping through quote prices, block by block.

7. What carries over from Ethereum

Plenty does. Robinhood Chain is EVM-equivalent: standard ABIs, ERC-20 events, Uniswap v2, v3 and v4 contracts, eth_getLogs filters and the usual libraries (ethers.js, viem, web3.py) all work unchanged. Robinhood’s public RPC even accepts eth_getLogs over up to 10 million blocks per request. The differences are in scale and timing, not in the data formats.

A checklist for indexing Robinhood Chain

1. Budget for ~820,000 blocks a day and design per-block work to be tiny or batched.
2. Order everything by (block, tx index, log index); treat timestamps as one-second labels.
3. Use l1BlockNumber wherever on-chain logic depends on block.number.
4. Keep a rollback window for soft-confirmed blocks; track safe and finalized and expose them.
5. Split gas into L2 and L1 parts.
6. Attribute trades through routers, executors and bundlers, not by from.
7. Run traces as a separate, slower pipeline, and check that your RPC provider supports them.
8. Key Uniswap v4 state by pool id, and price tokens through a quote graph.

FAQ

How many blocks does Robinhood Chain produce per day? About 820,000 at the current ~105 ms average block time, versus about 7,200 on Ethereum mainnet.

Is a Robinhood Chain archive node bigger than an Ethereum archive node? Not much. A Nitro archive was about 2.8 TB at block ~96.7 million, comparable to an Ethereum archive on Erigon or Reth and far smaller than Geth’s hash-based archive.

Why does block.number in a Robinhood Chain contract not match the block height? On Arbitrum-based chains, block.number inside contracts returns the Ethereum L1 block number. The L2 height is the block number you see in RPC responses and explorers.

How long until a Robinhood Chain transaction is final? It’s soft-confirmed by the sequencer immediately, safe once its batch is posted and safe on Ethereum (about 9–10 minutes behind the head when we measured), and finalized about 16 minutes behind the head.

Can I index Robinhood Chain with a hosted RPC provider instead of my own node? Yes for logs and receipts, but full backfills make millions of calls, so rate limits and per-call pricing add up. Traces may not be available on every provider.

Related reading

• How to get all Robinhood Chain transactions without running a node
• Robinhood Chain API: the complete developer guide
• Historical data API and the Robinhood Chain API overview
• Reference: chain stats, WebSocket stream