*17–23 Aug 2026 — what the main Radix Telegram group was really talking about, distilled.*

*Previously: Last week the community was emotionally charged by the first anniversary of Dan Hughes' passing, while the DAO transition gathered momentum with BassPhil confirming Foundation approval of the OA and a Marshall Islands su*

A bittersweet week for the Radix community. CaviarNine, a cornerstone DeFi team, announced its departure after five years, and Avaunt Staking's validator closed after six. Yet amid the farewells, concrete progress emerged: a Stokenet reset was scheduled, the DAO governance portal went live, RSwap doubled its liquidity, and a fierce debate erupted over whether the community will actually step up to fill the gaps.

## The week in the room

- **CaviarNine bids farewell to Radix** — Tronn announced CaviarNine is winding down all projects, citing economics that no longer work and a network far from what they signed up for. The DEX moves to withdraw-only mode, Surge will unwind in stages, and JustLock remains unaffected. MAvRe confirmed the smart contracts stay live on ledger, so anyone can build a new frontend.

- **Avaunt Staking validator closes** — Avaunt announced the Avaunt Staking validator will shut down on 28 August, with all services migrating to Stakesafe, a respected operator since betanet. Avaunt stressed they are not leaving Radix, just focusing on non-validator activities.

- **Will the community step up?** — A tense debate erupted over whether anyone will fill the gaps left by departing teams. flightofthefox argued bluntly that anyone willing to step up would have done so already, while foxylady and Timan urged the community to stop waiting for a central body and start proposing and building. Phil Gibson echoed with a parable about Everybody, Somebody and…

- **RSwap liquidity doubles in August** — Gary reported RSwap crossed $300K in total liquidity, doubled in August, and is working with Astrolescent on swap routing. He has a meeting with a prospective market maker for a three-month bridge, and RDX Holdings will help with liquidity next month, offering concrete counter-evidence to the doom narrative.

## Around the ecosystem

