Solana Archive Nodes and Historical Data: What Needs an Archive and How to Use It

A standard Solana RPC node maintains only a recent history of ledger data, so requests for blocks, transactions, or signatures older than some time window return no results. An archive, or, more precisely, an archive data tier, holds the full ledger history in a separate long-term storage and delivers it via the same RPC API. You need access to archive data if you want to obtain a wallet's history, the trades of a pool from some months ago, or any block created before last week; most people rent it rather than maintain it themselves. This post explains what the retention window is, which methods use the archive, what it means to run an archive, and how to use historical data efficiently.

Retention window

Any Solana validator or RPC node stores the ledger (i.e., blocks and transactions) in a local database that gradually accumulates entries. Due to the huge amount of history, nodes perform pruning: they keep a certain number of recent slots and drop older ones. The window is measured in days. Requests for any slots within the window succeed, while requests for any slots outside the window return null or an error that the slot is unavailable.

That might be unexpected for teams that are familiar with other chains, where a full node can deliver any history. On Solana, the full history is an explicitly separate product.

What is an archive tier

An archive is a long-term storage of all blocks and transactions starting from genesis or from the moment when the archive was turned on; all blocks and transactions are delivered via the same RPC methods. The reference implementation uses a wide-column database (there is support for a BigTable-style backend), and providers maintain something similar to that. When an RPC node receives a request for a slot that is out of the local retention window, it forwards the query to the archive.

On your side, nothing changes: the same call for a transaction works for transactions created yesterday or two years ago as long as the endpoint has an archive access.

Which methods use the archive

This last detail changes the way you design applications. There is no "balance at slot X" method on Solana. If you need any historical balances or positions, you should rebuild them yourself from the history of transactions (from pre- and post-balance in every transaction's metadata).

Typical archive queries

• wallet history: all transactions of an address, done with the combination of getSignaturesForAddress and subsequent getTransaction calls. Required by explorers, portfolio trackers, tax calculators.
• protocol analytics: all swaps at a pool during a period, re-created from blocks or from the lists of signatures for a program.
• indexer backfill: filling all the pre-live data.
• compliance and audit: proving what happened and when.
• research: any walk through history.

Running your own archive

It is the most expensive Solana infrastructure to maintain: the historical data is huge and grows by each slot, the backing storage has to grow along with that, and the ingestion process should never lag behind. Providers or large indexers with their dedicated data team are usually the ones who run it. For most projects, the option of renting access to the archive is reasonable. OrbitFlare historical data tier is an archive tier and is available via the same API endpoints as the whole service.

Using historical data efficiently

Historical calls are the heaviest and, under credit-based pricing, the most expensive requests in the API. There are four ways of reducing cost and latency:

• Page getSignaturesForAddress requests with before and until and stop as soon as you reach the range that you need; don't scan the whole history if you need only last month.
• Use getBlock with transaction details if a block contains many interesting transactions, and use getTransaction if there are few. It is very wasteful to fetch an entire block to get a single transaction.
• Cache immutable results. Finalized transactions never change; you should store them once.
• Backfill once, then stay live. Use a gRPC stream to receive new data and an archive for pre-backfill data.

Choose a pricing model that works well with the historical queries. Under requests-per-second pricing model, a historical call is the same as any other call; under credit pricing model, it is usually weighted heavier.

Conclusion

Solana's standard nodes forget history after some days; anything older is an archive query delivered from a separate long-term storage via the same RPC API. Historical calls to getBlock, getTransaction, and getSignaturesForAddress against old slots need an archive access; current-state calls never do, and there is no historical-state calls at all; thus, history reconstruction is an indexing task. Rent an archive access rather than run it yourself, do efficient paging and caching, and choose a pricing model that doesn't punish heavy requests.

OrbitFlare historical data tier delivers the full history through the standard API endpoints; combine it with the gRPC service for the post-backfill data.