Changes to the Hedera-Operated Mirror Node

Recent changes to the Hedera Mirror Node are expected to impact HashScan and the mirror node REST API. The changes are part of ongoing efforts to support the scalability and reliability of the mirror node service.

Who Is Affected?

These changes impact users of the Hedera-operated mirror node. Developers using the mirror node REST API with the Hedera-operated mirror node and HashScan users may be impacted if they are looking up historical data beyond 60 days.

Users of third-party mirror node services are not affected.

What Are the Changes?

These changes affect the viewing of historical data on HashScan beyond 60 days. Solutions are under development to minimize user impact.

The following mirror node REST API endpoints are affected, limiting their results to a 60-day time range:

• /api/v1/accounts/{id}

• /api/v1/contracts/results

• /api/v1/contracts/results/logs

• /api/v1/transactions

The API endpoints above will not show transactions older than 60 days when a timestamp parameter is not included in the query. The API server adds an implicit timestamp range [now - 60d, now] to query the database. A user can still view data older than 60 days using a timestamp range [T1, T2] provided in the query. The REST API will limit the query to:

• [max(T1, T2-60d), T2] if order is desc

• [T1, min(T1+60d, T2)] if order is asc

“links.next” and the RFC 5988 header will continue to be supported, but their operation will be altered due to the 60-day limitation. This means that if a query is made without a specified time range, the given API will return all results for only the last 60 days (on top of the 100-result limit). Here are two scenarios to help understand the delta of the current state vs. the updated state.

Scenario 1:

A user makes 10 transactions on the first day of each month for the past 10 months.

• Current State: When querying the history, the API will return 100 results for the last 10 months.

• Updated State: When querying the history, the API will return 20 results covering the last 60 days (months 9 and 10) along with a links.next hyperlink. The user will then use the hyperlink to get 20 results for months 7 and 8, and so on for months 5 and 6, 3 and 4, and 1 and 2. Once the final 20 results are delivered for months 1 and 2, then no “links.next” hyperlink will be present, indicating no more results are available.

Scenario 2:

A user has only ever made 1 transaction from their account 5 months ago.

• Current State: When querying the history the API will return 1 result.

• Updated State: When querying the history, the API won’t return any results covering the last 60 days (months 1&2), but a “links.next” hyperlink will indicate that more results are available. The hyperlink is used, and again, no results are returned (months 3&4); however, a “links.next” hyperlink again indicates the availability of more results (month 5). Finally, the hyperlink is used, and the transaction is returned without a “links.next” hyplerlink, indicating that no further results are available.

Call to Action:

1. Use the “links.next” or RFC5988 functionality.

2. When using the affected mirror node REST API endpoints to access history beyond the last 60 days, you should:

   1. Specify time ranges in any time period in the API request, but spanning no more than a 60-day range.

   2. Use the “links.next” or the RFC 5988 functionality to page through the history, keeping the following conditions in mind:

      1. Results returned will be within a 60-day time range

      2. No more than 100 results will be displayed per return

Timeline

These changes will be in effect on testnet and mainnet mirror node services during the week of September 16, 2024.

If you have any questions or need support, please reach out on Discord.