Skip to main content

Overview

getTransfersByAddress is a Helius-exclusive RPC method that returns parsed, human-readable token and native SOL transfer objects for a wallet address. It is not part of standard Solana RPC. It is focused on transfer activity, so it returns concise transfer records instead of full transaction payloads. Each record is normalized with parsed owner and token accounts, mints, raw amounts, decimals, UI amounts, instruction positions, and confirmation status, so you can reconcile balance movement without reimplementing Solana token parsing. This method requires a Developer plan or higher and costs 10 credits per request.

Parsed transfer objects

Return human-readable transfer records with parsed accounts, amounts, decimals, and transfer types.

Reconciliation ready

Model SOL, WSOL, Token-2022 fees, mints, burns, and account owner changes so balances can be reconciled accurately.

Mint, time, and amount filters

Narrow transfer history by mint address, block time range, or raw amount range.

Counterparty filters

Filter transfers by sender or recipient with with and direction.

When to use this

Use getTransfersByAddress when you need:
  • Wallet transfer history for payments or transfer monitoring
  • Portfolio activity and token movement analytics
  • Balance reconciliation you can trust for ledgers and accounting
  • Counterparty-specific transfer reports (who sent or received what)
  • Normalized SOL/WSOL, Token-2022 fee, mint, and burn handling without writing a parser
Use getTransactionsForAddress instead when you need full transaction data, signatures-only history, or non-transfer activity. A common pattern is to page through transfers here, then fetch the underlying full transactions with batched getTransaction calls (see Fetch full transactions for transfer rows).

Accuracy and reconciliation

getTransfersByAddress is built for applications that need transfer history they can trust for ledgers, payment tracking, portfolio activity, and balance reconciliation. Instead of returning raw transaction payloads and leaving every edge case to your parser, the API returns normalized transfer objects. The response explicitly models the transfer cases that commonly make Solana history difficult to reconcile:
  • Standard SPL token and native SOL transfers.
  • Token-2022 transfers with withheld fees, represented as ordinary transfer rows with separate fee fields.
  • Mints and burns, represented as transfers with a null sender or recipient.
  • SOL wrapping and unwrapping behavior, with a default mode designed to avoid noisy lifecycle rows.
  • Token account owner changes via SetAuthority.
  • Token-2022 withheld fee withdrawals.
  • Intermediary account flows, returned as the underlying transfer records instead of being collapsed into a guessed net movement.
For supported visible transfer events, this lets you reconcile balance movement without reimplementing Solana token parsing logic. Known exclusions, such as hidden SOL movements inferred only from balance changes, are called out in Limitations.

Quickstart

Request parameters

Pass the wallet owner address, not an associated token account (ATA). The API finds transfer activity for token accounts owned by that wallet.
string
obrigatório
Base58-encoded owner wallet address to query transfers for. Pass the wallet owner address, not an associated token account (ATA).
object
Optional configuration object for filtering, pagination, commitment, ordering, and SOL/WSOL behavior.
string
Filter by counterparty address. Returns only transfers to or from this address.
string
padrão:"any"
Filter by transfer direction relative to address.
  • in: transfers received by address
  • out: transfers sent by address
  • any: incoming and outgoing transfers
string
Filter by token mint address. Use So11111111111111111111111111111111111111111 for native SOL and So11111111111111111111111111111111111111112 for WSOL.
string
padrão:"merged"
Controls how native SOL and WSOL are represented.
  • merged: WSOL is treated as native SOL. Wrap and unwrap lifecycle rows are excluded, and WSOL mint values are rewritten to the native SOL mint.
  • separate: WSOL is preserved as a distinct mint, and wrap and unwrap lifecycle rows are included.
object
Additional filters for amount, block time, and slot.
number
padrão:"100"
Maximum number of transfers to return. Range: 1 to 100.
string
Cursor from the previous response for pagination.
string
padrão:"finalized"
Data commitment level.
  • finalized
  • confirmed
number
The minimum slot that the request can be evaluated at
string
padrão:"desc"
Result ordering.
  • desc: newest first
  • asc: oldest first

Response

