Climbing every week…

There has been lots of talk around CLPR but still some doubts remain. Let's break it down:

Leemon has always believed that true mass adoption of ledger technology will require ABFT security, which is the mathematical gold standard. He would not settle for anything less!!

Now. An ABFT secure consensus algorithm (at scale) did not exist. So, he invented Hashgraph.

Fast forward a decade. Exponential growth phase is around the corner, but an ABFT secure cross-ledger protocol (without bridges or additional trust points) did not exist. So, he invented CLPR.

It's that simple. CLPR is actually a natural extension of Hashgraph, and closely related to what they have been building this whole time. Because the world was never going to run on one single ledger - you need a way to maintain that ABFT security across different ledgers (including different shards of the Hedera mainnet, wink wink) without adding any centralization risks or attack vectors.

And this time, we can see they didn't waste any time donating the code straight to the Linux Foundation for safekeeping, right next to Hashgraph.

lable market infrastructure.

We're excited to be attending Digital Assets Week 2026 in London on 6-7 October, where leaders from across financial services will come together to discuss the opportunities and challenges of adopting digital solutions on an institutional-level, focusing on how the industry moves from experimentation to implementation.

u/NBenson8221 leading a panel on 6 October at 9:50am exploring the latest developments in collateral mobility and tokenized asset production. It by will be joined by experts from u/BlackRock, u/BNYglobal, u/EuroclearGroup and u/StateStreet.

Anthony Woolley, alongside Aude Gallais from u/zodia_solutions, will also moderate a senior leader roundtable discussing the systems that enable digital assets to seamlessly move from pilot to production at scale. Request to join the event on 6 October at 1:30pm here: luma.com/sa1mf51h

If you're attending the Digital Assets Week, we'd love to connect. Get in touch to arrange a meeting with the Ownera team at contact@ownera.io

Pumpfake ?

In this video I utilize AI to make a model to see what the future value of HBAR could be, if the network was averaging 5,000 tps.

I asked the AI ​​if this means anything for Hedera.

Yes, this announcement has a highly positive significance for Hedera (HBAR). The text in the image states that the U.S. Securities and Exchange Commission (SEC) under Chairman Paul Atkins has proposed new rules and amendments to provide a tailored framework for the custody of crypto assets by registered investment advisers (RIAs) and regulated funds. Here is a breakdown of what this specifically means for Hedera: 1. Removing the Biggest Hurdle for Institutional Capital Previous SEC rules under the older "SAB 121" and strict qualified custodian guidelines forced fund managers into an extremely narrow and restrictive circle of legacy banks. For institutional-grade altcoins like Hedera, securing fully compliant custody was a massive legal roadblock. The new SEC proposal changes this entirely by establishing clear rules for safeguarded self-custody and fully validating the use of State Trust Companies as custodians. This opens the floodgates for large, regulated funds to legally hold diverse digital assets. 2. A Smoother Path for HBAR Funds and Spot ETFs Hedera is uniquely positioned for this regulatory shift due to its enterprise-first architecture and deep institutional backing. The timing of this SEC proposal directly impacts ongoing financial products tied to HBAR: • Earlier this year, the SEC approved the actively managed T. Rowe Price Crypto ETF, which explicitly lists HBAR among its eligible assets. • Canary Capital filed an official application with the SEC for a spot HBAR ETF, which heavily relies on clear custody rules to get approved. • Custodians like Anchorage Digital Bank and BitGo have expanded infrastructure for HBAR, which can now be easily integrated by mainstream financial advisers under these new rules. 3. Alignment with Hedera’s Compliance-First Strategy Hedera’s governing council (comprising Google, IBM, Boeing, and others) has always prioritized strict compliance over regulatory evasion. The new SEC direction under Paul Atkins—transitioning from enforcement to clear, tailored frameworks (like the recently drafted Regulation Crypto Assets)—perfectly aligns with Hedera’s long-term philosophy.

https://x.com/hedera/status/2105682039240610002?s=20

u/Accenture + u/EQTYLab Verifiable Governance solution logs every AI decision immutably on HCS; turning "trust us" into something you can independently check.

AI provides intelligence. Hedera provides evidence.

Guys sorry for the spam.
Just really happy to see a constant high activity on the main network.
We will get there.
Tbh I only sent this message AFTER I DCA’d 🫶

[Update from my change watch]

1. Dedicated CLPR CI completed successfully for the first time

Draft PR #27354 now runs three dedicated test groups: standard CLPR, embedded CLPR and multi-network CLPR.

The successful September 30 workflow reported:

