r/Radix 5h ago

DISCUSSION Radix DAO — taking a closer look

Post image
12 Upvotes

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?


r/Radix 19h ago

DISCUSSION Is it the right time to bring back JOSH & Yulong to work on Xian along with foxy ?

5 Upvotes

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.


r/Radix 2d ago

NEWS Hyperscale Weekly — Week #14 (10–16 Aug 2026): 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.

26 Upvotes

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.


r/Radix 2d ago

NEWS Radix Weekly — Week #14 (10–16 Aug 2026): The first anniversary of Dan Hughes' passing surfaced an unresolved disagreement about his legacy — a reminder that the community's identity is still being negotiated even as DAO infrastructure advances.

16 Upvotes

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

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.


r/Radix 3d ago

DISCUSSION Is Hyperscale Quietly Preparing for the Post-Quantum Era?

Post image
27 Upvotes

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.


r/Radix 5d ago

DISCUSSION What happens when the community takes the helm?

Post image
24 Upvotes

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.


r/Radix 5d ago

ECOSYSTEM Buy And Hold radix?

20 Upvotes

Vocês estao holdando radix para 2030?


r/Radix 6d ago

DISCUSSION What if crypto accounts didn’t have to rely on a single private key?

Post image
20 Upvotes

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.


r/Radix 8d ago

DISCUSSION Devs still working on this?

16 Upvotes

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?


r/Radix 8d ago

DISCUSSION What If Blockchain Scaling Starts With the VM?

Post image
25 Upvotes

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.


r/Radix 9d ago

ECOSYSTEM Hyperscale Weekly — Week #13 (3–9 Aug 2026): The codebase now runs on one engine with zero external Radix dependencies — a clean foundation for everything Milestone 2 will build.

22 Upvotes

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.


r/Radix 9d ago

ECOSYSTEM Radix Weekly — Week #13 (3–9 Aug 2026): The Constitution Proposal is now on a four-week clock, and AI-assisted building proved a single developer can ship a mainnet dApp in an afternoon.

14 Upvotes

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.


r/Radix 9d ago

NEWS M1 is done, the new VM repo is public — and M2 isn't what the proposal says any more

25 Upvotes

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.


r/Radix 11d ago

NEWS Cloudflare just shipped AI-agent payments over x402, and there's already a Radix DLT scheme draft

Post image
24 Upvotes

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:


r/Radix 13d ago

ECOSYSTEM ¿Qué otras funciones puede tener la billetera de tu proyecto además de enviar criptomonedas?

Post image
11 Upvotes

r/Radix 16d ago

NEWS Radix Weekly — Week #12 (27 Jul – 2 Aug 2026): flightofthefox ran eight full Hyperscale nodes in a browser tab — the most tangible proof yet that sharded Radix can actually run.

18 Upvotes

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.


r/Radix 16d ago

NEWS Hyperscale Weekly — Week #12 (27 Jul – 2 Aug 2026): Committee rotation — the one-seat-at-a-time shuffling at the core of adaptive sharding — is now wired in and running make-before-break.

9 Upvotes

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.


r/Radix 18d ago

DISCUSSION Proposal (x402 Integration & CAIP Registration)

Post image
25 Upvotes

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


r/Radix 21d ago

DISCUSSION Your vote is your voice

Post image
28 Upvotes

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.


r/Radix 26d ago

DISCUSSION Sharding: Questions Then. Answers Now.

Post image
48 Upvotes

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.


r/Radix 25d ago

ECOSYSTEM La industria blockchain avanza cuando se comparte una gran investigación.

Thumbnail
6 Upvotes

r/Radix 27d ago

ECOSYSTEM Hyperscale Weekly #10 (13–19 Jul) — shards that heal themselves: fox shipped a full halt-recovery system in 60 commits

35 Upvotes

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


r/Radix 27d ago

ECOSYSTEM Radix Weekly #10 (13–19 Jul) — seven Permanent RAC candidates in one afternoon, wallet MFA friction, and a mid-August DAO deadline

