Helius says it has re-engineered how Solana’s historical data is stored and retrieved, introducing a new archival backend and an RPC method that collapses today’s multi-call workflows into a single request.

CEO Mert Mumtaz framed the change in sweeping terms: “today, Solana changes forever… we’ve solved the biggest data/RPC problem that exists,” he wrote, arguing that the status quo—historical queries hitting Google Bigtable—has been “slow,” “expensive,” and “inflexible.”

What This Means For Solana

Mumtaz highlighted the practical pain point every Solana indexer or wallet developer knows: getting the “first tx for a Solana address without looping back endlessly” and pulling the “most recent 100 txs for an address” both require chaining calls and traversals that can balloon into “thousands of RPC calls.” “Not anymore,” Mumtaz said.

At the heart of the release is a Helius-exclusive RPC method, getTransactionsForAddress, backed by a distributed archival storage layer that the company claims is “1,000x faster, more flexible, and more scalable.” Functionally, the method merges today’s common two-step pattern—getSignaturesForAddress to enumerate signatures, then getTransaction to hydrate details—into one call that can return fully decoded transactions, with bidirectional time ordering and range filters by slot or timestamp.

Helius’ documentation spells out that it enables reverse search without back-traversal and supports pagination tuned for large, active accounts. The company also emphasizes that this is not a core Solana RPC addition; it’s a proprietary extension available on Helius nodes, priced at 100 credits per request on Developer plans and above.
Performance claims span both the new method and legacy endpoints, with Helius saying getBlock, getTransaction, and getSignaturesForAddress are now “10x faster,” while the archival s

Go to Source to See Full Article
Author: Jake Simmons