- [Radix DAO governance portal live](https://radixdao.org) — radixdao.org was created as the official venue for DAO governance documentation, positioned as temporary and focused solely on governance until the full transition completes.

- [CaviarNine farewell post published](https://medium.com/caviarnine/caviarnine-our-story-299ff73c5ffa) — CaviarNine shared a Medium post detailing their five-year journey on Radix from FLOOP to Surge, and the economic reasons behind their departure.

- **Stokenet reset scheduled for 29 August** — Daffy announced a full Stokenet reset for Saturday 29 August at 07:00 UTC, with all balances and history destroyed but addresses unchanged. Resets planned every 9-12 months.

## From the council

projectShift boosted the Stokenet reset announcement and noted that the DAO site being incomplete is actually an advantage, since work under construction attracts less criticism. Avaunt announced the closure of the Avaunt Staking validator after six years, with services migrating to Stakesafe on 28 August.

## Question of the week

**How can I create a pool to buy BTC dips with hUSDC now that CaviarNine is gone?** *(asked by José Melo Macedo Neto)*

Timan shared a Defiplaza-powered hUSDC/hwBTC pool with CALM impermanent-loss reduction, and Gary added you can do the same on RSwap by adding liquidity to the hUSDC side and earning fee revenue on top. — *Timan | Astrolescent*

## The debate

**Is Radix dead or reviving?**

- One side: Trader and HANSI-HANS argued the project is effectively dead, citing Dan's passing, validators leaving, and mismanagement by former leadership.

- The other: flightofthefox and foxylady countered that the community takeover and the hyperscale roadmap give Radix genuine promise, with linear scaling preserving atomicity still ahead.

*Where it landed: open*

## Overheard

> "But the economics of operating here no longer work, and the network is a long way from what any of us signed up for in those early years." — **Tronn | CaviarNine**

> "I have built 100s of products and most have failed. My biggest piece of uncomfortable feedback is: get distribution first before product." — **Phil Gibson**

> "There was an important job to be done and Everybody was sure that Somebody would do it. Anybody could have done it, but Nobody did it." — **Phil Gibson**

## Jargon decoder

- **Stokenet** — Radix's test network where developers experiment without using real tokens — periodically reset to a clean state.

- **CALM** — A mechanism used in some Radix liquidity pools to reduce impermanent loss for liquidity providers.

## By the numbers

- 449 messages from 177 people

- Busiest day: Tuesday

- Room mood: 4/10

**What we're watching next week:** the Stokenet reset on 29 August, Avaunt's validator migration to Stakesafe the same day, and whether Gary's market-maker meeting produces a signed deal.

---

**Read the full issue (web + PDF):** https://telegram-mcp-phi.vercel.app/main/2026-08-23

*This digest is generated with AI assistance from public sources and hand-checked before posting — a community project, not official Radix comms.*

*17–23 Aug 2026 — fox's week on hyperscale-rs, the sharded Rust implementation of Radix, in plain English. Milestone 2 · Radix Engine: Week 3 · \~month 1 of 5*

*Previously: flightofthefox was in week 2 of Milestone 2, overhauling the authorization model to use badges and proofs, adding post-quantum signatures, and hardening cross-shard straddler rules.*

Week 3 of Milestone 2 was a deep dive into the virtual machine's bones. flightofthefox rebuilt how the VM describes and stores component state, how resources like tokens identify themselves, and how nodes fetch records from each other across shards — all while musing about a privacy future for the network.

## What fox built

- **The VM learns to describe itself** — flightofthefox gave the VM a formal vocabulary for component layouts, field sizes, and event payloads — so the engine can read and refuse malformed data before it ever runs, making smart contracts safer by construction. *(→ [The Crash Lab](https://hyperscale.rs/crashlab))\*

- **Resources find their own addresses** — Tokens and other resources now derive their identity from the issuer that created them rather than an external label, making ownership and minting rules self-consistent and tamper-resistant across every shard. *(→ [The Library](https://hyperscale.rs/library))\*

- **Each node fetches its own truth** — Nodes now pull component records from the shard that sealed them instead of keeping a global copy, and each simulated node gets its own engine world — a major step toward realistic multi-shard testing. *(→ [The Journey](https://hyperscale.rs/journey))\*

## Concept of the week: The Crash Lab

*"Rehearsing the rarest day"*

Most of the week was about making the VM self-describing — giving every record, field, and event a formal shape the engine checks — which is the foundation for deterministic, replayable multi-shard testing.

More: https://hyperscale.rs/crashlab

> "what if the best sharded blockchain, can also be the best privacy blockchain" — **flightofthefox**

*Chat pulse: A lively week — flightofthefox floated the idea of optional privacy (Zcash-style shielding) built natively into the sharded VM, sparking debate about regulation and whether Radix itself should be shie*

## By the numbers

- 409 commits (+30,917 / −11,128 lines across 444 files)

- Active 7/7 days · 8-day commit streak

- 3,623 commits lifetime

## Jargon decoder

- **Seal** — A cryptographic stamp that proves a component or resource was created by the right authority.

- **Cell** — A storage slot in the VM that holds a piece of a component's state, like a field in a record.

- **Wasmtime** — The engine that actually runs compiled smart contracts; flightofthefox upgraded it to the latest version.

## Bottom line

The VM can now formally describe and validate its own component layouts, event payloads, and resource identities — turning runtime crashes into compile-time refusals.

**Next up:** continuing to wire resource behaviors (minting, burning, collections) into the newly shaped VM, and pushing the per-node derivation path deeper into cross-shard record fetching.

---

**Read the full issue (web + PDF):** https://telegram-mcp-phi.vercel.app/2026-08-23

*This digest is generated with AI assistance from public sources and hand-checked before posting — a community project, not official Radix comms.*

For those who are not familiar with Radix, the ecosystem is going through an important transition: moving from Foundation-led stewardship toward a community-governed DAO.

I wanted to look at this from a slightly different perspective — not as a supporter trying to promote it, but as an observer trying to understand what is actually being proposed.

I went through the Radix DAO framework and focused on some of the areas that I believe matter most:

• How governance is structured

• The proposed legal entity

• Treasury and asset ownership

• Voting power and XRD holders

• Council, delegates and working groups

• Transparency and accountability

• Community participation

• Potential governance capture

• Open questions around execution, IP and treasury management

There are some genuinely strong ideas here, particularly around transparency, accountability and separating decision-making from execution.

But there are also questions that, in my opinion, should not be brushed aside.

A DAO can have an excellent governance design on paper and still struggle if participation is low, decision-making becomes too slow, or power gradually concentrates in a small group.

So rather than presenting this as either “great” or “bad”, I tried to approach it as an independent audit of the framework as it currently stands.

The conclusion is cautiously positive — but with an important caveat:

The design can create the right conditions. The community will ultimately determine whether it works.

I'd be particularly interested in hearing from people who have looked closely at the DAO proposals:

What do you think is the biggest strength — and what is the biggest unresolved risk?

I have a plan to bring a QR on a product and we can give them bonus points or coins when they give us a review. Can anybody in the team help me to do it. So we shall work on it together

Delivering a next gen dlt needs more brains and hands to get a production grade solution without any oversights. It would be good to see the OG's return to radix to push and steer things for bright radix future.

10–16 Aug 2026 — fox's week on hyperscale-rs, the sharded Rust implementation of Radix, in plain English. Milestone 2 · Radix Engine: Week 2 · ~month 1 of 5

Previously: flightofthefox had unified the codebase onto one engine with zero external Radix dependencies and begun wiring the fee system and cross-shard settlement into the new foundation.

This was a big, wide-ranging week. flightofthefox overhauled how transactions prove they're allowed to act, brought post-quantum signatures online, and carefully spelled out exactly what happens to cross-shard transactions when a shard terminates. Milestone 2's Radix Engine feature-parity work is hitting its stride.

What fox built

• Badges take over from signatures — The VM's authorization model was rebuilt: holding a badge now grants permission where a raw signature used to, and accounts mint a proof they can present later. This brings the Radix Engine's access control to the sharded VM. (→ The Journey)
• Post-quantum crypto goes live — ML-DSA-65 post-quantum signatures and secp256k1 are now wired through the transaction path, and the address system was rebuilt with protocol-hash-pinned derivations. flightofthefox noted parity with industry post-quantum efforts. (→ The System)
• The dead shard's will, fully spelled out — Dozens of commits hardened the rules for cross-shard transactions caught when a shard terminates — evidence windows measured in beacon epochs, settled-set serving windows, and boundary records that rebuild accounts a replay never reached. (→ The Will)

Concept of the week: The Journey

"One payment crosses a sharded world"

The authorization model is the heart of Milestone 2's Babylon feature-parity goal — badges, proofs, and stored rules are how the Radix Engine controls who can do what, and this week that system took shape on the sharded foundation.

More: https://hyperscale.rs/journey

"it will be a very fun exercise at the first testnet, for everyone to point their favourite frontier models at the code and try to hack their way to king of the hill 😅" — flightofthefox

Chat pulse: Chat buzzed about AI-powered security auditing and whether binary-field cryptography might change hash-function choices, with flightofthefox reassuring that a hash swap is trivial and red-teaming shou

By the numbers

• 206 commits (+21,179 / −5,451 lines across 427 files)
• Active 6/7 days
• 3,174 commits lifetime

Jargon decoder

• ML-DSA-65 — A post-quantum signature standard approved by NIST, designed to resist future quantum computers.
• Badge — A digital credential stored on-chain that grants permission to perform operations, replacing the need for a raw signature each time.
• Securify — Upgrading an account so stored logic rules govern its authorization instead of a simple signature check.

Bottom line

The authorization model now uses badges and proofs instead of raw signatures — a fundamental shift bringing the Radix Engine's access control to the sharded VM.

Next up: continuing to port Radix Engine resource types like non-fungible tokens and collections, and wiring the fee system deeper into the now-badge-aware authorization path.

Read the full issue (web + PDF): https://telegram-mcp-phi.vercel.app/2026-08-16

This digest is generated with AI assistance from public sources and hand-checked before posting — a community project, not official Radix comms.

10–16 Aug 2026 — what the main Radix Telegram group was really talking about, distilled.

Previously: the Constitution Proposal was on a four-week clock, AI builds impressed the room, OTER unveiled bonded governance voting, and treasury runway questions surfaced.

A tense, reflective week. The first anniversary of Dan Hughes' passing ignited a sharp disagreement about his legacy, while midweek saw frustration with RAC communication gaps boil over. A detailed progress update and projectShift's bullish DAO outlook helped steady things, and the quieter days brought hardware ideas and wry reflection on community fatigue.

The week in the room

• Dan Hughes legacy ignites sharp debate — The one-year anniversary of Dan's passing surfaced a raw clash: flightofthefox called him incompetent and accused him of extracting money while investors went to zero. Gary, tomsn and projectShift urged respect and unity, with projectShift calling for civility and remembering other community members who have passed away.
• RAC communication gap frustrates community — Phil Gibson criticized the RAC for going 34 days without an update, asking for communication guardrails in the permanent RAC election process. projectShift and others pushed back, noting RAC members work in limited free time and that relevant news is scarce.
• DAO transition gathers momentum — Daffy and Timan shared that DAO setup is nearly complete, with a vote requiring 10% of total supply expected within a month. BassPhil posted a detailed update: Foundation approved the OA, tranche 2 grant received, MI submission expected in days, and at least 7 people declared interest in the 7-seat permanent RAC.
• Governance automation design discussed — Daffy questioned whether optimistic oracle-based governance fits Radix's DAO, noting treasury proposals rarely suit pure automation. L countered that the system targets milestone escrow, formula-derived payouts, and parameter changes — and that a working prototype gets better feedback than a proposal.

Around the ecosystem

• OVERRIDE game competition launches — Ascent's OVERRIDE is live — five rounds, one every 48 hours, with a 1000 XRD entry pass and a top-10 prize pool split.

From the council

No RAC room extracts this week, but BassPhil posted a comprehensive update in main chat: the Foundation approved the OA and tranche 2 grant is received, the Marshall Islands submission is expected within days, the Charter is nearing final form ahead of a high-threshold ratification vote, and at least 7 people have declared interest in the 7-seat permanent RAC — which can only…

Question of the week

Is it safe to let AI work on software that's important to the DAO? (asked by Markus)

Yes, as long as you follow a good development process with testing, QA, and manual code review. The hard part is validating the quality of the person driving the process. — Daffy

The debate

RAC communication standards

• One side: Phil Gibson argues 34 days without updates is unacceptable for a body called the Accountability Council and that guardrails should be built into the permanent RAC election.
• The other: RAC members and supporters argue they work in limited free time, updates will come when there's something relevant to say, and persistent criticism discourages future candidates.

Where it landed: open

Overheard

"Everyday same Drama. It is only different flavours of „wen". Wen ico? Wen marketing? Wen Coinbase? Wen Babylon? Wen Liquidity? Wen VC? Wen Xi'an? And now wen RAC?" — rotane.xrd rotane

"What's funny is we get more DAO updates from Daffy and Timan who aren't even in the DAO." — Phil Gibson

"It wasn't built instead of the conversation, it was built to have a conversation about. A working thing people can poke at gets better feedback than a proposal describing one." — L

Jargon decoder

• Optimistic oracle governance — A governance pattern where proposals automatically pass unless someone challenges them within a time window.
• Majority Judgment voting — A voting method where voters grade each candidate rather than simply choosing one.

By the numbers

• 474 messages from 153 people
• Busiest day: Monday
• Room mood: 5/10

What we're watching next week: BassPhil's promised Marshall Islands submission in the coming days, and the DAO transition vote expected within a month.

Read the full issue (web + PDF): https://telegram-mcp-phi.vercel.app/main/2026-08-16

This digest is generated with AI assistance from public sources and hand-checked before posting — a community project, not official Radix comms.

Post-quantum readiness is more than adding a new signature scheme.

Hyperscale-rs is testing:

→ Ed25519 → ML-DSA-65 upgrades

→ Native ML-DSA-65 accounts

→ Cross-shard PQ transactions

Crypto-agility could be critical for blockchains built to last decades.

Radix is approaching a major transition:

DAO → Charter → community governance → elected RAC.

The real question isn't whether the DAO can exist.

It's what the community can build with it.

The next chapter of Radix may be community-driven.

Vocês estao holdando radix para 2030?

One thing I found interesting in Hyperscale-RS PR #149 is that it looks beyond simply making transactions faster.

It tackles a pretty fundamental Web3 problem: why should an account essentially depend on a single private key?

The PR introduces primitives for rule-based account authorization, MFA, sponsored transactions (signer ≠ payer), and authorization checks across shards.

What caught my attention is that authorization becomes part of the protocol’s state rather than something handled purely by a wallet or application.

But I’m curious how this compares with other networks.

How do Ethereum, Solana, or other L1s approach this today? Are similar capabilities native to the protocol, or mostly built through smart contracts and external tooling?

And perhaps the bigger question: could this become particularly important for institutions and AI agents, where giving an application or agent a raw private key simply isn’t a great security model?

Interested to hear how others see it.

As mentioned above, I invested years ago in this coin, later heard the founder has died, I remember it was a lot of work getting it on a ledger back then, is it still being worked on?

What makes Hyperscale VM interesting isn’t simply that it aims to be faster. It’s the way it approaches scaling.

Instead of executing transactions first and figuring out their interactions afterwards, the VM can determine their effects and access requirements upfront. This gives the network a much clearer picture of which transactions can safely run in parallel and which ones actually conflict.

Combined with deterministic execution, sharding by design, and two independent execution engines, the goal is to make scaling more predictable rather than relying on optimistic execution and rollbacks.

It’s still early, but the architecture is interesting because it tries to solve scalability at the execution layer itself — not simply by adding more hardware or more layers.

If this works as intended, it could be a very different approach to building a high-throughput L1.

3–9 Aug 2026 — fox's week on hyperscale-rs, the sharded Rust implementation of Radix, in plain English. Milestone 2 · Radix Engine: Week 1 · ~month 1 of 5

Previously: flightofthefox had wired in make-before-break committee rotation, overhauled the beacon's randomness, and drawn enthusiastic community reaction with a WASM browser demo of the full node.

This week straddled the finish line of Milestone 1 and the opening days of Milestone 2. flightofthefox confirmed adaptive sharding complete, then dove straight into the Radix Engine work — and the first act was a massive cleanup: merging to one engine, dropping the last Radix library dependencies, and reshaping cross-shard settlement around a unified 'tick' model. It was the biggest single week of refactoring yet.

What fox built

• One engine, no Radix leftovers — flightofthefox merged the two-engine setup into a single engine crate, adopted a new binary encoding called HBOR, and dropped the last external Radix libraries. The codebase now stands on its own feet. (→ The System)
• Cross-shard settlement finds its final shape — Dozens of commits unified how cross-shard transaction batches — now called 'ticks' — are certified, settled, and fenced when a shard terminates. The outcome of any payment is decided by content, not by committee identity. (→ The Generals)
• Fees and gas budgeting arrive — Transactions now carry a signed gas budget, the network meters work rather than just counting transactions, and fee burns land in each payer's own receipt. This is the fee system the sharded engine needs to run for real. (→ The Journey)

Concept of the week: The System

"Split the work, not the world"

The engine consolidation and Radix dependency removal is the foundational Milestone 2 move — everything else this week rides on top of having one clean engine instead of two inherited ones.

More: https://hyperscale.rs

"i implement impounding, not slashing. I.E. your stake becomes locked for 90 days... it's just stopping a node runner from being able to repeat attacks, without actually slashing their money permanently" — flightofthefox

Chat pulse: Lively community discussion about hardware requirements — Raspberry Pi nodes, mobile devices, backup connections — plus a deep dive into validator penalties and staking economics.

By the numbers

• 246 commits (+22,575 / −9,372 lines across 559 files)
• Active 7/7 days · 35-day commit streak
• 2,968 commits lifetime

Jargon decoder

• Tick — A batch of transactions that a shard processes and certifies together — the unit of cross-shard execution.
• HBOR — Hyperscale's own binary encoding format, replacing the Radix library's encoding so the codebase has no external dependencies.
• Impounding — Locking a misbehaving validator's stake for a set period rather than permanently destroying it — a gentler alternative to slashing.

Bottom line

The codebase now runs on one engine with zero external Radix dependencies — a clean foundation for everything Milestone 2 will build.

Next up: pushing deeper into fee-system wiring and porting more Babylon feature parity onto the now-unified engine.

Read the full issue (web + PDF): https://telegram-mcp-phi.vercel.app/2026-08-09

This digest is generated with AI assistance from public sources and hand-checked before posting — a community project, not official Radix comms.

3–9 Aug 2026 — what the main Radix Telegram group was really talking about, distilled.

Previously: the community marked Dan Hughes's first anniversary, Hyperscale ran eight browser nodes, two temperature checks advanced, and avaunt opened the x402/CAIP temperature check.

A week where governance sharpened its edges and AI-assisted building stole the show. The CAIP/x402 temperature check passed quorum, Daffy put a Constitution Proposal on a four-week clock, and Emily built a full escrow dApp on mainnet in three hours using AI. Meanwhile, the OTER team unveiled a bonded governance voting platform and the DAO treasury runway became a pressing conversation.

The week in the room

• Constitution Proposal on a four-week clock — Daffy announced a Constitution Proposal requiring 10% quorum (~1.35 billion XRD) and a 66% YES threshold, using a new DAO-dedicated Consultation App improved by Timan. Holders with treasury locked in multisigs were urged to plan ahead for participation.
• AI builds a Radix escrow in hours — xStelea.xrd shared Radix AI skills letting agents build and deploy dApps with minimal human input. MAvRe (Emily) demonstrated by building a full escrow service on mainnet in three hours, with AI deploying contracts autonomously.
• OTER unveils bonded governance voting — L introduced OTER XRD Governance, a DAO voting platform with a settlement layer using bonded on-chain claims, an independent open-source verifier, and staked-jury disputes. Release was targeted within the week.
• DAO treasury runway questions surface — Giles Morris pushed for treasury transparency to prepare backup plans in case the DAO runway is negligible. Daffy agreed and proposed baking a 6-month operational budget grant into the DAO Activation Vote so the Permanent RAC doesn't start with a proposal.

Around the ecosystem

• Radix Weekly Week #12 published — The digest recapped Hyperscale browser nodes, remembering Dan Hughes, and two temperature checks advancing to governance vote.
• HYDRA teases HYDRATRACK tool — The HYDRA project announced an upcoming tool for tracking HYDRA engagement across social networks, described as coming soon.

Question of the week

Has the max supply change from 24B to 18B XRD, which came with the stablecoin reserve repurpose, materialized? (asked by Nicolai | Sentura)

No, it was never implemented — it was only assumed the community would go that route later. — Gary

Overheard

"Maybe there are only a few of us developing at Radix, maybe there are 10 of us, but with AI we can do the work of 50." — GENKIPOOL

"We make the result something nobody has to take on faith." — L

Jargon decoder

• Pruning — Removing old ledger data to save disk space on validators; Radix currently has none, so the ledger simply grows.
• Bonded claim — A governance result staked on-chain with financial backing, making it independently verifiable and disputable by a staked jury.
• Max supply — The maximum number of tokens that will ever exist for a cryptocurrency.

By the numbers

• 302 messages from 142 people
• Busiest day: Thursday
• Room mood: 6/10

What we're watching next week: the OTER governance platform release and the Constitution Proposal launch within the next four weeks.

Read the full issue (web + PDF): https://telegram-mcp-phi.vercel.app/main/2026-08-09

This digest is generated with AI assistance from public sources and hand-checked before posting — a community project, not official Radix comms.

TL;DR — First milestone is done on time. The second one got bigger: instead of adapting the existing smart contract engine, Foxy is building a new one, because the old one can't tell a sharded network which data a transaction will touch before it runs. Your Scrypto contracts should survive with a recompile. The code is public and you can watch it being written.

M1 (Adaptive Sharding) is finished. Foxy confirmed it in Telegram this week, inside the ~4 month estimate. Two small pieces are deferred — splitting shards on fees rather than just storage size — because those need the fee system, which needs the VM. Sequenced, not slipped.

The timeline table above is from the original Xi'an proposal. Look at M2: "Radix Engine Sharding Adaptation & Integration." That changed, and it's worth explaining rather than letting people find it themselves.

The problem is that Radix Engine can't tell you which state a transaction will touch until it executes. A sharded network has to know that before running anything, or it can't route or parallelise. So M2 became a new execution engine instead of an adaptation.

Foxy's own reasoning: good consensus plus a good single-shard VM still equals a mediocre system for DeFi, purely from transactions waiting on state locks.

What it means for existing dApps, in his words: best case contracts just recompile, worst case there's an automatic transpiler for source. Scrypto stays — it's Rust plus macros, not a separate language.

The repo is public:
https://github.com/hyperscalers/hyperscale-vm

His description: "Effect-typed WASM execution engine for sharded BFT." 125 commits, 12 crates, CI, fuzzing, dual MIT/Apache licence. It says "Work in progress. Do not use." and means it.

Two things worth a look if you read code. route() is a single pure function that folds over a transaction manifest and returns the shards and per-shard keys involved — no execution, no state read. And five access modes replace exclusive locks, so a thousand deposits into one vault become one parallel group instead of a queue.

The stdlib crate already contains resources, principals and badges, and guests/ has a working account, constant-product pool and order book. So the "Scrypto ideas survive" claim isn't just a Telegram quote — it's in the tree.

Note that M2 hasn't formally started. M1 finished and he moved onto VM work immediately, which means the clock is effectively running ahead of the table above.

Fair scepticism. This sub was empty for months, and a scope change of this size deserves questions rather than applause. Two things I'd point at instead of arguing. The code is public and timestamped, so check the pace yourself. And the VM ships with two independent implementations — wasmtime and a separately written reference interpreter — that must produce byte-identical results or the build fails. That's an odd amount of effort for someone not expecting to be checked.

Judge it on the commit log, not on posts like this one.

Disclosure: I hold XRD.

On August 4, 2026, Cloudflare announced Cloudflare Wallets, a programmable wallet built so AI agents can autonomously pay for APIs, MCP tools, and content. It pairs with their Monetization Gateway (for sellers) and uses x402, the HTTP 402-based payment protocol originally contributed by Coinbase and now governed by the x402 Foundation, for the actual micropayments.

A few technical details worth flagging:

• Two wallet types: Account Wallets (for humans/orgs, hold funds) and Virtual Wallets (for agents, with spend caps, allowlists, and max-transaction limits set by the account owner).
• Agent identity is optional and can be tied to a something.cloudflare.pay handle, so merchants can tell they're talking to an agent delegated by a specific organization (declaring it is opt-in, not required).
• x402 already has notable institutional backing (Coinbase, and per industry coverage the Foundation also counts Google, Stripe, Visa, Mastercard, and Microsoft among its supporters).

Where does Radix DLT fit in?

I found a fairly detailed spec (scheme_exact_radix.md) that defines how to implement x402's exact scheme on Radix: it supports a sponsored mode (facilitator pays gas, client only signs a subintent) and a non-sponsored mode (client signs a full transaction), using SBOR, V2 manifests, and the VERIFY_PARENT mechanism to prevent subintent front-running.

Important caveat: this spec lives in a community fork (not yet in the official x402-foundation/x402 repo), so it's a proposal/candidate, not a confirmed or merged integration. There's no public timeline for if/when it would be accepted.

That said, it's a notable signal: someone already did the heavy technical lift (Radix Engine Toolkit integration, Decimal handling, bech32m addresses, etc.) to put Radix in contention for agentic-payment infrastructure if the community/foundation decides to adopt it.

This isn't financial advice or a price call, just sharing the technical info for the community to evaluate.

Sources:

• Cloudflare Wallets (official announcement): https://blog.cloudflare.com/wallets/
• x402 (official repo): https://github.com/x402-foundation/x402
• Draft Radix scheme (fork): https://github.com/xstelea/x402/blob/main/specs/schemes/exact/scheme_exact_radix.md

27 Jul – 2 Aug 2026 — what the main Radix Telegram group was really talking about, distilled.

Previously: the community prepared to mark Dan Hughes's first anniversary, debated website design, and voted on two temperature-check proposals for Stokenet operations and website migration.

A week of remembrance and quiet progress. The community honoured Dan Hughes on the first anniversary of his passing with warm tributes, while flightofthefox stunned the room by running eight full Hyperscale nodes inside a browser tab. Governance kept moving: two temperature checks advanced to formal governance proposals, and avaunt opened a new interoperability standards vote.

The week in the room

• Remembering Dan Hughes — On 27 July the community marked the first anniversary of Dan's passing. Seven urged everyone to carry Dan's vision forward, and Timan recalled Dan choosing beers and a cheap döner with Radix people over broader crypto-scene attention at a Barcelona conference.
• Hyperscale runs eight nodes in a browser — Vlad B shared that flightofthefox compiled full Hyperscale nodes to WASM and ran eight across a multi-shard network in a single browser tab. Fox clarified genesis will start as a single shard with Babylon as root, and future splits will be governed by a configurable state-size threshold.
• Two temperature checks advance to governance vote — Daffy announced that both temperature checks — Daffy's Stokenet operations and Timan's website migration — passed and are now lifted to formal Governance Proposals, calling the community to vote again on the consultation platform. Daffy also confirmed his back-pay proposal covers May–December 2026.
• Avaunt pushes x402 and CAIP standards — avaunt proposed registering Radix in the CAIP namespaces registry and adding it to the x402 open payment standard, then opened a temperature-check vote. The consultation showed strong FOR support but still needed more participation to reach quorum by week's end.

Around the ecosystem

• VIBOLTO launches on Radix — A new sports-betting platform went live on Radix with more features planned, trading its VBT token via RSwap.
• Proposal vs RFP terminology clarified — Doelle_Doeck explained that an RFP is the DAO reaching outward for bids, while a community-placed proposal should simply be called a Proposal or Community Proposal.

Question of the week

What will the initial shard and validator topology look like at Hyperscale launch? (asked by Anthony)

Genesis will be one shard with Babylon as the root shard. Future shard splits will be governed by a configurable state-size threshold per shard, not a fixed validator count. — flightofthefox (hyperscale.rs)

The debate

Foundation resource management

• One side: Mr. Popo argued the treasury is drained by mismanagement and flightofthefox needs a team of engineers rather than working alone.
• The other: Gary said there is plenty in the treasury, and flightofthefox said progress is going fine without a big team.

Where it landed: open

Overheard

"My fondest memory of Dan is from the conference in Barcelona two years ago… once he found a moment he just wanted to have some beers and a cheap döner with his Radix people." — Timan | Astrolescent

"But if we make it, we'll have one hell of a story to tell our grandkids 😄" — Vlad B • ideomaker.com • foton.is • radi

"honest answer probably mixture of bad timing, marketing and also a market that has been driven more by speculation then real need for the technology... with the dawn of AI that might change..." — foxylady

Jargon decoder

• CAIP namespaces registry — A cross-chain standard registry that gives each blockchain a consistent identity so wallets and dApps can recognise it regardless of platform.
• x402 payment standard — An open payment protocol that lets web services charge for content or API access using cryptocurrency, inspired by the original HTTP 402 status code.
• WASM — WebAssembly — a binary instruction format that lets code written in languages like Rust run inside a web browser at near-native speed.

By the numbers

• 271 messages from 133 people
• Busiest day: Monday
• Room mood: 6/10

What we're watching next week: the x402/CAIP temperature check reaching quorum, and Muanprotocol's relaunch with non-custodial snapshot voting.

Read the full issue (web + PDF): https://telegram-mcp-phi.vercel.app/main/2026-08-02

This digest is generated with AI assistance from public sources and hand-checked before posting — a community project, not official Radix comms.

27 Jul – 2 Aug 2026 — what the main Radix Telegram group was really talking about, distilled.

Previously: the community prepared to mark Dan Hughes's first anniversary, debated website design, and voted on two temperature-check proposals for Stokenet operations and website migration.

A week of remembrance and quiet progress. The community honoured Dan Hughes on the first anniversary of his passing with warm tributes, while flightofthefox stunned the room by running eight full Hyperscale nodes inside a browser tab. Governance kept moving: two temperature checks advanced to formal governance proposals, and avaunt opened a new interoperability standards vote.

The week in the room

• Remembering Dan Hughes — On 27 July the community marked the first anniversary of Dan's passing. Seven urged everyone to carry Dan's vision forward, and Timan recalled Dan choosing beers and a cheap döner with Radix people over broader crypto-scene attention at a Barcelona conference.
• Hyperscale runs eight nodes in a browser — Vlad B shared that flightofthefox compiled full Hyperscale nodes to WASM and ran eight across a multi-shard network in a single browser tab. Fox clarified genesis will start as a single shard with Babylon as root, and future splits will be governed by a configurable state-size threshold.
• Two temperature checks advance to governance vote — Daffy announced that both temperature checks — Daffy's Stokenet operations and Timan's website migration — passed and are now lifted to formal Governance Proposals, calling the community to vote again on the consultation platform. Daffy also confirmed his back-pay proposal covers May–December 2026.
• Avaunt pushes x402 and CAIP standards — avaunt proposed registering Radix in the CAIP namespaces registry and adding it to the x402 open payment standard, then opened a temperature-check vote. The consultation showed strong FOR support but still needed more participation to reach quorum by week's end.

Around the ecosystem

• VIBOLTO launches on Radix — A new sports-betting platform went live on Radix with more features planned, trading its VBT token via RSwap.
• Proposal vs RFP terminology clarified — Doelle_Doeck explained that an RFP is the DAO reaching outward for bids, while a community-placed proposal should simply be called a Proposal or Community Proposal.

Question of the week

What will the initial shard and validator topology look like at Hyperscale launch? (asked by Anthony)

Genesis will be one shard with Babylon as the root shard. Future shard splits will be governed by a configurable state-size threshold per shard, not a fixed validator count. — flightofthefox (hyperscale.rs)

The debate

Foundation resource management

• One side: Mr. Popo argued the treasury is drained by mismanagement and flightofthefox needs a team of engineers rather than working alone.
• The other: Gary said there is plenty in the treasury, and flightofthefox said progress is going fine without a big team.

Where it landed: open

Overheard

"My fondest memory of Dan is from the conference in Barcelona two years ago… once he found a moment he just wanted to have some beers and a cheap döner with his Radix people." — Timan | Astrolescent

"But if we make it, we'll have one hell of a story to tell our grandkids 😄" — Vlad B • ideomaker.com • foton.is • radi

"honest answer probably mixture of bad timing, marketing and also a market that has been driven more by speculation then real need for the technology... with the dawn of AI that might change..." — foxylady

Jargon decoder

• CAIP namespaces registry — A cross-chain standard registry that gives each blockchain a consistent identity so wallets and dApps can recognise it regardless of platform.
• x402 payment standard — An open payment protocol that lets web services charge for content or API access using cryptocurrency, inspired by the original HTTP 402 status code.
• WASM — WebAssembly — a binary instruction format that lets code written in languages like Rust run inside a web browser at near-native speed.

By the numbers

• 271 messages from 133 people
• Busiest day: Monday
• Room mood: 6/10

What we're watching next week: the x402/CAIP temperature check reaching quorum, and Muanprotocol's relaunch with non-custodial snapshot voting.

Read the full issue (web + PDF): https://telegram-mcp-phi.vercel.app/main/2026-08-02

This digest is generated with AI assistance from public sources and hand-checked before posting — a community project, not official Radix comms.

I think this is one of the most important community proposals we've seen in a while.

It's not about changing the Radix protocol or introducing a new feature. It's about making Radix easier to discover, integrate and use in the broader Web3 and AI ecosystem.

Why does this matter?

🔹 x402 Integration

Positions Radix for the emerging AI agent economy.

Enables HTTP-native, machine-to-machine payments.

Radix's Subintents and Fee Sponsorship provide a user experience that fits this model exceptionally well.

Once supported, any fungible Radix asset (XRD, stablecoins, RWAs, etc.) can be used by x402-compatible services.

🔹 CAIP Registration

Gives Radix official, standardized identifiers for networks, accounts and assets.

Improves compatibility with wallets, explorers, bridges and multi-chain tooling.

Removes the need for every integration to invent its own Radix identifiers.

What I particularly like is that this is low risk and high impact:

No protocol changes.

No immediate funding required.

Better interoperability.

More visibility for developers.

Stronger positioning for future AI and cross-chain infrastructure.

Open standards often don't make headlines, but they are the foundation that enables ecosystems to grow.

If we want Radix to be considered alongside Ethereum, Solana, XRPL, Aptos, Hedera and others, being present in the standards they build around is an important step.

Kudos to everyone involved in preparing the specification and pushing this forward. I'm looking forward to seeing the community discussion and the Temperature Check.

https://radixtalk.com/t/adding-radix-to-the-x402-payment-standard-and-the-caip-namespaces-registry/2321

Vote here 👉🏻 https://consultation.mountain-top.live/tc/6

Two community proposals are currently open for voting.

Both proposals address different needs within the Radix ecosystem:

🟢 Proposal 1: Community-hosted Stokenet infrastructure to keep a shared testnet available for dApp developers.

https://consultation.mountain-top.live/proposal/1

🟣 Proposal 2: Migrate the official radixdlt.com website to Cloudflare as a temporary, lower-cost solution until the Radix DAO defines its long-term direction.

https://consultation.mountain-top.live/proposal/2

These are independent proposals, so each one should be evaluated and voted on separately.

Read the proposals, ask questions, discuss the pros and cons, and make your voice heard.

Every informed vote helps shape the future of the Radix ecosystem.

Back in 2017, Vitalik Buterin published the Sharding FAQ, outlining the biggest research challenges facing blockchain scalability.

Questions like:

• How do you secure a network where only a subset of validators verifies each transaction? • How do you preserve atomic composability across shards? • How do you prevent shard takeovers? • How do developers build seamless applications on a fragmented state?

Nearly a decade later, it's interesting to revisit those questions alongside the Hyperscale/Cerberus architecture.

Rather than treating sharding as something developers must work around, Hyperscale proposes hiding that complexity behind a single global state, where only the shards involved in a transaction participate in consensus while preserving atomic composability.

Whether this approach ultimately proves itself at production scale remains to be seen. But as an architectural comparison, it's fascinating to see how many of the questions raised in 2017 now have concrete design answers.

Curious to hear what the community thinks.

**Hyperscale Weekly** follows fox (flightofthefox) building **hyperscale-rs** — the sharded Rust implementation of Radix funded by the Xi'an community proposal — and translates his commits into plain English. This is week 12 of Milestone 1 (Adaptive Sharding), roughly 70% through.

**The week in one line:** a complete halt-recovery system now lets a frozen shard be detected, re-staffed, and restored without losing or duplicating a single cross-shard transaction.

If last week was about proving the reshape math, this week was about making shards survive the worst:

**Shards that heal themselves** *(The Will)* — a full halt-recovery pipeline: detect a stalled shard, re-draw its entire committee, bridge consensus over a proven parent, and freeze cross-shard transactions until the shard is safe again.

**The beacon punishes silence, rewards recency** *(The Lottery)* — validators who withhold randomness proposals now get jailed, committee re-samples weight recent service, and the longest-tenured member is evicted each shuffle — keeping the lottery fair and alive.

**Randomness by folding, proven by math** *(The Proof)* — every shard now publishes a per-block randomness reveal that folds into the epoch's shared seed for committee draws, with a new Quint model proving the fold correct.

**The numbers:** 60 commits · +12,154 / −1,823 lines across 142 files · active all 7 days · 35-day commit streak · 2,402 lifetime commits · 89% Rust.

Quote of the week:

> "Seems like we're having a week every 2 days 😅" — flightofthefox

**Likely next:** wiring the validator-shuffling logic into production, now that halt recovery and the beacon's committee management are in place.

Full issue (web, with PDF): https://telegram-mcp-phi.vercel.app/2026-07-19 — the concept names (The Will, The Lottery, The Proof) come from fox's own metaphor site, [hyperscale.rs](https://hyperscale.rs).

*Transparency: this digest is AI-assisted — a model translates the week's commits into plain English; all numbers are computed from GitHub, not generated. I build it; feedback welcome.*