New: getTransactionsForAddress and up to 10x Faster Archival Data

getTransactionsForAddress (gTFA) is a new Solana RPC method for querying historical data that combines getSignaturesForAddress and getTransaction into a single call, with powerful new features including reverse search, time, status, and slot-based filtering, and pagination.

Until now, backfilling and querying historical data on Solana forced developers to use slow, expensive methods like getBlock or to loop over batches of signatures using getSignaturesForAddress and getTransaction.

Now, developers can use a single call with powerful filtering and sorting options to query up to 100 records with full transaction details or up to 1,000 records with just signatures.

Challenges of Querying Historical Data on Solana

Solana’s ledger holds every transaction ever sent on-chain. This historical data includes every mint, transfer, swap, and program interaction that has occurred since genesis.

To date, Solana has produced over 375 million blocks, and its full, unpruned transaction history from the genesis block to the present day is 100s of terabytes in size. 

Accessing this data quickly and reliably is essential for practically every team building on Solana today. Solana's archival methods power everything from your favorite wallet’s transaction history tab to your favorite explorer and portfolio dashboard. 

Until now, developers only had two options for querying archival data and both are painful: 

1. getBlock
2. getSignaturesForAddress plus getTransaction

Using getBlock is too Slow

First, developers may try querying getBlock to backfill data. While possible, this method is unnecessarily time-consuming, expensive, and resource-heavy:

1. Call getBlocks to find confirmed blocks in your slot range
2. Call getBlock on each block to get full transaction details, signatures, or accounts
3. Parse all relevant data from the block and store it in your database
4. Repeat until all blocks are complete

While the getBlock method works well for busy programs (e.g., indexing popular tokens like USDC or Solana programs like Pump.fun), using it for small, specific datasets is impractical.

Looping getSignaturesForAddress and getTransaction

Using getSignaturesForAddress (gSFA) together with getTransaction is another common way to backfill data.

This “N+1 loop” approach repeatedly fetches transaction signatures, typically 1,000 at a time, and then makes batch RPC calls to fetch the details of each transaction. 

Given the sheer number of RPC requests, developers will need to implement exponential backoffs and retry logic to avoid hitting rate limits and missing data. 

While using gSFA and getTransaction is more flexible than getBlock, it’s still expensive, complicated, and error-prone at scale.

Benefits of getTransactionForAddress

The new getTransactionsForAddress RPC method combines getSignaturesForAddress with getTransaction into a single call with powerful features that make building indexes and querying historical data easier and faster.

Here are the key features:

1. Reverse Search

Existing archival RPC methods, such as gSFA, required developers to start at the most recent transaction and work backward.

With getTransactionForAddress, developers can now choose between ascending (i.e., chronologically, oldest first) or descending (i.e., newest first) sort orders. 

Combined with time-based filters, developers can use getTransactionForAddress to query any piece of Solana’s history, from any point in time, in any order.

For example, Orb, our new Solana block explorer, uses the getTransactionsForAddress RPC method to power the “Show oldest first” filter:

If you wanted to query this same data using getSignaturesForAddress and getTransaction, you would need to:

1. Find the exact timestamp corresponding to the first transaction
2. Find the transaction signature corresponding to your start date
3. Loop backward from that signature using before: lastSignature 
4. Continue looping until the returned signatures' blockTime reaches the end date
5. Write backoff and retry logic to avoid hitting rate limits and missing data

This process is not only slow to query but also frustrating to set up and prone to error.

2. Advanced Filtering

With the new getTransactionsForAddress method, developers can filter by time range (i.e., Unix timestamp), slot, and status (e.g., succeeded or failed). These filters give you more precise, granular control over querying exactly the data you need.

For example, this time-based filter uses Unix timestamps to receive all successful transactions that occurred between January 1st, 2025, at 12:00 am (GMT) and October 1st, 2025, at 12:00 am (GMT).

// Time range with successful transactions only
"filters": {
  "blockTime": {
    "gte": 1767225600,
    "lte": 1759363200
  },
  "status": "succeeded"
}

3. Cursor-based Pagination

When you need to query more transactions than gTFA’s default limits (1,000 signatures or 100 records with full transaction details), you can use the paginationToken from the response to fetch the next page. The paginationToken is a simple string in the format "slot:position" that tells the API from where to continue.

For example, this query uses the paginationToken (a cursor) to scan the addresses’ history in batches of 100.

// First request
let paginationToken = null;
let allTransactions = [];

const getNextPage = async (paginationToken = null) => {
  const params = [
    'ADDRESS',
    {
      transactionDetails: 'signatures',
      limit: 100,
      ...(paginationToken && { paginationToken })
    }
  ];

  const response = await fetch(rpcUrl, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0',
      id: 1,
      method: 'getTransactionsForAddress',
      params
    })
  });

const data = await response.json();
  return data.result;
};

// Paginate through all results
do {
  const result = await getNextPage(paginationToken);
  allTransactions.push(...result.data);
  paginationToken = result.paginationToken;
  
  console.log(`Fetched ${result.data.length} transactions, total: ${allTransactions.length}`);
} while (paginationToken);

New Solana Archival System

In addition to the new getTransactionsForAddress method, we shipped a brand-new archival system rebuilt from scratch to optimize the archival’s router and storage paths.

The new system is enabled for all Solana archival RPC methods (e.g., getTransaction, getBlock, getInflationReward) and is available to users on all free and paid plans.

This means every archival method on every plan is now 2-10x faster — lower latency, better performance, and no code changes required.

Get started

The getTransactionsForAddress RPC method is publicly available starting today on all paid plans, and it can be used with your existing Helius RPC URL. The gTFA method costs 100 credits per call and is part of your RPC rate limit group.

To learn how the method works and get started, read the API reference and follow our getTransactionsForAddress quickstart guide.