---
title: "Radix vs Ethereum"
url: "https://radix-wiki.miow.me/contents/tech/comparisons/radix-vs-ethereum"
updated: 2026-10-03
description: "Ethereum uses Casper PoS with a single execution layer processing all transactions sequentially. Scalability relies on L2 rollups (Optimism, Arbitrum, zkSync)…"
---

# Radix vs Ethereum

|  |  |
| --- | --- |
| **Type** | Technical Comparison |
| **Radix** | [Cerberus](/contents/tech/core-protocols/cerberus-consensus-protocol), [Scrypto](/contents/tech/core-protocols/scrypto-programming-language), [native assets](https://learn.radixdlt.com/article/what-are-native-assets) |
| **[Ethereum](https://ethereum.org)** | Casper PoS, [Solidity](https://soliditylang.org), [ERC-20](https://eips.ethereum.org/EIPS/eip-20) |

# Radix vs Ethereum

## Consensus

**[Ethereum](https://ethereum.org)** 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](/contents/tech/core-protocols/cerberus-consensus-protocol), which _as specified_ parallelises consensus across shards so that throughput scales with shard count. As deployed on the live [Babylon](/contents/tech/releases/radix-mainnet-babylon) network, Cerberus runs [unsharded](/contents/tech/core-protocols/cerberus-consensus-protocol) — 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](/contents/tech/research/hyperscale-rs). The [500,000+ TPS test](/contents/tech/research/hyperscale-500k-tps) 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](/contents/tech/comparisons/radix-vs-solana).

## Programming Model

**Ethereum ([Solidity](https://soliditylang.org))**: Account-based model where tokens are mappings inside contracts. Requires `approve()` + `transferFrom()` pattern. Susceptible to reentrancy, approval exploits, and front-running.

**Radix ([Scrypto](/contents/tech/core-protocols/scrypto-programming-language))**: [Asset-oriented](/contents/tech/core-concepts/asset-oriented-programming) model where tokens are native [resources](/contents/tech/core-concepts/resources). No approval pattern. Reentrancy structurally impossible. Assets move in [buckets](/contents/tech/core-concepts/buckets-proofs-and-vaults).

## Transactions

**Ethereum**: Opaque calldata – users [blind sign](/contents/tech/core-concepts/blind-signing-and-transaction-manifests) hex data they can't read.

**Radix**: [Transaction manifests](/contents/tech/core-protocols/transaction-manifests) – readable, composable, verifiable before signing.

## Scalability

| Property | [Ethereum](https://ethereum.org) | Radix |
| --- | --- | --- |
| L1 throughput, live | ~15-30 TPS | One unsharded ledger ([measured 21 August 2026](/contents/tech/comparisons/radix-vs-solana)); halted from 31 August to 11 September 2026 |
| Demonstrated in testing | — | 500,000+ TPS, but on the Foundation's [Hyperscale test network](/contents/tech/research/hyperscale-500k-tps) rather than Cerberus or mainnet |
| Scaling approach | L2 rollups (live) | L1 [sharding](/contents/tech/core-concepts/sharding) (specified; in development as [Xi'an](/contents/tech/research/hyperscale-rs)) |
| Cross-shard composability | Async bridges | Atomic in the same transaction, as specified |
| Hardware requirements | Moderate (L1), centralized (L2 sequencers) | Commodity |

## 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](https://learn.radixdlt.com/article/what-are-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](/contents/tech/core-concepts/buckets-proofs-and-vaults) belonging to other people, and the [Radix Engine permitted it](/contents/tech/core-protocols/radix-engine). Twenty-six such transactions [emptied every Hyperlane-bridged asset on the network](/contents/history/hyperlane-asset-drain-2026) between 16:02 and 16:57 UTC, and at 22:02 UTC the cause was [stated publicly](https://t.me/radix_dlt/1000779) 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](/contents/tech/core-concepts/buckets-proofs-and-vaults) reference on the test that its [blueprint](/contents/tech/core-concepts/blueprints-and-packages) 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](/contents/tech/releases/protocol-updates#eagle-ray-enacted), 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](/contents/tech/core-protocols/radix-engine#eagle-ray-fix) 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`](https://t.me/RadixDevelopers/66392).