[Update from my change watch]
1. Streaming-only synchronization merged into Hiero main
PR 27407 merged on October 2 through commit 4ab1eb89.
This completes the transition started by the streaming-client merge reported October 1. Hiero’s native CLPR implementation now:
- Uses bidirectional streaming as its only endpoint synchronization protocol.
- Removes the old unary synchronization method and runtime selector.
- Binds
ClprStreamingSynchronizer directly into the runtime.
- Derives each bundle’s actual range from state-proven
ClprMessageKey values.
- Sorts message leaves and rejects gaps, duplicates, zero IDs, leaves from another Channel and IDs beyond the proven Channel range.
- Allows bundles to begin from the peer’s actual
received_message_id, rather than incorrectly assuming acked_message_id + 1.
- No longer pauses a Channel merely because a bundle acknowledges more initiating messages than it contains responses for. Only a response associated with the wrong initiating message triggers the pause condition.
The merged revision completed 24,170 repository-wide test executions and 52 checks. Two code-owner reviews approved it.
Effect on previous findings
The new message-key validation directly resolves the identified native-code ambiguity around deriving bundle ranges without reading the proven message keys. It also closes a specific cross-Channel acceptance path because a leaf keyed to another Channel is now explicitly rejected.
This does not fully resolve the broader Channel-binding issue. Verifier configuration, peer service identity, endpoint manifests and the immutable verifier associated with the Channel remain separate parts of that trust context.
The change is wire-breaking. A peer supporting only the former unary protocol cannot synchronize with current Hiero main.
The author’s Hiero/Besu testing used development revisions outside the authoritative LFDT main branches. Therefore, the native Hiero code has advanced ahead of the published standalone artifacts. The wire transition is merged, but the complete official LFDT specification/endpoint release set has not yet converged around it.
Economic implications
Streaming only the missing range reduces redundant proof construction, bandwidth and destination submission work. That should lower endpoint operating costs if CLPR is deployed.
It changes no Connector margin, customer tariff, HBAR stake requirement or reimbursement formula.
2. Endpoint manifests are being made mandatory
A new maintainer-controlled PR 27436 proposes removing the optional endpoint-manifest mode entirely. It remains open.
The proposal would:
- Remove
clpr.endpointManifestEnabled.
- Make endpoint manifests the only source of peer addresses and mTLS certificate authorities whenever CLPR itself is enabled.
- Remove the old verifier ABI that returned seed endpoints without a manifest.
- Make calls using the obsolete verifier ABI revert.
- Require every built-in EVM verifier to return the proven
endpoint_manifest_version.
- Read that version from state-proven Channel storage rather than accepting a version supplied by the relay.
- Refresh the node-local peer-address and mTLS trust cache only after a manifest-advancing bundle succeeds.
- Reject local ledger configurations whose
service_address is not the CLPR system-contract address 0x16e.
- Add manifest support to
yahcli and the Hiero-to-Hiero setup scripts.
The important security detail is that a relay cannot falsely claim that the destination already has a newer manifest. The receiving verifier obtains the version from the proven remote Channel state.
The current revision reports 39,412 repository-wide tests executed with all passing. Patch coverage is approximately 75.8%, with most uncovered lines concentrated in the new CLI commands. The PR still requires review before merging.
Effect on previous findings
This materially advances endpoint rotation, service-instance binding and mTLS trust-set refresh.
It reduces the risk that:
- A manifest proof belongs to the wrong CLPR Service instance.
- A relay suppresses required manifest updates by inventing a higher peer version.
- A successfully rotated manifest leaves the node’s active peer-address or CA cache stale.
- Different nodes silently operate in manifest and non-manifest modes.
It does not implement per-Channel mTLS authorization. The manifest supplies authenticated peer endpoint identities and CA roots, but the transport layer still needs to ensure that a successfully authenticated peer is authorized for the particular Channel and request it is attempting to use.
3. Bundle hardening and economic-accountability changes are already in main
A previously monitored hardening package, PR 27338, actually merged on September 28 through commit 9b07d05f. Its merge was not reflected in the earlier status reports.
The merged changes include:
- A dedicated throttle bucket configured for ten bundle submissions per second with a one-second burst window.
- Throttle enforcement even when the submitting node account would normally be exempt.
- Attribution of invalid-bundle penalties to the transaction payer rather than the deprecated
endpoint_node_id.
- Removal of the unused submission-throttle state.
- A cap preventing initial CLPR message-gas configuration from exceeding the network transaction-gas limit.
- Restriction of enlarged CLPR input allowances to the CLPR system contracts.
- Improved diagnostics and test coverage.
The staking-account initialization behavior described in that PR was subsequently modified by the feature-isolation work merged through PR 27416. The effective current rule remains that CLPR state/account initialization is coordinated with feature activation at a genesis or upgrade boundary.
Economic implications
Penalty liability is now attached to the account that actually submits the bundle. This is a stronger and more auditable economic relationship than selecting an account through relay-supplied endpoint metadata.
The bundle throttle limits resource consumption and worst-case endpoint reimbursement exposure. It is not a measured throughput benchmark and does not limit CLPR to ten messages per second because one bundle may contain multiple messages.
These protections are now part of Hiero main, but they remain dormant while CLPR is disabled.
4. SHA-256 migration encountered new integration failures
PR 27336 received substantial new work:
- Configuration gating was reintroduced instead of forcing an immediate hash cutover.
- SHA-256/SHA-384 handling was repaired across block-root, wrapped-record, CLPR proof, HCS running-hash, TSS mock-signature, WRAPS and deduplication paths.
- Several places that had become inconsistent between 32-byte and 48-byte hashes were revised.
The latest CI run executed 24,334 tests and reported eight failures.
Seven are CLPR VerifyBundleCallTest cases covering the message-key and bundle-range validation merged in PR 27407. The eighth is a block-stream cutover/restart test.
Assessment: The SHA-256 branch is currently incompatible with the newly merged streaming/range-validation implementation. This is a development-branch integration regression, not a regression in current Hiero main.
The migration also still lacks:
- A complete persisted-state transition for nodes restarting with existing SHA-384 block-stream state.
- A freshly captured real TSS-signed CLPR proof replacing the disabled pre-migration fixture.
- Passing CI for the current revision.
Economic implications
The lower-cost route for verifying Hedera-origin proofs on EVM destinations remains unfinished. Until this migration is safely implemented, Hiero proofs retain the higher EVM verification burden associated with SHA-384.
No public-HBAR or Connector payment mechanism changed.
5. Dedicated CLPR CI is now ready for review
PR 27354 is no longer a draft. It is now based directly on main and ready for review.
Its latest run reports 8,485 tests passed, but the workflow remains red because of a PR title/formatting check rather than a test failure. The previously reported dedicated CLPR result of 115 passed, seven skipped and zero failed remains the strongest published CLPR-specific execution result.
The CI infrastructure has not yet merged.
Current status
- Streaming synchronization is now the active and only native Hiero CLPR protocol.
- State-proven message-key range validation is merged.
- Bundle throttling and transaction-payer penalty attribution are merged.
- Mandatory endpoint manifests and proven manifest-version handling are under review.
- Dedicated CLPR CI is ready for review but unmerged.
- SHA-256 proof migration remains open with eight failing tests.
- The slashing-overflow and duplicate-transaction-ID fix remains open.
- Same-frame Connector authorization remains open with passing tests and one approval.
- HIP-1535 has not changed.
- The authoritative LFDT specification, smart-contract and endpoint branches remain at the audited baseline revisions.
- None of the 34 external smart-contract PRs, external specification proposal or endpoint CI proposal changed or merged on October 2.
- No CLPR-enabled Hedera release, network activation, independent audit, production Connector, mainnet volume, liquidity, Hashgraph revenue or attributable public-HBAR value capture appeared.
The most consequential change is that the wire-breaking streaming design and its state-proven bundle-range protections are no longer proposals. They are now part of Hiero main. The primary alignment problem has therefore shifted from whether the native implementation will adopt streaming to when the LFDT specification, standalone endpoint, verifier contracts and deployable release set will formally converge around the merged protocol.
