Radix vs Solana

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.

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.

Is Radix easier to build on than Solana?

For a program that holds tokens and pays them out, Radix needs less code and fewer concepts, because its engine does work that a Solana program does for itself. Solana's tooling has closed much of the setup gap since 2024, and Radix's advantage comes with a migration question that Solana does not have.

One job, two official examples

The hello-world example in the Scrypto repository creates a token with a supply of 1,000, keeps it in a vault inside the component, and gives one to whoever calls free_token, in 33 lines of code not counting comments. Solana's Anchor framework documents the nearest equivalent as a transfer from a program-held token account: it mints a token, holds it in an account the program controls, and transfers it to a recipient, in 93 lines. The two are not identical, since Anchor's mints on demand and sends the whole balance, but each is its framework's documented way to do the job.

The Radix method that pays out is one line:

pub fn free_token(&mut self) -> FungibleBucket {
    self.sample_vault.take(1)
}

It takes a token out of the vault and returns it in a bucket. The caller's transaction manifest decides where the token goes, and the engine fails the whole transaction if any bucket still holds tokens when the manifest ends (see worktop).

The Anchor version spends most of its lines on accounts. Each instruction lists every account it touches, with constraints on each: the mint, the program's token account, the recipient's token account, the token program, the associated token program and the system program. The program's token account sits at a program-derived address, derived from fixed seeds plus a one-byte bump, and the program signs the transfer by passing those seeds to the token program in a cross-program invocation. If the recipient has never held this token, the instruction first creates a token account for them, because on Solana a wallet needs a token account for every mint it holds, and the caller pays the deposit that keeps the new account on-chain.

Where the checks live

On Solana, only an account's owner program can change its data, but a program still has to confirm that each account passed in is the one it expects: owned by the right program, and signed by the right key. Anchor makes those checks when the developer picks the right account type for each field, and UncheckedAccount makes none. The Solana Foundation's security course covers missing owner checks and missing signer checks as separate classes of exploit, in which an attacker passes in an account the program did not expect.

On Radix, who may call a method is declared once in the blueprint: an enable_method_auth! block maps each method to the roles allowed to call it, and the system checks the caller's proofs against that rule before the method runs (see access rules and auth zones). A vault holds a single resource and refuses a deposit of any other, so a payment in the wrong token fails at the vault rather than depending on a check the developer remembered to write.

What Solana has fixed

Solana has worked on its own friction. Anchor 1.0, released on 2 April 2026, made Surfpool the default local network for anchor test, generates LiteSVM tests for new projects, and no longer depends on the separate solana command-line tool. The Radix equivalent of that local loop is resim, a simulator that creates accounts, publishes packages and runs transactions against a local ledger. Solana also has far more developers, libraries and live applications to learn from.

What the Radix model costs

When the engine enforces the rules, a flaw in the engine is a flaw in every component at once. On 31 August 2026 someone used a missing access check in the Radix Engine to take tokens out of accounts they did not own, and emptied the network of its bridged assets in 26 transactions (see Hyperlane asset drain). Eagle Ray, the protocol update that adds the check, enacted on 11 September, and the first exploit attempt after it was rejected the same day.

The other cost is what comes next. The Xi'an candidate in hyperscale-rs replaces the Radix Engine with hyperscale-vm, whose design lists Scrypto compatibility as a non-goal. Its lead developer has described moving an existing blueprint as a recompile at best and an automatic transpiler at worst, and the aim is to keep resources, manifests and badges while replacing the layers beneath them. A developer who learns the asset model today would keep that knowledge; whether today's blueprint code carries over unchanged is not settled, and the candidate has no published schedule.

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.

External links

• Solana Documentation: terminology (Sealevel, transactions entry)
• Agave validator requirements (Anza)
• Solana RPC: getRecentPerformanceSamples
• Radix Network Gateway API
• Radix Docs: node setup