Product Keynote: Helius - Get Transactions for Address

Querying historical transaction data on Solana has long been a developer's nightmare—expensive, slow, and confusingly complex. At Breakpoint 2025, Helius co-founder Nick Pennie unveiled a solution that could change everything: a new RPC method called "get transactions for address" that turns thousands of API calls into just one.

Summary

Helius, the self-described "API for internet capital markets," has built a completely new infrastructure for historical queries on Solana that eliminates the traditional reliance on Google Bigtable. The new system handles an index of over 2.3 trillion rows while delivering response times under 50 milliseconds—a feat that required reimagining the entire storage and retrieval architecture from the ground up.

The scale of the challenge Helius tackled is staggering. Solana has accumulated over 384 million blocks and 469 billion transactions, with the network currently processing more than 3,000 transactions per second—a number that continues to grow. The traditional approach using Bigtable not only proved expensive but also suffered from "hot partitions" under load, causing significant performance degradation when developers needed reliability most.

The new "get transactions for address" method solves multiple pain points simultaneously. It offers flexible sorting (both forwards and backwards in time), advanced filtering by time range and transaction status, and returns complete transaction data in a single response. What previously required thousands of individual RPC calls can now be accomplished with one request, saving developers both time and money while dramatically improving application performance.

Key Points:

The Problem with Historical Queries on Solana

Historically, developers querying Solana's past have relied on three main methods: get block, get transaction, and get signatures for address. When data falls outside the roughly four-day window held by Agave nodes, requests are routed to Google Bigtable—a solution that comes with significant drawbacks.

Bigtable is notoriously expensive for high-volume queries, and under heavy load, it experiences "hot partitions" that severely degrade performance. As Pennie colorfully described, the system essentially "catches on fire," leaving developers paying premium prices for substandard results. For applications requiring reliable historical data access, this represented an untenable situation.

The UX Nightmare of get signatures for address

The existing workflow for retrieving historical transaction data was remarkably cumbersome. A developer wanting to analyze a user's January 2024 transactions would first need to call get signatures for address repeatedly, walking backwards through time until reaching January. Then they'd need to call get transaction individually for every single signature returned.

This approach could easily result in thousands of separate RPC calls for what should be a simple query. Beyond being slow and expensive, the process was also confusing and error-prone. The method only supported backwards-in-time queries, adding another limitation to an already frustrating experience.

How get transactions for address Works

The new method consolidates everything into a single, flexible API call. Developers can specify an address, define a time range using block time filters, filter by transaction status (success or failure), and receive complete transaction data in one response. Pagination tokens handle cases where data exceeds a single response size.

Behind the scenes, Helius built the system using an inverted index architecture. Every transaction's addresses vector is flattened into address-signature pairs, creating an index spanning all of Solana's history. The team optimized range queries on this 2.3 trillion-row dataset to execute in under 50 milliseconds, regardless of the time period being queried.

Technical Infrastructure and Compression Achievements

Helius completely rebuilt the historical query infrastructure, replacing Bigtable with a custom solution incorporating a storage router, custom memory cache, Postgres, and Clickhouse. This architecture pulls data efficiently from different indices based on query requirements.

The compression achievements are particularly impressive. Solana's transaction data originally consumed approximately one petabyte of storage, which Helius compressed to 288 terabytes—a reduction of more than 70%. The same optimizations power get block and get transaction methods, with get block now executing in under 70 milliseconds.

Real-World Implementation: The New Explorer

Helius demonstrated the practical application through their new explorer interface. Users viewing a wallet can instantly skip to the oldest transaction, navigate to specific dates, and filter by transaction success status—all powered by the new get transactions for address method.

This visual implementation showcases how the technical improvements translate into tangible user experience gains. What would have been an agonizingly slow process of loading and paginating through historical data now happens nearly instantaneously.

Facts + Figures

• Solana has produced over 384 million blocks throughout its history

• The network has processed more than 469 billion transactions

• Current throughput exceeds 3,000 transactions per second and continues growing

• Helius's inverted index contains over 2.3 trillion rows

• Range queries execute in under 50 milliseconds regardless of time period

• Get block queries now complete in under 70 milliseconds

• Transaction storage compressed from 1 petabyte to 288 terabytes—a 70%+ reduction

• Agave nodes hold approximately four days of transaction data locally

• The new method eliminates the need for potentially thousands of individual RPC calls

• Helius replaced Google Bigtable entirely with a custom-built storage solution

Top quotes

• "We are the API for internet capital markets."

• "The problem, though, is that Bigtable is really expensive. And also, under load, you can have hot partitions, which causes performance degradation. Essentially, it catches on fire."

• "If this happens, you're paying a lot of money for poor performance, and you're going to be quickly out of a job."

• "You can quickly see how you end up chewing a lot of glass."

• "Now, if I've lost you, and this is confusing, good. That's the point. It is confusing. That's why we built get transactions for address."

• "The result here is that the whole thing is a lot more efficient. It means that you get to save money by making less RPC calls, and it's a whole lot faster."

Questions Answered

What is get transactions for address?

Get transactions for address is a new RPC method developed by Helius that allows developers to query historical transaction data on Solana with a single API call. Unlike the existing approach that requires calling get signatures for address followed by individual get transaction calls for each signature, this method returns complete transaction data in one response. It supports flexible sorting (both forwards and backwards in time), advanced filtering by time range and transaction status, and includes pagination for large result sets.

Why was querying historical data on Solana so difficult before?

The traditional approach relied on three methods—get block, get transaction, and get signatures for address—with data older than about four days stored in Google Bigtable. Developers had to make multiple sequential calls: first retrieving signatures, then fetching full transaction details for each one individually. This could mean thousands of RPC calls for a single query. Additionally, Bigtable was expensive and suffered performance problems under load due to hot partitions, and get signatures for address only supported backwards-in-time queries.

How much data does Helius's new system handle?

The system manages an inverted index containing over 2.3 trillion rows, derived from flattening address-signature pairs across Solana's entire 469 billion transaction history. The raw transaction data originally consumed approximately one petabyte of storage, which Helius compressed to 288 terabytes. Despite this massive scale, the system delivers range query responses in under 50 milliseconds and get block responses in under 70 milliseconds.

What technical architecture powers the new historical query system?

Helius built a custom storage infrastructure that completely replaces Google Bigtable. The system uses a storage router that pulls data from different indices, a custom memory cache, Postgres, and Clickhouse. The core indexing uses an inverted index approach where each transaction's addresses vector is flattened into address-signature pairs. Every optimization from code to networking has been tuned to achieve the sub-50 millisecond query times across 2.3 trillion indexed rows.

How does this benefit application developers and end users?

Developers save money by making dramatically fewer RPC calls—what previously required thousands of calls now takes one. Applications become faster because data retrieval happens in milliseconds rather than accumulating latency across multiple requests. The flexible sorting and filtering options reduce unnecessary data transfer and processing. End users experience this as faster-loading interfaces, instant navigation through transaction history, and the ability to quickly filter and find specific transactions.

Can you filter transactions by time period and status?

Yes, the new method supports advanced filtering capabilities. Developers can specify exact time ranges using block time parameters, such as requesting only transactions from January 2024. They can also filter by transaction status to see only successful transactions or only failures. Combined with bidirectional sorting (oldest-first or newest-first), these filters give developers precise control over the data returned, eliminating the need to fetch and process irrelevant transactions client-side.