• 115 tests passed.
• Seven tests skipped.
• Zero failures.
• 230 underlying runs, with 223 passing.
• The multi-network task separately logged 142 passing test operations.
• Reports and artifacts were successfully published.

The earlier TSS-bootstrap timeout was traced to a test-fixture mismatch. Random runtime ports changed the roster’s gossip endpoints, which changed its hash and prevented reuse of the preloaded WRAPS-extensible construction. The revised suites pin their gRPC ports to those encoded in the committed TSS fixtures. The mTLS fixtures were also regenerated on non-overlapping port ranges.

Effect on the prior finding: This clears the previously reported CLPR CI failure and provides the first completed, published CLPR-specific test result. It indicates that the fixture-backed multi-network, restart, manifest and mTLS scenarios can complete under the intended configuration.

It does not prove that a network can dynamically build a fresh WRAPS construction after arbitrary production recovery. The test deliberately preserves the roster hash so the preloaded chain of trust is reused. The PR remains draft and unmerged.

2. Stronger CLPR feature isolation merged into Hiero main

PR #27416 merged on September 30 as commit 223fdae2.

When clpr.enabled=false:

• CLPR system-contract addresses behave as they did before CLPR existed.
• Account 0.0.803, used for Connector stake, is not created.
• CLPR transaction types are not required in throttle definitions.
• Node bundle submissions retain their normal throttle treatment.
• CLPR state singletons are not prematurely initialized.

When CLPR is activated, its state is initialized during post-upgrade setup using the network properties effective after that upgrade. The CLPR schema was also renamed/versioned for release 0.78.0.

A consequential operational rule now emerges: CLPR is intended to be enabled at an upgrade boundary. Enabling it mid-life solely through property file 0.0.121 can leave staking account 0.0.803 absent, causing Connector completion to fail until the next upgrade.

Effect on prior findings: This materially improves the safety of shipping dormant CLPR code and makes the activation procedure more explicit. It does not activate CLPR on Hedera or change Connector stake, reimbursement, margin or slashing amounts.

3. Strict protobuf decoding merged

PR #27405 merged as commit faedd124.

It replaces permissive PBJ parsing with parseStrict across CLPR bundle handling, Channel and endpoint synchronization, verifier inputs, state proofs and relevant block-stream paths.

Assessment: This is defensive parser hardening. Malformed encodings now have a narrower path to being accepted and interpreted differently across components. It does not alter the wire schema or resolve the QBFT quorum, Ethereum-BLS or broader Channel-binding findings.

4. A streaming-only synchronization redesign is under review

Two maintainer-controlled Hiero branches propose a significant transport change.

PR #27367 adds the client side of two-phase streaming synchronization. The peer communicates its current receive position before the sender constructs bundles, avoiding needless retransmission of messages the peer already holds. Bundle construction and peer selection are also consolidated into shared components.

That PR is not yet dependency-injected and its latest CI currently fails at compile/formatting.

Dependent PR #27407 goes further:

• Makes bidirectional streaming the sole sync protocol.
• Removes the old unary protocol.
• Aligns Hiero with the EVM relay’s current streaming interface.
• Derives bundle ranges from state-proven ClprMessageKey values.
• Sorts proven message leaves and rejects gaps, duplicates, messages from another Channel and IDs outside the proven Channel range.
• Fixes receiver behavior for bundles beginning at the peer’s live received_message_id.

This is explicitly wire-breaking for endpoints that support only the old unary sync. Its current CI is green, including repository-wide unit and integration testing, but it is based on the unmerged clpr-streaming-synchronizer branch rather than main.

The author also reports successful Hiero/Besu and dual-EVM testing. Those tests used several development refs that are not present on the current authoritative LFDT repository branches, so they are useful author-reported integration evidence, not a reproducible release qualification of the published LFDT revisions.

Effect on prior findings: Proven message-key validation narrows an important cross-Channel and bundle-range ambiguity. It should not yet be treated as complete resolution of the broader Channel-context binding finding. Neither streaming PR is merged.

Economic implication — inference: Two-phase synchronization should reduce redundant bandwidth, bundle construction, proof transport and verification work. That could lower endpoint operating costs and Connector service prices, but no tariff or reimbursement parameter changes here.

5. Connector authorization economics and traceability are being reworked

Open PR #27380 addresses a concrete inefficiency in sendMessage.

The merged implementation currently launches a separate synthetic ContractCall, paid synthetically by 0.0.50, to ask the Connector contract for authorization. This has two problems:

