Linear Scalability

Traditional blockchains hit throughput ceilings. Adding more nodes doesn't help because every node must process every transaction in sequence. Radius takes a different approach: sharded state with parallel execution.

State sharding model

State consists of key : value pairs representing data elements used with Radius Network, including smart contract code, their "data", and account balances. Radius distributes distinct state elements across multiple independent shard clusters:

Each shard:

• Runs as a 3-node Raft cluster (tolerates 1 node failure)
• Stores a partition of the global state
• Processes transactions independently of other shards

Why this scales linearly

Double the shards, approximately double the throughput for non-conflicting workloads. The system supports up to 16.7 million shards (24-bit shard indexing).

How sharding works

State Partitioning

Keys are hashed and distributed across shards via a prefix tree. When the system scales:

1. New shard cluster starts
2. Routing table updates with new keyspace assignment
3. Keys migrate lazily on first access
4. Old shard forwards lookups to new location

Zero-Downtime Scaling

Scaling operations happen without interrupting service:

Parallel Execution

Transactions accessing different keys execute simultaneously. No global ordering required:

Only transactions touching the same keys require coordination.

The Architecture

Radius uses a distributed architecture based on PArSEC (Parallel Sharded Transactions with Contracts):

Why No Blocks?

Traditional blockchains batch transactions into blocks for consensus and propagation. Radius eliminates these constraints:

Per-Shard Consensus

Instead of global consensus on a block of transactions, Radius achieves consensus per-shard using Raft. Each shard independently replicates its state changes. This means:

• No mining or proof-of-work
• No validator coordination overhead
• No block production delays
• Immediate finality once Raft commits

Congestion Control

When multiple transactions compete for the same key, Radius uses intelligent batching:

1. Detection: Shards track which keys cause transaction conflicts
2. Routing: Frontend routes conflicting transactions to the same backend
3. Batching: Backend executes conflicting transactions sequentially within a single batch
4. Efficiency: One lock acquisition serves the entire batch

Specialized Shards

Radius supports heterogeneous shard configurations for different access patterns:

Edge shards allow routing high-traffic contracts to dedicated infrastructure without affecting the rest of the system.

Live Metrics

Track real-time network performance:

• Dashboard → — Live TPS, settlement times, shard health

Compared to Other Approaches

Next Steps

• Designed for the Internet of Tomorrow — EVM compatibility and differences
• JSON-RPC API — Complete API reference
• Quick Start — Get from zero to first transaction