History is not one capability
An old transaction receipt, an old account balance and a decoded DEX trade are different records. A node can retain blocks and receipts while pruning state needed for an old eth_call. An indexer may preserve selected decoded events without keeping arbitrary contract state. The label "history" does not resolve these differences.
Write the query before choosing storage
| Question | Required data |
|---|---|
| What happened in transaction X? | Transaction and receipt or equivalent execution record |
| What did balanceOf return at block N? | State at block N plus contract execution |
| What were swaps in pool P last month? | Events or a decoded dataset with that pool and date coverage |
| What changed during a disconnect? | Replay or a historical source covering the missed range |
For Solana, keep account-state queries separate from retained block and signature history too. Terminology differs across node implementations.
Test a boundary
- Choose one recent and one old fixture for each required method.
- Record the exact block or slot, method and expected record.
- Ask about per-method retention and pruning, including tracing dependencies.
- Repeat the oldest fixture near the boundary as the service ages.
Use the current product specification
An archive-capable protocol does not mean every endpoint stores archive state. Supanode's Robinhood documentation distinguishes retained transaction history from its recent-state window. Its SQL Indexers describe their own tables and retention separately. Read those limits before committing a backfill, and validate a sample query during a trial instead of inferring unlimited history from an endpoint returning one old receipt.