The Token Striving To Capture The $400 TLN TradFi Market
A Comprehensive Analysis Of Radix's Native Token; $XRD
Introduction
Ethereum has played a crucial role in the DeFi revolution, being the birthplace of decentralized finance. Ethereum has given rise to several notable DeFi projects that have revolutionized the landscape. These projects include Aave, which has created a decentralized lending marketplace for borrowers and lenders, Uniswap, which has introduced automated market makers to the decentralized exchange market; and Yearn Finance, which has introduced yield aggregators to help users maximize their returns. However, EVM networks like Ethereum are vulnerable to hacks and exploits, producing a bottleneck for mainstream adoption.
A Layer-1 Built For DeFi
Radix is a monolithic delegated proof of stake Layer-1 that aims to revolutionize smart contract development and unleash the full potential of decentralized finance (DeFi). Unlike other competing Layer-1s, Radix is not a blockchain. The up-and-coming L1 addresses multiple challenges holding back the current DeFi landscape from mainstream adoption. For too long, developers have had to tackle issues such as the difficulty of developing production-quality dApps, lack of modularity and standardization, broken incentive models, and limited scalability. Radix attempts to solve these issues by introducing an asset-oriented smart contract paradigm, a modular on-network blueprint catalogue, a decentralized and self-incentivizing developer ecosystem, and unlimited dApp scalability through the Cerberus consensus protocol. The protocol aims to provide developers with the tools and environment necessary to build scale, secure, and efficient DeFi applications.
Similar Projects
Radix shares similarities with well-known existing DLT solutions such as Solana, Aptos, and Sui. These projects all share a form of proof of stake, a rust-based smart contract programming language, and low transaction fees. In addition, projects such as Aptos and Sui utilize the Move programming language. This object-oriented language shares a few similarities with Radix's asset-oriented smart contract programming language, Scrypto. Readers can go here for a deep dive into comparisons between Radix and Sui.
This article will dive into the network's native token, $XRD, and analyze its various functions, value capture, and how it facilitates the flow of value throughout the ecosystem and its participants. Readers can go here for more detailed information concerning other protocol aspects.
$XRD Tokenomics
Below we can see the token flow diagram for Radix. This showcases how the system works, where the relevant sinks and faucets are and how value flows through/around the protocol.
Ecosystem Participants
Delegator
Users who stake their tokens with a Validator Node contribute to the consensus process and earn staking yield denominated in $XRD. Emissions from staking are derived from minting new $XRD tokens, representing 50% of the token allocation in aggregate. Delegators are typically long-term holders of tokens due to the opportunity cost of staking.
Developer
Developers are technical users who play a crucial role in creating dApps and fungible and non-fungible tokens. They can set royalties on their code, allowing them to receive payments denominated in $XRD directly to their wallet whenever another user instantiates a copy of their contract or performs method calls. The royalty system incentivizes developers to contribute valuable code to the ecosystem and furthers the viability of working on open-source code.
Full Node
A computer that runs Radix ledger client software stores a record of transactions and performs various network functions.
General User
A non-specialized user interacting with dApps, fungible and non-fungible tokens within the Radix ecosystem. They engage with the applications and assets built by developers, leveraging the functionalities provided and paying transaction fees in $XRD.
Validator Node
A full node that participates in consensus by verifying, voting on, and maintaining a record of transactions. Validator nodes stake $XRD tokens and earn a share of $XRD emissions based on ranking within the top 100 validator nodes. They must also maintain a minimum uptime of 98%.
Since the release of Babylon, validators will now be allocated 50% of the transaction fees in $XRD.
Validator Set
A validator set consists of nodes that validate transactions on the same shard. It is important to note that until the Xi'an update in 2024, Radix remains an un-sharded network, only requiring one validator set currently, and the one validator set consists solely of the top 100 validator nodes.
Protocol Components
Figure 1
Radix Dual Layer Protocol
Note. From Far, B. (2021, June 11). Radix DLT. Cerberus Infographic Series - Chapter I: The Radix Blog: Radix DLT. https://www.radixdlt.com/blog/cerberus-infographic-series-chapter-i
Cerberus
Conceived and built by Bitcoin OG Dan Hughes, Cerberus is a consensus protocol offering linear scalability and cross-shard atomic composability. Linear scalability refers to the ability to scale linearly as more nodes are added to the network. As a result, the network can handle increasing transactions without slowing down or compromising its performance. Cerberus achieves this by pre-sharding the ledger into 2^256 shards, collectively known as the shard space (See Figure 3.). On the other hand, atomic composability means that transactions from various dApps can be combined to create more complex offerings. If one of these transactions fails, the entire "manifest" of transactions will fail. In addition, the protocol prevents Sybil attacks through a delegated proof of stake model that weights votes according to their native token $XRD. See Figure 2. for more detail on the consensus and transaction process.
Figure 2
Cerberus Consensus Process
Note. From Far, B. (2021, June 11). Radix DLT. Cerberus Infographic Series - Chapter I: The Radix Blog: Radix DLT. https://www.radixdlt.com/blog/cerberus-infographic-series-chapter-i
Figure 3
Cerberus Shardspace
Note. From Far, B. (2021, June 11). Radix DLT. Cerberus Infographic Series - Chapter I: The Radix Blog: Radix DLT. https://www.radixdlt.com/blog/cerberus-infographic-series-chapter-i
Radix Engine
The Radix engine (See Figure 4.), which is the application layer of Radix, can be compared to the Ethereum Virtual Machine (EVM). Unlike other smart contract platforms, the Radix engine considers assets as a global feature of the platform itself, making token creation much simpler by enabling direct requests from the platform with desired parameters. Furthermore, the environment treats tokens as physical objects stored in user-controlled accounts. In other virtual machines, assets such as tokens refer to balances within a smart contract. Mimicking physical asset behaviour makes it more intuitive and user-friendly for developers. Furthermore, the asset-oriented paradigm eliminates risks such as reentrancy attacks. In order to maintain security, the Radix engine uses a Finite State Machine (FSM) that ensures the behaviour and integrity of assets on the platform.
Figure 4
Radix Engine V2
Note. From Radix DeFi White Paper (p. 12). (2022). [White Paper]. Radix Foundation Limited. https://radixdlt.com/whitepapers/defi
Scrypto
The smart contract programming language for Radix is called Scrypto, designed to simplify writing smart contracts. The language is built off of the low-level programming language known as Rust. Scrypto allows developers to create smart contracts known as components, which are instantiated from objects known as blueprints.
Figure 5
Packages, Blueprints & Components
Note. From Radix DeFi White Paper (p. 14). (2022). [White Paper]. Radix Foundation Limited. https://radixdlt.com/whitepapers/defi
As shown in Figure 5, the blueprints act as a skeletal structure of the component. A collection of blueprints forms what is known as a package. The Scrypto language has three main concepts; resources, buckets, and vaults (See Figure 6.). Resources can be fungible or non-fungible tokens, while buckets are transient containers that transport resources. Finally, vaults are permanent containers for resources.
Figure 6
Resources, Buckets & Vaults
Note. From Radix DeFi White Paper (p. 13). (2022). [White Paper]. Radix Foundation Limited. https://radixdlt.com/whitepapers/defi
Value Creation
Value creation refers to how the protocol is creating value and for whom. Value is created when a problem gets solved. Read here to understand more about value creation.
Scaling dApps For Real-World Demand
DeFi's scalability potential is limited by current DLT solutions through slow network throughput and high fees. Layer-2s have tried to solve the scalability issues of networks such as Ethereum's mainnet but have done so by compromising atomic composability between themselves and their dApps.
The Cerberus consensus protocol has been designed for unlimited dApp scalability. The protocol utilizes specialized sharding and a "braided" multi-shard consensus mechanism for the parallelization and atomic composition of assets and smart contracts.
Asset-Oriented Smart Contracts
Currently, there is difficulty in developing production-quality dApps on platforms that use the EVM and its variations. Developing even simple functionality into your dApp requires complex code. The added code complexity leads to hacks and potential exploits.
Radix aims to solve this issue by introducing a new paradigm of asset-oriented smart contracts with the Radix Engine and Scrypto programming language. The asset-oriented architecture enables easy and safe DeFi dApp development, expanding the pool of developers and reducing hacks.
Building With Legos
Building new products composed across numerous dApps proves to be a challenge. EVM-based smart contracts are known to developers for their lack of modularity, reusability, and standardization. The result is repetitive reimplementations of simple functionality, such as tokens and NFTs.
The solution to this issue is to make code modularity a network feature with an on-network blueprint catalogue. As a result, developers can contribute and access reusable and proven functionality, promoting shared computing and decentralized development.
Incentivizing Open-Source Development
The current funding options for Web3 developers do not align with the ecosystem's ethos. For the most part, developer incentives currently rely on centralized funding sources. The unintended consequences of this funding route are wasted resources and difficulty in rewarding valuable contributions.
Scrypto developers will rejoice that a new funding route is possible—a decentralized, self-incentivizing developer ecosystem with programmable developer royalties. As a result, developers are rewarded for valuable code in every transaction, fostering sustainable growth and community building.
Note. Radix will introduce additional subsidies for the royalties at the onset of the feature’s release but will taper off over time. Generally speaking, the developer royalties are paid by the users instantiating the blueprints or performing method calls.
Overall Goal
Radix is looking to bring the world of DeFi to the masses by building a ledger that can meet the needs of the global financial system, streamlining the developer experience, and cutting overall complexity for a UX that is appealing to the average person.
Value Capture
This refers to how the protocol is capturing the value it creates. Essentially, if value is being created then it has to flow somewhere (ideally to wherever the protocol deems most viable). Value capture can be broken down into (1) value accrual to the protocol and (2) value accrual to the token. Read here to understand more about value capture.
Value Accrual to Protocol
Besides developer royalty fees on Radix, 50% of the transaction fees on the network are burnt. The remaining 50% are allocated to validators. No share of these fees flows to any particular protocol treasury or a treasury of entities such as Radix DLT Ltd. or Radix Tokens (Jersey). However, entities such as Radix Tokens (Jersey) are incentivized through their initial token allocation in their treasury. The burning mechanism balances the inflationary nature of network staking emissions.
Value Accrual to Token
Keeping with the value of decentralization, value capture solely occurs through value accrual to the token. The accrual occurs through three avenues: staking, burning, and yield. Staking is a direct form of value accrual, where tokens are "locked" to help perform consensus, constraining the supply and putting upward pressure on price. Delegators or Validators that wish to unstake their tokens are subject to a 1-3 week unstaking period. The burning mechanism is an indirect form of value accrual. As more transactions occur on the network, token burn reduces the supply and "indirectly" causes upwards price pressure. Lastly, a yield on the token entices potential holders to purchase $XRD.
Business Model
It’s important to understand the business model of the protocol since it ties into how value is flowing in the system and is relevant for the sustainability of the protocol.
Currently, the Radix protocol's business model needs proper revenue sources. At this point, the protocol relies on $XRD emissions to incentivize various types of users within the ecosystem.
Emissions come from:
Protocol emissions are solely sourced through staking.
Amount to an estimated 300M units per year
Due to be released every year for the next 40 years
Since the Babylon release, 50% of transaction fees are burnt, while 50% are allocated to validators.
Note. Until the Babylon update is launched, validators will receive rewards solely from staking emissions. At Babylon, the tokenomics of $XRD changes, whereby 50% of the fees on the network get burnt, and the remaining 50% are allocated to validators.
Emissions are denominated in:
$XRD
Emissions go to:
Ecosystem participants help perform consensus and ensure network security
The two main participants that perform these functions are Validator Nodes and Delegators.
Radix Foundation and its subsidiaries that operate 4 out of the 100 active validator nodes
Token Utility
This refers to how the token is being used within the project and by whom. Essentially the token’s use case. Read here to understand more about Token Utility.
Radix's native token, $XRD, shares a similar token utility to other competing proof of stake networks.
Gas Token
Transaction fees must be paid for any user to participate in the network. These fees, or gas, must be paid in $XRD.
Network Securing
As with other proof of stake networks, user types such as Validator Nodes or Delegators must attain $XRD to facilitate consensus and network security by staking tokens.
Medium of Exchange
Due to it being the network's native token and, therefore, the most liquid, $XRD is the preferred means of payment for the network's dApps. Payment extends to goods and services these dApps provide and is the most prominent form of payment for dApp development.
$XRD Demand Drivers
Demand for a token can from three sources, those being demand for the token due to its utility, demand due to a mechanism (i.e staking) and demand due to speculation. Essentially, demand drivers refer to who is buying/holding the token and why. Read here to understand more about Token Demand Drivers.
The $XRD token has four main demand drivers: Gas Fees, Node Requirement, Staking Rewards, and Protocol Success. These demand drivers come from Utility, Mechanism, and Speculation.
Gas Fees - (Utility)
Individuals utilizing the ecosystem's dApps must pay gas for transactions. Gas fees are denominated in $XRD. As a result, users will need to purchase $XRD for paying gas fees and burning them in the process. The source of the demand driver is one of utility.
Node Requirement - (Utility)
Validator Nodes require a certain amount of $XRD as collateral to participate in consensus and network security. Therefore, Nodes must acquire $XRD through direct ownership or Delegators in return for a staking yield. Just like Gas Fees, the source of this demand driver is utility.
Staking Rewards - (Mechanism)
Investors seeking yield from proof of stake tokens, such as $XRD, will purchase to stake the token. The source of the demand driver is a mechanism of its proof of stake consensus model.
Protocol Success - (Speculation)
Investors and traders are confident in the team's abilities at RDX Works, and Radix's DeFi dApp ecosystem will purchase and hold $XRD. The source of the demand driver is speculative.
$XRD Distribution & Unlocks
It’s important to understand how the supply is being split up into different allocations and how these allocations will be distributed (vested or emitted).
A Tale of Two Tokens -
Before the launch of the Radix Ledger, eXRD, an ERC-20 version of the token, was made available. The purpose of this move was "intended to promote the distribution of Stake and achieve a high degree of decentralization before the release of the Radix Ledger (mainnet)" (Castellana et al., 2020). Once the Radix Ledger was released during the Olympia update, eXRD token holders could (and still can) participate in a one-way bridge process to exchange their ERC-20 version to the native $XRD on a 1:1 basis.
Table 1
Token Profiles
Note. Adapted from e-Radix. (n.d.). CoinGecko. https://www.coingecko.com/en/coins/e-radix, Radix. (n.d.). CoinGecko. https://www.coingecko.com/en/coins/radix & *Castellana, A., Hughes, D., & Ridyard, P. (2020). Economic Model (p. 7) [White Paper]. Radix Tokens (Jersey) Limited. https://www.radixdlt.com/whitepapers/economics
Token Allocations -
Figure 7
Token Allocation: eXRD
Note. From Castellana, A., Hughes, D., & Ridyard, P. (2020). Economic Model (p. 7) [White Paper]. Radix Tokens (Jersey) Limited. https://www.radixdlt.com/whitepapers/economics
Figure 8
Token Allocation: eXRD & XRD
Note. From Castellana, A., Hughes, D., & Ridyard, P. (2020). Economic Model (p. 10) [White Paper]. Radix Tokens (Jersey) Limited. https://www.radixdlt.com/whitepapers/economics
Network Emission: Token allocation for rewarding Staking Nodes and Delegators for securing the network.
Stable Coin Reserve: A reserve of $XRD that is indefinitely locked and removed from the circulating supply. The stablecoin reserve is meant to help bootstrap projects that intend to develop stablecoins for the network. If the reserve is unnecessary, it will remain locked and burned after the lockup period.
Founder Retention: Tokens are reserved for team allocation.
Radix Community: Allocation for early supporters of Radix when it was in its theoretical development phase (2013-2017).
Liquidity Incentives: Tokens are reserved for liquidity mining programs.
Radix Tokens (Jersey): Allocation to Radix Tokens (Jersey) Ltd. for funding awareness programs and operating expenditures.
Developer Incentives: Tokens to bootstrap the developer royalty system and other related incentives.
Network Subsidy: Allocation dedicated to funding grants.
Token Sale: The initial token sale of eXRD opened on October 8th, 2020, and was completed on October 22nd, 2020.
Token Unlock Pivot -
Initially, token unlocks for eXRD and $XRD was to be carried out according to price target milestones (See Table 2.). However, in Q3 of 2021, Radix surveyed to gauge if the community wanted to stick with price-based unlocks or a full token unlock. The community answered, and on September 15th, 2021, all Radix tokens (eXRD & $XRD) were unlocked (excl., staking emissions & stable coin reserve).
Table 2
Initial Priced-Based Unlocking
Note. From Castellana, A., Hughes, D., & Ridyard, P. (2020). Economic Model (p. 8) [White Paper]. Radix Tokens (Jersey) Limited. https://www.radixdlt.com/whitepapers/economics
Figure 9
Token Distribution Schedule: Final Unlock
Note. Distribution Schedule as of complete unlock, September 15th, 2021. Includes $eXRD & $XRD. To keep matters simple, network emissions of $XRD will begin during the final unlock on September 15th, 2021 (as opposed to August 11th, 2021). Liquidity and Developer Incentives were combined, and locked Stable Coin Reserve resulted in a 2.4B discrepancy in the chart. Adapted from Castellana, A., Hughes, D., & Ridyard, P. (2020). Economic Model (p. 13-15) [White Paper]. Radix Tokens (Jersey) Limited. https://www.radixdlt.com/whitepapers/economics
Feedback Loops
A tokenomics analysis is focused on how value flows through the system and how it interacts with different users/components of the protocol. Feedback loops are relevant since they may be positive or negative and thus have an outcome on the underlying value capture (be it on the protocol or token level).
Short On Supply
As seen in Figure 10, two feedback loops reduce the circulating supply of $XRD, which inevitably causes upward pressure on the price. It's important to note that these downward pressures of circulating supply are less with inflationary staking emissions. Furthermore, the upwards pressure on price due to lowering circulating supply will also be dampened by some users selling their staking emissions.
Figure 10
Circulating Supply Feedback Loops
Note. Illustration depicting fundamental metrics of network adoption and transaction volumes' relationship with token mechanisms of burning and staking. Own work.
Network Adoption
The first feedback loop begins on the left of Figure 10 with increasing network adoption.
The increase in network adoption will lead to more users coming into Radix and staking their tokens.
The result is that more tokens are locked up, and the circulating supply reduces.
A lower circulating supply results in higher potential prices, all else equal.
The increase in prices would increase general awareness of Radix and lead to higher network adoption, closing the loop.
Transaction Volumes
The second feedback loop on the right begins with increasing transaction volumes on the Radix Ledger.
The ever-increasing transaction volumes result in a higher burn rate of $XRD.
Burning $XRD reduces the circulating supply.
A declining circulating supply will cause upwards price pressure.
As mentioned earlier, the upwards pressure in prices would increase the awareness of Radix and lead to increasing transaction volumes, closing the loop yet again.
Since the release of Babylon, the magnitude of the fee burn has been reduced by 50% while allocating more $XRD rewards to validators based on transaction volumes. Due to this change, it becomes more enticing for new validators to compete for one of the top 100 validator slots as transaction volumes increase. The fee change will be a boon for scalability in the long run, with the introduction of sharding during the Xi'an upgrade. On the flip side, declining transaction volumes and lower $XRD rewards for validators may risk the network's security by making the activity less appealing.
Connecting The Loops
Some may have noticed that there is a double-edged arrow line that insinuates there is a connection between the above-described feedback loops. The arrow was added because, arguably, there is a direct feedback loop between network adoption and transaction volumes. As either increase, such will lead to a rise in the other.
A Key Point to Consider
The prior feedback loop causes an upwards price pressure, as mentioned earlier. However, this could prove problematic in cases where the transaction fees are not adjusted to compensate for the rise in the price for $XRD. This situation would slow down the network since transacting becomes more costly.
Code, Deploy, Get Paid
Figure 11
Developer Experience Feedback Loop
Note. Illustration depicting the relationship between developer adoption, activity, and royalty payments. Own work.
Figure 11 describes a feedback loop related to the developer experience. As developer adoption and activity rises, so do blueprint instantiations and component method calls. As overall dApp activity increases, the amounts of royalties that get paid to developers increase. As it becomes more profitable to make an income off developer royalties, awareness of Radix will increase in the developer community, increasing activity and adoption and closing the loop.
Alternatively, the feedback loop works in the opposite direction as well. Assuming developer activity remains stagnant or declines over time, dApp activity suffers, and it becomes less economically viable to depend on the developer royalty system as a form of income.
Observations/Thoughts
Emissions Schedule
Staking emissions are distributed over an approximately 40-year period. When emissions run dry, validators will need more incentives to facilitate consensus. By extension, stakers will have no use for pledging their tokens, and this could be seen as a direct threat to the network, which relies on stake to secure itself from attackers.
Solution: Capitalizing on Real-World Adoption
Keeping a similar intuition for developer royalty fees, either create a new fee on top of the existing developer royalties or tax a certain amount from developers to pay for staking emissions.
Fee Burn
Although burning all transaction fees, with the sole exception of developer royalties, might sound enticing initially, there could be long-term consequences. A constant burning of all transaction fees places deflationary pressures on the $XRD token, causing an upwards movement in price. This might sound great to investors. However, users looking to participate in network activity will find it increasingly expensive. In addition, new entrants to the ecosystem that would like to stake or become a validator will find it inaccessible due to the costs. There is also an opportunity cost of burning all fees, whereby these tokens might be better suited to be allocated elsewhere to incentivize behaviours across various user types. The issue is further compounded when the $XRD emissions run out after a few decades.
Solution: Babylon
Fortunately, the tokenomics of $XRD will change slightly with the upcoming Babylon update. Instead of 100% of transaction fees being burnt, 50% will be allocated to validators. For more information on this change, readers can go here.
Since the Babylon release, the described fee burn as noted above has been changed to partly allocate to validators.
Protocol Revenue
A downside to most proof of stake networks is the lack of protocol revenue sources. Due to the nature of this type of consensus, emissions are required to incentivize users to participate in securing the network. However, emissions should not be considered as revenues.
Solution: Expand Developer Royalties
Add the capability for developers to accept non-native tokens, such as stablecoins, for their royalty fees in exchange for a small share. The non-native tokens could then be sent to an entity such as the Radix Foundation, or a protocol DAO could be established to collect these revenues.
Staking: Yield
As seen in other proof of stake networks, the staking yield on Radix is denominated in its native token, $XRD. This design has obvious implications, as it is inflationary and puts downward pressure on the token's price. Furthermore, users, depending on their strategy or situation, may opt to sell a large portion of their staking yield at fixed intervals, exacerbating the problem.
Solution: Real Yield
Allocate a share of protocol revenues, outlined in the previous section, in the form of non-native tokens. Therefore, users looking to “cash in” on their yield could do so with non-native tokens, decreasing the selling pressure of native token emissions.
Staking: Time to Unstake
The current staking mechanism requires a 1-3 week unstaking period. Apart from the cooldown period, there are no other mechanisms to keep users staking and “locking” their tokens for extended periods. An issue arises where due to low switching costs, users can easily unstake to chase other staking yields of various proof of stake networks or even within these networks regarding DeFi dApps.
Solution: Lock for Fixed Terms
Create fixed terms for stakers to lock their $XRD tokens in return for a higher yield. The yield could come from a new fee that could be introduced. Taking it a step further, a vote-escrow model, whereby stakers who lock their tokens for a fixed term receive a soulbound NFT representing their governance power over a protocol DAO. In addition, the soulbound token could outline additional NFT data such as the specific time lock, higher yield rates, etc.
Validators
Until the Xi'an update, validators must compete based on the amount of delegated staked to be in the top 100 validators to receive network emissions. Although the top 100 list allows many validators to participate in consensus and earn rewards, it does not prevent a minority from taking the majority of staking or "vote" power. An example is the Radix Foundation’s 4 active validators, which may stake 25% of the total staked supply.
Solution: A Level Playing Field
As seen in other networks such as Flare, add an effect of diminishing returns for earning emissions past a certain threshold of stake or "vote" power. As a result, users would then be dissuaded from delegating stake to large validators and give opportunities to smaller players.
Stablecoin Reserve
As mentioned earlier, the stablecoin reserve is a 2.4B allocation of $XRD to the Radix Foundation to help bootstrap essential network infrastructure such as a decentralized stablecoin. Since the Foundation holds and manages the reserve, there is a centralization risk. Issues may arise in the future where decision-making is done in a way that needs to consider the needs and concerns of all Radix stakeholders.
Solution: Democratization
Form a governance structure such as a DAO that is decentralized, on-chain, and democratizes at least some of the decision-making about the Stablecoin Reserve review process, use of the reserve through an on-chain treasury, and its allocation.
Blueprint Catalogue and Developer Royalties
The blueprint catalogue is a novel way to encourage modular dApp development. Coupled with developer royalties, the open-source model becomes more sustainable and financially feasible. However, this will not prevent some users from copying and pasting code inside the blueprint catalogue, bypassing the royalty system.
Solution: Recognize Just Actors
Create a decentralized reputation system that appropriately rewards those using the catalogue. A special badge can be given out declaring that a user has properly instantiated the given blueprint and paid the royalty. Badge holders could be entitled to future financial and non-financial rewards.
Summary
Radix is taking a different approach to solving the most pertinent issues in DeFi. Its novel consensus protocol, Cerberus, brings the crucial features of linear scalability and atomic composability to allow developers to build safer and more modular dApps at scale. Security is vital to bring DeFi to the masses, and the Radix Engine and the Scrypto programming language further bolster this by treating assets as first-class citizens on the platform.
Linear Scalability
Achieving linear scalability for any blockchain is no small feat, even more so when done on the main chain. Although there have been great strides to scale proof of stake networks such as Ethereum with sidechains, L2s, and other techniques, it remains a patchwork solution.
At the launch of the Xi’an update sometime in 2024, Radix’s consensus protocol, Cerberus, will allow for linear scalability by introducing sharding. In other words, as more nodes are added to the network, the throughput will increase accordingly. The performance testing of Cerberus in its various iterations has achieved more than 1 million transactions per second (TPS).
Atomic Composability
In most cases, other networks that solve the first issue of linear scalability will ultimately break the atomic composability of transactions.
Radix has achieved not only the feat of linear scalability but has done so in a manner that retains the atomic composability of transactions. Simply put, atomic composability allows for bundling transactions across dApps into a single manifest for execution. Upon execution, if one transaction fails in the sequence, the whole manifest of transactions fails and reverts to its original state.
Asset-Oriented Smart Contract Language
Today, most networks that use some version of the EVM, and its programming language, Solidity, are susceptible to more vulnerabilities, such as re-entrancy attacks, due to the message-based architecture and language. Tokens are not physically present in a user’s wallet but reference a balance in the token’s smart contract.
Scrypto, a rust-based smart contract language, aims to solve the issue of message-based EVM networks with its asset-oriented design. Coupled with the Radix Engine, the equivalent of the EVM, developers using Scrypto can mimic physical asset behaviour across smart contracts, ensuring higher security.
Given a secure platform, developers can further the open-source movement with features like the blueprint catalogue in return for financial incentives such as the built-in developer royalties system. Its native token, $XRD, will be the medium by which all this value is captured and flows throughout the network and its participants. Radix aims to raise the DeFi revolution to the next level by making it feasible for mainstream adoption. With the Babylon update around the corner, bringing smart contracts to the mainnet, the protocol is positioned to be the next disruptive Layer-1.
If you’re interested in the condensed, need-to-know tokenomics information for Radix including all the resources used for this article, check out the report on Tokenomics Hub: https://tokenomicshub.xyz/radix
This post does not contain financial advice, only educational information. By reading this article, you agree and affirm the above, as well as that you are not being solicited to make a financial decision, and that you in no way are receiving any fiduciary projection, promise, or tacit inference of your ability to achieve financial gains. The author of this article has a financial interest in the investment(s) discussed.
Feedback and Collaboration
Interested in having your protocol reviewed by Tokenomics DAO or want to collaborate on an article? Feel free to reach out via email here.
 | A guest post by
|