Migrate from getSignaturesForAddress + getTransaction to getTransactionsForAddress

Why migrate?

The standard way to fetch an address’s transaction history on Solana takes two steps: call getSignaturesForAddress to list signatures, then call getTransaction once per signature to fetch the details. For 1,000 transactions, that is 1,001 HTTP requests. getTransactionsForAddress is a Helius-exclusive RPC method that collapses both steps into one call. It returns up to 1,000 full transactions per request, with filtering, bidirectional sorting, and token-account support that the standard methods don’t have.

	`getSignaturesForAddress` + `getTransaction`	`getTransactionsForAddress`
Requests for 1,000 transactions	1,001	1
Credits for 1,000 full transactions	~1,001 (1 credit per call)	100 (10 credits per 100 transactions)
Associated token account (ATA) history	Not included	Included via `filters.tokenAccounts`
Time and slot range filters	No	Yes
Status filter (succeeded/failed)	No	Yes
Sort order	Newest first only	Newest or oldest first
Pagination	`before`/`until` signatures	`paginationToken`

The result: roughly 10x fewer credits, 1,000x fewer round trips, and no client-side batching, rate-limit handling, or retry logic for the getTransaction fan-out.

Before and after

Here is the same task — fetch the last 1,000 transactions for an address with full details — in both patterns:

const rpcUrl = 'https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY';

// Step 1: Get signatures (1 request)
const sigResponse = await fetch(rpcUrl, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'getSignaturesForAddress',
    params: ['YOUR_ADDRESS_HERE', { limit: 1000 }]
  })
});
const { result: signatures } = await sigResponse.json();

// Step 2: Get transaction details (1,000 additional requests)
const transactions = await Promise.all(
  signatures.map(async (sig) => {
    const txResponse = await fetch(rpcUrl, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        jsonrpc: '2.0',
        id: 1,
        method: 'getTransaction',
        params: [sig.signature, { maxSupportedTransactionVersion: 0 }]
      })
    });
    const { result } = await txResponse.json();
    return result;
  })
);

const response = await fetch('https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'getTransactionsForAddress',
    params: [
      'YOUR_ADDRESS_HERE',
      {
        transactionDetails: 'full',
        maxSupportedTransactionVersion: 0,
        limit: 1000
      }
    ]
  })
});

const { result } = await response.json();
const transactions = result.data; // Full transactions, same shape as getTransaction

getTransactionsForAddress is not part of standard Solana RPC, so @solana/web3.js has no Connection helper for it. Call it with a raw JSON-RPC request as shown above — it works on the same Helius endpoint as the rest of your RPC traffic.

Parameter mapping

Every option from the old two-step flow has a direct equivalent. Most names carry over unchanged — only pagination works differently.

From getSignaturesForAddress

Old option	New equivalent
`limit`	`limit` — same 1,000 maximum
`before`	`paginationToken` from the previous response
`until`	`filters.signature.gt`
`commitment`	`commitment` — `confirmed` or `finalized` only; `processed` is not supported
`minContextSlot`	`minContextSlot` — unchanged

From getTransaction

Old option	New equivalent
`encoding`	`encoding` — applies when `transactionDetails` is `"full"`
`maxSupportedTransactionVersion`	`maxSupportedTransactionVersion` — unchanged
`commitment`	`commitment` — same rule as above

Two capabilities have no old equivalent at all:

filters — narrow results by blockTime, slot, status, tokenTransfer, or tokenAccounts server-side instead of fetching everything and filtering in your code.
sortOrder: "asc" — chronological (oldest-first) results, which the standard methods can’t return without fetching the entire history and reversing it.

Migration steps

Confirm you're on a Helius endpoint

getTransactionsForAddress is Helius-exclusive. It works on https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY (and devnet) — the same endpoint your existing calls already use if you’re a Helius customer. No API key or plan changes are needed.

Replace the two-step fetch with one call

Delete the getSignaturesForAddress call and the getTransaction loop. Make a single getTransactionsForAddress request with transactionDetails: "full", carrying over your encoding, maxSupportedTransactionVersion, and commitment values as shown in the parameter mapping.If you only need signatures (for example, to feed an existing pipeline), use transactionDetails: "signatures" instead — it costs 10 credits flat per call.

Update the response handling

The response envelope changes in three ways:

Results live in result.data (an array), not directly in result.
Each full-mode entry is { slot, transactionIndex, blockTime, transaction, meta }. The transaction and meta objects are identical in shape to what getTransaction returns, so your parsing code carries over unchanged.
Signatures-mode entries match getSignaturesForAddress output (signature, slot, err, memo, blockTime, confirmationStatus) plus a new transactionIndex field.

One behavioral difference to keep: with the old pattern, a getTransaction call could return null for a signature. With getTransactionsForAddress, every entry in result.data is a complete transaction — remove any null-handling for missing details.

Replace signature-based pagination

Swap the before cursor loop for paginationToken:

let paginationToken = null;
const allTransactions = [];

