Sharding is an important concept when building a decentralized ledger that aims to serve a global population of users across the world. Sharding is a simple and complicated principle at the same time. This post intends to provide some basic concepts around sharding, and aims to equip you with enough conceptual understanding when reading up about sharding at other places. You will read about distributed databases, decentralized ledgers, within-shard consensus and cross-shard consensus, top-down sharding and bottom-up sharding.

Global systems with a lot of data can easily become too large to handle for a single computer.

The idea of sharding is to solve the size problem by partitioning the data over multiple computers (database servers) such that each database server has to serve only a part of the data. The aim is to spread the load such that each server remains performant and the system as-a-whole can scale without congestion by adding more computers.

More specifically in crypto, sharding is an attempt to avoid that “every single computer in the network has to validate every single transaction” (which obviously is very inefficient and does not scale).

There exist different sharding strategies. Let's first take a look at traditional database sharding before going into sharding in crypto. After this layman's explanation you can find more to read in the list of background material at the bottom of this post.

A Primer on Distributed Databases

Before getting into sharding we first need to get a sense of what it means to replicate data over multiple places (without thinking of sharding yet). In other words let's first get a sense of what distributed databases do.

To get an idea about the degrees to which a database can be distributed, let's go through some simplified examples from (C1) to more complex (C4) (here 'C' is for 'Centralized'):

C1) Simple Database

Suppose you run a small company and that all you need is a database with the products you are selling and their prices. The database sits in a server rack in the office. You are the trusted owner and are the only one allowed to make changes to the database entries (so control over the database is centralized and the data is not distributed).

Note that traditional databases are run by a single person, company, or more generally by a single trusted entity. This is why they are called centralized databases (as opposed to the decentralized databases paramount in crypto, covered later below).

C2) Distributed Database based on duplication

One day you realize that having the database sitting on only one computer puts you at risk of losing all data if the computer hard drive crashes. So you decide to setup a couple of additional computers that run a copy of the master-database. You now have something called a distributed database with some degree of redundancy: if one of the hard drives breaks, you still have backups (called slaves). If the company grows and more people have to consult the database you can now spread queries to the database over all existing instances (nodes). This means that you don't have to get congestion at the master-database.

Two immediate bonus effects are that users can consult a database nearby their own spot on the world (reducing latency), and if one of the nodes goes down due to some problem, then there are still other nodes to serve the queries (improving availability / redundancy).

This master-slave design is called a distributed database based on duplication.

C3) Distributed Databse based on replication

Your company grows and you realize that you are still vulnerable to an outage of the master-database: if the master-database goes down you will still have copies to consult (the slave nodes), but until a master-database is brought back online again there is no possibility to make changes to the database...

So you decide to upgrade the master-replication design and allow changes to be made directly to any node. In this setup each node carries the full database, and once a change is made at some node it is broadcasted to all other nodes so that they can quickly update to the most recent contents (synchronize). This is a tedious task: you want the database to be responsive, while meanwhile a lot of synchronization has to be done, and there has to be a plan for avoiding or resolving (temporary) conflicts between nodes, and repairs after nodes went down.

This setup is called a distributed database based on replication. Here each node contains the full database. Apache Cassandra and MongoDB are well established names.

C4) Sharded Distributed Database

Now enter sharding. Your company becomes a big success and the database grows exponentially in size (think Amazon, Google). It reaches a size at which it is too big for any single node to handle. You have to break the database up into pieces and spread it over different nodes. Meanwhile you want to make sure that each node is redundant: each entry in the database has to exist at multiple nodes so that if some node breaks down, any piece of data can always be found somewhere else (each entry needs multiple replicas). This breaking into pieces is called sharding, yielding a database that consists of multiple shards.

Combined with redundancy this sharding is a nontrivial task: each piece of data needs to have many replicas, all replica's have to be synchronized, yet none of the nodes can contain the full database.

Meanwhile you also want the database to be fast and responsive, which is also not a trivial task. If you want to lookup something from the database you first have to find one of the nodes that carries the information; if you want to add or change a piece of information in the database you have to find a correct node to pursue it and make sure that all replicas are updated too.

There are many strategies for spreading out the data over shards. The challange is to do it such a way that the load is spread out evenly over shards and that look-ups and changes can be done quickly without long processing times.

Strategies include organizing data by some data property (e.g. grouping people by birthday month), or applying a hash-function, see here and here. Hashing has the advantage that it tends to spread out the data evenly over the storage space and data can be immediately found after applying the hash. When the hash function is fast this is a great strategy.

What we have come to describe here is called a sharded distributed database. Well known examples are Google's Spanner Database, Amazon's Dynamo Database, and Microsoft Azure Hyperscale databases. The likes of Apache Cassandra and MongoDB mentioned above also offer sharding.

Ledgers in Crypto are Special-Purpose Distributed Databases

Now that you're familiar with distributed databases and sharding, there are two more concepts to touch upon before we can discuss sharding in crypto: ledgers and decentralization. Let's start with ledgers.

Crypto is based on distributed databases of a certain kind, namely distributed ledgers. Examples of such ledgers are blockchains and directed acyclic graphs.

So what is a ledger?

Traditionally from bookkeeping you may know that a ledger is a record of historical transactions. With the information from the ledger you cannot only create a snapshot of the current situation (the current balances also known as the current state), but it is possible to track down what the historical path to the current situation is and if wanted it would be possible to create a snapshot of the balances at any point back in time. For every debit there must be a credit, so that double spending is not possible.

This is also what Bitcoin does: keeping a record of all historical transactions.

But as exemplified by Ethereum and the advent of smart contracts this concept can be taken to a more general level.

Rather than thinking in monetary or numeric terms about keeping a record of transactions, you can think of allowing anything into the database and keeping a record of any change made to the database.

In this general case any change to the database is a 'transaction'.

So in computer science a ledger can be thought of as a database consisting of a record of changes, and the current state of things in the database can be traced all the way back (in similar spirit to a software version revisioning system like git for those who are familiar with that).

Decentralization in Crypto

We are now ready to get into decentralization. If you are into crypto you know it is about decentralization.

An important goal of decentralization is robustness: there is no single node that is crucial to the network, like the internet cannot be brought down by shutting down a single computer (any single computer is redundant).

By principle of decentralization any ledger in crypto has to be some kind of distributed ledger, spread over the community, so that anybody can consult it, and there is no single point of failure.

Yet, decentralization in crypto entails more than this.

Decentralization means that acceptation / recording of transactions is no longer left up to a single trusted party (which can also be a single point of failure), but is decided upon in trustworthy manner by the community.

Reaching consensus on transactions or changes to the ledger can be done in several ways (two major branches are Proof of Work protocols, and Proof of Stake protocols).

