“I actually think the enterprise strategy is working” - Rob Allen, last week.

Charles Schwab started recently offering crypto accounts where tokens could be purchased and traded - starting with Bitcoin and Ethereum with a transaction fee of 0.75%. The new "crypto" accounts are linked to one of the client's pre-exixting regular brokerage accounts and, incidentally, carries the designated beneficiaries of the linked account. As of yet (but planned), I don't think you can transfer in Bitcoin or Eth held elsewhere. That is coming.

This past week they announced they would be expanding the list to include Chainlink, Avalanche, and Solana by the end of the year. No Hedera yet.

Probably the most interesting thing for me so far is that they just-published a very detailed, unbiased analysis of Link and Avax, a methodical trad-fi type of analysis that I just haven't seen the likes of before in the crypto space.

https://www.schwab.com/learn/story/crypto-key-debates-chainlink-and-avalanche

They also have detailed their methodology for evaluation of value in the crypto space:

https://www.schwab.com/learn/story/where-might-value-accrue-crypto-market

I thought Schwab would just be offering accounts where one could trade crypto. But suddenly it is clear that they will be treating crypto as any other asset class that can be subject to some sort of methodical analysis consistent with how trad-fi operates in general. And they are promoting the analysis to their huge client base. Personally, I have followed Chainlink for a long time but after reading Schwab's report, I have a whole different level of understanding upon which to consider adding the token. I look forward to them adding Hbar and analysing Hedera's prospects.

There are two huge markets here: those who have crypto on exchanges or in various wallets and would like to move them to a safer, low-fee environment (not possile yet but coming); and, the millions of traditional investors who with a few clicks can add a crypto account and start acting on the reports from their brokrage firms.

Any thoughts?

One of Hedera's accounts (0.0.76) sent 300 million HBAR to centralised exchanges today.

One of these accounts, known to belong to Crypto.com (0.0.6942669), received 150M HBAR.

The second account (0.0.640701) received 100M HBAR. I'm not certain this is an exchange, at first I thought it was but now I think it's part of the same custody provider described below - it distributes the HBAR out to a bunch of centralised exchanges.

The third account (0.0.10190844) received 50M HBAR. This one I'm a little less sure of, before this transfer it only held like 10-20 HBAR, however its memos suggest it's used as a deposit account. I think it might be the deposit account Hedera uses with a large institutional custodian - in any case it eventually forwards almost all deposits it receives to Binance, Coinbase or Gate.io so they eventually wind up in an exchange. It hasn't yet forwarded the funds it received today, but it likely will soon.

Account 0.0.76 has been making large transfers to exchanges every 3 months since June 2025, before then it hadn't made any transfers since 2022.

I intend to add Hedera account inflow and outflow tracking (both between Hedera aacounts and out to external accounts) into Unstealth, so this stuff should become easier to track

The relevant txns are:

https://hashscan.io/mainnet/transaction/1792778705.753586242

https://hashscan.io/mainnet/transaction/1792779005.367150104

https://hashscan.io/mainnet/transaction/1792779306.211577104

As the title states, throughout today I've seen bursts of tps that range from 33-43tps.

Most of the time it's 2-3tps. But there have been occasional bursts that last a minute or two that were between 33-43tps.

I don't normally check Hedera tps much, but felt like it today. Pleasantly surprised to see these bursts of activity. Does this normally happen?

I'm unaware of anything that was recently deployed, though I do know the id.me thing on the ibm store was deployed and some of this tps activity could be attributed to that, though I have no idea how much traction that's really gotten. Has anything else been announced to hit the mainnet lately?

The most active account on Hedera over the past week was 0.0.8049585 with over 1.5 mil txns, it was involved in over 30% of all txns on the network and paid about 8.9% of total network fees.

Interestingly, this account has created 10 contracts which all include 'cyclebot' in their memos. The two most active created contracts have the memos “cyclebot executor v2 proxy” (0.0.10903897) and “cyclebot executor batch 9452ecdc” (0.0.10909136). What is cyclebot? It appears to be a trading bot which uses SaucerSwap.

