Someone running a private Radix network asked this morning why it produced blocks faster than mainnet. Nothing throttles them. The nodes were sitting in one data centre.

Radix has no block time. Where other chains count blocks, Radix counts rounds, and the consensus configuration sets no duration for a round. It sets one for the epoch: five minutes. Rounds run as fast as the validators can finish them, so the round rate measures the distance between validators.

The clock does not get the last word. An epoch can only end on that five-minute target inside a band – no fewer than 500 rounds, no more than 3,000 – and the engine source gives the reason: to limit what a validator can do by lying about the time.

Nine consecutive epochs on mainnet, 13:24 to 14:09 UTC today. Each ran 296 to 305 seconds and took 1,808 to 1,842 rounds. That is one round every 164 milliseconds, and nowhere near the 3,000 ceiling.

On Radix, a token issuer who wants to freeze or claw back someone's holding cannot do it from a blueprint, the smart-contract code written with Scrypto, Radix's Rust SDK. The vault a blueprint works with has no freeze, unfreeze or recall method. Only a transaction manifest can, through four instructions that each take the address of the one vault holding the tokens, not the account and not the token. Both powers are roles declared on the token when it is created, so they hold wherever it goes, and a freeze is three separate switches, for withdrawals, deposits and burns, each lifted on its own. radix.wiki/developers/scr…

When Radix moved from Olympia to Babylon in September 2023, the new ledger took over every balance, stake and token but not the transaction history, which stayed in a single Olympia Gateway service that depends on the Radix Foundation. @GenkipoolC has restored that history from an old node database and published it as public-domain files on Hugging Face and the Internet Archive: 2.7m transactions across 175,567 accounts. Its explorer runs no Olympia database: it reads the files directly and fetches only the few hundred kilobytes a lookup needs. In that explorer, a Babylon account that existed on Olympia shows its history back to July 2021. radix.wiki/ecosystem/genk…

Since the Cuttlefish update of December 2024, a Radix user can sign half of a transaction. A pre-authorization, which the Radix Engine calls a subintent, is a signed fragment: it says what leaves your account, asserts what must arrive, and carries a deadline. It cannot pay the fee, so a dApp or a trading counterparty builds the full transaction around it, pays the fee in radix:native and submits it, and you need no XRD at all. If what you asserted does not arrive, the whole transaction fails and nothing moves. radix.wiki/contents/tech/…

Would you be open for a seat at the newly formed DAO of @radixdlt protocol ? Candidacies are open and we are about to run community elections.

Your profile would be a great value for the DAO team, and you could be surprised about RADIX tech level (equal or even better than SUI)

Please consider developing on @radixdlt, you WILL be surprized about its tech level.

A Babylon node, the software every Radix validator runs, keeps about 770 GB on disk, and community developers spent this week working out how much of it a validator needs. Dropping old substate versions and indexes takes it to 460 GB. On 5 November @flightofthefox published a s transaction history older than a retention the operator sets, and estimates most validators could run well under 100 GB that way. This week's Radix Week in Review has the measurements, the hUSDC refund and the Gateway rebuild: radix.wiki/blog/week-in-r…

Radix's Gateway API, the service wallets and dApps read the ledger through, answers for the past as well as the present. Each of its state endpoints takes an at_ledger_state field (a state version, an epoch or a timestamp) and returns balances, holdings and validators as they stood at that moment. Pinned to midnight UTC on 1 October 2023, three days after the Babylon release went live, the validator list returns 245 validators; today the same call returns 290. How the Gateway reads the ledger: radix.wiki/contents/tech/…

radix:native has no fixed supply, and only one thing on Radix can mint it: the consensus manager, the system component that closes each five-minute epoch. XRD's mint rule requires a badge only the consensus manager can present, and the rule for changing that rule is set to deny everyone, so no key holder and no vote can take the power for themselves. It mints at every epoch to pay validators and their stakers: total supply read off the ledger today is 13,567m XRD, 28.5m more than on 30 September. The same two-layer read answers whether any token's issuer can still change its rules: radix.wiki/contents/tech/…

The hUSDC refund is being paid on Radix. Since 10:31 UTC today, the account holding the recovered hUSDC has sent it out one account at a time, smallest holdings first: 71 accounts and 138k hUSDC by 15:12 UTC, of the 361k due to 79 accounts on the published list. hUSDC is the USDC bridged in over Hyperlane and drained on 31 August, and an October governance vote put 95% behind returning it to the accounts that held it. How each account's share was traced: radix.wiki/contents/histo…

In Hyperscale, Radix's sharded consensus, each shard runs at its own pace, and the shards reach global agreement only once per epoch.

@flightofthefox, the hyperscale-rs developer, said in the Radix developer chat today that a revision of a large part of the consensus is under way, after which the beacon chain would order every shard's block header against every other shard's. The beacon chain is the slow chain all validators run to decide which committee governs which shard.

