TM Rating: 74.5%
Review Date: 13/12/2022
Radix is an L1 blockchain platform where the full range of powerful DeFi applications can be built safely and soundly. It follows the Asset-Oriented Smart Contract Paradigm, where assets are a global feature of the platform.
The Radix Network follows three key technological features, particularly:
- The Scrypto programming language
- The Cerberus consensus algorithm, and
- The Radix Engine.
Scrypto is Radix’s custom-built asset-oriented smart contract language to help build complex, powerful dApps. The core piece of the Radix solution is their unique Consensus algorithm, Cerberus, ensuring atomic composability and unlimited scalability for their platform. They have introduced a Developer Royalty system, like how nodes are rewarded for running the platform. Radix has launched their ‘Alexandria’ environment with the Scrypto language and Radix Engine v2, with “component” smart contracts running in a private environment for early builds and testing. And are expected to launch ‘Babylon’ the public mainnet version of Alexandria, by Q2 2023.
The project looks quite promising with the constant building by their developers. They have a strong team with a good DeFi ecosystem. In the recent RADFI 2022 event, they showcased their products and their wallet interface, which was very user-friendly.
Notes To Take:
- Radix uses a rust-based ‘Scrypto’ as an on-ledger smart contract language.
- ‘Cerberus’ is our unique consensus algorithm that will power the only public decentralized network.
- Cerberus takes this concept even further, presuming that each transaction can specify precisely which shards are relevant (and thus must be ordered) for a specific transaction.
- BFT style consensus called “braiding.”
- ‘Cerberus’ braided consensus runs a single 3-phase BFT instance (called a “3-chain”) within each shard, but braids any number of these instances (shards) together in a transaction using commitments created and shared by the leaders of all related shards. The result is an “emergent” 3-braid consensus that ensures all relevant shards can atomic
- Each shard, with its local BFT instance, can run completely independently, as can any emergent multi-shard instance (as needed for a given transaction) that isn’t related to any other at the time.
- Cerberus provides linear scalability through unlimited parallelism.
- Asset-Oriented Smart Contract Paradigm
- Radix engine uses a finite state machine (FSM) model.
- Assets are a global feature of the platform that removes double spending completely
- Radix engine V2 will add computation of powerful smart contract
- Smart contracts, called components, to be more modular and composable
- Encourage modularity and reusability by introducing blueprints that are on-network templates of useful functionality that can be instantiated over and over into components (like libraries)
- On-Network DeFi “Lego Bricks”
- Introduces blueprint catalog
- Developer Royalties
- Decentralized developer self-incentivization using blueprint and components usage
Radix engine design
- Radix Engine treats tokens as global objects at the platform level. This is important to let us parallelize the movement of assets as much as possible.
- Radix transactions are unique and based on “intent.” This is important to enable high throughput through dApps without conflicts.
- Each smart contract (or “component” in Radix terms) – including all of its data and the resources it owns – is assigned to a single shard at any point in time.
– Instapass is a single sign-on compliance service that will be used initially by Instabridge. It is a streamlined way for users to connect to regulatory-compliant DeFi applications.- Instabridge is an optional service allowing anyone to quickly convert between eXRD and XRD – moving value freely between Radix and Ethereum networks.
Initial Screening | |||
Keep researching | |||
Does this project need to use blockchain technology? | Yes | ||
Can this project be realized? | Yes | ||
Is there a viable use case for this project? | Yes | ||
Is the project protected from commonly known attacks? | Yes | ||
Are there no careless errors in the whitepaper? | Yes | ||
Project Technology Score | |||
Description | Scorecard | ||
Innovation (Out Of 11) | 5 | ||
How have similar projects performed? | Good | 2 | |
Are there too many innovations? | Too innovative | 0 | |
Percentage of crypto users that will use the project? | 1%-5% | 1 | |
Is the project unique? | Yes | 2 | |
Architecture (Out of 12) | 10 | ||
Overall feeling after reading whitepaper? | Good | 2 | |
Resistance to possible attacks? | Good | 2 | |
Complexity of the architecture? | Not too complex | 2 | |
Time taken to understand the architecture? | More than 1 hour | 0 | |
Overall feeling about the architecture after deeper research? | Good | 4 | |
Code Quality (out of 15) | 15 | ||
Is the project open source? | Yes | 2 | |
Does the project use good code like C,C++, Rust, Erlang, Ruby, etc? | Yes | 2 | |
Could the project use better programming languages? | No | 0 | |
Github number of lines? | More than 10K | 1 | |
Github commits per month? | More than 10 | 2 | |
What is the quality of the code? | Good quality | 2 | |
How well is the code commented? | Good | 2 | |
Overall quality of the test coverage? | Outstanding | 2 | |
Overall quality of the maintainability index? | Outstanding | 2 | |
When Mainnet (out of 5) | 5 | ||
When does the mainnet come out? | 6 months after TGE | 5 | |
Usability for Infrastructure Projects (out of 5) | 5 | ||
Is it easy to use for the end customer? | Yes | 5 | |
Team (out of 7) | 6 | ||
Number of active developers? | 5+ – 2 | 2 | |
Developers average Git Background? | Senior- 2 | 2 | |
Developers coding style? | Solid – 2 | 2 | |
Total Score (out of 55) | 46 | ||
Percentage Score | |||
Innovation | 9.09% | ||
Architecture | 18.18% | ||
Code Quality | 27.27% | ||
Mainnet | 9.09% | ||
Usability | 9.09% | ||
Team | 10.91% | ||
Total | 83.63% |