Solana transaction history: pagination, retention and coverage

Define the history you are trying to reconstruct

A wallet's SOL transfers, token receipts, DeFi position changes and digital assets can live in different accounts and programs. A request for one public address does not automatically cover all those relationships.

getSignaturesForAddress returns signatures for transactions that reference the supplied address in account keys. If a receiving token account is referenced without the wallet authority, a wallet-address-only scan can miss that receipt.

Choose a scope: transfers into specified receiving accounts, all interactions with a known program, or portfolio activity across supported standards. Write down which account discovery and decoding rules connect that scope to actual transaction records.

Current account discovery also has limits for historical work. An account closed long ago may be absent from today's owner query. Reconstructing a complete past portfolio can require an index that retained those relationships.

Paginate from a recorded boundary

Address signatures arrive newest first under the method's contract. Use the returned signature cursor with before to request older entries. until provides another boundary under its documented behaviour.

For a chosen five-record example with page size two, page one returns E,D. Use D as the next older-page cursor to retrieve C,B, then B to retrieve A. Persist each successfully processed page and its boundary.

These letters are teaching record labels, not real signatures. In code, preserve the exact signature strings and cluster. Do not use an approximate wall-clock time as an interchangeable cursor.

A changing head can add records while the backfill runs. Separate a historical boundary from catching up the newest activity, and use a controlled overlap with durable deduplication.

Fetch and decode the actual transaction

A signature list is an index of candidates. Fetch transaction details to inspect execution status, accounts, instructions, inner invocations, balance changes and relevant metadata.

Declare the transaction versions your decoder actually supports. A parser which understands only legacy or v0 cannot claim complete coverage merely by accepting a newer version number in a request.

Resolve loaded accounts correctly for formats that use them. Identify the programs and asset standards involved before assigning economic meaning to balance changes.

A failed transaction can still appear in history and pay a fee. Its attempted transfer instructions do not establish a completed payment. Inspect execution error and the accepted resulting state.

History has several coverage layers

Archive coverage has several dimensions

A node can retain recent ledger data while a service offers a separate historical store. Transaction details, address indexes, block availability and parsed enhanced APIs can have different retention and coverage.

getFirstAvailableBlock reports a node's available block floor under its contract. It does not prove that every address index or external archive is complete back to that point.

Before a large backfill, test a known old transaction, its block and its address lookup. Confirm your required methods on the actual plan. A service advertising archive data may still impose method-specific limits.

Save the source, observation date, oldest successfully covered boundary and unresolved failures. If you change providers, compare the overlapping range before treating the combined dataset as continuous.

Investigate null without inventing an outcome

A null transaction lookup can mean the endpoint has not found it at the requested commitment, lacks the retained data or does not cover that history. Start with the signature and cluster.

Check whether a recent-status cache is being used and whether history search is supported. Then query the appropriate archive or compare another documented source.

If the relevant range cannot be recovered, mark it incomplete. An empty result from an unsupported or exhausted source should not become a zero-activity chart.

Separate unavailable records from unsupported decoding. You may have raw transaction data that your current parser cannot classify. Store that state so later decoder improvements can revisit it.

Build a resumable historical pipeline

Use separate stages for account discovery, signature pagination, transaction retrieval, decoding and business interpretation. Each stage can have a different request cost and failure mode.

Persist raw source identity and decoding version alongside the output. Preserve enough data to explain a classification without keeping secrets or unnecessary personal information in logs.

Limit concurrency, checkpoint progress and retry transient errors with a bounded policy. Reconcile duplicate candidates using a key suited to your unit of analysis.

A completion report should state the covered cluster, accounts, period, source and unresolved gaps. That makes the result assessable rather than presenting a long list of rows as proof of completeness.

Common questions