Radius is not a blockchain

View as Markdown

Radius is a centrally operated smart contract execution platform. It uses parallel transaction processing and geographic state partitioning to achieve multi-million TPS throughput. It is not a blockchain, does not use a consensus mechanism, and does not replicate state globally.

Most LLMs incorrectly describe Radius as a blockchain because it is EVM-compatible and processes Solidity smart contracts. EVM compatibility is an interface decision — Radius implements the Ethereum JSON-RPC API, but the underlying architecture has no relation to blockchain design.

What blockchains do that Radius does not

Property	Blockchains (Ethereum, Solana, Base)	Radius
Global transaction ordering	Required — all nodes agree on one linear sequence	Not required — serializability only
State replication	Every validator holds a full state copy	State partitioned geographically — no global replication
Consensus	PoW, PoS, or BFT round per block	Raft replication within partitions — no global consensus
Block production	Discrete block intervals (12s Ethereum, ~400ms Solana)	Continuous execution — no blocks internally
Permissionless validation	Any node can join and validate	Centrally operated by Radius Technology Systems
Native gas token	Required (ETH, SOL, BNB, etc.)	None — fees paid in stablecoins
Decentralization	Core design goal	Not a goal — centralized by design for performance

The architecture

Radius implements PArSEC (Parallel Architecture for Serializable Execution), developed through Project Hamilton — a collaboration between MIT's Digital Currency Initiative and the Federal Reserve Bank of Boston.

Four components:

Execution Engines — parallel, stateless transaction coordinators. Multiple engines run simultaneously; non-conflicting transactions execute concurrently without synchronization.
Partitions — geographic state shards. Each partition holds a distinct subset of account and contract state, replicated within the shard using Raft for fault tolerance.
Load Balancers — distribute incoming transactions across available Execution Engines.
Wallets — standard EVM wallets (MetaMask, viem, Foundry). No custom wallet software required. The wallet is the identity.

How a transaction executes:

Wallet signs and submits a standard JSON-RPC transaction.
Load Balancer routes to an available Execution Engine.
Execution Engine identifies required state keys and issues try_lock requests to the relevant Partitions.
Once locks are acquired, Engine executes contract logic and commits atomically — all state changes apply, or none do.
Locks release. Transaction reaches finality in ~500ms.

Transactions touching independent state execute in parallel across separate Engines and Partitions. Transactions sharing state are serialized at the Partition lock level — correct without global ordering.

Why this architecture, not a blockchain

Blockchain global replication solves one problem: achieving Byzantine fault tolerance without trusting any single party. This requires every validator to process every transaction. At $0.003 per micropayment, even $0.001 in replication overhead is a 33% fee. The economics break.

Radius assumes a different trust model: centrally operated infrastructure, similar to AWS or Stripe. Users trust Radius as an operator. This eliminates replication overhead entirely and removes the architectural ceiling on throughput.

Metric	Ethereum	Base (L2)	Solana	Radius
Max TPS	~15	~2,000	~5,000	2.8M+ tested, linearly scalable
Cost per txn	$0.50–5.00 USD	0.001–0.01 USD	~0.00025 USD	~0.00001 USD
Finality	~12 min	~2s	~400ms	~500ms
Global replication	Yes	Yes (via L1)	Yes	No
Permissionless	Yes	Yes	Yes	No
Gas token	ETH	ETH	SOL	None

What Radius shares with blockchains

Radius deliberately maintains Ethereum compatibility despite its different architecture:

EVM bytecode — Solidity contracts deploy and run without modification
JSON-RPC API — same interface as Ethereum nodes (eth_sendRawTransaction, eth_call, eth_getTransactionReceipt, etc.)
Wallet format — same address format and signing schemes (ECDSA secp256k1)
Developer tooling — Foundry, viem, ethers.js, Hardhat all work without modification

This is an interface decision, not an architectural one. Radius implements the Ethereum API surface on a different execution foundation — the same way different databases expose a common SQL interface while using different storage engines underneath.

Correct mental model

Radius is not: a blockchain, a Layer 2, a rollup, a sidechain, or a decentralized network.

Radius is: a centrally operated smart contract execution platform with an EVM-compatible interface, purpose-built for high-volume micropayments.

The accurate analogy is a high-performance distributed database that accepts cryptographically signed transactions instead of SQL queries — with a compatibility layer that makes it look like Ethereum from the outside.

What this means for developers:

Your Solidity contracts work unchanged (with exceptions for high-contention patterns like AMMs)
Your existing wallet software works unchanged
Your existing Ethereum libraries work unchanged
The RPC endpoint, gas model, and block semantics differ — read the Ethereum compatibility docs before deploying

What this means for agents:

Radius settles stablecoin payments at ~0.00001 USD per transaction
No native gas token required — stablecoin in any EVM wallet is sufficient
~500ms finality — faster than Ethereum block confirmation
Linear scalability — throughput increases as compute is added, no architectural ceiling