TL;DR

  • Today, fetching wallet history on Solana requires custom loops: get all token accounts, fetch signatures for each, then fetch the transactions
  • And while you're paying for every call and byte returned, you're also merging, deduping, and sorting all of it client-side
  • Alternatives exist, but until now they've been closed-source and priced at a premium
  • We fixed that with getTransactionsForAddress (gTFA), live on all Triton endpoints in paid beta:
    • Purpose-built for wallet history, token-launch analytics, compliance, and portfolio tracking
    • Allows you to filter server-side by slot, blockTime, signature, and status; sort either direction; resume the next call where the last one ended via paginationToken
    • Billed as a standard RPC call: $10 per million queries + $0.08 / GB
    • Open-sourcing soon under AGPL, so any provider can offer the same method

The wallet-history problem

If you've built a wallet, a portfolio tracker, or a tax tool on Solana, you've written this loop: call getSignaturesForAddress to find signatures for an account, then call getTransaction once per signature to load each one. With Solana processing tens of millions of transactions a day, that alone makes deep history slow to resolve and expensive to fetch.

The account model multiplies it.

On Solana, a wallet signs transactions but doesn't hold tokens. Native SOL token sits in the wallet itself, while everything else lives in associated token accounts (ATAs) it owns. getSignaturesForAddress only returns transactions that reference the address you passed, so a USDC payment to your wallet never shows up on gSFA(wallet). For that, you need to run another loop.

End-to-end, the complete workaround will look like this:

  1. Call getTokenAccountsByOwner to find the wallet's token accounts
  2. Call getSignaturesForAddress for the wallet and each of its token accounts
  3. Merge and deduplicate results
  4. Sort chronologically
  5. Loop getTransaction once per signature to load the data

And since the merging and deduplication all happen client-side, you can't ask for the 50 most recent transactions either. To get the right answer, you fetch everything, pay for it, and then trim what you don't need.

A single-call replacement has existed on Solana for a while, but only as a closed-source method outside the JSON-RPC standard and priced at a premium.

We wanted to fix that on Hydrant, our ClickHouse-based ledger backend, and ship an open, spec-compliant, and affordable alternative.

And today, it's finally live: Triton's getTransactionsForAddress.

Key features

The reason we can serve a single-call address-history method at standard RPC pricing comes down to database optimisation.

We rewrote our entire storage layer on ClickHouse, physically sorting tables exactly as builders query Solana. Time-ordered scans, slot-ranged filters, and paginated reads now hit pre-sorted partitions instead of scanning the whole archive, cutting both latency and cost.

Flexible chronological sort

Read history in either direction. sortOrder: asc walks forward through time, useful for token-launch playback or funding traces. sortOrder: desc returns the most recent transactions first for use cases like recent-activity feeds.

Server-side filtering

Hydrant runs your filters server-side and only sends back the matches, so there's no extra data to download or pay for. You can filter the ledger using gte, gt, lte, and lt on any of these:

  • slot: when you know the exact slot range you want
  • blockTime: a Unix timestamp range, for monthly reports, daily windows, or "everything since last Monday." eq matches an exact second
  • signature: pick up from a known signature without re-walking everything before it
  • status: succeeded, failed, or any (default). Skip transactions you don't need

Combine them into a single filters object to ask precise questions, such as "all successful transactions in January 2025 for this wallet," in one request.

Full transaction data with ATAs in one call

Hydrant indexes transactions by the owner field at ingest time, delivering both the decoded transaction data and the wallet's ATA history in a single response.

transactionDetails: "full" returns up to 100 decoded transactions per page, with the encoded body and metadata.

Change tokenAccounts setting to get the ATA activity:

  • none (default): ATAs not included, only the transactions referencing the address directly
  • balanceChanged: includes transactions that modified the balance of a token account owned by the address. Filters out unrelated operations like fee delegations
  • all: includes every transaction touching any token account the address owns
💡
gTFA matches any token account whose owner field is the queried address, read from token balance metadata.

Cursor-based pagination

When a result set exceeds a page (1,000 signatures or 100 full transactions), the response includes a paginationToken in the form of "slot:position". Hand it back on the next call, and Hydrant will resume exactly where the last page ended, with your filters and sort order preserved.

Performance

Per-call, getTransactionsForAddress is as fast as the rest of Hydrant. The bigger win is the call count itself.

To show the difference, we benchmarked getTransactionsForAddress against the classic getSignaturesForAddress + getTransaction loop on exchange wallets:

Getting started

You can call getTransactionsForAddress on Triton today since existing endpoints already route to Hydrant by default. Once Hydrant ships open-source under AGPL, any provider running it will be able to offer the same method.

What to watch in production

If something looks off after you ship with gTFA, start by checking the following:

  • A paginationToken in the response indicates that more results are available. Walk it until it comes back null to get the complete dataset
  • The default tokenAccounts: none skips ATA activity. Set it to balanceChanged for wallet-history features
  • The tokenAccounts filter relies on metadata added at slot 111,491,819 (December 2022). Older ATA history won't surface
  • transactionDetails: "full" caps at limit: 100; signatures caps at 1000
  • paginationToken is scoped to the query that produced it. Don't reuse it across requests with different filters

When to reach for something else

gTFA is built to pull batches of historical data for a specific address: wallet history, token-launch analytics, compliance reports, and portfolio trackers.

If your workload looks more like one of these, the purpose-built tools are the right call:

  • Live activity tracking. Use Yellowstone gRPC (Dragon's Mouth) for sub-slot updates without polling
  • Reliable live indexing. Use Fumarole for indexers and compliance pipelines that prioritise 100% completeness and accuracy over raw speed
  • Historical indexing. Use Old Faithful (the only verified, public Solana ledger) with Anza's Jetstreamer for streaming it at over 2.7M TPS, free and on your own hardware

Further reading