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. Described in isolation those choices read as a list of adjectives, so each page here takes one network the reader already knows and works out where Radix diverges, what the divergence buys and what it costs.
How to read them
Radix vs Ethereum is the load-bearing one, because the account-and-contract model is the picture most readers arrive with. All of these pages are written on a wiki about Radix, so read them with the caution that deserves: where a claim is contested or a Radix feature has not shipped they say so, and Radix’s branch of the architectural fork is the one with the least mainnet evidence behind it.
Cerberus vs Other BFT Protocols
This page compares a specification against deployed protocols, which is the first thing to hold in mind: Cerberus 's distinguishing feature – atomic c…
Radix vs Cosmos
Radix and Cosmos take fundamentally different approaches to scalability: Cosmos uses sovereign app-chains connected via Inter-Blockchain Communication…
Radix vs Ethereum
Ethereum uses Casper PoS with a single execution layer processing all transactions sequentially. Scalability relies on L2 rollups (Optimism, Arbitrum,…
Radix vs Polkadot
Both Radix and Polkadot address scalability through sharding , but with very different architectures: Polkadot uses a hub-and-spoke model: parachains…
Radix vs Solana
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 executi…
