Hedera deploys v0.78.1 with cross-ledger protocol still disabled

Hedera completed its mainnet upgrade to consensus-node version 0.78.1 on October 16, putting software that contains an implementation of the Cross Ledger Protocol, or CLPR, into production nodes. The important limitation is in Hedera’s own release notes: CLPR remains behind a feature flag.

That distinction separates deployed code from an activated network service. The upgrade advances the protocol’s path toward cross-ledger messaging, but it does not show that users can open CLPR channels, transmit messages between ledgers or move assets through the system today.

What changed on mainnet

Hedera’s status service recorded the maintenance beginning at 17:00 UTC on October 16. It marked the network available again at 17:05 UTC while verification continued, then declared the upgrade completed at 17:26 UTC. Those timestamps describe the maintenance window reported by Hedera; they are not a measurement of transaction latency, application downtime or validator performance.

The status page identifies the live consensus-node version as 0.78.1. Hedera’s linked release documentation, however, is organized under release 0.78 and currently lists build 0.78.0 rather than a separate change log for the 0.78.1 patch. That documentation gap prevents a precise public accounting of which patch-level changes distinguish the deployed build.

For the broader 0.78 release, the notes say developers implemented CLPR behind a feature flag. They also list an increase in the maximum number of consensus topics from 1 million to 2 million, changes to block-node request timeouts and buffering, and a revised block-root hashing structure. The topic figures are configured protocol limits described by Hedera, not observed topic counts or evidence that network use doubled.

What CLPR is designed to do

CLPR is an asynchronous messaging design for independent ledgers. Its specification describes channels between networks, endpoint software that transports proofs and messages, verifier contracts that evaluate another ledger’s committed state, and connectors that fund execution on destination networks.

The design is intended to avoid depending on a separate bridge validator network. Instead, participating ledgers verify state proofs using ledger-specific verifier logic. Messages can carry arbitrary data, potentially supporting contract calls, token-related workflows, oracle updates or application messages.

Those are design capabilities, not results established by Friday’s upgrade. The specification itself warns that applications must confirm they are using the intended channel and peer ledger. Different networks also require compatible proof systems, verifier implementations, endpoint infrastructure and operational configuration before useful communication can occur.

The CLPR specification says the protocol introduces no separate token. Connectors use the participating ledgers’ native assets to cover remote execution and may face protocol-defined penalties. No production connector set, fee market, active channel inventory or mainnet message volume was disclosed with the 0.78.1 deployment.

Activation is the next verifiable milestone

The most defensible reading is that Hedera has packaged CLPR code into the software now running on mainnet while retaining an operational control that keeps the feature unavailable. A feature flag lets maintainers ship and test code without exposing its functions to users; its presence should not be described as a CLPR launch.

The next material checkpoint is an attributable activation notice accompanied by public configuration details. After activation, evidence could include registered channels, supported peer ledgers, verified cross-ledger messages, disclosed verifier assumptions and measured reliability. Until those records exist, claims about adoption, bridge replacement, asset flows, security superiority or HBAR demand would run beyond what the October 16 deployment proves.

Hedera’s upgrade therefore matters as protocol preparation. It moves CLPR from specification and development into the mainnet software family, but leaves production availability and performance unestablished.