Radix Compared

Introduction

Radix makes choices that have no counterpart on most networks. Assets are engine primitives rather than balances inside contracts, authority is carried by badges that are themselves resources, and the state model is sharded by design rather than by appended rollups. Describing those choices in isolation tends to produce a list of adjectives. Setting them against a network the reader already knows makes them concrete.

That is what these pages are for. Each takes one well-understood design and works out where Radix diverges, what the divergence buys, and what it costs.

The comparison set

Radix vs Ethereum is the load-bearing one, because Ethereum’s account-and-contract model is the default mental picture almost every reader arrives with. The gap between a token as a balance in a mapping and a token as a resource the engine itself moves is where most of Radix’s design follows from.

Radix vs Solana sets two different answers to throughput against each other: parallel execution on one very fast machine, against sharded consensus across many ordinary ones. Radix vs Cosmos and Radix vs Polkadot both address the multi-chain approach, where scale comes from many chains linked by a messaging layer and atomic composability across them is the thing given up.

Cerberus vs other BFT protocols is the narrowest and most technical of the set, placing Cerberus among the HotStuff-derived family it comes from.

How to read them

A comparison written by a project about its rivals is worth reading with the obvious caution, and these pages are written on a wiki about Radix. Where a claim is contested or a Radix feature has not shipped, the pages say so, and the research section carries the unresolved parts of the design. The comparisons are most useful for locating the real architectural fork in the road; the question of which branch was right is still open, and Radix’s branch is the one with the least mainnet evidence behind it.