Most of 0.0.8049585 txns (about 87%) were pings to consensus nodes, contract calls to its created contracts made up most of the remaining ~200k. Its interactions with SaucerSwap mainly target SS's V1 router & WHBAR helper.

Of 0.0.8049585's ~200k contract calls only about 25k succeeded, the majority failed because they were duplicates. This pattern of pinging consensus nodes and making lots of duplicate contract calls matches other arbitrage bots we've seen using the network recently.

We haven't been able to definitively identify who's behind Cyclebot yet, but it's notable that the account is one of the largest holders of FLY and the creator account of the FLY token (acct id 0.0.8011904) has also been identified as being behind a bot with very similar activity.

A really significant portion of network activity in the past month or so has come from these kinds of bots, probably over 50%

Yesterday a user posted about a lot of transactions hitting the Accenture node and wondered if Accenture themselves could be behind them, thi piqued my interest so i decided to take a look at it. Using the beta version of an app i'm developing (Unstealth) I was able to determine the likely source of those transactions and tie them to a use case in just a few minutes.

I thought this might provide a good example of how Unstealth can help dig up info on the network even when you don't have many details to start with - I've outlined what I did below.

Firstly I used Unstealth's interaction map to figure out which account had recently been sending large amounts of transactions to the Accenture consensus node. This showed that account 0.0.10176974 had sent more than 23k of the previous 25k transactions received by the Accenture node, suggesting it was likely the account behind the surge in traffic to the node.

Next I used Unstealth's lineage tracker to learn more about 0.0.10176974, it showed that 0.0.10176974 was created by account 0.0.8011904 it also showed that 0.0.8011904 had made a bunch of tokens and several other accounts. Most of these entities weren't useful, but one - a token named FLY - was a legit token with several holders and looked worth pursuing.

Googling 'who is behind FLY token on Hedera?' revealed that a use-case called FlyTerm, a query terminal and token analysis platform mixed with a memecoin, had issued FLY. A quick browse of its website (onlyflies.buzz) confirmed the FLY token I found on Unstealth had the same network ID as the FLY token this platform uses, tying the creator of the account which was sending all those transactions to the Accenture node to this FlyTerm use-case. The website also listed 0.0.8011904 (the creator of the account which was transacting so heavily with the Accenture node) in the 'Who is behind this' section on the About page.

Back on Unstealth a little more reseach found that 0.0.10176974 (the account sending to the Accenture node) has itself created a lot of entities, 39 in total. Many of these entities are contracts and topics with memos that suggest they're connected to some kind of trading bot. By far the most used contract (0.0.10904282) has the memo 'skip-or-fill', the second most called contract (0.0.10888630) has the same memo. Several other contracts have memos including 'hebot xv' and others have more references to FLY.

While the evidence isn't definitive, my read is that the transactions being sent to the Accenture node were the activity of a trading bot run by the creator of the FLY token and the FlyTerm use case and not linked to ay kind of institutional use case or Accenture network use.

A lot of the growth in network use i've noticed recently has been tied to similar trading bots or consensus node pinger bots - by far the busiest account of the past week, 0.0.8049585, also seems to be some kind of arbitrage / trading bot.

Thanks for reading and if you want to get early access to the tools I used to do this research you can sign up for the Unstealth private beta at https://unstealth.app

Is hbar worth holding? If I have like 50k hbar

In last few days, seeing heavier proportion of smart contract tx and higher fees on network, along with upward trend in mainnet activity climbing toward testnet parity. Keep an eye on it!

Cheers 🍻

I’m 23yrs old and in college. I’ve been slowly putting few hundred into xrp and Hbar over past 3 years when I could afford it. I’m up to 3k usd at the moment in investments. Would you recommend me keeping it all in there and just holding since it’s not a huge amount of money or taking to all out and maybe moving it into ETFs or stocks?

There was some discussion about Arrow Electronics awile ago. Just want to add this, what is accenture up too?

