Query Smarter - Cherry and HyperSync in Action

Cherry is fully open-source. Dive into the code, browse the docs, or contribute at https://github.com/steelcake/cherry.

Developers face a recurring pain point as the blockchain ecosystem matures: accessing data efficiently at scale. Accessing blockchain raw data has long meant interacting with the JSON-RPC interface, the default protocol implemented by Ethereum nodes. This standard played a crucial role in supporting decentralized access. However, while running your own node remains the most decentralized option, most teams turn to node-as-a-service providers like Infura or Alchemy to avoid operational overhead. The result? An intermediary layer that remains constrained by the limitations of the EVM's interface: expensive, rate-limited, inefficient for historical data retrieval, and not designed for high-throughput data workflows. JSON-RPC doesn't cut it unless you care for maximum decentralization when building analytics tools.

As a solution, many providers have built alternatives with custom-made APIs to overcome the limitations of JSON-RPC. While faster, they introduce a new problem: a lack of standardization. Each provider defines its own schema and semantics, leading to fragmentation and vendor lock-in.

At Cherry, we've also embraced moving beyond JSON-RPC—but with a different philosophy. Instead of contributing to the growing sprawl of proprietary APIs, Cherry defines a generalized, open-source query layer built on shared schemas and consistent semantics. It standardizes how developers interact with blockchain data by exposing it through familiar, table-like abstractions—blocks, logs, transactions, traces, and more.

This approach allows developers to express precise, efficient queries. You can filter, query, and select precisely what you need—e.g., "give me only Transfer events from this wallet between block X and Y"—without pulling unnecessary data. This cuts down bandwidth usage and makes pipelines significantly more efficient. And because Cherry is designed to be provider-agnostic, developers can switch between or combine multiple providers without rewriting everything.

HyperSync: Raw Speed with Minimal Friction

Among the most powerful providers integrated with Cherry is HyperSync by Envio. Built from the ground up in Rust, HyperSync is a next-gen data engine that replaces traditional RPC endpoints with a blazing-fast, flexible, and with access to both historical and real-time blockchain data. Together, Cherry and HyperSync represent a shift in how developers think about blockchain data ingestion: not as a slow stream of JSON responses but as a queryable, high-performance dataset that can power real-time applications, analytics, and insights across chains.

HyperSync isn't limited to Ethereum—it supports over 70 EVM-compatible chains (including Arbitrum, Optimism, Polygon, and Base), making it ideal for cross-chain applications and multi-network tooling.

Designing Targeted Data Requests with Cherry

Cherry's query interface drew inspiration from the HyperSync API, which is one of the reasons they work so well together. Let's check an example of how to use it in Cherry.

# Defining a Provider
provider = ProviderConfig(
    kind=ProviderKind.HYPERSYNC,
    url="https://eth.hypersync.xyz",
    stop_on_head=True,
)

# Querying
query = IngestQuery(
    kind=QueryKind.EVM,
    params=Query(
        from_block=from_block,  # Required: Starting block number
        to_block=to_block,  # Optional: Ending block number
        include_all_blocks=False,  # Optional: Weather to include blocks with no matches in the tables request
        fields=Fields(  # Required: Which fields (columns) to return on each table
            transaction=TransactionFields(  # Required: Transaction fields
                block_number=True,
                transaction_index=True,
                from_=True,
                to=True,
            ),
            log=LogFields(  # Required: Log fields
                block_number=True,
                block_hash=True,
                transaction_index=True,
                log_index=True,
                transaction_hash=True,
                address=True,
                topic0=True,
                topic1=True,
                topic2=True,
                topic3=True,
                data=True,
            )
        ),
        transactions=[ # Optional: List of specific filters for instructions
            TransactionRequest(
                from_=["0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"],
                include_logs=True,
            )
        ],
    ),
)

An example of query in Cherry

The IngestQuery structure is designed to work with large blockchain datasets efficiently and precisely. It allows you to define what data to pull, how to narrow it down, and which specific fields to retrieve. Every query is scoped to a particular blockchain environment — Ethereum-compatible (EVM) or Solana-based (SVM) — via a QueryKind.

Selecting Only the Fields That Matter

Instead of retrieving full tables, the query object requires you to explicitly opt into each data field you want to retrieve, keeping responses lightweight and minimizing unnecessary processing. Field selection is handled independently for each table—for example, BlockFields, LogFields and TransactionFields—so you can precisely tailor what you get back.

Filtering Data at the Source

Beyond selecting columns, you can use request objects like TransactionRequest to filter rows based on meaningful conditions. Most fields are queryable. Want to isolate only certain transactors in a specific block range? You can filter by from_ ('_' to avoid keyword) and to. Each request targets one table and defines what subset of rows should be returned.

Controlling Table Inclusion

The blocks table can be included unconditionally by setting flags such as include_all_blocks=True. All other tables require either a dedicated request (e.g., TransactionRequest, LogRequest allowing row filtering) or an inclusion flag (like include_transactions=True, include_logs=True) that follows the [table]Request logic. These controls let you combine requests to shape multi-table responses, where each table includes only relevant, filtered data.

Wrapping Up: A Smarter Stack for Blockchain Data

Once your query is constructed, the response will reflect both the fields you selected and the row-level filters you've defined. For instance, the above query in the block range and return:

• A filtered set of transactions, where from address is “0xd8d…”
• The logs included in the above transactions.

This level of customization makes querying a powerful tool for building focused, high-performance data pipelines across EVM and SVM chains.

We've published a detailed walkthrough of how to build pipelinse in a dedicated post. If you want to see how the pieces come together, check out:

👉 Indexing Solana’s Jupiter with Cherry — An End-to-End Tutorial in Python.

Final Thoughts

With Cherry, we introduce a standardized, open-source query layer that simplifies how teams interact with on-chain data—structured, precise, and provider-agnostic. And with HyperSync, that same query layer is powered by one of the fastest data engines available today, delivering massive performance gains across 70+ chains without sacrificing flexibility. By combining Cherry's standardization layer with HyperSync's speed and flexibility, developers no longer need to compromise between ease of use, performance, and openness.

Whether you're building analytics dashboards, running large-scale ETL pipelines, or monitoring real-time activity across multiple networks, this stack gives you the speed and structure to get the job done.