do {
  const response = await fetch('https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0',
      id: 1,
      method: 'getTransactionsForAddress',
      params: [
        'YOUR_ADDRESS_HERE',
        {
          transactionDetails: 'full',
          maxSupportedTransactionVersion: 0,
          limit: 1000,
          ...(paginationToken && { paginationToken })
        }
      ]
    })
  });

  const { result } = await response.json();
  allTransactions.push(...result.data);
  paginationToken = result.paginationToken;
} while (paginationToken);

The loop ends when paginationToken is null — no more comparing signature lists or tracking the last signature yourself.If you used until to stop at a known signature, replace it with filters.signature: { gt: "KNOWN_SIGNATURE" }. If you used it to stop at a point in time, filters.blockTime or filters.slot is usually a cleaner fit.

Optional: enable complete token history

The old pattern misses associated token account (ATA) activity entirely unless you also called getTokenAccountsByOwner and fetched signatures for every token account. To include it, add one filter:

{
  "filters": {
    "tokenAccounts": "balanceChanged"
  }
}

balanceChanged returns transactions that reference the wallet or change the balance of any token account it owns, filtering out spam. See associated token accounts for the none/balanceChanged/all options and the pre-2022 caveat.

Verify against the old output

For a sample address, fetch history both ways and compare the signature sets. With filters.tokenAccounts unset (the default none), getTransactionsForAddress returns the same transactions as getSignaturesForAddress for the same range. Then deploy and remove the old code path.

Behavior differences to review

Most migrations are a drop-in replacement, but check these before shipping:

Commitment. processed is not supported; use confirmed or finalized. If your old code polled recent history at processed, switch to confirmed.
Metering. Full-transaction responses cost 10 credits per 100 returned transactions (10-credit minimum); signatures-only responses cost 10 credits flat. The old pattern cost 1 credit per call — cheaper per request, but far more expensive per transaction fetched. Failed responses are free. See metering.
Network support. Mainnet has unlimited retention. Devnet is supported with 2 weeks of retention. Testnet is not supported.
Reserved addresses. A small set of system addresses (Vote Program, System Program, sysvars) route to fallback archival paths or return empty. If you index those, review limitations and edge cases.
Multiple addresses. Like the old flow, one request covers one address. Query addresses in parallel and merge; see multiple addresses.

Frequently asked questions

Is getTransactionsForAddress a standard Solana RPC method?

No. It is a Helius-exclusive method available on Helius RPC endpoints. Standard Solana RPC and other providers only offer getSignaturesForAddress and getTransaction. Your other RPC calls are unaffected — the method lives on the same endpoint alongside the full standard RPC surface.

Do I still need getTransaction after migrating?

Only for one-off lookups where you already have a signature and no address context, such as verifying a specific transaction a user pasted in. For any address-based history — backfills, indexing, wallet activity feeds — getTransactionsForAddress replaces both methods.

Does it work with @solana/web3.js?

The method isn’t in the Connection class, but it works with any HTTP client against your Helius RPC URL. Use fetch (or your language’s equivalent) with a standard JSON-RPC body, as shown in the examples above. You can keep using Connection for everything else.

Will it return the same transactions as getSignaturesForAddress?

Yes. With default settings (filters.tokenAccounts: "none"), it returns transactions that reference the queried address — the same set as getSignaturesForAddress. Setting tokenAccounts to balanceChanged or all returns more: it adds activity from the wallet’s associated token accounts, which the standard method cannot see.

How much does it cost compared to the old pattern?

Fetching 1,000 full transactions costs 100 credits with getTransactionsForAddress versus roughly 1,001 credits (and 1,001 requests) with getSignaturesForAddress + getTransaction. Signatures-only responses cost 10 credits flat per call. See Helius credits for full pricing.

Let an AI agent do the migration

If you use Claude Code, Cursor, or another coding agent, paste the prompt below into your repository’s agent session. It finds the old pattern in your codebase and rewrites it.

Migrate this codebase from the two-step Solana transaction history pattern
(getSignaturesForAddress followed by getTransaction) to the single Helius RPC
method getTransactionsForAddress.

## Background