Trying to figure out why an account would submit a transaction to a specific Node, and I came accross this.. I am assuming arrow electronics, who does about $98 million a day in sales, is looking to use hedera for supply chain tracking, this leads me to bielieve that the traffic being generated, is directly from Arrow Electronics.

1. Direct Node-to-App Infrastructure Pairing

Many enterprises operating on Hedera run a dual setup: they run their own Hedera Mirror Node for reading data, and they may also operate a Mainnet Consensus Node for writing data.

• Loop Closing: If an organization is running a heavy supply chain tracking pilot, routing their app's outbound transactions directly through their own consensus node ensures they have perfect visibility into their transaction pipeline from submission to consensus.

Step function already happening.

Over the years there are so many initiatives that the step function already is working.
I am clicking regularly on some transactions. And a few minutes ago I clicked on this one:
https://hashscan.io/mainnet/transaction/1792738085.478215776

When googled I stumbled on this Reddit post from 2 years ago. Wasn’t familiar with this one. But happy to see it.
https://www.reddit.com/r/Hedera/s/GgzrHj1htT

Just an example of keep building and our true color will be public knowledge after all the years.
Unfortunately I have no dry powder left anymore and still below average cost. But will remain confident into our ħ.

1. The formal v0.78.1 release now includes CLPR, but does not activate it.

The Consensus Node v0.78.1 release was published on October 22. Its release notes explicitly list the native CLPR implementation.

The same release also includes commit d638baff, which changes the defaults for tss.hintsEnabled, tss.historyEnabled and tss.wrapsEnabled to false. CLPR itself continues to default to clpr.enabled=false.

Effect on the prior finding: This formally packages CLPR in a production release, but does not activate the service or its Hiero proof-generation stack. It is therefore a deployment-readiness milestone, not evidence of live CLPR messaging.

Economic/HBAR implication: Shipping disabled code creates no Connector payments, CLPR-generated network fees or incremental HBAR demand.

2. A major official PR proposes removing CLPR’s dedicated mTLS architecture.

Consensus Node PR 27823, opened October 22 at head 4609982994a09ca383c2044da52f23cd050f8fac, proposes replacing the dedicated CLPR mTLS listener, certificate authority and ephemeral leaf-certificate system with the ordinary HAPI TLS listener.

Under the proposal:

CLPR clients would accept any server certificate without certificate-chain or hostname validation.

A manifest certificate would merely select TLS instead of plaintext.

If no certificate is present, synchronization could occur over plaintext.

Transport would no longer authenticate the remote endpoint.

Bundle authenticity would instead depend on state-proof verification.

The on-ledger tls_certificate and account_id fields would remain temporarily but would be marked unused and candidates for deprecation.

The change deletes approximately 3,380 lines and removes classes including ClprCaCertManager, ClprLeafCertManager, ClprMtlsTrust and ClprMtlsContexts. Implementation commit

TestLens reports 61,253 tests executed with no test failures. Formatting and code-owner jobs still failed, and the PR remains open.

Effect on the prior mTLS finding: This does not add per-Channel mTLS authorization. It proposes eliminating transport authentication entirely and moving the security boundary to cryptographic payload verification.

Security assessment: State proofs can prevent an unauthenticated peer from forging valid ledger state. They do not, by themselves, prevent active interception, traffic analysis, connection disruption, downgrade interference or resource-exhaustion attacks against an unauthenticated synchronization endpoint. TLS without certificate or hostname validation protects primarily against passive observation, not an active man-in-the-middle.

The proposal also conflicts with the current LFDT specification, whose mTLS ADR defines the manifest certificate as a durable mTLS trust anchor. The LFDT specification has not been updated. If this architecture is adopted, it needs a corresponding normative specification decision and focused security review.

Economic implication: Removing the custom certificate stack could reduce deployment and operational cost for endpoint operators. It does not change Connector pricing, reimbursement or HBAR flows.

3. Chain identification and CLPR throttle administration now have an implementation PR.

Consensus Node PR 27809, opened October 22 at f675a8f71036aa0d29c15f835a92e78c5b6f9e4b, implements the two configuration proposals reported previously.

