---
title: "Radix vs Polkadot"
path: "/contents/tech/comparisons/radix-vs-polkadot"
version: "1.2.0"
author: "Hydrate"
createdAt: "2026-02-19T05:51:32.304Z"
updatedAt: "2026-03-16T18:20:55.606Z"
---

# Radix vs Polkadot

<Infobox>
| **Radix** | Unlimited shards, native composability |
| **[Polkadot](https://polkadot.com)** | Limited parachain slots, shared security via relay chain |
| **Key Difference** | Infinite sharding vs fixed parachain capacity |
</Infobox>

## Overview

Both Radix and [Polkadot](https://polkadot.com) address scalability through sharding, but with very different architectures:

### Sharding Model

**Polkadot** uses a hub-and-spoke model: parachains (application-specific shards) connect to a relay chain that provides shared security. Parachain slots are limited and auctioned — creating artificial scarcity.

**Radix** uses [Cerberus](/contents/tech/core-protocols/cerberus-consensus-protocol) with effectively unlimited shards. Consensus is braided dynamically per-transaction across relevant shards — no slot auctions, no capacity limits.

### Composability

Polkadot's XCM (Cross-Consensus Messaging) enables cross-parachain communication, but it's asynchronous. Radix provides [atomic composability](/contents/tech/core-concepts/atomic-composability) across all shards — critical for [DeFi](https://en.wikipedia.org/wiki/Decentralized_finance) where partial execution can mean lost funds.