I called this early September when I confirmed that THA and Hashgraph VC were not investing in Hedera projects: https://x.com/itsbrandond/status/2108784276997108034

Was hard to believe, and really sad to see this much value extracted from hard working builders and holders in the ecosystem, following Hedera's lawsuit against Exponential Science.

It seems the governing council has given hundreds of millions (USD) in HBAR to the wrong folks over the years.

case no. 655628/2026

Full recording available in their discord.

Claude summary:

Headlines

• Tokenized stocks are live. They launched last week through Sodax, a compliant provider. You can buy tokens for stocks like NVIDIA, Apple and Tesla, plus ETFs. The tokens track the price of the underlying asset but don’t give you actual shares or shareholder rights.
• SAUCE emissions cut in half. A recent tokenomics proposal halved the MasterChef emission rate. The goal is less inflation and, over time, a shrinking SAUCE supply.
• Perpetuals (perps) are close. The code is being audited by Halborn, which also audited V3. SaucerSwap Labs plans to open-source it after the audit. Because they’re a US company, they’re working with three law firms on a compliant launch. Peter's (Co-Founder, CEO) best guess is mid-November. Early on he said he’d be surprised if it came later than November; near the end he said he’d be surprised if it slipped into December.

SAUCE tokenomics (Joseph, Co-Founder, COO)

• Eligible revenue goes to BrewSaucer, which buys SAUCE on the market. That SAUCE is then split:
  • 40% to xSAUCE
  • 30% to the development fund
  • 10% burned
  • 20% to protocol-owned liquidity and the incentive reserve
• Revenue comes from the V1/V2 fee switch, V3 fees, and staking rewards on the HBAR held in the wrapped HBAR contract. That contract holds about 205M HBAR earning roughly 1.8% a year. The latest daily collection was about 10,400 HBAR, all of it used for SAUCE buybacks.
• SAUCE issuance doesn’t depend on trading volume. More trading means more buybacks, burns and rewards, not more new SAUCE.
• Perps fees, after the liquidity providers’ share, will go through their own BrewSaucer for buybacks, burns and rewards. xSAUCE holders will get fee discounts on perps positions, similar to V3.

How the stocks work

• A stock trade is an “intent”: you say what you’ll spend, which stock token you want, and the minimum you’ll accept. Independent solvers in the Sodax network fill the order, and the token lands in your Hedera wallet.
• The stocks are Robinhood stock tokens. Sonic is the hub chain that links the Hedera, Robinhood Chain and Stellar versions.
• Fees: there’s currently a 0.25% interface fee, and all of it goes to the development fund. None of it goes to xSAUCE or burns yet. That changes once SaucerSwap becomes a liquidity source for Sodax, at which point its fees would follow the BrewSaucer split above. That integration is planned but not live.
• Paying with other tokens: today you can only pay with HBAR or USDC. They don’t want a separate pool for every token, so they’re looking at routing through HBAR instead (for example SAUCE → HBAR → NVIDIA). There’s no date or promise yet.
• Earning from stocks: they plan to add pools like HBAR/NVIDIA so people can earn fees by providing liquidity.

Other Q&A

• AI agents: SaucerSwap’s docs now include an MCP server, a tool that lets AI agents look up how its contracts and APIs work. The use case they’re most interested in is agents that manage liquidity positions: checking whether you’re in range, tracking fees, and preparing transactions for you to approve. They expect more trading to come from agents finding SaucerSwap through its docs, and the team uses AI tools heavily in its own development.
• Team wallets: the team allocation finished vesting in July 2025. Four of the six original founders have fully sold out. Peter and Joseph still hold significant SAUCE and see it as a long-term holding. Grants and protocol revenue have cut how much SAUCE the company needs to sell to cover costs, and the relevant accounts are listed in the docs.
• Security: their contracts can’t be upgraded, but they do get replaced over time. Every new or replacement contract that holds user funds is audited before it goes on mainnet, which Peter called non-negotiable. They also keep reliance on outside protocols to a minimum.
• Robinhood Chain: Peter sees it as good for Web3 overall. What interests him is apps built around those assets, like using a stock token as loan collateral.
• CLPR cross-chain transfers: CLPR is announced but there’s nothing to integrate yet. They’re open to it if it ends up simple and secure.
• Burning LP tokens: V1 LP tokens are burned automatically when you withdraw. To lock liquidity for good, send the LP tokens to a burn address like 0x…dead. A third-party locker such as DaVinci is the option if you want conditions like an unlock date.
• Team: the team works remotely across the US, Canada and Europe. They last met in person at HederaCon in Miami. Morale is high despite a rough altcoin market. A developer update came out yesterday, with a promise of more frequent and transparent updates. The mobile app is expected to get the stocks too.

[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.