Radix vs Ethereum

Consensus

Ethereum uses Casper PoS with a single execution layer processing all transactions sequentially. Scalability relies on L2 rollups (Optimism, Arbitrum, zkSync) which introduce sequencer centralization and cross-rollup composability challenges.

Radix uses Cerberus, which as specified parallelises consensus across shards so that throughput scales with shard count. As deployed on the live Babylon network, Cerberus runs unsharded — one shard group over the whole ledger, with the braiding machinery inactive — so today it too commits one ledger, and the linear-scaling property is a claim about the specification and about Hyperscale / Xi'an. The 500,000+ TPS test measured the Radix Foundation's Hyperscale implementation on a test network; it is not Cerberus and has never been a property of mainnet. For what each live network is actually doing, see Radix vs Solana.

Programming Model

Ethereum (Solidity): Account-based model where tokens are mappings inside contracts. Requires approve() + transferFrom() pattern. Susceptible to reentrancy, approval exploits, and front-running.

Radix (Scrypto): Asset-oriented model where tokens are native resources. No approval pattern. Reentrancy structurally impossible. Assets move in buckets.

Transactions

Ethereum: Opaque calldata – users blind sign hex data they can't read.

Radix: Transaction manifests – readable, composable, verifiable before signing.

Scalability

Strengths of Each

Ethereum's strengths: Largest ecosystem, most liquidity, widest tooling support, strongest brand recognition, battle-tested over 10+ years.

Radix's strengths: Superior asset model (native assets, no approvals), readable transactions, a scaling design that adds shards rather than layers, developer-friendly Rust-based language, and an execution model with no reentrancy and no approve() pattern to abuse.

Where the comparison stands, September 2026

The throughput row and the strengths above both need a date. On 31 August 2026 a single transaction took resources out of sixty vaults belonging to other people, and the Radix Engine permitted it. Twenty-six such transactions emptied every Hyperlane-bridged asset on the network between 16:02 and 16:57 UTC, and at 22:02 UTC the cause was stated publicly as the engine rather than the bridge.

The defect sat in the reference check every transaction passes before any contract code runs, which accepted a vault reference on the test that its blueprint was a vault, without asking who owned it. So the two comparisons this page draws against Solidity still hold – reentrancy and the approval pattern are absent from Radix – and the broader claim they were carrying does not. The engine removes a class of bug; it did not remove this one.

Its node runners halted mainnet that evening to stop further use of the defect. The last state the ledger committed was version 557,840,627, at 21:19:48 UTC on 31 August, and nothing more committed for ten and a half days. The fix shipped as the Eagle Ray protocol update, which enacted at the start of epoch 339,898 at 11:39 UTC on 11 September 2026. It adds a check, before every method call, that the calling frame is allowed to invoke the object it names; the Radix Engine page covers the change at source. After the restart a blueprint written to repeat the drain was published on mainnet, and its call was rejected with InvalidInvokeAccess.