RADIX WikiRADIX Wiki

Consensus and scalability

Solana orders transactions with Proof of History and agrees on them with Tower BFT, over one global state machine: there are no shards and no execution partitions. Parallelism comes from the runtime instead. Sealevel is defined in Solana's own terminology as "Solana's parallel run-time for onchain programs", and a block's transactions entry is "a set of transactions that may be executed in parallel" — transactions declare the accounts they touch, so non-conflicting ones run across cores at once. The cost of that design is hardware: the Agave client's own validator requirements ask for 12 cores / 24 threads, 256 GB of RAM (ECC suggested), and separate PCIe Gen3 NVMe drives for accounts, ledger and snapshots. Voting is itself a transaction, and can cost a validator up to 1.1 SOL per day.

Radix is two different systems depending on which one is meant. Cerberus as specified braids consensus across only the shards a transaction touches, and throughput scales with shard count. As deployed, on the live Babylon network, Cerberus runs as a single unsharded instance — one shard group covering the whole ledger, which makes it equivalent to the original HotStuff BFT protocol, with the braiding machinery inactive because there is nothing to braid. Braiding has never run in production. Linear scaling by shard count is therefore a property of the specification and of the Hyperscale / Xi'an work in progress, not of the network available to transact with today.

What does hold today is the hardware floor. A Radix node's documented minimum is 4 vCPU, 16 GB of RAM and a 500 GB SSD, with 8 vCPU and 32 GB recommended for validators (see Running a Node) — roughly an order of magnitude below what an Agave validator is asked for.

What each network is actually doing

Both figures below are single calls against each network's own public endpoint, taken on 21–22 August 2026, and either can be repeated in one command. They measure demand, not capacity: neither is a benchmark, and neither is a ceiling.

MeasurementSolana mainnet-betaRadix mainnet (Babylon)
SourcegetRecentPerformanceSamples, 10 samples of 60 sGateway /stream/transactions, 100 most recent user transactions
Window600 s, ending at slot 440,790,9723,359.6 s, 22:09:48–23:05:47 UTC on 21 August 2026
All ledger traffic4,026 tx/s5.5 tx/s (state versions 552,958,337 → 552,976,939)
User traffic only2,192 tx/s (non-vote)0.03 tx/s (100 transactions in 56 minutes)

The top row is not comparable to the bottom one on either network, and that is the point of showing both. Roughly 46% of Solana's transactions in this window were validator votes, which are consensus overhead carried on the ledger; on Radix the equivalent overhead is the per-round ledger transaction, which is why the state version advances 18,602 times in a window that contains 100 user transactions. Comparing a headline TPS figure from one network against a user-transaction figure from another is the most common way these numbers are misread.

Asset model

Solana uses the SPL Token standard: token balances live in accounts owned by the token program, and a wallet holds an associated token account per mint. It is a materially safer arrangement than the EVM pattern of a contract keeping a balance mapping, because the asset is not the application's private bookkeeping — but moving a token is still a program invocation, and delegation and approvals are program-level constructs.

Radix makes assets a feature of the engine rather than of a program. Resources are created and moved by the Radix Engine itself, held in vaults, and passed between components in buckets that the engine will not let a transaction lose or duplicate. There is no token contract to approve against, and a transaction manifest states in readable form which resources move where. See asset-oriented programming for the full model.

Where each is heading

Solana's near-term throughput work is client engineering rather than a protocol change — the Firedancer client from Jump Crypto, and Anza's successive Agave releases. Radix's is a replacement stack: Hyperscale, the Xi'an candidate, which shards, replaces the Radix Engine with a purpose-built WASM VM, and in its first published execution benchmark ran plain transfers 20.3× faster than the Radix Engine on one core. It is unreleased.

Asked how the two compare, the lead developer of the Xi'an candidate offered an assessment that is worth reading as one implementer's view rather than as a measurement. Solana, in that view, "is not sharded", and its theoretical ceiling "might shift somewhere between 100-200k TPS" once the current client work settles — with the caveat "not sure what it'll actually be in practice tho". On the difference in goal rather than degree: "Solana is awesome. It's a good design if optimizing for low-latency. That's a different focus than Hyperscale which is uncapped throughput though".

Key trade-offs

Solana's strengths: a large live ecosystem with deep DeFi, NFT and payments activity; parallel execution already running in production; sub-second slot times and fast finality; a mature fee market with an explicit compute budget per transaction.

Radix's strengths: assets enforced by the engine rather than by application code; transaction manifests a user can read before signing; validator hardware an order of magnitude cheaper; and a scaling design that adds shards rather than raising the hardware floor.

The honest asymmetry: Solana's advantages are shipped and measurable today, while Radix's scaling advantage is a specification plus an in-development implementation. The Babylon network that exists now is a single unsharded ledger, and — as the measurement above shows — is nowhere near using even that.

HydrateLast updated Aug 21, 2026v2.0.07 revisionsVerified Aug 21, 2026