That would give consistent cuts: one position per shard where every cross-shard transaction is either fully in or fully out. A Gateway, the service wallets and apps read the ledger through, could then read an account on one shard and a pool on another as of the same moment, without catching half a swap.

The question came from a community developer rebuilding the Gateway for Hyperscale, who asked which transaction order to build on. A total order would also be possible, but still a choice: with execution and consensus running separately, ordering by inclusion and ordering by finalization can put different transactions first.

radix.wiki/contents/tech/…

Congratulations to the Radix community on this important milestone!

A Python script can work with Radix without running a node. Reading the ledger is plain HTTP: POST a JSON body to the public Gateway, and /state/entity/details returns the state of an account, component or token. Writing goes through radix-engine-toolkit on PyPI, which builds, signs and compiles a transaction on your own machine; the Gateway's /transaction/submit then sends it to the network.

The steps, with a read script tested against mainnet: radix.wiki/contents/resou…

A Radix account can refuse a deposit. Its owner picks a rule: accept anything, accept only tokens the account already holds, or reject by default with exceptions for named tokens. So a project sending a token to a few thousand accounts cannot assume every transfer lands.

The Account Locker is the network's built-in answer, added in the Bottlenose protocol update in 2024. The sender puts the tokens in a locker, each amount addressed to one account. With one switch set, the locker tries a direct deposit first, and only what an account turns away stays behind to be claimed. Only the owner of that account can claim it, and the sender can take unclaimed tokens back only if the locker was created to allow that.

The Radix Wallet watches the lockers of the apps you have connected an account to, and shows you what is waiting there to claim.

radix.wiki/contents/tech/…

Radix's highest sustained throughput is 500,000 transactions per second, reached on 31 January 2026 in a public test of Hyperscale, the sharded consensus the Radix Foundation was building, by more than 590 nodes on datacentre servers, desktops and laptops.

Throughput there grows with the number of shards, slices of the ledger that each process their own transactions: private runs sustained about 250k on 64 shards and 500k on 128, the same rate per shard.

Mainnet does not run at that rate yet. It runs as a single shard group until Xi'an, the sharding upgrade, which has no release date.

radix.wiki/contents/tech/…

The 419,699 USDC caught mid-transfer on the Hyperlane bridge during August's exploit is back on Radix, and the Radix Foundation plans to refund it to the holders on Wednesday.

Also in this week's review: what the Foundation has committed to the new Radix DAO LLC, and hyperscale-rs moving its whole network layer to iroh.

The week in full: radix.wiki/blog/week-in-r…

Radix DAO LLC, the legal company for the Radix DAO, was incorporated in the Marshall Islands on 9 October with registration number 10280-26. The Transition RAC, the interim council running the DAO's formation, published the signed formation documents today.

A DAO LLC under Marshall Islands law gives a token-holder collective legal personality and limited liability: the DAO can hold assets and sign contracts in its own name, and its members are not personally liable for what it does.

The Radix Foundation has relayed a commitment to grant the company about 2.7bn radix:native and 100k US dollars in stablecoins, and the council is drawing up the handover with counsel. The DAO's ratified documents take force once the Activation Vote passes.

radix.wiki/ideas/dao-inco…

Stokenet, Radix's public test network, has been run by the community since the Radix Foundation handed over its validators, stake and Gateway this year. This weekend its operator is stress-testing the Gateway, the API that wallets and dApps use to read the ledger and submit transactions: an 8-hour run started at 14:00 UTC today, after a shorter test on Friday evening.

Anyone building on Stokenet who sees slow or failed requests is asked to report them in the Radix Developers Telegram. How the network is run and paid for: radix.wiki/contents/tech/…

Candidacy for the permanent council of the Radix DAO now closes on 13 November. The Transition RAC, the five-member Radix Accountability Council steering Radix from the Radix Foundation to the DAO, extended it by two weeks on 30 October, the day it was due to close. It wants at least 12 candidates, so one election can fill seven seats and leave replacements.

Five have stood so far, each introduced by a post of their own on RadixTalk:

Giles Morris, an accountant who runs a finance and tax business, offering budgeting and planning pro bono.

linuxx, a Linux sysadmin for 30 years, who wrote a Rust SDK for Radix and runs a full node.

Seböööl, who runs several companies in Germany, led hardware development before that, and researches Radix's move to Hyperscale.

a137x, a Radix developer since 2021 and founder of OTER and Tahuna, offering to review proposals' code and check vote counts.

Peterjan Litjens, in the community since 2018, with a background in logistics and industrial planning at NXP Semiconductors.

radix.wiki/ecosystem/radi…

"what happens when you compile the whole node to WASM and slap a multi-shard network in a browser tab" @flightofthefox

hyperscale.rs/demo?warmup=260