Who uses archive RPC and indexing for a new chain?

Layer 1 and layer 2 teams, rollup and appchain operators, and foundations preparing a mainnet launch for their builders.

Goldsky

Archive RPC and indexing for a new chain

Talk to our team

What is archive RPC and indexing for a new chain?

Archive RPC and indexing for a new chain is the data access a chain team arranges before mainnet: an RPC endpoint that serves every block back to genesis, plus indexed data that apps can query, sometimes called rollup or appchain infrastructure.

Chain teams set it up because builders decide where to launch partly on whether they can read the chain on the first day without running their own nodes.

Goldsky serves RPC through Edge RPC, streams the chain’s history with Turbo Pipelines and hosts subgraphs for builders, while the chain team runs the chain itself and decides what its builders get.

You can give a new chain archive RPC and indexing two ways: serve RPC and host subgraphs for builders, or serve RPC and stream the chain into your own database.

How archive RPC and indexing for a new chain work

The diagram follows a chain from its first mainnet blocks to the first apps launching on it, and shows who serves each kind of data in between. Your setup may differ.

Mainnet goes liveYour chain produces its first blocks

Apps launchYour ecosystem ships without running nodes

EdgeServe RPC from day oneArchive RPC for builders and wallets

TurboStream the chain’s historyFrom genesis into your own systems

SubgraphsHost app APIsBuilders deploy subgraphs on your chain

Goldsky

Ways to give a new chain archive RPC and indexing

Hosted subgraphs let each builder deploy and query a GraphQL API of their own, while streaming lands the chain’s history in a database the chain team owns and serves from its own API.

Usual setupOption 1: RPC and hosted subgraphs

Best for: A new EVM chain whose builders want indexed APIs on day one
Products: Edge Turbo Subgraphs
What you run: Your own client code
What you write: JSON-RPC calls, and the decoding of what comes back
Where your data lives: Read from the chain
How results reach you: Returned when you call

Option 2: RPC and your own database

Best for: A chain team that owns its indexed data and serves its own API
Products: Edge Turbo
What you run: The destination: your database, queue or bucket, or a Postgres database Goldsky hosts
What you write: Pipeline YAML and SQL; TypeScript transforms when needed
Where your data lives: In your own database or systems
How results reach you: Pushed to you

Ways to give a new chain archive RPC and indexing
	Usual setupOption 1: RPC and hosted subgraphs	Option 2: RPC and your own database
Best for	A new EVM chain whose builders want indexed APIs on day one	A chain team that owns its indexed data and serves its own API
Products	Edge Turbo Subgraphs	Edge Turbo
What you run	Your own client code	The destination: your database, queue or bucket, or a Postgres database Goldsky hosts
What you write	JSON-RPC calls, and the decoding of what comes back	Pipeline YAML and SQL; TypeScript transforms when needed
Where your data lives	Read from the chain	In your own database or systems
How results reach you	Returned when you call	Pushed to you

Option 1: Give a new chain archive RPC and indexing with hosted subgraphs

Edge RPC serves the chain from its first block, a pipeline streams its history into your systems, and builders deploy subgraphs on the chain to give their apps GraphQL APIs.

When to launch with hosted subgraphs

Builders on your chain already write subgraphs, or want an indexed API for their own contracts without running an indexer, and you want them building on the first day.

What you’ll need

Goldsky Edge
Goldsky Turbo
Goldsky Subgraphs
A running chain with at least one archive node
A database or warehouse for the chain team’s own copy of its history
A builder program that tells developers where to find the endpoints

