---
title: "Radix vs Ethereum"
url: "https://radix.wiki/contents/tech/comparisons/radix-vs-ethereum"
version: "1.3.0"
updated: 2026-08-21
last_verified: 2026-08-21
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# 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) |

## 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 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. 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)) |
| 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 (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, structurally eliminates common exploit classes.