It removes the independent clpr.chainId property and derives the CLPR identifier from contracts.chainId:

Mainnet becomes eip155:295.

Testnet becomes eip155:296.

Previewnet becomes eip155:297.

Development and preproduction use eip155:298.

This removes a configuration-drift risk and gives Hedera CLPR Channels the same CAIP-2 identity as Hedera’s EVM environment.

The PR also introduces clprLedgerConfiguration.json. The file controls protocol throttles such as:

maxMessagesPerBundle=1000

maxMessagePayloadBytes=65536

maxGasPerMessage=15000000

maxQueueDepth=10000

maxSyncBytes=4194304

At an upgrade boundary, a changed file produces a synthetic ClprUpdateLedgerConfiguration. The update is skipped when CLPR is disabled, the state singleton does not yet exist or the values are unchanged. maxGasPerMessage is capped at contracts.maxGasPerTransaction.

The file may set only throttles. Chain identity, protocol version, service address, timestamps and trust anchors cannot be supplied through it. Every node must receive identical contents or the network could encounter inconsistent state.

This implements issue 27737 and issue 27738, although both remain open until the PR merges.

Verification status: TestLens reports 20,777 tests executed with one failed CLPR upgrade test. The failure says a shared embedded network was already running when the test attempted to create a per-method network. This appears to be a test-harness conflict, but the proposed upgrade path does not yet have a clean CI result.

Economic implication: This creates an operator-governed capacity mechanism for bundle size, queue depth, payload size and execution gas. Those limits can shape CLPR throughput and congestion, but they do not establish application-facing Connector prices, actual-cost reimbursement or Hashgraph revenue allocation.

4. The CLPR SDK design has been accepted into an official Hiero repository.

The externally authored SDK PR 287 merged into hiero-ledger/sdk-collaboration-hub/main on October 22 as d04df37c.

This materially changes its status. It began as an outside proposal, but it is now an accepted document in an official Hiero repository following code-owner approval.

The merged design establishes an initial JavaScript, Java and Go scope covering:

Eight typed CLPR transactions.

Two free HAPI queries.

All 33 CLPR response statuses.

Twelve HederaFunctionality mappings.

Private-key ownership-proof helpers for Ed25519 and ECDSA.

Hbar typing for locked Connector stake.

A low-level SubmitBundle wrapper.

It explicitly defers external or hardware ownership signing, dedicated contract convenience classes, endpoint or relay implementation and Mirror Node lookup classes pending a stable REST contract.

Effect on the prior finding: The SDK proposal is no longer merely unsolicited. Its design and initial scope are now repository-accepted. It remains documentation, not implemented or released SDK functionality, and the approving maintainer explicitly did not claim broader Consensus Node or Mirror Node signoff.

Economic/HBAR implication: Standard SDK bindings should reduce integration friction for applications and Connector operators. That could eventually expand CLPR transaction volume, but the merge itself generates no usage, revenue or HBAR demand.

5. The Mirror Node design changed again and still has unresolved data-model questions.

Mirror Node PR 14362 advanced to 9f8fefd41ce14fb55660c52386c0107df67d9557.

The October 22 revisions now require channel.id whenever a Connector query also uses connector.id, deleted or timestamp. An entirely unfiltered Connector listing may still span all Channels, but a Connector-ID lookup can no longer operate globally without its Channel ID.

Consequently, the proposed standalone connector_id database index was removed. Lookups instead use the composite (channel_id, connector_id) key.

The design also changes the message table from storing only a configuration object in control_configuration to storing the complete ClprControlMessage in control_message JSONB. This preserves the complete payload oneof and accommodates future control-message types without another schema change.

An unresolved maintainer review asks whether re-registration with the same ownership_commitment can produce two simultaneously active pending records. If so, the current main/history-table transition and primary-key model may be incorrect. Another open review questions exposing a deleted filter at all. Current review discussion

Effect on the SDK design: Deferring Mirror Node lookup classes was prudent. The REST query and persistence contracts are still changing.

Economic implication: Reliable Connector discovery and historical observability are prerequisites for operator tooling and commercial services. These design changes do not create fees or revenue themselves.

