Helius BlogMay 4, 03:50 PM
getTransfersByAddress: Parsed Solana Transfer History in 1 Call
getTransfersByAddress is a new Helius-exclusive Solana RPC method that returns parsed, human-readable token and SOL transfer records for a wallet address — with native filters for mint, time, amount, slot, direction, and counterparty.
It's the perfect counterpart to getTransactionsForAddress (gTFA). Where gTFA returns full transaction payloads, getTransfersByAddress returns concise transfer objects: who sent what, to whom, when, and how much.
Why do we need a transfer-specific RPC method?
Most wallet, payments, and portfolio products don't need the entire transaction payload. They need transfers.
So, what do they do? Each team writes a different version of the same transfer parser, and unfortunately most get the edge cases wrong.
Until now, building a clean Solana transfer history required devs to:
Pull signatures with getSignaturesForAddress
Fetch each signature with getTransaction
Parse pre/post balances, token balances, and inner instructions
Reconstruct transfers, handle SPL Token vs Token-2022 fee semantics, and untangle WSOL wrap/unwrap noise
Repeat across multiple pages, handle retries, and store results
Even with the getTransactionsForAddress method collapsing steps 1 and 2 into one call, steps 3–5 still fall on the developer.
Now, getTransfersByAddress does this work for you and returns the result as a structured list.
getTransfersByAddress Response
Each transfer object includes the signature, slot, block time, transfer type, sender, recipient, mint, amount (raw and UI), decimals, confirmation status, and precise instruction indices so you can map each transfer back to the source transaction.
{
"signature": "",
"slot": 315073428,
"blockTime": 1736159420,
"type": "transfer",
"fromUserAccount": "",
"toUserAccount": "",
"fromTokenAccount": "",
"toTokenAccount": "",
"mint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
"amount": "2500000",
"decimals": 6,
"uiAmount": "2.5",
"confirmationStatus": "finalized",
"transactionIdx": 35,
"instructionIdx": 1,
"innerInstructionIdx": 0
}
The type field tells you exactly what happened — transfer, transferFee, mint, burn, wrap, unwrap, changeAccountOwner, or withdrawWithheldFee — so you don't have to infer behavior from raw program data.
Why is parsing Solana transfers difficult?
A transfer in a Solana transaction isn't a single concept.
It's a category that hides a half-dozen edge cases, and getting any of them wrong corrupts your data.
SOL vs. WSOL
Native SOL and Wrapped SOL look like the same asset to a user, but they live in different parts of a transaction.
Native SOL moves through pre/post lamport balances on system accounts. WSOL moves through SPL token balances on token accounts.
A user swapping on Jupiter may wrap SOL into WSOL, swap WSOL for USDC, then never unwrap — leaving a WSOL token account behind.
From the user's perspective, they spent SOL. From the network’s perspective, there were three transfers and a wrap.
Worse, the wrap itself isn't a transfer