Many in the Radix community are looking ahead to our mainnet launch this year, and beyond, and beginning to think about what will be possible to build on the Radix public network. We’ve been throwing around a lot of new terms and technologies in our DeFi White Paper and other communications and we realize that it’s gotten a little confusing. RPN-1? REv2? Drop 3 and 4? Scrypto?

So we wanted to bring a little clarity to what will be available in the first release of the Radix public network and beyond – in particular for builders who are eyeing the exciting developer features that are coming.

New Names for Radix Releases

First, let’s get our names straight!

The development roadmap for the Radix public network is split into a sequence of major releases. These releases define points when we push out significant upgrades to the Radix node software that bring new features and capabilities to the Radix public network (ie. the “mainnet”).

These releases aren’t new networks – they’re just big upgrades to the single Radix public network that we’ll be diligently working on improving over time.

Up to now, we’ve been calling the first release of the Radix public network “RPN-1” (Radix Public Network 1 … yawn). But this has started to get confused with the names of technologies like “Radix Engine v2”. So we’re moving to named major releases of the Radix public network.Each release will be named after a city that bore one of the wonders of the ancient world (thanks to Radix community member Ben for the suggestion!):The first release, previously called RPN-1, will now be called Olympia – city of the Statue of Zeus, celebrating creation.The second release will be Alexandria – city of the Lighthouse, lighting the way for explorers.Each of these major releases will include a stack of Radix technologies, sometimes with their own names and versions, but integrated and tested in whole as a coherent update to the

Radix public network. We tend to split the Radix software stack into two major layers: the application layer, and the consensus layer.

• The consensus layer is all the low-level ledger stuff that defines things like network security, scalability, and decentralization. This is where Cerberus, our consensus algorithm, lives on Radix.
• The application layer is what developers interact with, creating assets, decentralized applications, and transactions. For Radix, this is the Radix Engine, and all of the developer tools that interact with the Radix Engine like our libraries and, in the future, the Scrypto programming language.

With each major release of the Radix public network, the functionality or performance of at least one of these layers takes a big step forward. Let’s dive into the first two planned releases.

First Release: Olympia (previously called RPN-1)

This is the release we’ve been developing in earnest throughout 2020, with launch scheduled for the end of Q2 this year.

Olympia will mark the genesis of the XRD token, and holders of the current eXRD ERC-20 token will be able to swap them 1:1 for XRD. Our internal milestones for this release are called “drops” and we’ve just completed the second of our four planned drops. The end of the third drop will be the release of a public betanet that will allow node runners, users, and developers to explore how Olympia will function, without risking “live” tokens.

‍The consensus layer of Olympia will be an unsharded form of Cerberus, using a validator set of fixed size (100), selected by dPOS. The fully sharded form of Cerberus will, in a later release after Olympia, provide the linear scalability needed for mass adoption of the Radix network – as represented by our Consensus White Paper, and the subject of our founder Dan’s ongoing research platform in parallel with our product development. But for our first mainnet release, this simplified version of Cerberus will prove out our core 3-phase BFT-style consensus with dPOS Sybil protection, while minimizing risk while we implement the more complex aspects of the sharded Cerberus design.

Unsharded Cerberus will still provide an incremental scalability improvement over Ethereum, with at least 50 TPS. We expect that this will be more than sufficient for the use level of an early stage network  – after all, Ethereum is serving most of DeFi today with only 15 TPS! A later Radix public network release will include fully sharded Cerberus that will bring unlimited on-demand scalability – when network usage requires it.

‍The application layer of Olympia will be Radix Engine v1. Radix Engine v1’s capabilities will be familiar to those who have been following Radix for some time and will be functionally similar to our previous private “betanet emulator”.

The focus here is on tokens – the most essential use case for DLT. Unlike most application blockchains, Radix does not force the developer to copy and redeploy smart contract code in order to create a token, like an ERC-20 contract. Issuance of named, personalized tokens is a first-class feature of Radix Engine v1, and any token created by a developer behaves no differently from the native Radix platform token, XRD. This again is unlike Ethereum where ETH is implemented in a completely different fashion than ERC-20 tokens, creating a mess of special-casing for developers.