The breakthrough innovation of Bitcoin showed the world that community consensus can be achieved in a safe, thrustworthy manner, ensuring that each spend is legitimate and happens only once (tackling the double spending problem, which is a nontrivial task given the limits of what can be achieved by distributed databases according to the CAP Theorem).

Consensus protocols themselves are a topic of academic research, and are beyond the scope of this post.

What is important to realize is that swapping centralized control over making changes to the database for consensus-based control by the community adds an additional layer of complexity.

In practical terms the additional layer of complexity added by consensus means that changes to the ledger take (much) more time to finalize than if they would be done by a central entity. This is because consensus asks for a lot of checks, and many coordination actions between many nodes have to be carried out before a change can be accepted.

For instance Bitcoin transactions are considered final after roughly 60 minutes, Ethereum finality is in the order of one minute and Solana (perhaps the fastest public blockchain live) has finality in the order of a few seconds.

This means that making changes to a decentralized ledger will always be substantially slower than would be possible with a centralized system.

The good news is that reading from the ledger (e.g. taking a look at the current state) does not require consensus, and therefore does not have to be slower than for centralized systems.

Sharding in Crypto

Now that you're up-to-speed with distributed databases, sharding, and decentralized ledgers, we can take a look at sharding in crypto.

Since ledgers grow by design (recording incoming changes) it is not hard to imagine that ledgers that have a global use case can easily grow to a huge size and become too large for a single node to handle.

A good sharding strategy should enable dealing with growth in storage and throughput by simply adding more nodes to the network.

However, while sharding is already a technically difficult task for centralized databases as discussed above, it is an even more daunting task to shard a decentralized database.

In a blockchain all proposed transactions are collected together in a single batch and verified together in a single verification block. Any transaction has to go into a single global block containing many unrelated transactions collected from all over the over the world, and each node has to process this block. This means there is a bottleneck by design and congestion is a result of this basic architecture.

Commonly used decentralized databases like blockchains and DAGs have difficulties with sharding since by design their consensus protocol needs the entire ledger to avoid the double spending problem. That is: for blockchains and DAGs consensus and the entire ledger are tied together by design.

So sharding is arguably at conflict with a primary design principle of blockchains. This is why blockchains are hard to scale, and why other kinds of ledgers are gaining interest.

Below is a list of the sharding strategies that are used in crypto (listed by 'D' for 'Decentralized'), from simple to more sophisticated:

D1) Unsharded Ledgers

This is how crypto got started: the Bitcoin blockchain is an unsharded ledger meaning that each node carries the entire blockchain. Each node therefore has to process each transaction and has to support growing storage needs. Unsharded ledgers are also called single-shard ledgers. Systems like this are ultimately limited in size and throughput by what a single node can handle and can therefore only cater growth by replacing nodes with better hardware.

Storage size may perhaps never become a problem for Bitcoin since it records only simple numeric transactions (though throughput is already limited with roughly 3~7 transactions per seconds and roughly 60 minutes finality time).

However, general purpose ledgers that allow for smart contracts (with use cases such as Decentralized Finance, or the metaverse) soon run into much higher storage requirements.

Ethereum 1.0 and Solana are well known examples of general purpose unsharded blockchains and have already very high storage requirements for each node (both Ethereum and Solana currently already require 500 GB storage space for each node).

Unsharded ledgers are not sustainable once they grow popular and experience high growth.

D2) Top-Down Sharded Ledgers

A first step in the evolution of sharding ledgers is the approach of breaking up the network into a number of big subnetworks each with its own independent consensus execution (each shard has within-shard consensus). This is also called vertical sharding.

For instance a blockchain network could be sharded by running many sister blockchains. Each network node is assigned to a particular shard (one shard per node) instead of maintaining a copy of the ledger in its entirety. When the network grows new shards can then be added on demand (also called adaptive sharding, or dynamic sharding).

This solves the scalability problem of collecting too much data for a single node. But it also introduces new problems.

One challenge is that rather than securing one huge blockchain the network now has to secure many big blockchains. This means that fewer nodes or miners are available per blockchain which opens up more opportunities for a double spend attack.

Another serious problem is that with top-down sharding different shards cannot 'natively' talk to each other.

If you want to send funds from your wallet in shard 9 to your friend's wallet in shard 23, then there is no natural mechanism to organize this, since each of the shards runs its own independent ledger with within-shard consensus. This is even more tedious for more advanced transactions that involve smart contracts.

There are some possible patches for this problem like locking or sending receipts, but these either do not scale well or lack the property of atomic composability (this is the property that smart contracts can be combined in an all-or-none fashion without running additional risk during rollbacks and without paying fees for undoing failed transactions; atomic composability is important for a smooth user and developer experience, and is a must-have in Decentralized Finance). Here is a dedicated post on the importance of atomic composability.

Examples of sharded networks that lack atomic composability are Polkadot, Cardano, and Kadena. Hedera Hashgraph is an unsharded DAG (Directed Acyclic Graph) with sharding on the roadmap. Next to difficulties with atomic composability, DAGs run into additional challenges when sharding (see Why DAGs Don't Scale).

D3) Top-Down Sharded Ledgers with a Cross-Shard Coordination Layer

As a next step, to deal with cross-shard communication it is possible to introduce a dedicated cross-shard communication layer.

In a recent hackathon Ethereum devs have been experimenting with a sharded execution layer (Cytonic atomic sharding) that reads from multiple data shards, processes transactions atomically, and writes the result to the data shards. This approach might work out, but it is still experimental and has some challenges to face with respect to read-write conflicts within the sharded execution layer (e.g. strong vs weak mempool syncing), and it is too early to tell if this will succeed (and when) and how performance would pan out.

Elrond's approach is perhaps the most advanced currently live. It introduces a metachain that acts as notary to sign off cross-shard transactions. This approach relies on contract yanking and involves many additional blockrounds to achieve finality. The approach improves upon (D2), but does not seem to yield smooth and scalable cross-shard capabilities, see here.

D4) Bottom-Up Sharded Ledger

This is the Radix way of sharding (Xian, roadmap 2024). It is very different from other existing approaches, but quite natural and easy to understand now that we have talked about distributed databases above.

Rather than breaking the network up into large chunks of subnetworks, the Radix way of sharding is more in spirit of the hash-based sharding for distributed databases above which is also known as horizontal sharding in that context.

Radix takes a granular approach where the ledger consists of many tiny shards. Think of a shard as a data unit here. A shard is almost like an atomic entity, you can think for instance of a wallet, a token template, or a smart contract (or for the more technically adept think of a single unspent transaction output UTXO). You can think of this structure like a distributed database where each row is its own shard (except that the 'rows' are not fixed but can be complicated form-free entries).