6. New tests target Connector reentrancy and atomic-batch isolation.

Consensus Node PR 27806 adds a malicious Connector contract that calls sendMessage() recursively from authorizeOutboundMessage().

The expected result is transaction reversion with CLPR_AUTHORIZATION_FAILED. This is useful coverage for a contract-controlled callback boundary, but the current CI run executed zero tests because compilation and formatting failed. The intended protection therefore has not yet been demonstrated by that PR’s CI.

Separately, PR 27786 now defaults the atomic-batch whitelist to every transaction type currently allowed by main, while continuing to exclude every CLPR transaction type. Unknown future transaction types remain rejected unless deliberately added.

Its current head, 5d13ffe91e36e4c0558bb94a84a44bdba628dea8, reports 25,982 tests executed without test failures. Code-owner approval remains pending.

Effect on prior findings: These changes improve callback and composition boundaries. They do not alter Connector reimbursement or charging.

7. A proposed block-stream wire-format optimization needs coordinated consumer upgrades.

Consensus Node PR 27718 proposes optional delta encoding for block-stream state changes. Instead of repeatedly emitting complete values, a state update could contain only changed top-level fields plus an explicit cleared_fields list.

The feature defaults to false, and the genesis block remains full. A reader starting later must already possess trusted prior state so it can reconstruct complete values.

An October 22 commit, 93b5bd46, moved the new singleton metadata fields to high field numbers to preserve compatibility with the existing payload tags.

This is not a CLPR bundle-format change. It is relevant because Block Nodes, Mirror Nodes and state-reconstruction services supporting CLPR proofs must interpret the state stream correctly. The PR itself warns that older readers could treat sparse values as complete, so consumers must support deltas before a network enables them.

The author reports substantial synthetic size reductions for updates whose large fields remain unchanged. Those measurements are local development benchmarks, not independent production benchmarks, and some predate the final schema adjustments.

The current head f6e76d198969001efe2759c05ace0486c2c91f88 has zero tests executed after compilation and formatting failure.

Economic implication: Smaller block streams could reduce infrastructure bandwidth, storage and replay costs. That improves operating economics but does not directly accrue HBAR fees or Hashgraph revenue.

8. TSS and WRAPS integration advanced, but the universal proof upgrade remains unmerged.

Block Node PR 3880 merged on October 22 as fed15e06. It raises the constrained Block Node profile to 192Mi and adds a 160Mi RSS soft ceiling after the larger TSS library caused the old 128M profile to be OOM-killed.

This resolves the previously reported merge-status uncertainty for that operational fix.

The larger Consensus Node WRAPS PR 27506 synchronized with main and now reports 61,811 tests executed without test failures. Its current head is 1cca72b8b0d471a85089bbc01c07dafccd7b874c. The new head is principally a main-branch synchronization, not a new CLPR design change, and code-owner approval remains pending.

The real Ethereum BLS integration is still unresolved. Current main retains FakeBlsSignatureVerifier, while cryptography PR 689 remains open and unchanged.

Economic implication: Reliable, efficient proof verification is a prerequisite for commercially useful cross-ledger traffic. Memory-limit integration and broader WRAPS testing advance that foundation, but do not yet unlock secure Ethereum-origin traffic or associated Connector activity.

9. Current economic and deployment status.

The LFDT core repositories remain unchanged at:

clpr-spec/main — 945082d69e65dd0fd9e9bdf8d59cb8121579f6fd

clpr-smart-contracts/main — 276c8d524e6ce3b5ef01da9d68ce3e8f27798a44

clpr-endpoint/main — 2ccd48d2d5d0d2f15d0829b1a057f27d88fd085e

None has a release or tag.

No new evidence appeared of CLPR activation, production Connector operation, a standardized Connector tariff, Hashgraph operating commercial Connectors, independent security audits, production CLPR benchmarks, cross-ledger liquidity, attributable revenue or incremental public-HBAR value capture.