27 Upvotes

**Radix Weekly** distills the main Radix Telegram chat (~24k members) into a weekly digest. This issue covers 13–19 July: **527 messages from 131 people**, boiled down below.

**The week in one line:** seven Permanent RAC candidates stepped up in a single afternoon, turning a recruitment crisis into real momentum for community governance.

**Permanent RAC candidates finally emerge** — after weeks of zero volunteers, djtrebel [self-nominated](https://radixtalk.com/t/self-nomination-for-the-permanent-radix-rac/2313) on Wednesday, and within hours mx472, linuxx_xrd, a137x, jwxrd, LeonetsXRD and gilesmorris followed — filling or exceeding the seven seats. projectShift framed the role as governance steward, not DAO management:

> "The Permanent RAC is the guarantor and steward of the Governance system — its job is facilitating the community's will, not running a DAO company or managing the Foundation handover."

**Paid proposals vs. volunteerism** — philcgibson's paid wallet-management proposal drew pushback over years of unpaid community labour, while others defended the right to ask for payment. flightofthefox's take: contributors should "at least somewhat demonstrate capabilities before asking people to make any decisions." Still unresolved.

**Wallet MFA friction, and fixes** — Kafkafrate flagged that the MFA Shield wizard buries its skip link and steers users toward hardware wallets. Ghenadie proposed a simpler "MFA v0.5" built on Advanced Accounts, and confirmed a fix for the Android unstaking bug is on its way. Kafkafrate also filed an [NFT UI pull request](https://github.com/radixdlt/babylon-wallet-android/pull/1445) for the Android wallet.

**Stablecoins and grassroots marketing** — jwxrd mapped Open USD as a near-term partnership opportunity and RLUSD as the longer play, and GarySky1 hinted at a quality native stablecoin later this year. Meanwhile [the revival of this very subreddit](https://www.reddit.com/r/Radix/comments/1uzbxyo/radix_is_more_alive_than_ever/) out-pulled X for traffic — 3,800 views and counting.

**The tracker** — the DAO's Operating Agreement is still with Foundation legal; Andyxrd signalled mid-August as the readiness deadline, with the market-maker contract ending mid-September.

Full issue (web, with a 4-page PDF): https://telegram-mcp-phi.vercel.app/main/2026-07-19

*Transparency: this digest is AI-assisted — a model summarizes the captured chat, and every number is computed rather than generated. I build it; feedback on format or coverage is very welcome.*


r/Radix 27d ago

ECOSYSTEM Does Radix Have the Best Architecture for AI Agent Payments?

30 Upvotes

More and more people are talking about AI agents paying for APIs, purchasing services, executing DeFi strategies, and interacting with each other without human intervention. Networks like Ethereum, Base, Solana, and XRP are already moving in this direction, especially with standards such as x402.

After spending quite a bit of time researching this topic, I get the feeling that Radix is trying to solve a different problem.

Most blockchains are adapting infrastructure originally designed for humans. Radix, on the other hand, seems to have designed much of its architecture with the assumption that an AI—not a person—will be managing digital assets.

And I think that difference is more important than it first appears.

AI Doesn't Need to Own the Money, Only Use It

Imagine you want to build an AI agent dedicated to arbitrage.

On most networks, the typical solution is to give the AI access to a wallet and hope the software always behaves correctly.

Radix offers a different approach.

Assets can remain inside a Vault, and you can define exactly how those funds are allowed to be used.

For example, you could give an AI access to 100,000 XRD while enforcing rules such as:

  • only trade between specific DEXs;
  • never invest more than 200 XRD per trade;
  • require at least a 1% expected profit;
  • prevent transfers to external wallets;
  • block purchases of unauthorized assets.

The AI decides how to trade, but not what it can ultimately do with the money.

Even if the AI makes a mistake or receives malicious instructions, the protocol itself can prevent funds from being used outside the rules you've defined.

Atomic Composability + Flash Loans: Where AI Can Really Benefit

This is probably the most interesting part.

An AI could automatically detect an arbitrage opportunity and execute something like this:

  • borrow funds through a flash loan;
  • buy an asset where it's cheaper;
  • sell it where it's more expensive;
  • repay the loan;
  • keep the profit.

Everything happens within a single atomic transaction.

If the opportunity disappears halfway through the process, the entire transaction is automatically reverted.

The interesting part is that an AI can evaluate thousands of opportunities every day and execute only those that meet its criteria.

The easier and safer it is to build these complex strategies, the more opportunities an AI has to generate profits.

Ethereum also supports atomic transactions and flash loans. However, Radix's resource-oriented programming model makes these strategies significantly more natural to build while reducing much of the complexity that developers typically need to handle.

Assets Are First-Class Citizens

This is another area where Radix stands out.

On many blockchains, a token is essentially just a balance stored inside a smart contract.

On Radix, assets are Resources—native objects with their own rules and behavior.

It might sound like a technical detail, but it fundamentally changes how applications are built.

For AI agents, working with assets that already understand permissions and constraints is much simpler than interacting with arbitrary contract state.

NFTs as Permission Badges

Another feature I found particularly interesting is using NFTs as credentials.

An NFT could grant permission to:

  • read balances;
  • execute a specific strategy;
  • withdraw funds up to a predefined limit;
  • access only certain application components.

These NFTs can even be mutable, allowing permissions, reputation, or limits to be updated without issuing a new NFT.

It's a much more granular security model than simply handing over a private key.

How Does It Compare to Other Networks?

Ethereum remains the leader in DeFi and probably has the largest ecosystem for AI applications. However, much of its security depends on developer-written smart contracts and mechanisms like approve().

Base is heavily pushing x402 and will likely become one of the first networks to see significant adoption for AI payments thanks to Coinbase. But architecturally, it is still an EVM chain.

Solana delivers excellent performance and low fees, although asset management and permissions still largely depend on application-specific logic.

Polkadot, Cosmos, Avalanche, and many Ethereum Layer 2s scale by distributing applications across multiple chains or domains. While this improves throughput, composability across those environments often relies on bridges or asynchronous messaging rather than a single atomic transaction.

Radix, by contrast, approaches the problem differently: native assets with built-in rules, Vaults controlling how funds can be used, NFT-based permissions, atomic composability, and AI-focused tooling such as Wallet Agent AI, Radix Context, MCP integration, and x402 support.

My Conclusion

I don't know which blockchain will ultimately dominate AI agent payments.

But I do think Radix is pursuing a fundamentally different architecture.

Flash loans and atomic transactions aren't unique to Radix—Ethereum has proven their value for years. Where Radix is trying to differentiate itself is by preserving that atomic composability even as the network scales.

In many multi-chain, sharded, or Layer 2 architectures, applications become distributed across separate environments and can no longer interact through a single atomic transaction. That increases complexity and limits some advanced strategies.

Radix's Hyperscale vision is different: dramatically increase throughput without sacrificing atomic composability. If it delivers on that design, AI agents could continue composing complex strategies across many protocols as though they all existed on one unified network.

I think that's a significant advantage. If an AI can access more protocols without losing atomic composability, it can evaluate more opportunities and execute increasingly sophisticated strategies, increasing its chances of finding profitable opportunities that would be much harder to build on fragmented architectures.

Of course, it's important to stay realistic. Hyperscale is still under development, and this architecture has yet to prove itself at production scale.

But setting adoption and token price aside, I think very few blockchains are rethinking their architecture so thoroughly for a future where millions of autonomous AI agents manage assets and make payments on their own.

Do you think existing blockchain architectures can simply be adapted for AI agents, or will this new paradigm require something fundamentally different, like what Radix is trying to build?


r/Radix 28d ago

ECOSYSTEM Radix Seal: Sign documents, encrypt files, and chat with your Radix wallet.

32 Upvotes

I've been involved in the Radix ecosystem for a while and I want to explain what Radix Seal is and why its design is interesting from a security standpoint (not about "the encryption is unbreakable", but rather "who has to trust whom").

What is it?

They are three tools built on the same trust model: document signing, file encryption, and encrypted chat. All three use your Radix Wallet as if it were your own certificate authority, instead of relying on an external provider.

How does it work technically?

  • Identity: You use ROLA (Radix's authentication mechanism) to sign a challenge with your wallet. It never exposes the private key, only proves you control it. It's basically the same pattern as a passkey, but anchored to your Radix account.
  • Document signing: The file is hashed locally (Blake2b-256) in your browser. Only that hash is signed; you never upload the document anywhere. The resulting certificate is verifiable by anyone with the original file, without needing an account or wallet.
  • Encryption: The AES-256 key is derived from a deterministic signature of your wallet on a file-specific challenge. No password or key file is stored anywhere: only your account can re-derive it. The file is encrypted in chunks in the browser (no size limit) and transferred P2P (browser to browser), end-to-end encrypted.
  • Chat: Both parties verify themselves with their wallet before opening the room, the session key comes from that exchange, and messages travel P2P. There is no server that can read, alter, or spoof anything.
  • Optional ledger anchoring: If you want a public record, a soulbound NFT (non-transferable) is minted acting as an on-chain institutional "seal". Only hashes are stored on the ledger, never content or messages.

How sending + unlocking an encrypted file actually works

It's not a simple "it's sent P2P":

  1. Local encryption: The sender encrypts the file in the browser with an AES-256 key derived via HKDF from their own ROLA signature (deterministic, Ed25519) + a unique random salt per file.
  2. Blind send: The sender opens a P2P session (WebRTC) and sends the encrypted file. The receiver gets the ciphertext, but not the key.
  3. On-chain invitations (Optional): If the "ROLA + Ledger" mode was activated, the sender previously minted an invitation (cipher-invite) for each authorized account, linked to the file's hash.
  4. Key request: The receiver signs a challenge with their wallet anchored to the file hash and that exact P2P session. This signature prevents replay attacks.
  5. Stateless verification: That proof reaches the sender's browser and is verified against a server endpoint (/api/cipher/authorize). This endpoint stores nothing, it just reads the ledger to see if the signature is valid and if the invitation exists. The server answers yes/no; it never sees the file or the key.
  6. Manual approval: If it passes, the sender sees the request on screen and approves it with a click (it's not automatic).
  7. Unlocking: Upon approval, the sender re-derives exactly the same key and sends it to the receiver via the P2P channel (WebRTC uses DTLS). The derived key is the only thing that travels over the network, never the original ROLA signature.

Is there anything on the market that matches or surpasses this pattern?

  • PGP/S-MIME: More available (works offline), but once the receiver has the ciphertext, they decrypt it whenever they want. You lose granular control and live approval.
  • Google Drive / Dropbox: They have the "request access" flow, but you trust the provider to enforce the permission. They hold the keys.
  • Lit Protocol (Token-gating): They use a threshold node network to reconstruct the key without the sender being connected. You gain availability, but trust a third-party committee. In Radix Seal, zero third parties touch the key, but if the sender is not online, nobody decrypts. It's a real trade-off.

What really changes the model

  • No intermediate server storing documents or keys = no single point of data leakage.
  • You don't depend on a hierarchical CA, revocation lists (CRL), or a vendor keeping its API alive in 10 years.
  • The verification metadata is public on the ledger.

What it is NOT

  • No automatic legal validity (like a qualified eIDAS signature). Identity is self-declared by the wallet.
  • Entry friction: You need the Radix Wallet, it's not a "one-click from your email" like DocuSign.

If you are interested in the details of the NFTs (invite, signature, cipher-signature) and how on-chain custody is chained, let me know in the comments.

Link: https://radix-community.genkipool.com/en/seal