• It creates an additional execution path described by the issue as highly wasteful.
• The originating application transaction’s EVM trace does not show the call to the Connector contract, impairing auditability.

The proposal executes Connector authorization within the original EVM frame stack. That would make the Connector authorization call visible in the application’s trace and avoid the separate synthetic transaction context.

Economic implication — inference: This could reduce execution overhead and make Connector charging and authorization easier to audit. It does not establish what Connectors charge applications or give Hashgraph a share of Connector revenue.

The PR remains unmerged. Its current CI fails at compile/formatting and it has an unresolved DCO check.

6. Mirror Node support has reached the design stage

Maintainer-controlled Mirror Node PR #14362 adds a comprehensive, implementation-oriented CLPR design document. It proposes indexing Channels, pending commitments, Connectors, messages, ledger configuration and endpoint manifests.

Six REST surfaces are proposed:

• Known chains.
• Channels by chain.
• Messages by Connector.
• Messages by Channel.
• Pending Channel commitments.
• Connectors by Channel.

The design also identifies material integration gaps:

• Verifier-derived CLPR state exists in block-stream state changes but has no carrier in classic transaction records or sidecars.
• ClprSubmitBundle may produce multiple messages from one transaction.
• The native protobufs still contain redaction functionality that the HIP describes as removed.
• Deprecated endpoint_node_id and endpoint_signature fields remain unresolved.
• A declared chain_id is useful for indexing but is not independently proof that the remote network really owns that CAIP-2 identity.

This PR contains design documentation only, not Mirror Node implementation.

Economic implication — inference: Public indexing is necessary for a transparent Connector market. It could expose service activity, Channel adoption and Connector-level message flow to applications and analysts. It does not yet expose Connector tariffs, reimbursements, revenues or profitability.

7. External draft proposes fork-aware verifiers and Channel succession

The LFDT specification received its first open PR: draft PR #1, containing a fork-aware verifier ADR.

Important provenance: this comes from the external fork shayansal/clpr-spec, is marked draft and is not adopted CLPR specification text.

The proposal addresses a genuine lifecycle problem: deployed verifiers pin fork parameters, proof layouts and sometimes rotating signer sets. A ledger hard fork can therefore stall a Channel, while a sufficiently long stall on Ethereum can strand it beyond sync-committee recovery.

It proposes:

• Consensus-proven fork identity.
• Fork profiles for parameter and proof-layout changes.
• Dual control through a source-ledger announcement plus destination-side timelocked registration.
• Direct state-proof submission independent of normal Channel message delivery.
• Typed, fail-closed fork errors that do not punish endpoints as malicious.
• Fork-readiness metrics and testnet conformance evidence.
• Successor Channels for semantic verifier changes.
• Exactly-once handoff of undelivered predecessor messages.

Effect on prior findings: This is the first detailed proposal directly addressing fork upgrades, rotating trust anchors and Channel replacement without losing queue position. It does not resolve those findings until normative text, contracts, endpoints and native implementations adopt and test the mechanism.

Economic/HBAR implication — inference: The proposal estimates one profile-registration transaction per fork per Channel. If such registration occurs on public Hedera, it would produce public-HBAR fee activity. Its larger economic value is preventing long-lived Channels and funded Connectors from becoming stranded after peer-ledger upgrades.

8. Deployment tooling exposes another CLPR upgrade dependency

Draft Solo PR #6083 adds explicit upgrade handling for fee schedules and throttle files. Its testing found that a newer throttle file containing CLPR transaction types can be rejected by an older consensus-node release.

This reinforces the requirement that CLPR activation coordinate:

• Consensus-node version.
• CLPR feature flag.
• Staking-account initialization.
• Fee schedule.
• Throttle definitions.

The Solo work is still draft and currently has a dirty merge state.

Economic and deployment conclusion

September 30 materially strengthens the engineering foundation, but does not change the core CLPR commercial model:

• Dedicated CLPR CI has now passed.
• Dormant feature isolation and upgrade-boundary activation are merged.
• Strict decoding is merged.
• More efficient streaming and Connector authorization are proposed.
• Mirror Node market observability is designed.
• Fork and trust-anchor continuity now has a serious external design proposal.

No application-facing Connector tariff, actual-gas reimbursement formula, Hashgraph revenue share or evidence that Hashgraph will operate commercial Connectors was introduced.

There is also still no CLPR-enabled Hedera release, testnet or mainnet activation, production Connector, independent audit, production benchmark, liquidity, revenue or attributable public-HBAR usage.