Open mainnet
Nothing can be read or indexed until the chain is producing blocks that builders and users treat as real.
Your validators or sequencer produce blocks from genesis onward, and at least one archive node keeps every past state. If the archive is missing or incomplete, anything that needs old blocks, from an indexer’s backfill to a wallet’s history screen, has nothing to read.
Serve archive RPC to builders and wallets
Handled by Goldsky Edge
RPC is how wallets, apps and tools talk to a chain: every balance read, transaction lookup and submitted payment goes through it.
Builders need an endpoint that serves the newest block and every block back to genesis, and that keeps responding when one node falls over. If the only endpoint is a single node the chain team runs, every builder’s app goes down with it.
Goldsky’s Edge RPC serves the chain over HTTPS with automatic failover across several upstream nodes, routes requests for old blocks to archive nodes and splits large eth_getLogs ranges so indexers get complete results.
What Edge RPC serves (opens in a new tab)
Stream the chain’s history from genesis
Handled by Goldsky Turbo
Explorers, dashboards and the chain team’s own reports need every block and event since launch in a database, not only the latest state.
The copy has to start at the first block and keep following the tip, including when the newest blocks are replaced in a reorg (the chain swapping its most recent blocks for another version). A copy that starts late or ignores reorgs gives the chain team numbers that don’t match the chain.
With Turbo Pipelines, an Edge EVM source can read any EVM chain through Edge RPC from start_at: earliest and write blocks, transactions and logs to your database, with reorg corrections applied to tables keyed on a primary_key.
Stream any EVM chain from genesis (opens in a new tab)
Let builders deploy subgraphs on the chain
Handled by Goldsky Subgraphs
Most apps need their own contracts’ events in a form they can query, which is what a subgraph (a schema plus code that turns events into records) gives them.
Builders deploy their subgraph against the chain and get a GraphQL endpoint for it. Without hosted indexing, each team runs its own indexer and node before it can ship, and a decentralized indexing network may need community testing and a governance vote before it indexes a new chain.
Goldsky Subgraphs supports custom EVM chains, so builders can deploy to your chain with goldsky subgraph deploy and query the hosted GraphQL API that comes back.
How Subgraphs index a chain (opens in a new tab)
Tell builders where the data is
Endpoints only help if developers can find them on the first day.
Publish the RPC URL, the chain ID and how to deploy a subgraph in your developer docs before mainnet opens. If builders learn about them after launch, the first apps ship late or not at all.
Launch apps on the chain
A chain’s value to its users is the apps built on it.
Builders point their apps at the RPC endpoint and their subgraph APIs and ship without running nodes. Your team watches usage from the chain’s own history and fixes gaps that builders report.

What to know about launching with hosted subgraphs

Goldsky runs the RPC layer and hosts the subgraphs; the chain team runs the chain and its archive nodes.
Each builder writes and deploys their own subgraph, so the indexed API matches their contracts and nobody waits on the chain team.
Subgraphs give builders a GraphQL API to query, while the chain team’s own copy of the history comes from the pipeline.

Option 2: Give a new chain archive RPC and indexing by streaming to your own database

Edge RPC serves the chain from its first block, and a pipeline streams the chain’s blocks and events into a database the chain team owns, behind an API the chain team runs for builders.

When to stream a new chain into your own database

The chain team wants to own its indexed data and serve it to builders from its own API or explorer, rather than have each builder deploy a subgraph.

What you’ll need

Goldsky Edge
Goldsky Turbo
A running chain with at least one archive node
A database or warehouse the chain team runs
An API or explorer that serves the indexed data to builders

Open mainnet
Nothing can be read or indexed until the chain is producing blocks that builders and users treat as real.
Your validators or sequencer produce blocks from genesis onward, and at least one archive node keeps every past state. If the archive is missing or incomplete, anything that needs old blocks, from an indexer’s backfill to a wallet’s history screen, has nothing to read.
Serve archive RPC to builders and wallets
Handled by Goldsky Edge
RPC is how wallets, apps and tools talk to a chain: every balance read, transaction lookup and submitted payment goes through it.
Builders need an endpoint that serves the newest block and every block back to genesis, and that keeps responding when one node falls over. If the only endpoint is a single node the chain team runs, every builder’s app goes down with it.
Goldsky’s Edge RPC serves the chain over HTTPS with automatic failover across several upstream nodes, routes requests for old blocks to archive nodes and splits large eth_getLogs ranges so indexers get complete results.
What Edge RPC serves (opens in a new tab)
Backfill the chain’s history from genesis
Handled by Goldsky Turbo
Everything your API will return about the past depends on a complete copy of the chain since launch.
The backfill has to cover every block from the first one, so it needs an archive node behind it. A gap of even a few blocks shows up later as missing transactions that nobody can explain.
A Turbo Pipelines job with an Edge EVM source can read a fixed range from start_at: earliest to an end_at block, write it to your database and exit once the range is done.
Run a one-time backfill job (opens in a new tab)
Keep the database following the chain
Handled by Goldsky Turbo
After the backfill, new blocks keep arriving, and your copy has to keep up and stay correct.
Each new block’s transactions and events have to land in the same tables, and a reorg has to update or remove rows that no longer exist on the chain. If reorgs aren’t applied, your API serves transactions that were dropped.
Goldsky keeps a long-running pipeline streaming new blocks into the same tables, and Turbo Pipelines passes reorg corrections through as updates and deletes to any sink with a primary_key.
How reorgs reach your tables (opens in a new tab)
Serve the indexed data from your own API
Builders need a way to query the data you hold, such as an explorer, a REST API or a GraphQL layer.
Your team builds and runs the API on top of the database and decides what it exposes. If it can’t keep up with builders’ traffic, their apps slow down with it, so it needs the same care as any production service.
Launch apps on the chain
A chain’s value to its users is the apps built on it.
Builders point their apps at the RPC endpoint and your API and ship without running nodes. Your team watches usage in its own tables and adds the fields builders ask for.