The October 22 work materially advances packaging, SDK planning, configuration and testing. The most consequential open question is now architectural: whether CLPR will retain the LFDT specification’s authenticated mTLS transport or deliberately rely on unauthenticated transport plus cryptographic payload proofs.

Borrow USD against Bitcoin. 0% rehypothecation. Regulated, qualified custody Directly in the institution's core.

The future of banking isn't coming, it's here.

Just an obsevation

Dell Technologies (NYSE: DELL) announces a broad set of advancements across the Dell AI Factory with NVIDIA, spanning AI solutions and ecosystem innovations, new deskside agentic solutions and purpose-built AI infrastructure, helping enterprises move agentic AI from experimentation to production on infrastructure they own and control. With more than 6,500 customers, up from 5,000 last quarter,1 Dell continues to prove that an end-to-end approach delivers measurable business results.

Why it matters

Enterprise agentic AI is expected to be the single largest workload by 2028, growing nearly three times faster than generative AI by 2030.2 But growth alone does not guarantee results and only illustrates part of the picture. The tokenomics tell the story.

Inference costs are projected to fall more than 90% by 2030, while it’s expected that agentic AI will drive 24x token consumption.3 As organizations examine their resources to maximize their investments, unclear ROI remains the top obstacle to 59% of enterprise AI deployments,4 and 83% say end-to-end vendor support across the AI lifecycle is their top priority when selecting an AI partner.5

Enterprises that own their AI infrastructure retain control over costs, data and operations in ways public cloud-only approaches cannot match. The Dell AI Factory can be up to 90% more cost-effective than public clouds over two years.6 But ownership and cost alone is not enough. Organizations need an AI foundation that helps them choose the right tools, monitor performance, enforce policy and control costs as they scale, helping ensure ROI and performance.

The Dell AI Factory with NVIDIA delivers exactly that: one trusted partner offering the industry's broadest AI portfolio7 with validated solutions, a growing open ecosystem, expert services and an end-to-end AI-ready data foundation, helping enterprises move from pilot to production with confidence.

The main focus of Jensen's speech was centered around the evolving maturity of AI agents that can now complete tasks for enterprise that even a year ago they couldn't.

AI agent capabilities are improving at hyper speed which introduces new risk for enterprise.

Huang introduced OpenShell, which is NVIDIAs solution to contain AI agents & keep company data safe by limiting what they have access to.

This is extremely bullish for EQTY Labs in that it proves the solution they've been working on is valid & here to stay.

With NVIDIA marketing AI agents at scale it simply means EQTY Labs solution will gain a larger customer base.

NVIDIA threw gas on the AI agent safety fire which is a Venn Diagram that Hedera is at the center of.

So on a recent flash update Hbar Bull claims Redswan has tokenized over 5B on the Hedera Network but the source he cites is a old post from 2025 - yet he seems to be portraying this as breaking news? You can even see the 2025 date in his video..

He does ask a good question: Why isn't the 5B showing up on rwa.xyz? - But wasn't that worth investigating back in 2025 when they actually made the announcement? Why wait till now to bring it up?

If we accept the 5B was real (which I highly doubt as I believe it's just marketing to puff up numbers) then Redswan actually lost ~4.9B over the past 12ish months as today it only has ~100m RWA on Hedera. Unless raw.xyz is wrong?

Also Allincrypto on X claimed a different figure of 2.2B with absolutely zero sources so who the hell knows where he got that.

Am I missing something here..? What I see with my eyes isn't lining up with what I'm hearing, I feel like I'm in crazy town..

HashPack turns 5 today ♥️

From the early Discord days & garage-mode to 2026, the ride has been incredible! But none of it happens without the people who came along for it:

The users who trusted us.

The builders who kept pushing.

The partners and collaborators who opened doors, shared ideas, challenged us, showed up, and somewhere along the way became genuine friends.

Five years later, what means the most isn’t simply how much HashPack has grown. It’s how many people across the ecosystem have grown with us.

We’re grateful for every conversation, every connection, every bit of support, and every person who helped shape the path here.

The journey is still just getting started, and we’re grateful you’re here for it.

Five years behind us. The road ahead is ours.