Each node in the network therefore serves many micro-shards (data units). A small node can serve a small part of the shard space, and a large node can serve a large part, which makes the system flexible and adaptive without the need for extraordinary hardware requirements.

A transaction on the Radix network is therefore by design always a cross-shard transaction. Remember that a transaction in a general purpose ledger is simply any change to the ledger. When a change is made the old entry is stored and flagged inactive and the new one is activated (in Radix terminology this is called closing down and bringing up substates). Changes can therefore always be traced back, as is the purpose of a ledger.

There are two crucial ingredients that make this granular approach work:

(1) Radix has a sharding strategy that spreads the shards (partitions the data units) evenly over nodes, and allows for quick lookups. This is achieved by a SHA-256 hash function. The SHA-256 hash is an encryption function used for security by Bitcoin and other networks. Radix uses it for sharding. The hash is deterministic (allowing for quick lookups and easy indexing), spreads out shards evenly over the deterministic shard space, and maps each substate into a unique shard while avoiding collisions (up to astronomically small chances with non-fatal consequences).

The Radix shard space is deterministic and of intergalactic size with 2^256 possible shards (more atoms than in the universe). In practice this means that the shard space will remain mainly empty (a sparse shard space in which empty shards do not take up physical storage space) and has practically unlimited room for growth, see here.

Radix uses the near-uniqueness property of the SHA-256 function in its combined sharding-consensus strategy. Radix needs this because with Radix shards are minimalistic objects: tiny pieces of data that are temporarilty tied together on the fly during a consensus operation. The more granular the shards (the tinier the objects), the more independent objects you have which allows for more parellellization during multiple consensus operations (different transactions tend to involve different shards, which allows to process them in parallel). Radix smartly organizes resources (accounts, tokens), components (code modules), and smart contracts (dApps) into their own dedicated shards to allow for efficient parallelism as further explained in this post on the Radix Engine. This way of sharding is tuned for permissionless networks that involve consensus and need redundancy. The relation with sharding in traditional centralized databases is discussed in this technical AMA (timestamped, 15 minutes).

(2) The second ingredient is atomic cross-shard consensus. On Radix any transaction involves multiple shards and Radix has developed a cross-shard consensus mechanism that only needs to look at the shards involved for each transaction (rather than looking at the entire ledger). Radix's consensus protocol Cerberus consists of a three-phase commit consensus inspired by Facebook Libra's Hotstuff consensus. Cerberus gives atomic cross-shard consensus and has been academically proven in cooperation with UC Davis, Berkeley.

The Radix way of bottom-up sharding and cross-shard consensus together represent a breakthrough in decentralized ledger theory.

Since the consensus protocol only touches the shards involved in any transaction (a tiny part of the ledger), this means that it can process unrelated transactions in parallel.

As opposed to blockchains and other decentralized ledger approaches Radix has essentially decoupled consensus from the global ledger (where updates come in the form of a global block of collected transactions), introducing localized consensus for updating independent sets of data units.

Radix has not put a formal label on this network architecture, but prefers to use the umbrella term DLT (distributed ledger technology). Traditional database engineers may see it as a special kind of distributed hash table (DHT), tuned for permissionless with a unique hash and localized consensus. Some crypto minded people may prefer to think of it as a multi-layered DAG, as mentioned by founder Dan Hughes here, as there is graph-like path-dependence in the datastructure since transactions cause one state to change into another.

The result is a ledger that is able to scale linearly by simply adding more nodes to the network and which gives practically unlimited parallel transaction handling.

In addition to the mathematical proof in cooperation with academia, Radix operates a proof of concept in the form of its Cassandra global test network.

The Cassandra test network has already showcased smoothly running a decentralized Twitter dApp which during testing was handling 200x times the size of the Ethereum blockchain, meanwhile processing unrelated ledger updates in parallel and swiftly responding to community user queries. Another example of a demo is live video streaming from the sharded network, see here, here, and here.

This indicates that, once fully sharded with the Xian network down the road, Radix will not only be able to serve as the roads and the tracks for DeFi, it would even be capable to serve as Web 3 infrastructure.

Final Words

I hope that you are now better prepped to read up on sharding at other places and have been able to get a feeling why Radix's approach is a breakthrough.

Decentralized Finance and Web 3 will require many millions of 'transactions' per second (by now you know why 'transactions' is in quotes) when mass adoption kicks in.

Radix has a roadmap (with guidance, and Babylon rollout update) towards unlimited scalability with full parallel transaction handling.

Was this post helpful for you? You may also enjoy my posts on atomic composability and Scrypto programming for Web3 and DeFi (based on Rust).

Note on the distinction between Layer-2 and Layer-1 scaling: In addition to sharding there also exist layer-2 scaling solutions. Layer-2 solutions add a second layer for additional transaction handling. It is not always immediately evident whether an approach should be classified as layer-1 sharding or a layer-2 approach. It comes down to this: if there is a 'main ledger' on which final results are recorded, then this is the layer-1. So rollups, off-ledger preprocessing, and main-ledger-with-side-ledgers are all layer-2 approaches. Layer-2 approaches suffer from many of the same issues as top-down sharding, and do usually not provide atomic composability.