Response field details

  • fromUserAccount and toUserAccount are always present. When a side does not exist, the value is null.
  • fromTokenAccount and toTokenAccount are only included when token-account endpoints are meaningful for the row. They are omitted completely for native SOL transfers.
  • Mint transfers are one-sided: fromUserAccount is null, and they can only be returned as inbound transfers for the recipient.
  • Burn transfers are one-sided: toUserAccount is null, and they can only be returned as outbound transfers for the burning owner.

Filters

Use comparison filters for numeric range queries. All comparison fields are optional and can be combined.

Transfer types

The type field identifies the transfer behavior represented by each row.

Transfer types and instructions

SOL and wSOL behavior

SOL exists on Solana in two forms that often appear together in real user activity:
  • Native SOL is the chain’s native asset. It lives directly in a wallet or account as lamports. One SOL is 1,000,000,000 lamports.
  • Wrapped SOL (WSOL, often written wSOL) is an SPL token representation of SOL. It uses the WSOL mint So11111111111111111111111111111111111111112 and lives in a token account, like USDC or any other SPL token.
Users and applications wrap SOL when they need SOL to behave like an SPL token, usually for DeFi, swaps, token-account-based accounting, or program interfaces that only accept SPL tokens. Wrapping typically funds a token account with native SOL and syncs it into WSOL. Unwrapping closes the WSOL token account and returns the SOL to a lamport destination. That lifecycle can create confusing history if you are trying to answer a simple question like “how much SOL moved between this wallet and someone else?” A wrap or unwrap often moves SOL between accounts controlled by the same owner. If those lifecycle rows are shown as ordinary transfers by default, apps can double count activity or show internal bookkeeping as external payments. By default, getTransfersByAddress uses solMode: "merged". In this mode:
  • Native SOL and WSOL are treated as one SOL asset when querying by So11111111111111111111111111111111111111111.
  • WSOL transfer rows are normalized to the native SOL mint so SOL-denominated history is easier to reconcile.
  • Wrap and unwrap lifecycle rows are excluded because they usually represent movement between accounts controlled by the same owner, not a payment to another user.
  • SOL and WSOL transfers between different owners are still represented as transfers.
  • Rent recovered from CloseAccount is represented as a native SOL unwrap row when close-account lifecycle rows are returned.
Use solMode: "separate" when you need WSOL as a distinct SPL token mint or want to inspect wrap and unwrap lifecycle records. In this mode, WSOL keeps the mint So11111111111111111111111111111111111111112, and wrap/unwrap records are returned with type: "wrap" or type: "unwrap". For WSOL account closures in solMode: "separate", unwrap records for the WSOL mint represent the remaining WSOL token balance returned as SOL. Rent refunded from the closed token account is returned as a separate native SOL unwrap row.

Token-2022 transfer fees

Token-2022 TransferCheckedWithFee instructions are represented as one transfer record with type: "transfer". The destination amount is returned in amount; withheld fee details are returned in feeAmount and feeUiAmount. For transfers with fees, the source is debited amount + feeAmount, while the destination is credited amount.

Examples

Filter by USDC

Incoming transfers from a sender

Amount and time range

Paginated request

Fetch full transactions for transfer rows

getTransfersByAddress returns parsed transfer rows, not full transaction payloads. If you need the full transaction for every transfer, page through transfers first, dedupe by signature, then fetch the full transactions with batched getTransaction calls. getTransfersByAddress is not batchable across multiple owner addresses. Query one owner address at a time, then batch the resulting getTransaction requests by signature. A single transaction can emit multiple transfer rows, so always dedupe signatures before fetching transactions.

Limitations

  • Failed transactions are not included in V1.
  • Hidden SOL movements inferred only from balance changes are not supported in V1.
  • harvestWithheldTokensToMint is not supported in V1 because it does not indicate the collected amount.
  • Intermediary account flows are not reduced. If a transaction moves funds through intermediary accounts, the underlying transfer records are returned.
  • Not batchable across multiple owner addresses. Query one owner at a time.

Next steps

getTransactionsForAddress

Full transaction history with filtering, sorting, and token-account support.

API reference

Full request and response schema for getTransfersByAddress.

Indexing guide

Backfill and sync transfer data into your own index.

Historical data overview

Compare all Solana historical data methods.