With Radix’s reach growing daily, more and more people are looking at our network and our mission, and some get sufficiently interested to dive deep into what it is that makes Radix different from any other DLT. And once they take the time to learn, they get excited. Once they get excited, they start looking for anything that is standing in the way of faster adoption, and then they wonder how can the team not realize how important it is to do <something important>?
We’d like to take a moment to talk about why you’re not seeing some things that might seem like they should already exist, and why some things feel primitive instead of world-class. We’d also like to explain what’s exciting right now about Alexandria for developers, and how it leads into Babylon when things will change pretty dramatically.
To set the stage for that, let’s begin with a quick orientation…
Revisiting the roadmap
There are four planned major phases for the network, each with its own target audience and primary goals. Let’s talk about them in brief, as they’re foundational knowledge that will inform everything that follows in this post.
Olympia is the first public release of the Radix network. It’s not the end, and is not intended as a platform for development - it’s the very first iteration of a truly decentralized network that will provide many months of operation and token use that will let us get to the later milestones with confidence.
- The target audience is early token holders and the first node-runners.
- The primary goals are to release and tune our consensus model, to allow token holders to stake to validators to secure the network, and to allow stakers to begin earning emissions.
- Olympia is currently meeting its goals. We have had over 2.75 billion XRD staked, we have had 100% uptime of the protocol over 6 months of operation, we have replaced a client layer which was not up to the task (the archive nodes), we have a manageable set of planned features in the pipeline, and we have a second-to-none node-runner community of amazingly capable and helpful people.
Alexandria is the first release of our developer-oriented tools, and does not impact the Olympia mainnet. However, it is definitely where we are directing developer attention right now, to create a community of builders around Scrypto and what the network will become at Babylon.
- The target audience is the developer who may one day deploy code to the network.
- The primary goals are to ensure that Scrypto and Radix Engine v2 are so good that everyone who tries them will want to build DeFi on Radix, and to get developers ready to release their applications as soon as Babylon ships.
- Alexandria is exceeding its goals so far. Initial response to Scrypto has been overwhelmingly positive, we already have the core of a highly engaged and supportive developer community, the major blocks of Scrypto/REv2 feature work are going faster than we expected, and our design sessions are turning up solutions that outperform our expectations in both flexibility and simplicity.
Babylon is where we marry the preceding two tracks, and enable programmability on mainnet.
- The target audience grows to encompass the full range of early adopters, both builders and users.
- The primary goals are to provide the world’s best DeFi consumer and developer experience, to reach people for whom existing DLT networks are unapproachable, and to enable an unprecedented range of DeFi applications and services.
Xi’an is where we unlock unlimited scalability, and make it possible to service the demand of the global financial system on a single network.
- The target audience is everyone on the planet who possesses a mobile phone.
- The primary goal is to create a radically better financial landscape.
With that out of the way, let’s talk about some topics that have been cropping up quite a bit lately.
Why aren’t you doing more to support developers building atop Olympia?
We aren’t dedicating high amounts of resources to Olympia development support because that isn’t the focus of Olympia; the top priority of those resources is to ensure that Babylon is the perfect place for DeFi development, and that the developer experience is as smooth as it can possibly be at Babylon release.
We have released some basic tools and documentation on how the pieces of Olympia work, and even with that limited toolset some people and projects have started creating things atop the network. That’s great, and we love to see it…we just can’t prioritize the team dedicating the time it would take to make the Olympia development experience a friendly one.
Time spent doing great documentation, creating tutorials, establishing rewards programs or overseeing developer grants is time not spent building towards Babylon. On top of this, the manner in which a developer or consumer interacts with the network will be quite different at Babylon, so much of that documentation would no longer be relevant.
If you’re a developer, you can check out Alexandria and Scrypto right now, and get a leg up on being ready for Babylon or plant your flag as an early expert who projects will be looking to hire. You will find that, even in these early stages, we’re spending significant effort on documentation, examples, and community support, with lots more to come…we’re learning how to do these things well, so we’ll be firing on all cylinders when Babylon ships.
If you want to be deploying services and applications right now, atop Olympia, you have our love and our goodwill, but we want to make sure you go into it with your eyes open. We’ll give you the best help we can on Discord, and try to point you in the right direction when you get stuck, but expect bumps in the road.
Where’s the slick wallet experience? Where’s the mobile wallet?
The Olympia wallet has a narrow focus on a limited set of user scenarios. It isn’t sexy. We have some usability improvements in the pipeline, but ultimately it is a workmanlike product rather than something that is intended to capture a general audience of varying sophistication.
Babylon is where we expect many people to be doing things in their wallet multiple times a day, whether on their phone or their computer, and we are in the midst of a massive and long-running design effort to deliver a game-changing experience for DLT users and app developers. Babylon will absolutely feature a mobile wallet, and we will absolutely be constantly pushing to make it as appealing, easy to use, and polished as possible.
Why isn’t there a 24/7 response team to investigate reported incidents?
We don’t have the bench depth to support such a team at this time, and the Olympia network does not have sufficient functionality and usage to justify building out that team at the expense of other priorities.
Finding the correct level of support is a balancing act, and we always want to be honest with ourselves and the community when we have to do better. For example, when it became clear that the level of service being provided by the archive node architecture was below the needs of the network, we completely reprioritized the development schedule to properly address this shortcoming with a new, greatly improved design.
With the release of Babylon we expect a dramatic surge in the level of interesting activity on the network, and we regularly discuss the increased need for support at that time.
Why is there no feature-level roadmap for future releases, with detailed milestones and dates?
The stuff we’re building is right out at the “here there be dragons” edge of the map. There’s little or no prior art to refer to, nothing that came before that we can use as a convenient yardstick to help estimate the effort or sequence of steps required to achieve it. We rely a great deal upon being able to shift priorities quickly when we learn new ways of doing things, hit upon a great design that enables some interesting class of functionality that we hadn’t realized was possible, or discover that some part of the stack is more challenging than we anticipated, and needs more thinking and prototyping.
Any fine-grained roadmap we published would need constant updating, which would necessarily also require each update to be accompanied by a detailed explanation of what adjustments were made and why, and pretty soon all the technical staff would be ready to throttle whatever poor soul had the unenviable task of getting all those updates together every couple of weeks.
When we have confidence that we can commit to a particular feature or timeframe, we usually talk about it in some combination of Discord, Telegram, and the bi-weekly Radix Report. We also introduced the monthly roundtable calls as a forum where we can discuss internal goings-on for those who want to know more about what’s occupying our day-to-day attention and what the near future holds.
Closing thoughts
We understand that at times it can feel like we are neglecting important things, or not properly addressing commonly brought up needs. Radix is supposed to eat the world, how can you guys not have a mobile wallet?!
The message we are hoping to impart here is that we are on a multiyear roadmap, and things happen in stages. There are a great many competing priorities, and we have to keep first things first in order to meet the extraordinarily ambitious goals of Babylon and Xi’an.
If you think we’re focusing on the wrong things, by all means please let us know. Community feedback is something we discuss extensively, and is always weighed when charting the course forward.
If you want to shape the roadmap from the inside, please check out our open positions at https://radixdlt.com/careers. We’re in a time of rapid growth at RDX Works, and we can promise you a rich variety of interesting problems to solve with an amazing team beside you.