Radix is a fast and scalable platform for building decentralized applications, tokens and coins.
Radix offers a novel distributed ledger architecture for decentralized applications, that is sharded to scale in an efficient, unbounded linear fashion combined with a secure consensus algorithm called ‘Tempo’.
Radix scales linearly as new nodes join the network using the theory of sharding, but without compromising on decentralization or security. It enables resource-restricted devices to run a Radix node like on the Raspberry Pi. This enables inexpensive transactions at incredible speeds with near-instant finality. Read more here.
Tempo is a combined data architecture and secure consensus algorithm that is both, sharded to scale linearly and secured by a novel consensus algorithm based on Leslie Lamport's logical clock theory. Read more here.
Radix is fast, scalable, efficient, secure and highly decentralized. Read more about the Radix features.
Radix works on Leslie Lamport's logical clock theory. Read more here.
The atom model is an abstraction layer on top of the Tempo ledger designed to give the most power and ease of use to users of the system. More information will be published in the upcoming security white paper.
Radix makes it easy for developers to build most use-cases without smart-contracts and without worrying about blockchain scalability or expensive fees. It is fast, scalable, and simple to use. Start building with Radix.
Daniel Hughes, chief technical officer of Radix DLT invented the Radix platform and ‘Tempo’ - it’s underlying engine.
In 2011 Dan Hughes, the founder of Radix, discovered Bitcoin and was instantly hooked by the underlying elegance of its distributed protocol. Having tested the limits of distributed ledgers based on blockchains, block-trees, and directed acyclic graphs(DAG), he found they all had a fundamental inability to scale. He dedicated his time developing a highly scalable distributed ledger technology platform. Five years in R&D and after many iterations he eventually invented ‘Tempo’ - a novel distributed ledger architecture for trustless systems, that is sharded to scale in an efficient, unbounded linear fashion.
Radix enables merchants to accept cryptocurrencies without worrying about wild price swings. It helps developers to build applications that demand transaction rates beyond today’s blockchains. And last but not the least, it allows everyone to participate in ‘mining’ without special hardware and complex software setups.
Radix provides <5 seconds settlement times with fixed micro fee. It provides merchants the ability to accept payments globally without friction. The Radix token is a stable cryptocurrency specifically designed to help protect merchants from wild price swings and incentivize them to accept and use Radix in their everyday business.
The Radix platform will enable developers to create, distribute and manage highly scalable distributed applications for both public and private networks. Developers can easily build applications without worrying about expensive smart contracts. The Radix protocol scales linearly with all applications on the network run asynchronously without worrying about scaling limits of the underlying protocol.
Nodes get rewarded for maintaining the public network. As Radix does not use PoW/PoS to secure its decentralized ledger, the Radix node can run on devices like Raspberry Pi. Validators don't require special hardware, or access to capital to start. Radix reduces the barrier to entry by helping anyone with standard commercial hardware to run a node and makes it fair for everyone by eliminating mining cartels.
Radix is funded by our founder and CTO Daniel Hughes. He has also raised a round from a small community of early crypto enthusiasts back in 2013/2014. Funding details will be made available before going live.
No, Radix is not open-source yet. It will be open-sourced to support further development of the Radix Public Network in the future. Private deployments will be licensed. Additionally, we are actively working with individuals and institutions to audit and peer-review the code before we launch.
Radix will be open source after launch. Right now the team is focused on testing and optimizing the platform.
Our internal tests show that we scale beyond 25,000 tx/s, the average number of transactions processed by VISA. Combined with a fast transaction settlement time of less than 5 seconds, we already rival the current payment network rails and fiat transaction settlement times.
Radix is NOT doing an ICO. Radix is well funded to deliver the product. We strongly believe in delivering a stable product before we announce the token sale. The Radix MainNet will launch with an integrated decentralized exchange, which will allow and govern the creation of Radix tokens. You can buy the Radix tokens on launch.
To be decided ...
To be decided ...
The Radix stable coin is a low volatile token that is governed by a decentralized monetary supply policy. This policy mints or burns the tokens based on demand. Demand data is supplied by the decentralized exchange to this policy which creates an elastic supply, dampening the volatile spikes without affecting the long term price curve. This allows the creation of a true crypto stable coin, one which is not pegged to fiat currencies, assets or basket of goods. It also helps combat price manipulation.
The Radix Stable Token has an elastic supply. Instead of supply being fixed, the price is stabilized. This protects consumers from price manipulation and high volatility.
To be decided ...
You will be able to buy the Radix tokens from the decentralized exchange, which is integrated in the protocol, when we launch our mainnet.
You can earn Radix tokens by running a node or holding Radix tokens both. Read this incentive whitepaper for more details.
We have released both desktop and mobile wallets to store Radix tokens. Download and take them for a test ride here.
Within Tempo, all Nodes have a local logical clock; an ever-increasing integer value representing the number of events witnessed by that node. Nodes increment their local logical clock when witnessing an event which has not been seen previously. Upon storing an event the Node also stores its current logical clock value with it. This record can then be used to help validate the temporal order of past events if required.
Within Tempo, all nodes have a local logical clock (see Logical Clocks)
These Logical Clocks can then be made into Vector Clocks, where the Logical Clock of many Nodes are collected in relation to the same event, and then used to create a comparison of order between Nodes in order to determine which event proceeded which.
Note: on their own, Vector Clocks only create a partial ordering - Node Commitments are also necessary to complete the ordering of events.
See the Tempo White Paper for more details: https://papers.radixdlt.com/tempo/#commitments
Radix uses logical clocks to provide a simple and reliable method for nodes to record and recall events in the order they have witnessed them. While these logical clocks are simple and reliable, they do not provide any security against nodes tampering with the logical clock values that it has assigned to events.
To ensure the assigned logical clock values are tamper-proof, nodes produce “Commitments” which are an ordered, cryptographically secure, compact representations of the events witnessed by a node.
To assist with total order determination of events, nodes declare to the network a periodic commitment of all events they have seen. A commitment is a merkle hash.
A temporal proof is a cryptographically secure record of ordered events. Before an event can be presented to the entire network for global acceptance, an initial validation of the event is performed by a subset of nodes which, if successful, results in: A Temporal Proof being constructed and associated with the Atom, and a network-wide broadcast of the Atom and its Temporal Proof. For more information, see: https://papers.radixdlt.com/tempo/#radix-tempo
Byzantine fault tolerance (BFT) is the dependability of a fault-tolerant computer system, particularly distributed computing systems, where components may fail and there is imperfect information on whether a component has failed. In a "Byzantine failure", a component such as a server can inconsistently appear both failed and functioning to failure-detection systems, presenting different symptoms to different observers.
Distributed systems are subject to a variety of faults and attacks. A faulty/malicious node may exhibit arbitrary behavior. In particular, a faulty node may corrupt its local state and send arbitrary messages, including specific messages aimed at subverting the system. Many security attacks, such as censorship, freeloading, misrouting, and data corruption, can be modeled as Byzantine faults. Systems can be protected with Byzantine fault tolerance (BFT) techniques, which mask a bounded number of Byzantine faults, e.g. using state machine replication. BFT is a very powerful technique, but it has its costs. In a practical system that needs to tolerate up to f concurrent Byzantine faults, BFT cannot be implemented with less than 3f+1 replicas. Moreover, BFT scales poorly to large replica groups; as more servers are added, the throughput of the system may actually decrease. Byzantine Fault Detection is an alternative approach that aims at detecting rather than masking faulty behavior. With this approach, the system does not make any attempt to hide the symptoms of Byzantine faults. Rather, each node is equipped with a detector that monitors other nodes for signs of faulty behavior. If the detector determines that some node has become faulty, it notifies the application software, which can then take appropriate action. For example, nodes can cease to communicate with the faulty node; once all correct nodes have followed suit, the faulty node is isolated and the fault is contained. Lies (or faults) in Radix can be detected using merkle trees of commitments.
Radix uses both BFT to defend against network splits/attacks and BFD to defend against malicious behavior like double spends, transaction suppressing, etc.
We label events within the network (such as messages or transactions) as ‘atoms’. These atoms carry mass if they are transferring value, for example transactions or payloads with fees. This mass is calculated in a very simple manner, simply being the quantity (e.g. the amount of Radix being transferred) multiplied by the amount of time it has been static for. For example, if I transferred 10 Radix to Bob which I had held for 10 days then the mass of the atom being sent would be 100. If I had 5 Radix but had held for 20 days then the mass would similarly be 100.
The first node in the temporal proof for a valid transaction receives this mass. Nodes then build up mass across the multiple transactions they validate. The record of this mass is stored by nodes serving the same shards as said recipient node, as they store temporal proofs from completed transactions (known as finality). It is important to remember that transactions don’t just have a single gossip path through the network but rather have multiple routes due to the nature of our gossip protocol, which sees nodes ‘talk’ to all of their neighbouring nodes. This means that transactions are seen by a large majority of nodes.
This mass allows us to resolve conflicts which cannot be solved by simple resolution by letting us use mass as the determining factor. We add up the mass of all nodes involved in the temporal proof for the conflicting transactions and the atom with the most total mass associated with it is accepted. The losing transaction is meanwhile discarded.
Expanding upon this logically, in the event of a network split whichever network has the greatest mass is the mainnet. The mainnet then absorbs all non-conflicting transactions (i.e. anything that doesn’t constitute a double spend) into it. Conflicting transactions are, again, discarded. This works because although both transactions will have reached finality on their respective networks, the transaction on the mainnet will possess the mass of this large majority of nodes involved in validating it, meaning it will sum greater than the subnet.
Why do we need mass?
As discussed above, we use mass to defend against complex network attacks. You can read more about it in this blog post.
Probably yes. More details will follow in the upcoming security whitepaper
No. Not currently.
Yes, Radix is developing a unique smart contracting language that can be learnt by even beginners. More details will follow as we progress through out Roadmap milestones.
Our current alpha network has scaled up to 25,000 tx/s with only 16 to 20 nodes and without sharding. Our team recently tested speeds up to 80,000 tx/s on the same alpha network. We are focusing on optimizing the node first, before proving our theory of unbounded scalability with sharding. Keep an eye on our twitter and telegram for milestone announcements. Check our roadmap here.
When the network is not being stress tested, we do a sustained transaction throughout of about 2,500 tx/s. Check our explorer here.
Linearly scalability is the ability of Radix to process more transactions per second as more nodes join the network. This property helps the network scale in an unbounded, linear fashion, where every new node increases the overall throughput of the network. Increasing the amount of nodes have little to no detrimental effects on pre-existing Nodes and thus the scalability is deemed linear and unbounded.
Radix is massively sharded to scale linearly. Read more about our design philosophy here.
Sharding is way to distribute network load by cutting up the distributed database into multiple manageable parts. We wrote a ELI5 blog post on what is sharding and an introduction to sharding in Radix. Read about our protocol design philosophy and how sharding will help us scale to millions of devices.
Yes. The Radix ledger is divided into 18.4 quintillion shards. Depending on your node capacity (based on CPU and bandwidth), the node can scale down to serve only some shards/parts of the ledger. There is also a high degree of incentive for nodes to maintain under-served shards as the more shards low node count shards they maintain (serve) the higher the probability of getting fees.Thus every node maintains as many shards as it is able to; if a shard becomes too heavy for the node, it will automatically drop that shard. The more shards a node services, the more likely it is to get fees.This allows any device to be a useful participant of the network creating the trust layer for the internet of things.
Incentives in the Radix network are designed such that under served shards become an opportunity for node operators. Less nodes on a shard increases the possibility of earning more rewards for validating transactions. This allows the market to naturally gravitate towards supporting as many shards as possible, especially those which are under served. Radix is designed to provide a high degree of redundancy due to its massive shard space of 18.4 quintillion shards (2^64). At the start, all nodes will hold all shards, and pretty much every node will store all the transactions provided enough time has passed for gossip.The more nodes that have been in a shard, the more secure a shard history is due to the number of redundant copies of the shard information being maintained.
It is also possible for nodes to leave a shard, come back later and re-affirm history. This makes any attack vector, not just all the nodes in a shard now but all the nodes that have ever witnessed the event you are trying to change.
As discussed before there is also a high degree of incentive for nodes to maintain under-served shards as the more shards low node count shards they maintain (serve) the higher the probability of getting fees.
For shard selection incentives, see: https://papers.radixdlt.com/incentives/#shards
Yes. Radix will start with a shard space of 2^64 or 18.4 quintillion shards, which will be able to support every device in the world, and then some more.
Tempo relies heavily on eventual consistency to achieve a total ordering of events. Radix avoids the CAP Theorem limit that DAGs and Blockchains suffer from by allowing transactions to be both asynchronous and concurrent. This allows it to scale out limitlessly. The Radix shard space is key to this scalability - 18.4 quintillion shards that nodes can maintain concurrently, while the Tempo consensus makes sure double spends don’t occur across these shards without being detected and rejected.
We have yet to see how decentralized exchanges will behave with high traffic and whether they may be able to function as expected or even outperform centralized exchanges. A key part of product development is to ship the MVP, iterate and improve as we get live feedback from the users. So the DEX is projected to improve and scale as we understand how it behaves in a live environment.
Short answer - because if you store balances you cannot do state sharding without making the transactions non-atomic. A UTXO type system of consumables allow you to state shard with zero destination overhead, whereas a balance model ends up having a significant destination overhead, making sharding inefficient and only secure through a form of centralised orchestration.
Long answer - to answer this question we need to first establish that sharding is necessary - generally speaking there are two constraints with a DLT:
1. Transaction throughput
2. Storage throughput
With a DAG your transaction throughput is higher than on a blockchain as the transport can be optimized - you are dealing with transactions individually rather than as a block. However, those transactions still need to be validated, and at around 2,000 transactions per second on a single shard (assuming standard servers) you will see the performance of the full nodes on a network start to drop significantly. Pruning the ledger does nothing to reduce this load as this is a throughput constraint, not a storage constraint.
To scale beyond the 2,000 transactions per second mark you will therefore need to start splitting the throughput load; this requires sharding the network, splitting the work amongst the nodes, rather than requiring all the nodes to do all the same work.
Now that you are splitting up the ledger into parts, you need a method of dealing with transactions between shards.
Using balances, rather than UTXO can certainly reduce the storage requirements of the ledger on a given shard as you can prune the transaction history; however, one shards output is no longer another shards input without overhead. Since no TX history is being stored, just balances, the transactions between shards are not atomic, and this starts creating serious complexity. As a worked example:
There are four shards - A, B, C, D and I start with a balance of 50 on shard A and send 10 to wallet X on Shard B.
My balance is now recorded as 40, and at some unknown time in the future wallet X will have a balance of 10 (lets disregard the mechanics of how wallet X becomes aware of the spend in shard A).
However, I also send the same 10 to wallet Y on Shard C, and wallet Z on Shard D.
If I am only recording balances, and not UTXO; and only one of those transactions is valid, how do I void the updated balances of the wallet on the other two shards once the triple spend in Shard A is resolved?
The overhead I tried to avoid by making transactions non-atomic has simply moved to the double spend resolution process, as I now have substantial inter-shard communications to perform to correct the double spend as the output of one shard is not the input of another; we have no transaction history to construct a balance, just the balances themselves.
Now there is a co-ordinator requirement again - some sort of central authority with a guaranteed, up to date view of all shards, to make sure that any given spend only updates 1 of the balances on any shard.
Without that, without transaction history, and without atomicity, double spending between shards becomes trivial.
Transactions on the Radix Network confirm and finalize in 5 seconds or less. Current test networks may experience some delays, as we test and break things.
$0.01 to start with - this is set arbitrarily high to prevent spam attacks. Fees will gradually decrease as paid operations on the network increases.
Radix is as private as private as bitcoin. It does not support complete anonymous transactions, but will support pseudo-anonymous transactions in the medium term. The ledger is design as such that in the future it will be very easy to create an anonymity layer on top of it. The team will not focus on it until the basic features are stable.
Yes - essentially this means you can pay the transaction fee with the token you are sending, e.g. “Coffee Token” rather than Rads.
This is to make sure that anyone who creates tokens on our system is not forced to also make sure their customers and coin holders must also use Rads if they want to use the system. This was specifically designed into the Radix protocol to make sure all tokens are first class citizens.
This does, however, rely on:
1. The Radix DEX (decentralized exchange) being live (white paper pending) - part of the Radix protocol.
2. That the token you want to pay the fee with, and the Radix token, have liquidity as a traded pair on the DEX.
Once these two facts are live; it is then possible for anyone who pays the transaction fee with their own token as the tx fee will be converted to Radix tokens on the DEX; allowing the node to confirm any token transaction and receive XRD instead, without the sender requiring to hold XRD to send their tokens.
However, if your Coffee Token is not popular enough to have a trading pair on the DEX, then you will still need to pay the TX fee in Rads.
Download, install and take the alphanet wallets for a test drive on your desktop or android phone. Download here.
No, not quite. Radix has several token types that are possible to create on the Radix platform. One of these tokens is the Radix low volatility coin, which aims to create a token with a more predictable, less volatile value to make it more useful as a currency. This Radix token will have an elastic supply. It is not pegged to fiat currencies, assets or a basket of goods. It is a relatively stable coin which derives its value from the utility of the network. It is elastic in supply and price stabilized at the protocol level, governed by an economic monetary supply policy. More information will be shared in the upcoming economics white paper.
Economic incentive design of the Radix Public Network and the stable coin mechanism are highly critical to its success. We are simulating, iterating and experimenting with different economic theories before launching. The economics white paper will only be published after rigorous review and confidence in the theories we put forward.
The initial Radix token supply is going to be distributed to the early-backers of the Radix platform. Subsequently, new tokens are created by the decentralized exchange if and when the demand for the token increases. Part of the newly created tokens are then distributed to the existing token holders and node runner as a reward. % reward is not decided yet.
Using a decentralized exchange (DEX) people will be able to trade Radix tokens for their respective cryptocurrency and fiat pairs. If none of the Radix token holders are selling, to keep the price of the token relatively stable, the DEX will create new tokens that would partially fulfill the buy order.
The Radix monetary supply policy will dictate creation or destruction of the Radix native tokens. Full details of the Radix Low Volatility Token will be released in the upcoming Economics White Paper.
There are several different token types that can be issued on the Radix network.
One of the most hotly anticipated is the Radix low volatility coin, which, when launched will have a starting value which is to be decided. The coin value will be 'relatively' stable, not pegged (ie. it is NOT fixed at $x forever.
Over the longer term, the price will increase in a controlled manner if there is a sustained imbalance between the supply side and the demand side. The higher the sustained imbalance to the demand side, the higher the price and the more tokens will be in circulation. The price discovery process will allow it to float up/down, but the economics will attempt to smooth out the peaks and troughs to reduce volatility.
This is still an experimental coin type and the full details will be released in the upcoming Economics White Paper.
Simply, the more services - which includes number of shards - that a node provides for the Radix network, the larger the potential earning base. Each node earns fees from any Temporal Proof's they create. The distribution of which nodes provide the temporal proofs is probabilistic, not resource intensive. In other words, you don't have to ‘mine a block’ to get TX fees, just confirm a transaction!
A machine will automatically maintain as many shards as are possible, given its resources; very small machines will run only a few shards, large machines many more.
For more information, see: https://papers.radixdlt.com/incentives/
Yes. You may have multiple nodes behind a single IP address but it doesn't necessarily mean that you increase the chance of earning more rewards.
The current requirements are
2 CPU cores
8 GB memory
256 GB disk
The guide to help you get started with the node-client software is published. You can take a look here. We will notify you when the public node client is released if are signed-up to our mailing list. Nodes will be easy to setup.
No Radix does not requires any tokens to host a node.
There’s a private testnet on https://explorer.radixdlt.com/, but no public testnet yet, there will be open developer betas in the near future though, so we suggest signing up for the mailing list :)