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

Code Examples

A few code examples related to getTransactionsForAddress on Solana

Fetching Transactions by Order

Traverse an address's full history forwards in time β€” something that wasn't possible with a single getSignaturesForAddress call.

Newest first (default)

Fetches the 100 most recent transactions for an address, starting from the latest and going backwards in time. This is the default behavior β€” useful when you want to see what happened most recently on a wallet.

const response = await fetch("https://rpc.shyft.to?api_key=YOUR_API_KEY", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "getTransactionsForAddress",
    params: [
      "5quBtoiQqxF9Jv6KYKctB59NT3gtJD2Y65kdnB1Uev3h", // base58 address to fetch transactions for
      {
        sortOrder: "desc", //sort order descending (default behavior)
        limit: 100
      }
    ]
  })
});

const { result } = await response.json();
result.data.forEach(tx => console.log(tx));

Oldest First

Fetches transactions starting from the earliest recorded activity for the address and moves forward in time. Useful when you want to replay an address's history from the beginning - for example, reconstructing the full transaction timeline of a wallet, or fetching its first ever transaction.

Fetch token balance changes for an owner address

The balanceChanged filter tells the server to find all SPL token accounts owned by the queried owner address and return only the transactions where a token balance actually changed.

Fetch transactions within a slot range

The slot filter tells the server to return only transactions confirmed within the given slot range.

Since slot production speed varies slightly (validator skips, network conditions), don't rely on these estimates for precision time-based queries. If you need exact time ranges, use blockTime with Unix timestamps instead β€” it's more reliable for wall-clock scoping. Use slot when you already have a known reference slot from a previous query or transaction.

Fetch successful transactions only

The status: "succeeded" filter tells the server to return only transactions that executed successfully - where meta.err is null. Failed transactions are excluded from the results.

Fetch full transaction payloads

Setting transactionDetails: "full" returns the complete transaction payload - instructions, accounts, pre/post balances, logs, and metadata.

Common Filters for Reference

status : Filter by whether the transaction succeeded or failed on-chain. Use succeeded to exclude failed transactions, failed to inspect errors only, or any to return both. Maps directly to whether meta.err is null or not.

slot : Scope your query to a block range. Useful when you know roughly when an event happened and want to avoid scanning the entire address history.

blockTime : Same as slot but uses wall-clock Unix timestamps instead of slot numbers. Convenient when working with human-readable date ranges. Less reliable than slot for very old blocks where blockTime may be null.

tokenAccounts : Expand coverage to SPL token accounts owned by the queried address. Set to balanceChanged to include only transactions where a token balance actually changed - useful for transfer and swap history. Set to all to include any transaction that touched an owned token account regardless of balance change.

signature : Bound your query relative to a known transaction signature's ledger position. Rarely needed in practice - prefer slot for range scans and paginationToken for resuming pages.

Last updated