For the complete documentation index, see llms.txt. This page is also available as Markdown.

Filters

Available Filters for getTransactionsForAddress - Slot Range, Block Time, Status, Signature and Token Accounts

By default, getTransactionsForAddress returns all transactions for an address in reverse chronological order. Filters let you narrow that result set on the server before anything is returned - so you're not pulling down thousands of transactions and discarding most of them on the client.

Following filters are available:

  • slot - for slot based scans,

  • blockTime - for time-range scans,

  • signature - for ledger-position bounds,

  • status - for filtering by execution outcome, and

  • tokenAccounts - for expanding or restricting coverage to SPL token accounts owned by the address. All filters are optional and can be combined in a single request.

Filters are passed as a nested filters object inside the options parameter. Comparison-based filters (slot, blockTime, signature) accept a comparison object with one or more operators (gte, gt, lte, lt, eq) so you can express both open-ended bounds and closed ranges.

Available Filters

Filter
Type
Description

slot

comparison object

Filter by slot number. Supports gte, gt, lte, lt.

blockTime

comparison object

Filter by Unix timestamp. Supports gte, gt, lte, lt, eq.

signature

comparison object

Filter by signature position within the ledger. Supports gte, gt, lte, lt. Rarely needed β€” prefer slot or paginationToken for range scans.

status

any | succeeded | failed

Filter by transaction outcome. any returns both. Corresponds to meta.err === null (succeeded) or non-null (failed).

tokenAccounts

none | balanceChanged | all

Controls token-account fan-out. See Token Account Filtering below.

Comparison object example

{
  "gte": 425214949,
  "lt":  425215949
}

Multiple comparison operators can be combined in a single filter to express a range.

Slot, Block time & Signature Filtering

Slot

Filters by the slot number a transaction was confirmed in. Accepts gte, gt, lte, lt. Use a single operator for an open-ended bound, or combine two to express a closed range:

Blocktime

Filters by the Unix timestamp of the block. Accepts gte, gt, lte, lt, and also eq for an exact match. Works the same way as slot but in wall-clock time:

Signature

Filters by a transaction's position in the ledger relative to a known signature. Accepts gte, gt, lte, lt - no eq, since you'd just query that signature directly. Works the same way structurally as slot and blockTime:


The key difference between the three: slot and signature are ledger-native (always present, always reliable), while blockTime can be null for very old blocks. For deep historical scans, prefer slot.


Token Account Filtering

By default, getTransactionsForAddress only returns transactions where the queried address appears directly in accountKeys. Setting tokenAccounts expands this to include transactions that touched token accounts owned by that address.

Value
Behavior

none

Only transactions where the address appears directly in accountKeys. Default.

all

Also includes transactions that reference any token account owned by the address, regardless of whether a balance change occurred.

balanceChanged

Like all, but only for token accounts where the pre/post token balance metadata shows a change. Useful for filtering to actual transfers and swaps rather than read-only account references.

Token ownership is determined from the meta.preTokenBalances and meta.postTokenBalances fields embedded in the transaction, not from a separate on-chain lookup.

When tokenAccounts is all or balanceChanged, the queried address may not appear in accountKeys at all for some results. The address is the owner of an account that participated β€” not a signer or fee payer in that transaction.

Signatures mode (transactionDetails: "signatures")

Response fields

Field
Type
Description

signature

string

Base58-encoded transaction signature.

slot

u64

The slot this transaction was confirmed in.

transactionIndex

number

The transaction's position within its block. Zero-indexed. Useful for deterministic ordering when multiple transactions share a slot.

err

object | null

null if the transaction succeeded. Otherwise contains the TransactionError object. Mirrors the err field from getSignaturesForAddress.

memo

string | null

Memo program message attached to the transaction, if any.

blockTime

i64 | null

Estimated Unix timestamp of the block. null for very old blocks where this wasn't recorded.

confirmationStatus

string

Confirmation status: processed, confirmed, or finalized.

paginationToken

string | null

Cursor for the next page. null when there are no more results.

Pagination

When a response includes a non-null paginationToken, there are more results. Pass the token in the next request unchanged to continue scanning from where the previous page ended.

Understanding the token structure

The pagination token is two numbers separated by a colon:

The first number is the slot - the block the last returned transaction was confirmed in. The second number is the transactionIndex - the zero-indexed position of that transaction within that block. So 250000101:5 means the 6th transaction in slot 250000101.

This two-part structure is more precise than a signature-based cursor. A signature alone doesn't tell you where in a block a transaction sat - two transactions in the same slot have different signatures but you can't derive their ordering from those signatures alone. The slot:transactionIndex pair pins the exact position in the ledger, so resumption is always deterministic.

How to Paginate?

A single request only returns up to your limit. When more transactions exist, the response contains a paginationToken you can pass into the next request to continue fetching. It's a "slot:transactionIndex" string pointing to the last result returned.

Last updated