Hedera will make block streams the default network data output format in September 2026, creating a required infrastructure update for mirror node operators and direct consumers of record files. The change will establish block streams as the canonical format for ingesting Hedera network data, replacing the legacy record-stream model for new data after the cutover.
The update is tied to Hedera’s planned v0.77 mainnet upgrade and requires operators to deploy hiero-mirror-node v0.155.1 or a later cutover-compatible release before the transition. Operators that remain on older versions risk losing access to new automated network data once record streams stop receiving fresh output after the September deadline.
Mirror Node Operators Face the Main Upgrade Burden
The change does not apply equally to every builder using Hedera. The required action falls on commercial and self-hosted mirror node operators, along with teams that consume record files directly. Hedera said application developers using HAPI, SDKs, the mirror node REST API, explorers or JSON-RPC Relay are not directly required to update application code for this cutover, making the impact primarily an infrastructure and data-ingestion issue.
Under the current model, network output is distributed across several stream types and supporting files. Block streams consolidate that architecture by packaging transactions, transaction results, consensus events, state changes and network signatures into a unified block-based format. In practical terms, the network’s historical output becomes easier to consume, verify and route through downstream infrastructure.
That restructuring matters for indexers, analytics providers, explorers and data services that depend on timely mirror node synchronization. Rather than processing multiple legacy file types separately, operators will move toward a single block stream pipeline, with mirror nodes reading from block nodes and cloud storage available as a fallback. The goal is cleaner data delivery without changing ordinary user transactions.
September Cutover Requires Production Readiness
Hedera’s timeline places the first stage of the migration in July 2026, when consensus node v0.75 begins streaming wrapped record blocks through block nodes. The more important deadline comes in September 2026, when consensus node v0.77 is expected to activate the TSS cutover and make block streams the canonical output format. Mirror node operators must be ready before that second stage.
The operational checklist is narrow but important. Teams need to upgrade to the required mirror node version, validate ingestion in staging against testnet and previewnet, confirm access to the new block stream buckets, and verify synchronization after the cutover. Hedera said older releases will stop ingesting new data at the transition point, making version compatibility the key dependency for uninterrupted service.
Historical record files will remain available through the legacy bucket, but new data will no longer be written there after the cutover. That distinction is important because the update does not erase past network history; it changes how new finalized network output is produced and distributed. The legacy format becomes historical infrastructure rather than the live data path.
For Hedera’s infrastructure stack, the move is less a consumer-facing feature than a backend standardization step. Block streams are designed to reduce duplication, improve verification, and align mirror node output more closely with the network’s finalized block architecture. The immediate market takeaway is operational continuity, not a token event or application-layer launch.
The clean reading is straightforward: Hedera is moving its live network data pipeline from record streams to block streams by default in September 2026. Mirror node operators and record-file consumers must complete the required upgrade ahead of the cutover, while most application developers are not expected to make direct code changes. The transition turns block streams into Hedera’s primary data-ingestion standard for the next phase of network infrastructure.