It’s worth noting that Olympia will not yet include “smart contract” style programmability or the other advanced developer features that we’ve described in our DeFi White Paper. The goal of Olympia is to launch the first iteration of our core technologies on a truly open, decentralized network, and build confidence in these core technologies in a live environment. Atop that proven, solid foundation, we are already beginning to build our developer-oriented features for our second release...

Second Release: Alexandria

Alexandria, the second major release of the Radix public network, is scheduled for the end of 2021.

The focus of Alexandria will be the introduction of Radix Engine v2. XRD tokens will of course carry through to Alexandria, just as they will to all future versions of the network.

‍The consensus layer of Alexandria will remain unsharded Cerberus with a fixed-size validator set. That isn’t to say that it will be unchanged however. We anticipate a number of refinements to unsharded Cerberus for further enhanced network security and robustness following Olympia’s release that will likely be rolled out with Alexandria. But the core consensus operation will be the same.

Development on fully sharded Cerberus will of course be full-speed-ahead following Olympia, but will be targeting a release beyond Alexandria. We expect that unsharded Cerberus’ 50+ TPS will remain sufficient for Alexandria – again, well ahead of what Ethereum is currently providing for current levels of real-world usage. Targeting fully sharded Cerberus development for a later release allows us to focus Alexandria on developer features atop a solid consensus foundation.

This leads us to…

‍The application layer of Alexandria is the star of this major release, bringing the first iteration of Radix Engine v2 which provides the foundation for the many breakthrough developer features from our DeFi White Paper that we plan to implement.

REv2 will bring with it programmable Components – Radix’s redesigned form of smart contracts created specifically for the needs of decentralized finance applications. Components will be created using Scrypto, the expressive programming language we are creating for fast, secure development of finance-oriented dApps for DeFi.

REv2 also enables the concept of Blueprints and an on-ledger Blueprint Catalog (read more about Components, Blueprints, and the Catalog in this post). Blueprints are very similar to Components; they can be thought of as templates for common Component types that anyone can discover and use (“instantiate”) from the Catalog. Rather than having to create all Components from Scratch, the Catalog may contain an existing Blueprint that is designed for a common piece of functionality. If so, a developer can select to create a Component of their own from the Blueprint just by specifying a few options – like picking the options on a new car – no code necessary. Blueprints will also be created using Scrypto.

Much work remains, however, on Radix Engine v2, Scrypto, and the low-level systems required for Components and the Blueprint Catalog. The goal of Alexandria is to allow builders to start building using these technologies, but we certainly won’t have all features and capabilities from the start.

Our current plan is to start by providing the ability for developers to write, compile, and run Scrypto within a private instance of Radix Engine v2. This will be an excellent starting point for developers to begin concretely working on the creation of Components and Blueprints that ultimately will be deployable on-ledger.

We also plan to build and include the first set of Blueprints for developers in Alexandria. These Blueprints will represent common on-ledger application functionality that developers can configure, deploy, and use without writing any Scrypto. Certainly tokens will be among the first Blueprints, but with much greater power and flexibility than those possible with REv1. We will have more to say about the initial set of Blueprints and their capabilities as we get closer to the release of Alexandria.

Work on Alexandria is well under way in parallel with Olympia, and we’re looking forward to sharing more with you in the coming months.

Getting Developers Engaged

We’ve heard from community members and eager devs: “how can I get started?” First, sign up to the Radix developer’s list. It’s too early for us to directly engage with developers at this stage ahead of these releases, but signing up to the list ensures that you will stay informed on developer features as we progress toward the Olympia and Alexandria releases and can begin to say more.

In the next 2-3 months we will be announcing details of our betanet program that will lead up to the launch of Olympia. If you’re interested in experimenting with Olympia’s token-oriented features, this will be a great place for you to get started using our Java library.

Alexandria (Q4’2021) is where we expect the real developer excitement to start. If you’ve joined our developer’s list, you’ll be among the first to see early forms of Scrypto and example Component code and learn about the Blueprints Radix intends to provide.

As we get closer to the release of Alexandria, we’ll also have more to say about our roadmap for releases beyond Alexandria including other features enabled by Radix Engine v2 like the Developer Royalties system, our Developer’s Guide service, and more.