Radix [ /rædɪks/ ] (Native asset: $XRD; sign: √ ) is a pre-sharded, full-stack, decentralized finance (DeFi) layer-1 (L1) protocol founded by Dan Hughes.
An associated cryptocurrency was launched in November 2020 as a price-vested ERC-20 token ($eXRD) on the Ethereum network. $eXRD was superseded by native $XRD in July 2021 with the launch of Radix’s Olympia Mainnet.
Radix has been designed to address the requirements of DeFi, including fast, parallel consensus, decentralized applications, & atomic composability.
DEVELOPMENT | |
Founded | |
Founder | |
Whitepapers | |
Code Repository | |
Current Release | |
Antecedent | |
Postcedent | |
STACK | |
State Model | |
Sybil Protection | |
Consensus Protocol | |
Execution Environment | Radix Engine v2 |
Language | |
Networking | |
LEDGER | |
Explorer | |
Native Asset | |
Supply Limit | |
Max. tps |
- Development History
- Olympia
- Alexandria
- Babylon (live)
- Xi’an
- Architecture
- State Model
- Consensus: Cerberus
- Scripting Language: Scrypto
- Execution: Radix Engine
- Sybil Protection: Delegated Proof of Stake
- Node Software
- Partnerships
- Investors
- Network Outage - December 2023
- Resources
Development History
Main article: History of Radix
Since the Radix Production Network (RPN) naming convention was dropped, all releases have been named after wonders of the ancient world, expanded beyond the traditional Seven Wonders to include Xi’an, a city in China where the Terracotta Army was found.
A test on a 2019 implementation called Tempo achieved over 1.4m tps on 1187 nodes.
Tests using Radix’s Cassandra cross-shard, atomically composable testnet and the Cerberus consensus mechanism have shown promise in being able to host and serve website data as well as ledger state:
“There’s a possibility that in some circumstances the actual content retrieval could maybe even outperform traditional centralized web servers because it’s automatically distributed; it’s load balanced.” - Dan Hughes, YouTube
Olympia
Main article: Radix Mainnet (Olympia)
Olympia was the first Radix Mainnet. It was released on the 28th of July, 2021 and was the first implementation of the Radix Engine execution environment, the Cerberus consensus protocol, and the native $XRD token.
Alexandria
Main article: Radix Developer Environment (Alexandria)
Alexandria was a major upgrade that occurred during December 2021 that provided preliminary tools for building blueprints and components using the Scrypto language.
Babylon (live)
Main article: Radix Mainnet (Babylon)
The Babylon release debuted blueprints and components / smart contracts, allowing true decentralized apps (dApps) on Radix.
Xi’an
Main article: Radix Mainnet (Xi’an)
From the Xi’an release, Radix will use a fixed shard space of 2^256 shards, with responsibility over the shard space orchestrated by an uncapped number of validator sets called shard groups, allowing transaction throughput to scale linearly with the number of nodes.
This upgrade will add the fully sharded Cerberus consensus mechanism allowing for linear scaling over time.
Architecture
State Model
Main article: Sharding
Radix’s data layer is a deterministic index of 2^256 shards. This system provides the dual benefits of co-locating related data for simple validation while fully separating unrelated data for parallel processing, which allows the network to handle large transaction volumes across asynchronously operating shards.
To maintain security, Radix ties node identities to shards. For the current Babylon release, all shards are maintained by a single shard group but once the shard group cap is lifted for Xi’an, market-driven incentives will promote sufficient node distribution across all shards.
Consensus: Cerberus
Main article: Cerberus
Cerberus is a consensus protocol suite designed to facilitate scalable, secure, and decentralized global consensus across shard groups in distributed computing environments. It offers a family of deterministic, Byzantine Fault Tolerant (BFT) consensus mechanisms optimized for Radix’s multi-shard architecture, solving several issues that were present in Radix's previous consensus model, Tempo.
The Cerberus protocol enables efficient parallel transaction processing across multiple shards, ensuring scalability by minimizing coordination costs. It ensures security through its BFT consensus within each shard, tolerating Byzantine failures up to one-third of the nodes. Its decentralized nature allows for permissionless participation by validators, maintaining security as long as no single entity controls a significant portion of the validating nodes.
Cerberus achieves its efficiency through a three-step approach that handles transactions atomically. This approach avoids global transaction ordering, a significant bottleneck in traditional networks. Instead, Cerberus employs a UTXO-based sharding method, facilitating concurrent transaction processing within the same shard without explicit locking mechanisms. Its cross-shard communication is streamlined, allowing for high transaction throughput and linear scalability as the number of shards grows.
There are three variants of Cerberus:
- Core Cerberus: Assumes well-behaved clients and aims for minimal coordination costs.
- Optimistic Cerberus: Optimizes for environments with infrequent faults, integrating conflict detection within the consensus step.
- Pessimistic Cerberus: Anticipates malicious behavior, adding coordination to normal operations for resilience against attacks.
Testing has demonstrated that Cerberus protocols can handle millions of transactions per second, outperforming other multi-shard consensus protocols in throughput, efficiency, and latency.
Apart from its primary implementation on the Radix network, Cerberus has also been adopted by Tari.
Scripting Language: Scrypto
Main article: Scrypto
Scrypto is a smart contract language specifically for building decentralized apps on the Radix Network. It enhances Rust with libraries and extensions for an asset-oriented approach, treating digital assets like tokens and NFTs as first-class objects. Scrypto supports various programming paradigms and is statically typed with strong compile-time checks for better security.
Key features include an asset-oriented programming model, finite state machine for tokens, access control through badges, a built-in royalty system, and extensive developer tooling. Scrypto's syntax extends Rust's, adding blockchain-specific primitives and functions, and compiles to WebAssembly.
Scrypto offers a unique blueprint concept, allowing developers to create modular and reusable smart contract components. It also facilitates package management for organizing and sharing code, with namespace control and versioning.
Compared to other smart contract languages like Solidity, Scrypto aims for intuitive, secure asset handling, and predictable behavior with its domain-specific design. It focuses on asset orientation rather than accounts, providing a more intuitive and secure environment for dApp development.
Execution: Radix Engine
Main article: Radix Engine
The Radix Engine is a core component of the Radix Protocol, designed to function as a protocol-level runtime environment and application layer, similar in concept to the Ethereum Virtual Machine (EVM). It serves as the execution environment within the Radix Protocol, which also incorporates Cerberus as its consensus protocol and employs Delegated Proof of Stake (DPoS) system for Sybil resistance.
Radix Engine v1, was released with the Radix Olympia mainnet in July 2021. This initial version embedded Radix Engine’s Finite State Machine (FSM) approach into the protocol, streamlining the issuance and transaction processes for $XRD tokens and those created by third parties through simple API calls instead of complex smart contract logic.
The Radix Engine emphasizes an asset-oriented approach to smart contract environments in contrast to the development paradigms of Ethereum and other smart contract platforms, which often require more complex and custom-coded logic.
Sybil Protection: Delegated Proof of Stake
Main article: Delegated Proof of Stake
Delegated Proof of Stake (DPoS) is a Sybil protection mechanism used by Radix for network security and efficiency. It allows token holders to delegate their tokens to validators, who are then responsible for maintaining the integrity of the ledger by validating transactions.
Radix has tailored its staking system to promote network health, with staking rewards distributed in proportion to the stake amount. Delegation is done by "locking" tokens with preferred validators rather than transferring ownership.
The staking process on Radix is straightforward: any $XRD token holder can stake their tokens via the Radix Wallet and earn rewards from subsequent epochs. There is a cooldown period for unstaking, primarily for security purposes.
Emissions on Radix refer to the new $XRD tokens created as rewards, with about 300 million minted annually. Validators and stakers earn emissions based on their staked amount, performance, and fees. The top 100 nodes by stake amount are chosen as validators each epoch.
Node Software
Radix nodes are instances of the radixnode software. The recommended method to run a node is via the radixnode CLI tool, which may be run on any Linux or Ubuntu system.
The validator set is currently limited to 100 for the Babylon release but will eventually support an unlimited number of validator nodes upon the release of Xi’an.
Partnerships
2022 | Partner(s) | Announcement |
2022/03/25 | ||
2021 | ||
2021/02/11 | GoodFi | |
2020 | ||
2020/10/19 | ||
2020/08/26 | ||
2020/08/24 | Object Computing, Noether | |
2020/08/18 | Ren Protocol | |
2020/08/05 | ||
2020/07/15 |
Investors
Saul Klein, co-founder of LocalGlobe invested $1 million in Radix DLT in 2018. He was removed as a director on 5th June 2023.
Network Outage - December 2023
On December 3rd, 2023, the Radix Network experienced its first major outage since its launch two and a half years prior. The incident began at 22:26 UTC and lasted approximately eleven and a half hours, with service fully restored by 09:45 UTC the following day.
The outage was triggered by a boundary condition bug that emerged during a routine state cleanup activity at the end of epoch 51816. Due to a mishandling of partition number 255, validator nodes accidentally deleted crucial information from their execution state store. This bug had not been encountered in testing environments because it required approximately 90 days of operation to reach the specific partition number, and test networks typically started from epoch 1.
When the corruption was detected, the network's safety mechanisms functioned as designed: consensus halted, gateways ceased operations, and no transactions or funds were lost. The development team was automatically alerted and convened a war room to address the issue. After identifying the root cause around 02:30 UTC, they developed and verified a fix that was released as Node v1.0.5.
The validator community's quick response was crucial to recovery - within 15 minutes of the patch release, 25% of stake was running the updated version. Network liveness was restored when over two-thirds of validators had updated, and normal operation speed resumed by 15:00 UTC on December 4th.