getTransactionsForAddress is a Helius-exclusive JSON-RPC method served on
standard Helius RPC endpoints (https://mainnet.helius-rpc.com/?api-key=...).
It returns up to 1,000 full transactions per call, replacing one
getSignaturesForAddress call plus one getTransaction call per signature.
Docs: https://www.helius.dev/docs/rpc/gettransactionsforaddress.md

## Step 1: Find the old pattern

Search for:
- getSignaturesForAddress calls (via @solana/web3.js Connection, raw JSON-RPC,
  or another SDK) whose signatures are then passed to getTransaction /
  getParsedTransaction / getTransactions
- Pagination loops using `before` or `until` signature cursors
- getTokenAccountsByOwner calls used only to fetch per-token-account signature
  history

Leave standalone getTransaction calls (single-signature lookups with no
address context) unchanged.

## Step 2: Rewrite each call site

Replace the two-step flow with one raw JSON-RPC request (web3.js has no
Connection helper for this method):

```javascript
const response = await fetch(HELIUS_RPC_URL, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'getTransactionsForAddress',
    params: [
      address, // base-58 string
      {
        transactionDetails: 'full',       // or 'signatures' if only signatures were used
        maxSupportedTransactionVersion: 0, // carry over from the old getTransaction options
        encoding: 'json',                  // carry over ('json', 'jsonParsed', 'base64', 'base58')
        limit: 1000,                       // up to 1,000
        // paginationToken: '...',         // from the previous response, for page 2+
        // sortOrder: 'desc',              // 'desc' (default, newest first) or 'asc'
        // filters: { ... }                // optional, see mapping below
      }
    ]
  })
});
const { result } = await response.json();
// result.data      -> array of transactions
// result.paginationToken -> string cursor, or null when done
```

Parameter mapping:
- limit -> limit
- before: <sig> -> paginationToken (preferred) or filters: { signature: { lt: <sig> } }
- until: <sig>  -> filters: { signature: { gt: <sig> } }
- commitment -> commitment ('confirmed' or 'finalized' only; if the old code
  used 'processed', use 'confirmed')
- minContextSlot -> minContextSlot
- encoding / maxSupportedTransactionVersion (from getTransaction) -> same names,
  top level of the config object

Response shape:
- Full mode: each entry is { slot, transactionIndex, blockTime, transaction, meta }.
  transaction and meta are identical in shape to getTransaction results, so
  existing parsing code carries over. Entries are never null - remove
  null-handling that existed for missing getTransaction results.
- Signatures mode: entries match getSignaturesForAddress output
  ({ signature, slot, err, memo, blockTime, confirmationStatus }) plus
  transactionIndex.

Pagination: loop while result.paginationToken is non-null, passing it back as
paginationToken. Remove manual last-signature tracking.

If the old code fetched signatures for the wallet's token accounts too
(getTokenAccountsByOwner + per-account getSignaturesForAddress), replace all
of it with one call using filters: { tokenAccounts: 'balanceChanged' } and
delete the merge/dedupe logic.

## Step 3: Constraints and cleanup

- The endpoint must be a Helius RPC URL; other providers do not serve this
  method. Do not change endpoints for other RPC calls.
- Remove now-unused batching, throttling, and retry helpers that existed only
  for the getTransaction fan-out.
- One request covers one address; keep parallel queries for multi-address code.
- Preserve the surrounding code style and error handling conventions.

## Step 4: Verify

- Run the project's type checks and tests.
- Do NOT make any RPC calls yourself. Instead, write a standalone script (e.g.
  scripts/verify-gtfa-migration.mjs) that fetches history for one address both
  ways - the old getSignaturesForAddress + getTransaction flow and the new
  getTransactionsForAddress call with default filters - and prints whether the
  signature sets match, listing any differences. Read the RPC URL from an
  environment variable and the address from a CLI argument; never hardcode an
  API key.
- Tell the user how to run it, for example:
  HELIUS_RPC_URL="https://mainnet.helius-rpc.com/?api-key=..." \
    node scripts/verify-gtfa-migration.mjs <address>
- Summarize every call site changed and flag any you were unsure about.

The prompt is self-contained — the agent doesn’t need access to this page. For agent-ready docs, MCP search, and skills, see Helius for AI agents.

Next steps

getTransactionsForAddress guide

Full tutorial covering filters, sorting, pagination, and token accounts.

API reference

Complete request and response schema.

Indexing guide

Use getTransactionsForAddress to backfill and sync a Solana index.

Historical data overview

Compare all Solana historical data methods.

Overview

Best Practices

How-To Guides

RPC Method Guides

Using Orb

Migrate from getSignaturesForAddress + getTransaction to getTransactionsForAddress

Why migrate?

Before and after

Parameter mapping

From getSignaturesForAddress

From getTransaction

Migration steps

Behavior differences to review

Frequently asked questions

Is getTransactionsForAddress a standard Solana RPC method?

Do I still need getTransaction after migrating?

Does it work with @solana/web3.js?

Will it return the same transactions as getSignaturesForAddress?

How much does it cost compared to the old pattern?

Let an AI agent do the migration

Next steps

getTransactionsForAddress guide

API reference

Indexing guide

Historical data overview

​Why migrate?

​Before and after

​Parameter mapping

​From getSignaturesForAddress

​From getTransaction

​Migration steps

​Behavior differences to review

​Frequently asked questions

​Is getTransactionsForAddress a standard Solana RPC method?

​Do I still need getTransaction after migrating?

​Does it work with @solana/web3.js?

​Will it return the same transactions as getSignaturesForAddress?

​How much does it cost compared to the old pattern?

​Let an AI agent do the migration

​Next steps

getTransactionsForAddress guide

API reference

Indexing guide

Historical data overview

Why migrate?

Before and after

Parameter mapping

From getSignaturesForAddress

From getTransaction

Migration steps

Behavior differences to review

Frequently asked questions

Is getTransactionsForAddress a standard Solana RPC method?

Do I still need getTransaction after migrating?

Does it work with @solana/web3.js?

Will it return the same transactions as getSignaturesForAddress?

How much does it cost compared to the old pattern?

Let an AI agent do the migration

Next steps