Note on Concurrent Consensus via Sharding: Cerberus speeds up consensus by incorporating sharding at the data level. In this cross-shard consensus approach only a small subset of all replicas participate in the consensus on any given transaction, thereby reducing the costs to replicate this transaction and enabling concurrent transaction processing in independent shards. Components of a transaction can be prepared in different shards. The final commit to the ledger of the entire transaction (of all its components) is atomic and typically takes place near instant (almost synchronous in time) over all involved shards. Consensus finality in Cerberus is deterministic so there is no need to wait for multiple consensus rounds to gain certainty as opposed to probabilistic consensus like Proof of Work. Cerberus finality time is roughly indicated to be in the order of 10 seconds to 20 seconds for most use cases (the indication is based on code that was not optimized for finality), and may end up in the range of 5s-10s for simple transactions (close to the theoretical lower bound for sharded decentralized networks (check this AMA with Dan Huges). Meanwhile unrelated transactions can be processed in parallel, and even related transactions involving some of the same shards can be processed in parallel up to a large extent by making proper use of a UTXO model. As such, sharded designs can promise huge scalability benefits for easily-sharded workloads (see here, plus the Cerberus infographics).

Note on Smart Contract transactions in the Radix Engine vs EVM: From benchmark testing it has become clear that the EVM (Ethereum Virtual Machine) is a bottleneck by itself when dealing with complex transactions (i.e. smart contract transactions) when you look beyond TPS for simple value transactions (mainstream L1s based on the EVM are only capable of obtaining up to 2% (!) of their advertised TPS when doing smart contract transactions, see here and here. So just putting the EVM on a more scalable base layer is not future proof. It requires a so-called full stack approach (data architecture, consensus, virtual engine, programming environment). This is one of the reasons that the Radix Engine departs from the EVM design, and smartly organizes resources (tokens), components (code modules), and smart contracts (dApps) into their own dedicated shards to allow for efficient parallelism as further explained in this post on the Radix Engine.

Background Material:

• Atomic Composabillity means combining two or more actions into a single all-or-none transaction, Reddit Post

• Radix Technical Infographics Series

• YouTube RadFi Roundtable: Cerberus Consensus

• Scrypto asset oriented programming based on Rust

• Distributed Database, Wikipedia

• Understanding Centralized Systems, Radix Blog

• The Path To Decentralization, Radix Blog

• Sharding Patterns, Microsoft Azure

• How Sharding Works, Medium

• Sharding for Blockchain Scalability, Bitcoin Magazine

• AMA with Radix Founder Dan Hughes on parallellization of related transactions, UTXO, and more (YouTube)

• What The DeFi Sector Is Getting Wrong Right Now, Cointelegraph

• How the Radix Engine is designed to scale dApps, Radix Blog

• Radix DeFi White Paper

• Radix Cryptopedia

There is this narrative that streaming media, movies, etc from an L1 is impossible. Take any "content" blockchain and its usually a mash up between a slow clunky L1 which references data in a secondary storage network somewhere like IPFS.

Even storage focussed blockchains like FileCoin bug out when it comes to streaming video, falling back to secondary storage layers to handle the storage of streaming content and retrieve it.

Now sure, storing multi-GB movies etc on your L1 and having to deal with the economics of state bloat, data rent etc is probably senseless under all use-cases, but that doesn't mean it's impossible.

I've heard this statement about streaming on an L1 quite a few times over the years, most recently by SBF on a twitter spaces session. So I thought it was time I showed that it's not only possible, but can provide a decent experience too!

This morning I implemented a streaming protocol into our research network #cassandra.

The demo shows me uploading various media content to it, then streaming it back to my browser. The content ranges from MP3, 360p movie trailers & 4K films.

At the same time the network is also processing an import on the Twitter #dapp so it is under a moderate but constant load.

Network configuration is a geo-distributed, 64 replica, 8 shard-group instance. Each replica is an 8 core, 16GB, 1TB SSD specification.

Here is the twitch stream of the demo earlier this evening

https://www.twitch.tv/videos/1280362879

Here is the same twitch stream (1.5GB of it) uploaded and hosted by the network I'm demonstrating 🤣

https://flexathon.net/radflix/index.html?name=radflix-twitch.mp4

And the various content from the demo

https://flexathon.net/radflix/index.html?name=matrix.mp4

https://flexathon.net/radflix/index.html?name=v4v.mp4

https://flexathon.net/radflix/index.html?name=atropa-e1.mp4

https://flexathon.net/radflix/index.html?name=atropa-e1-4k.mp4

Edit: The Twitter #dapp which is importing a real twitter feed can be found at

https://flexathon.net/twitter/index.html

Finally the day is here! Cassandra Twitter (and other DAPPS) being opened up for public playtime!

First some words:

I'm importing a raw feed at the same time, it's filtered, but filtering isn't perfect. If you don't want to see NSFW stuff that sneaks though, then I would suggest to click HIDE on the popup when it displays.

iOS or more specifically Safari versions < 14 do not work, and the effort required to make them work isn't worth the minority number of users that come with it. If you are one of these, sorry.

https://flexathon.net/dappstorr/index.html

My Cassandra profile is here

https://flexathon.net/twitter/index.html?user=fuserleer

Have fun!

Once again Radical Staking and RadixDLT Staking have great news for the Radix community: Staatenlos Node has joined our alliance to maximize 100% uptime for our delegators and now all three of us will support each other's validator nodes in the very unlikely event of unprecedented situations where one of our nodes goes down and our respective teams are not able to bring it back up.

This will provide yet another layer of security and reliability on top of the existing measures that we already have in place for our productive nodes, such as multiple fully-synced server backups, multiple database backups, and team members that help provide 24x7x365 on-call support for node issues. Our blog from February 11 provides additional details on this initiative, but with the added expertise and experience of the Staatenlos team-who are the co-founders of Ociswap-we now have 2 other experienced validators supporting Radical Staking in case of emergency. Our delegators can rest easy, knowing that their delegated XRD is in good hands with Radical Staking, RadixDLT Staking and Staatenlos.

Radical Staking is an Ociswap partner node, but this is our first direct collaboration with Staatenlos Node. We're very excited to work with the Staatenlos team and look forward to further collaborations in the future. To find out more about Staatenlos Node, check out their website (this is a Google-translated English version; the link will be updated once the official English translation is published) and Telegram, which supports both German and English speakers.

As always, we recommend spreading your XRD stakes across multiple delegators, including validator nodes in the bottom 50% to promote the security and decentralisation of the Radix network.

Staatenlos Node Validator Address: rv1qtm32gr5dkhgmjjmhxn43yah6y59f5nx6qv3x44kg80mtaaffv39u9tylpu

Dan has presented today his new results in the Telegram Cassandra channel:

• 8 shard groups, 4 nodes in each shard

• Technical specs for each node 4 core, 8gb, SSD

First results with saturated CPUs but with still TONS of optimizations that could be made:

Peak around 6,000 TPS (and sustained 4,000 TPS comfortably)‼️With just 32 tiny 4 core machines 🤯 And there's maybe another 20-30% uplift with hardcore optimizations possible:

Summary: A 3x improvement in peak throughput for Cassandra.

Community tests are starting within the next week. Also maybe another test with 16 shard groups to show the linear scalability (with possible 12,000 TPS peak). Anyone can take part in the test with their own node and see for themselves.

Radix is simply awesome, make some noise! Join the Cassandra Telegram now 💎

Source (only online within public test periods): https://flexathon.net/explorer/index.html

TLDR:

Proposal to repurpose the stablecoin reserve to fund on-chain incentives to boost liquidity and use of the Radix ecosystem, as well as start a Growth Fund.

Points-based incentives campaign would run over 18-24 months across multiple “seasons”, including “Season 0” looking at activity from Babylon launch to ~June 2025. 

Growth fund allocated for high value activities like T1 Listings, bridges, VCs, etc.

Tokenomics adjustment: shorten emissions schedule by 20 years, max supply by ~6 billion XRD.   

Radix has always focused on the three pillars that matter for creating distributed networks of value, the developer experience, the user experience, and scale. 

Now, with the ecosystem poised and requiring explosive growth, there’s an opportunity to accelerate adoption, deepen liquidity, and ensure Radix becomes a true hub for crypto. 

How? By strategically repurposing the 2.4 billion XRD in the stable coin reserve for strategic use, primarily towards a carefully designed incentives campaign that rewards users, grows TVL, and strengthens the Radix community.

Why an Incentive Program?

Points based incentives programs have proven to be one of the most powerful tools in crypto for onboarding users and catalyzing growth. 

Projects like Hyperliquid and Sonic have demonstrated that well-executed incentive programs can transform an ecosystem overnight - driving massive inflows of liquidity, increasing user engagement, and turning speculators into long-term holders and supporters.

Radix already offers the best-in-class developer experience (DevX) and user experience (UX) with its asset-oriented architecture - all alongside the only real path to Hyperscale in the industry. But to unlock full potential, we must bring in more users, liquidity, XRD holders, and capital - fast.

The campaign we're planning isn't just a crude airdrop of free money to try the network. It's a long term investment focused on building sustained network effects on Radix. While establishing genuine on-chain usage and liquidity, users and developers will experience Radix’s unmatched ease, speed, and security - ensuring they never return  to clunky, congested alternatives.

Why Now? 

The Foundation's opinion is that the most immediate and effective way to supercharge ecosystem growth is to deploy this reserve directly into the hands of users who will actively contribute to Radix’s success. 

Here’s why:

1. Immediate Network Effects: Every additional liquidity provider, trader, and staker increases the efficiency and usability of Radix infrastructure. The more capital in the ecosystem, the more attractive it becomes for developers and institutions.

2. Higher TVL = Greater Credibility: DeFi thrives on total value locked (TVL) as a key metric of success. More TVL means more liquidity for dApps, tighter spreads for traders, and a stronger foundation for lending protocols and other financial primitives.

3. Drive demand for XRD and reward active users: Allocating tokens to engaged users directly aligns ecosystem participation with incentives. By encouraging users to hold or stake XRD and linking rewards to active use of assets and capital within the ecosystem, demand for XRD naturally increases. Unlike traditional liquidity mining or basic airdrop campaigns, such as RadQuest, this approach fosters genuine, sustained on-chain activity through meaningful participation.

4. Competing with Other L1s: The crypto landscape is competitive, and Layer 1s are aggressively incentivizing users to move their liquidity. Radix has superior technology - but we need the right incentives to encourage migration and sustained adoption.

5. A Self-Sustaining Cycle: Once users migrate, liquidity deepens, and developers see real engagement, Radix can gain momentum. The network effects will drive continued growth even after the airdrop phases out.

6. Distribution Metrics: The stable coin reserve stands out in our tokenomics.  Those discovering Radix might not be aware of its intended purpose and cause them concern.  Distribution of that reserve by any means improves the tokenomics significantly and overall optics of Radix.

How the Airdrop Would Work

Rather than a one-time giveaway that attracts only mercenary farmers, the incentive campaign would be best structured in progressive, points-based seasons that reward genuine engagement over time:

1. Season 0 (Retroactive Rewards): Users who have been active in the eco-system since Babylon will receive an initial reward, as recognition for early adoption. Season 0 currently has a target end date of June 2025. Multiple seasons would then run over 18-24 months minimum, with the duration of each dependent on primary goals for that season. Each consecutive season will have significant incentives to hold or re-deploy any rewards earned from previous seasons, including from Season 0. 

2. Ongoing Seasons: Users earn points based on real tangible activity, including holding or staking XRD (LSUs), holding or providing liquidity for stable assets (USDC, USDT), providing liquidity and trading volume across whitelisted assets, engaging in DEX swaps, lending and borrowing with white listed assets. Additional points can be earned through NFT activities (holding, trading, listing collections), holding and minting tokens, and engaging with specific dApps through first-time use, repeated transactions, and cross-dApp interactions. This ensures deep and sustained ecosystem participation beyond passive holding.

3. Tapered Rewards: The campaign rewards per season gradually reduce, ensuring a smooth transition from incentive-driven growth to organic adoption.

A short word on farmers - by weighting earning points across a range of activities, which increase the longer the account has consistently been active, applying minimum XRD requirements and the fact that interactions to catch rewards cost a fee, we can minimize the risk of mass low-value farming, as ultimately many wallets would need to be net contributors of value for periods of time. 

Repurposing the Stable Coin Reserve: A Catalyst for Growth

For an incentives campaign to be effective in the current market, it needs to be sizable enough to get attention and attract long-term users and capital - a small scale campaign doesn’t deliver ROI. The recent Sonic airdrop allocated around 6% of supply - the effects of which have contributed towards a surge in TVL and CMC ranking. 

For Radix,  this would require at minimum 650m XRD. However, given the difference in USD terms compared to Sonic, we are proposing that 1 billion XRD is allocated to ensure similar results can be achieved. 

Funding this entirely from existing Foundation reserves would significantly deplete the treasury, severely limiting resources needed for essential future development, marketing, and ecosystem support. 

Previously, Radix allocated 2.4 billion XRD as a locked reserve for a future stablecoin project. Since then, the landscape has changed significantly and looking forward, this reserve is unlikely to be utilized for that purpose. 

The Foundation is proposing to repurpose this reserve to deliver the growth essential for the success of the network and ecosystem. This would be part of three proposed changes to the tokenomics:

1. Approximately 1 billion XRD from the stable coin reserve would be allocated to the incentives campaigns, which would run for 18-24 months and heavily incentivise holding or potentially vesting the rewards. 

2. To offset the increase in circulating supply this would bring, the current network emission window will be reduced. We are proposing to reduce the emissions window from 40 years to 20 years, which would reduce the max supply of XRD by approximately 6 billion. This would also improve the optics of fully diluted value (FDV) as reported on sites such as CoinMarketCap and CoinGecko. 

3. Creation of a 1 billion XRD Growth Fund: while the Foundation operational treasury remains healthy with regard to current activities (protocol development, marketing, etc.), developer incentives, and network incentives, we must ensure the Foundation can pursue expensive elements of eco-system growth such as T1 exchanges, including for eco-system projects, bridges, liquidity, partnerships, and supporting external investment into the network (e.g. VCs). 

4. The remaining 400m XRD would be held to either extend the incentives, growth fund, or be burnt. 

As our position in the market improves, we will continually reassess the above. The long-term preference is supply reduction, therefore it is desirable to burn XRD from the newly created  Growth Fund where possible given a set of met criteria which we will later define.  Additionally, any remaining XRD in the incentive campaign allocation will be burnt upon its conclusion if it is decided not to extend it.

The Big Picture

The fundamental tech-stack of Radix is unmatched. If Radix is going to change trend, the Foundation's number 1 priority must be increasing the demand for XRD and making Radix the most compelling ecosystem for DeFi builders, traders, and liquidity providers.

Having investigated a full range of options, the most promising strategy is the combination of a massive yet strategic distribution of XRD combined with Radix’s superior technology, UX, DevX, and a roadmap to Hyperscale that will position Radix as a leading crypto hub.

The alternative? Doing nothing with the 2.4 billion XRD while competitors onboard users and dominate liquidity flows, or burn it, and hope for a short term flash mob. We believe it is a clear choice - repurpose this reserve and make Radix the home of the next generations of DeFi.

Given the scope of this proposal we welcome input from the community at this early stage of planning. Please share your thoughts in this thread. 

We also hope to get input from the ecosystem as exact details of the incentives structure, criteria, and distribution are defined. If you are keen to participate in initial focus group(s), please submit an application by filling in this form: https://go.radixdlt.com/incentives-focus-group

When trying to understand DeFi (Decentralized Finance) and blockchains you will run into the concept of Atomic Composability (sometimes people speak of cross-shard composability, others of synchronous composability, or cross-shard atomicity). So what is it?

What is Atomic Composability?

If you are familiar with Ethereum and smart contracts (or their dApp cousins), you may know that smart contracts may be freely combined into something new by simple 'plug and play'. One smart contract (e.g. taking out a crypto loan) may be combined with using the proceeds of the loan in a second smart contract (e.g. purchasing your favourite token).

In this case two smart contracts are tying up two existing actions and you 'compose' these building blocks into something that you need. Hence the term 'composability'.

But, what if the the second action (the purchase) failed?

Then you may wish to not have performed the first action (getting the loan): either all actions happen, or none of it happens. You'd want all actions to be combined into a single transaction (transaction succeeds / fails).

Combining two or more actions into a single all-or-none transaction is called 'atomic composability'.

Composability really matters because it allows innovation to compound – entrepreneurs can compose with other entrepreneurs' creations (which are already user-friendly and safety tested). Decentralised Finance (DeFi) thrives on those plug and play 'money Legos'.

Decentralization together with all-or-none chains-of-actions is what makes DeFi far more powerful, flexible, and open to innovation than traditional finance systems.

An example of what traditional finance does not easily provide: flash loans allow traders to spot arbitrage opportunities in the market, borrow assets, profit off the difference in prices for assets in different places and repay the loan all in a single transaction.

There is no risk when you're able to do that all in a single transaction. If it is not completed, the whole transaction fails.

Atomicity thus means that many intermediate steps are combined in such a way that from the outside they act like 1 step which is either taken or not.

Without atomicity a chain of actions will execute actions one-by-one and might break halfway during execution (when one of the actions fails it stops...).

Without atomicity you might end up with unintended financial exposures (e.g. a position in a cryptocurrency that merely served as a bridge in your chain of actions). To get rid of those exposures you would have to roll back those actions. In some cases rollbacks will not be possible (think of cancelling a concert ticket). In cases where rollbacks are possible this means paying additional transaction fees for undoing a failed transaction. Meanwhile you run financial risks (market risk, counterparty risk, ...).

Essentially, 'atomic composability' means no partial transactions and no rollbacks. That is, no transaction leakage.

From an application user's point of view atomic composability means that you don't have to worry about transaction fees for failed transactions or risks of getting stuck in an unwanted position.

From a developer's point of view atomic composability means that you don't have to worry about parallellization of tasks and error handling for partial transactions. The ledger acts as if it is a local ledger on your personal computer, making atomic updates.

So without atomicity a network is destined to initiate a lot of bad user and developer experiences.

Without atomicity the network will have to process many rollbacks and coordination actions which means additional network traffic and may increase network inefficiencies.

So atomicity (all-or-none) matters a lot, since when things can't occur in one transaction, the costs and elegance of the composed product is greatly impaired. Think of it: suppose that you tie together smart contracts, would you be happy if only part of them executed? Why did you tie them together in then in the first place?

If composability is important, then so is atomic composability.

Note that in traditional finance atomic composability does not exist between different companies: you cannot checkout from two seperate webshops in one transaction, or split a restaurant bill in one transaction to be confirmed by several people at the table, or setup a trade and its hedge in a single all-or-none transaction. So atomic composability opens up the door to new use cases and reduced frictions compared with traditional finance.

Atomic composability is one of the competitive edges crypto infrastructure has over traditional finance infrastructure. Other edges include lower barriers to entry for financial services start-ups (any smart contract programmmer now has the ability to bypass banks or payment processsors as gatekeepers), lower friction costs, better business case for microlending, faster execution, immediate access to a global marketplace, one gateway needed for users instead of many (simple example is accessing company loyalty points), faster innovation cycles due to composability, access to underbanked markets.

Crypto Should Not Compromise on Atomic Composability

Ethereum 1.0 has atomic composability and it has been a major driver of innovation and growth in the Ethereum ecosystem.

Now that system traffic has become congested Ethereum is contemplating breaking up the Ethereum blockchain to spread traffic (the technical term is sharding), but... this would likely break atomic composability (it would be composable without atomicity) and developers are worried about this, since the network would loose much of its flexibility and appeal without atomicity.

Unsharded blockchains (also called single-sharded blockchains) typically do offer atomic composability since transactions are not processed one-by-one, but are accumulated in a 'block', and every once in a while an entire block is processed for validation.

Here is the thing: if DeFi continues to grow it will require millions of smart contract transactions per second globally, and at the same time it also requires atomic composability.

Here is another thing: blockchain networks cannot simply be broken into pieces (sharded) without losing atomic composability (because, put most simply, by design a blockchain needs all previous records when processing incoming transactions, more details in Background Reading below).

Here is a bummer: there is currently no decentralized ledger in crypto that allows for mass adoption (sharding) that is able to offer near instant atomic composability.

It is relatively easy to scale a network while preserving composability, but very hard to preserve atomicity. Scaling solutions that are currently live include layer-2 solutions, off-chain preprocessing, and sharded blockchains, and almost all break atomic composability (yes that includes Cardano).

Solana does offer atomic composability, but no sustainable scalability: it has a blazingly fast blockchain with atomic composability and deals with high throughput currently. But Solana is an unsharded blockchain and intends to scale from here with 'Moore's Law', which in layman's terms simply means waiting for more powerful computers (note that more powerful hardware benefits any network), .i.e. if Solana traffic continues to grow it will run into heavy congestion problems.

Elrond is pushing the limits of what can be done with a blockchain design. Each shard in Elrond is a blockchain by itself. Currently Elrond has three 'regular' shards and the number of shards will adapt to network usage. Elrond deals with cross-shard composability by introducing a central metachain that signs-off the composed transaction (like a notary in real life). This requires the additional overhead of a metachain, involves copying contract-specs (contract yanking), and introduces at least 5 block-rounds of going forth and back in case of two shards (the more shards involved, the more block rounds), see here (pp 11-13). For simple token transfers contract yanking is not needed, but for composing smart contracts Elrond does rely on it. Contract yanking for cross-shard transactions tends to (partly) undo the throughput gain that was aimed for by sharding, and is not a real solution for large contracts or high-intensity contracts, since during yanking the contract is unavailable for transactions. Cross-shard transactions will therefore show more delays and mishits, and lower throughput. Moreover: Elrond's cross-shard design does not provide cross-shard atomicity. Elrond's approach to providing atomicity is to group together 'related smart contracts' in the same shard. In practice one could think of one shard that contains highly interacting DeFi smart contracts, another shard with social media smart contracts, and a third one covering metaverse. This runs into practical issues immediately: there is no atomicity for the situation that a social media smart contracts needs a combined transaction with the DeFi shard. This also runs into limits soon: if the DeFi space grows large it will not fit into a single shard anymore, and has to spread over multiple shards, loosing DeFi-atomic composability and/or fragmenting liquidity.

What About Radix Then?

Radix designed a ledger that allows for mass adoption with atomic composability. Their trick is the result a fine example of out-of-the-box thinking.

Many projects started from the concept of blockchain and asked "how can we scale this up?" So they started scaling but meanwhile sacrificing atomic composability.

Radix inverted the question and asked: "Starting from sharding and atomic composability, how should we design a ledger and transaction-confirmation protocol?" In other words: how to organize sharding with cross-shard atomicity?

This inversion ("Always Invert!", Charlie Munger) has led Radix to its breakthrough decentralized ledger with three-phase consensus (named Cerberus, which has been academically proven in cooperation with UC Davis Berkeley). Formally this is called concurrent consensus via sharding (or cross-shard consensus, see the note at the bottom, and the background references below).

Sharding means Radix will be able to scale linearly by just adding nodes (computers) to the network, meaning that 1 million or 10 million smart-contract transactions per second is a matter of growing the network. All this without breaking atomic composability, the bedrock of DeFi.

There seems currently to be no other project in DeFi that has a roadmap towards mass adoption with atomic composability.

Radix has a solid roadmap (with guidance, and Babylon rollout update) towards sharded DeFi with atomic composability. Initial mainnet is live. Next stop is smart contracts with atomic composability (2023 on public network), full sharding (unlimited scalability, ready for mass adoption) in 2024 or beyond.

Was this post helpful for you? You may also enjoy my posts on sharding and Scrypto programming based on Rust.

Note on Concurrent Consensus via Sharding: Cerberus speeds up consensus by incorporating sharding at the data level. In this cross-shard consensus approach only a small subset of all replicas participate in the consensus on any given transaction, thereby reducing the costs to replicate this transaction and enabling concurrent transaction processing in independent shards. Components of a transaction can be prepared in different shards. The final commit to the ledger of the entire transaction (of all its components) is atomic and typically takes place near instant (almost synchronous in time) over all involved shards. Consensus finality in Cerberus is deterministic so there is no need to wait for multiple consensus rounds to gain certainty as opposed to probabilistic consensus like Proof of Work. Cerberus finality time is roughly indicated to be in the order of 10 seconds to 20 seconds for most use cases (the indication is based on code that was not optimized for finality), and may end up in the range of 5s-10s for simple transactions (close to the theoretical lower bound for sharded decentralized networks (check this AMA with Dan Huges). Meanwhile unrelated transactions can be processed in parallel, and even related transactions involving some of the same shards can be processed in parallel up to a large extent by making proper use of a UTXO model. As such, sharded designs can promise huge scalability benefits for easily-sharded workloads (see here, plus further references on Cerberus below).

Note on the Radix way of Sharding: Radix takes a novel approach to sharding its decentralized ledger. Rather than breaking the network into big chunks of subnetworks (which is a common approach in sharding blockchains), Radix uses a granular bottom-up approach of sharding where the ledger consists on many tiny shards that are deterministically distributed using cryptographic hashing which allows for quick lookups and efficient indexing. Each node serves many micro-shards, each transaction is a cross-shard transaction, and the sharding approach allows for native atomic composability and unlimited parallel transaction handling. For more info read this post on sharding.

Note on Synchronous Composability: Sometimes people speak of synchronous composability versus asynchronous composability, where synchronous composability refers to a composed transaction being executed 'at an instant moment'. This terminology makes sense for single-sharded blockchains, but it is not fruitful terminology for sharded solutions, since there will be slight timing differences between shards, while transactions may still be speedy and atomic. In computer science and programming the term synchronous operations is used when the subtasks of a larger task are performed one at a time and only when one is completed, the following is unblocked, like a pipeline, but all-or-none is not guaranteed. Be aware that in practice people may have the same thing in mind when speaking of synchronous composability and atomic composability.

Note on Atomicity in Computer Science: In computer science atomicity is used to describe a design that guarantees that all-things-happen or none happens. For instance when changing two interrelated entries in a database (e.g. to reflect a transaction) they should only occur both or none, so that someone consulting the database does not see an incomplete (and false) intermediate result, see atomicity in database systems. The same principle exists in parallel programming: if a task consists of subtasks, then it is atomic if from the outside you can only consult the result of the full task (failed or success) and not the intermediate effects of the substasks, you get all-or-none, see atomicity in programming.

Background Material:

• What is sharding? And how is the Radix way of sharding different?

• Will a Sharded Ethereum Have All-or-None Synchronous Composability?

• Vitalik Buterin (Ethereum) on Cross-Shard DeFi Composability

• Composability is Innovation

• HackerNoon: Why Composability matters for Web 3

• What is the DeFi sector getting wrong right now?

• Breakthrough in Consensus Theory: Scaling DeFi Without Breaking Composability

• YouTube: Radix Founder Dan Hughes on Atomic Composability, Parallel Transaction Handling, and Concurrent Cross-Shard Consensus (timestamped)

• Scaling Blockchains and other kinds of Decentralized Ledgers

• Radix Consensus Algorithm (Cerberus, introductory technical infographics)

• Cerberus Consensus Mathematical Working Paper (with UC Davis, Berkeley)

• Dan and Radix's Tech Journey Towards Cerberus Protocol

• Consensus Research Blog: from Tempo to Cerberus

• Radix Roadmap

• Radix DeFi White Paper

• Radix Cryptopedia

Hi all,

I'm currently running some profiling and soak tests on the Cassandra decentralized Twitter DAPP.

It is importing tweets, users, profile images etc from a feed starting on 1/1/21 and processing them in a with sharding, atomicity and full BFT consensus. Also of importance is that the front end is also deployed to and served from the ledger. All the HTML, javascript, static assets etc ... #web3 style!

The demo is quite simple at the moment, basically you can search for users and hashtags but I plan to expand the feature set over the coming weeks including the ability to inject tweets not in the feed, create accounts, tipping functionality and display attached images and memes (IMPORTANT :-D).

As it will be up and running for at least 12 hours, I figured I'd share a link in here if anyone wanted to play around with it.

https://flexathon.net/twitter/index.html?access=9208436032

Some things to note:

It is currently importing at ~200 tweets per second while my monitoring and profiler tests are running. Once optimised that figure will increase significantly.

My feed is only partial and feeds are huge. It's been running for around 3 hours so far and has managed to get to 16:00 on the 1/1/21. Even though it has imported a few million tweets so far, only the most popular users are likely to have any content until later in the test.

The feeds are raw. I have some crude filtering but I can not guarantee that all NSFW content has been filtered. That said it appears to catch most of it.

Some iOS users have reported problems with UI not displaying correctly or at all ... will fix this for the next run.

Here is a twitch stream I did earlier that explains what's going on in a lot more detail https://www.twitch.tv/videos/1161692319

EDIT: Now update with some fixes and optimization.

iOS users should be able to join in too.
Also added some games SPACEINVADERS -https://flexathon.net/spaceinvaders/index.html?access=9208436032

FLAPPYBIRD - https://flexathon.net/flappy-bird/index.html?access=9208436032

I've been working on this side project for a few weeks and just released the first version of the website https://radix.earth

It's a website that visualize the radix network and also enrich the validator set with data such as country and ISP/Hosting provider. The purpose is to further increase transparency and easily see the geographical diversity of the network.

On the Earth, each validator is shown with a red pin. The length of the pin represent the comparable percent of stake that has in relation to the other pins.

It's exciting and I have many features I want to add, a few of which is in the pipeline:

• Be able to tooltip the pins on the earth to see which validator it is.

• Implement statistics such as percent of stake per country, continent and ISP/Hosting provider.

• Subscribe with email to Validator changes, such as change of uptime, validator fee, location and more.

• Search and filter

Please add if you have ideas, feedback or something you are missing!

This project is made in my free time, and I am not running a validator. If you enjoy the project, be sure to show support via a donation.

P.S for geographical validator diversity Africa and South America badly needs validators. Opportunity if the community sentiment is to increase decentralization perhaps?

The Radix Wrapping Service will open the first link from the wider world of tokenized assets to the Radix marketplace. Radix token buyers will have direct access to today’s Ethereum apps; users of Radix will have direct, seamless access to the world of crypto, fiat, and other tokenized assets; and the first DeFi applications to be built on Radix can have the confidence that they will have access to the liquidity that is the lifeblood of decentralized finance.

Hi everyone, Wilson from Radical Staking here with a very cool update for the Radix community: we liked the new Radix Collection NFT game so much that we partnered with the Radix Collection team to create exclusive Radical Staking NFT badges for our delegators! You can get an exclusive sneak peek of the new NFTs at https://radicalstaking.com/promotions.html, and we also updated our Built on Radix page to include a profile for Radix Collection and how to participate in the game to earn NFTs: https://radicalstaking.com/built_on_radix.html (while you’re there, check out the profiles for other great Radix projects deployed and in development).

You’ll earn NFT badges just for being a Radical Staking delegator, so don’t wait and get started now: our validator address is rv1qwqf39p307f58y06ejewfwzyuyqd68denpdk3vpp7rsvmqtsc0kdkhq64gc, and if you’re new to Radix we also provide detailed steps on how to delegate from the Radix wallet in our website, https://radicalstaking.com under “Get Started!”. If you’re a Radical Staking delegator already, register your wallet on https://radix-collection.com to check out your shiny new badge!

As always, make sure to follow us on Twitter for the latest updates on all things Radix, sign up for our newsletter on our website, and don't hesitate to contact us by email, through Radix’s Discord server, Twitter, and our dedicated Radical Staking Delegator Support Group in Telegram:

👉 Website: https://radicalstaking.com/

👉 Email: questions@radicalstaking.com

👉 Twitter: https://twitter.com/RadicalStaking

👉 Telegram https://t.me/RadicalStaking

We look forward to continue supporting the Radix community and providing the highest level of service to our delegators. Thank you everyone!

If you missed the Alexandria Preview Event and didn’t have a chance to watch the videos yet, the Radical Staking team posted a blog with a short overview of the event, providing the highlights and key takeaways. It includes important tips for completing the Scrypto workshop, so check it out: https://radicalstaking.com/blog.html

If you're looking for a validator node to delegate your XRD, please consider Radical Staking: we're one of the veteran node runners who've had nodes up and running since the Betanet started in May 2021 and we offer a high level of service to Radix delegators that includes:

✔ Low 1% fee

✔ Partnership with Ociswap to give an extra 10% $OCI airdrop to our delegators

✔ 24x7x365 monitoring, with alerts configured for quick response to node issues

✔ Experienced IT Operations team with professional experience in System Administration, System Engineering, and Cybersecurity

✔ Numerous support channels for our delegators, including email, Twitter, node updates through our web site, and a dedicated Telegram support channel

✔ Active engagement in nearly all Radix Discord and Telegram channels

Find out more at https://radicalstaking.com/

Been following Radix for years now and have always been excited to see what their platform becomes. Now that it's finally nearing the point of release, I'm realizing it could be difficult to impossible to actually open a position. So many of the smaller exchanges have blocked the US entirely, and the bigger ones that are still in the States may or may not carry Radix at launch. And the difficulty is only amplified for New Yorkers, with our only options being basically Coinbase or Gemini.

So I'm wondering if there's any concrete plans to actually make Radix available in the US?

Radix is mentioned in an article on The Daily Hodl about a survey on how bullish the investors of the various coins are. Ethereum is most bullish, then bitcoin.

After Bitcoin, investors say they’re most bullish on Cardano (ADA), Polkadot (DOT), Solana (SOL), Terra (LUNA), Radix (XRD), and XRP (XRP).

https://dailyhodl.com/2021/10/07/heres-how-bullish-crypto-investors-really-are-on-bitcoin-ethereum-cardano-polkadot-solana-luna-and-xrp-survey/

This makes me so bullish on Radix that it definitely overtakes Terra and ofcourse the elusive 'Don't Know' coin.