What to know about streaming a new chain into your database

The chain team owns the tables and the API on top of them, and runs that API.
The pipeline’s SQL decides which columns each table holds, so the schema is yours.
Tables with a primary key take reorg corrections as updates and deletes; an append-only destination such as a queue receives correction records and has to apply them.

How to power a block explorer

Index every block, transaction and log of a chain into the database behind a block explorer.

A pipeline backfills every block, transaction and log of the chain into your database and keeps adding new blocks as they’re produced, correcting rows after reorgs; the block explorer Dora streams its chains’ data into its backend database this way with Goldsky. Your explorer serves search and pages from that database and reads live state over RPC.

What you’ll need

Goldsky Edge
Goldsky Turbo
A database for blocks, transactions, logs and traces
ABIs or verified source code for the contracts you decode
Your explorer’s search, pages and API

Pick the chains and data to index
An explorer can only show what it has indexed, so start from what users look up.
List the chains, and for each the blocks, transactions, logs and traces you’ll show. Traces record internal calls between contracts, and leaving them out means value moved by a contract never appears on an address page.
Load every block since genesis
Handled by Goldsky Turbo
Users look up old transactions as often as new ones, so the index has to start at the first block.
An index that starts late shows addresses with missing transactions. A backfill from the first block needs archive data, because ordinary nodes drop old state.
Goldsky’s Turbo Pipelines Edge EVM datasets stream blocks, transactions, logs and traces from any EVM chain through Edge RPC, which routes historical requests to archive nodes, starting from earliest and carrying on at the chain tip.
Stream any EVM chain (opens in a new tab)
Keep up with new blocks and reorgs
Handled by Goldsky Turbo
An explorer that lags, or still shows a block the chain dropped, gives users the wrong answer.
New blocks have to land within moments, and blocks the chain replaces in a reorg have to disappear from search. Rows keyed on a block hash or log ID let each correction update the right row.
Each Edge EVM row carries a _gs_op column, c for an insert and d for a delete when a reorg orphans it, and a Postgres sink with a primary_key applies both, so the database converges to the canonical chain.
See how reorgs reach your database (opens in a new tab)
Decode contract events
Users want to read “transfer of 100 tokens to this address”, not encoded log data.
Your explorer decodes logs and calls with each contract’s ABI or verified source, so pages show event names and fields. Contracts nobody has verified stay raw until someone does.
Serve search and pages
An explorer is only useful if any address, transaction or block comes up quickly.
Your database indexes the tables for lookups by hash, address and block, and your API serves the pages. Balances and contract state change with every block, so read them live rather than from the index.
Read live state over RPC
Handled by Goldsky Edge
Current balances and contract reads come straight from the chain.
Pages call the chain for balances, contract code and reads at the latest block. A single provider that falls behind leaves every page showing stale numbers.
With Goldsky, Edge RPC serves those calls over HTTPS, fails over across several upstream providers and cross-validates their responses.
See how Edge RPC fails over (opens in a new tab)