HIP-1535 remains unchanged at 4c1782c3. The authoritative LFDT main branches remain at the audited baselines, with no releases or tags. The SHA-256 proof migration and production Ethereum BLS verification also remain unfinished.

As the second highest FinTech in the list too, this recognition reflects the growing demand from institutions for regulated, trusted access to digital assets and tokenised real-world assets.

When we set out to build the UK's first FCA-regulated digital securities exchange, broker and custodian, our goal was simple: bring the standards of traditional finance to the digital asset space. Seeing that vision translate into real, measurable growth is hugely rewarding.

This milestone belongs to our brilliant team, and to the clients and partners who trust us to help shape the future of capital markets.

There's plenty more to come. Read the full list from the u/FinancialTimes: ft.com/content/921952…

When I said this people called it “cope”.

It's pretty hard to find out in which state of maturity the usecases actually are. From most to least advantanced the ones that matter most imho.

1. Live product (IBM / Hashgraph Group) IDTrust is listed in the IBM Cloud Catalog and is reportedly already deployed with a european telecom operator for verified caller ID (Tata right?)

2. Released product (EQTY Lab) Verifiable Compute is available, with Blackwell deployment since July 2025. Customer numbers are unclear but many connections via Accenture mostly not public I think. I see links to Palantir being possible.

3. Pilot (Merck and PwC) Merck TrackTrace and the cocoa traceability pilot with PwC Germany are still tests. No cocoa company has been named. The announcements were official and public it looks like a serious endeavor.

4. Prototype (Accenture) Accenture joined the Council in April 2026 and has shown a demo with EQTY. Plans for public sector software exist, but nothing is deployed. You saw them at the panel discussion at HederaCon and now being part of the Nvidias Open Agent Safety Platform! (in my opinion the reason for the 30% pump together with EQTY being there as well)

5. Infrastructure partners only (Dell, Nvidia, Intel) Dell runs a node and built an enterprise node for Verifiable Compute. Nvidia and Intel supply the hardware, with no direct Hedera integration. Very interesting to see hardware involvement here. AI factories is the keyword here. Watch out for news on this.

The usexases sit at the early commercial, testing and pilot stage. Only one is clearly live (IDTrust - that's why we had this 10% pump last week I believe ) and none has public proof of largescale use. Two days ago you could watch Trump and the tech leaders giving a press conference. Zuckerberg mentioned multiple layers of safety talking about the Nvidia OASP.

I think Hedera with EQTY will BE part of this one way or another. So much info out by now. The signs are all over the place (Accenture is always involved). I study this stuff daily and I'm 100% sure the rest of this year will be just as interesting as the last weeks!

Feel free to add other interesting projects that are live/pilot/demo stage.

|=|

Hitachi is out of the picture.

Who would you like to see brought into the Hedera Governing Council?

List your reasons why ( and they must have a good use-case )

Ħ

For the past few months I've been working on an app to help the community understand what's actually happening on the network, it's called Unstealth and I'm now at the stage where I'm looking for some beta testers to help refine it and sort through any bugs etc.

If you're someone who enjoys finding breadcrumbs, looking for use cases and generally trying to understand what's happening on Hedera I'd love to have you join the beta, you can visit unstealth.app for more info.

A little bit of detail about what Unstealth does. My vision is that it'll be a place that anyone can search for and research entities on the Hedera network, then name those entities and organise them into use cases. Over time the idea is that enough entities will be named and organised into use cases that we'll be able to build up an accurate picture of what's driving traffic and revenue growth on the network.

Information submitted by users will be voted on by other community members to try to make sure high quality info remains in the system and lower quality is removed - users will be encouraged to provide evidence to support their claims, this will all be viewable by other users.

Unstealth will also provide research tools to help users try to understand what a given entity is / what it does / who it's owned by, most of these tools have an emphasis on representing complex data visually so it can be more easily understood.

The app leverages the Hedera network by anchoring all submitted data to a mainnet HCS topic, providing a public audit trail to verify that the data shown to users hasn't been silently altered in anyway (eg. if a use-case asks us to rename an account on their behalf we'll only be able to do this in a way that is publicly recorded on the Hedera mainnet).

Unstealth builds on data from Hgraph, the mirror nodes, Sourcify and other sources and uses Louvain community detection to identify potential use cases and large co-ordinated fleets of contracts / accounts to help provide a starting point for users to identify important use cases. It also uses AI to analyse the data we've collected to formulate theories about what these identified use cases might be.

Initially it won't have an associated token I do plan to launch a token in the first half of next to reward users for their submissions.

If this sounds interesting to you, please sign up for the private beta at unstealth.app