Radix platform is built as a permissionless, programmable distributed ledger with its own uniquely developed consensus mechanism. Having been built as a solution to Ethereum's problems while implemented to DeFi, we are going to describe most of its features in comparison to Ethereum’s blockchain. 

Programmability 

Since Radix aims at eliminating the room for error both in network possibilities and in human interaction which can be very costly in the case of handling financial transactions. In order to host decentralized applications the network needs to be programmable, but robust, predictable and designed specifically to produce correct results on-ledger in response to requests. 

This is why instead of being Turing complete like in the case of Ethereum, the Radix Engine allows developers to build “Components” that are Conditional Finite State Machines which is a solution that is commonly used in mission-critical embedded systems where predictable correctness is the first priority. The programming language used for the Radix Engine is called Scrypto. 

Smart contracts 

Smart contracts are the key component of Ethereum’s programmability. They allow anything to be built on top of its network. However this flexibility is the problem when it comes to building Decentralized Financial applications. It puts the developer on the spot and errors could occur in writing the code, and especially in DeFi these smart contracts can easily get complex when combining with each other to produce a function. 

The key problem here is not the mere number of operations a smart contract can perform, but it's “fluid” design. The way smart contracts are designed is similar to a server running a code.To make that server perform its function it offers “methods” that users or other apps can call by sending a signed message. In order to perform the right function that correlates with the received message it has different variables (if-then) that are triggered by different call methods. 

These variables are actually what represents a token. It's simply a change in balance between wallets that are made inside an ERC20 smart contract which is created to behave like a supply of tokens by maintaining an internal list of balances. In this particular case to change those variables a “send” method is called upon a smart contract. 

Components 

Radix platform's equivalent of smart contracts is called components, which are built with finite state machine logic. Components are defined in behavior and function by "actions," which are equivalent to Ethereum's "method." These actions directly translate an existing input state to output or an after state. 

Designed in this way, these components are defined, but they can limit the room for errors and make them behave more like physical assets. Secondly, these components' usage is intuitive and predictable, which creates explicit guard rails on what can and cannot happen in creating the final output state.

Thus, a token on the Radix network behaves more like a physical asset that can be exchanged between users via, for example, a "change owner" action. In this case, the token is a component defined by actions similar to those that can be performed with real-world coins. 

Instead of smart contracts maintaining a balance for different wallets in this way, the token as a component acts like a tangible coin that can be owned by the users. Unlike in Ethereum's smart contract having to define a token supply, Radixes components are defined by their sub-components, so the token definition component (name, symbol, max supply, etc.) is subdivided into indivisible tokens equivalent to one Satoshi to Bitcoin. This leaves only a ledger maintaining the balances in the network as a whole. The advantage of this design is best seen when applied to liquidity pool staking and swapping tokens. Components that are limited in action can only perform a predefined operation. For example, a wrapped token defined to be given to a depositor can only fulfill this function, limiting the room for errors. 

Consensus mechanism

In order to achieve scalability and faster processing throughput, Radix has developed its unique consensus algorithm called Cerberus. It is designed behind the concept of sharding, which means that instead of all the nodes processing every transaction and competing to find blocks, they are processing smaller increments of the whole. 

This is something ETH 2.0 will introduce, but instead of bringing shards into a monolithic blockchain, the Radix network splits the ledger into "shard spaces." Being built in this way, the network splits processing into multiple times, instead of a global chain. Secondly, it uses a different Byzantine Fault Tolerance mechanism to verify the synchronicity of shards working together to produce a specific transaction since different shards are combined to do so. 

The consensus is called "braiding," and instead of a typical BFT-style consensus which uses 2 or 3 phases of signed commitments from different nodes to confidently finalize a transaction, it runs a single 3 phase BFT instance within each shard but braids these instances together with commitments provided by the leaders of the other related shards. 

Thirdly and most importantly, these sharding dynamic 3-braid consensus processes may run in parallel. This increases the network's throughput and enables local BFT instances to run completely independently and unrelatedly to any other at the time.

Instead of having each shard to conduct consensus independently, which makes transaction processing across multiple shards atomically difficult, the Radix network made a different approach to sharding in order to achieve composability. Cross-shard coordination has been made easier.

Application layer

Radix Engine is the application layer for Cerberus and the underlying ledger. Its bottom-most layer for scalability is the Radix Virtual Machine. It provides the partial ordering that Cerberus requires to braid consensus on a per-transaction basis – including transactions driven by Component Action logic. It does this by defining transactions as a related set of changes to state encoded across shards. 

Radix is a network for building Decentralized Financial applications. As such, its key components have been described in the technology section. However, as a platform focused on the ease of development, the main feature that stands out is its "Components Catalogue" and "Developer Royalties." 

This design of the incentive mechanism being embedded on the ledger is purposefully done to increase these decentralized financial applications' developments and help foster its developer community, rewarding it for its contribution. Like how mining is rewarded by the network's native token, those who write code are rewarded by its usage. 

When a Component's Scrypto code is pushed to the network, it is first added automatically to an on-ledger registry called the Component Catalog. This acts as a library that other developers can use to don't have to write the code from scratch and when they use an existing Component, it is called an Instantiated Component. It has its own unique identity on the Radix network, and its Actions become available for use by users.

When a developer wrote the code in Scrypto and deployed it to the Component Catalog, it has certain royalties for its use. Collection of royalties is then per-usage bases that increase developers' incentive to build tools and templates for the network's functions.

Product use cases

Radix network’s specified use case is for DeFi. It has been built from the ground up, having these applications in mind, which is why the network’s design is different in every way. Being built in this unique way, it took an approach of thinking about its use case beforehand. Considering the token’s behavior mimicking a physical asset and its limited actions, it is perfect for transferring value, stacking in pools due to its simplistic and straightforward nature, minting new tokens, and performing other operations are currently seen in decentralized finance space. 

However, while DeFi is it’s current focus, there is no reason Radix’s Cerberus consensus technology couldn’t be applied for other uses. 

Token use case 

The RADIX token (XRD) is a non-redeemable Utility Token. RADIX is intended to have two principal functions on the Radix Network. It may be used to pay for services on the network; second, it may secure the Network against attack through the proof-of-stake. As a utility token, it also serves to pay transaction fees for network usage and pay out those maintaining it both with computational power and functionality (developer royalties).