What I see next for Vaulta/Antelope
Through the entire history of EOS to Vaulta, many differing visions of what’s best for the network are have come and gone. Since 2018, this has resulted in a cycle where the organizations leading development have alternated between technology and product. This creates a positive feedback loop where each iteration leads to evolution.
This post will briefly look historically at these cycles and explore where we are today. I’ll end by sharing my opinions on what’s next and the things I’m looking forward to.
7 years of iteration
Looking back at examples over time I think will help illustrate the idea behind this two part cycle. There have been 3 major cycles in my view. Listed below are their rough timelines, their technology focuses, and how that was then applied towards product development.
2018-21: EOSIO/EOS -> B1 products (in Voice/Bullish)
2021-23: Antelope/EVM L2s -> Crowdfunded products (via Pomelo/Eden/Grants)
2023-??: Spring/EVM L2s -> Web3 Banking products (in exSat/EOS-EVM)
It may not be an exhaustive list, but goes to show each cycle started as it started with the development of a technology - then ended with the creation of one or more products that leverage it. Each of these cycles attempted to sparking usage/adoption through products.
The first two cycles were heavily skewed towards native EOSIO/Antelope development, with EVM L2s only being introduced towards the end of the second cycle. These first two cycles concluded without meaningful or sustained on-chain adoption - for a myriad of reasons we won’t completely dive into here.
The third cycle is still actively being developed and is in its product phase.
Perception
Based on how people talk about Vaulta today, I believe this is how most view its history.
This is not the complete picture of Vaulta though, at least to those of us working every day on the technology side. That’s in large part because most people cannot recognize progress being made in the dark corners of Github. It’s too abstract, the markets often won’t care at all, and any actual announcements of technical progress are pretty boring.
Only when products development is announced does the level of awareness and excitement about one of these cycles reach the general public. I’m writing this post in part because I want people to be more aware of the quiet cycle I’ve been focused on - and what I envision happening next as this cycle enters its product phase.
The fourth cycle
Since mid-2022, a lesser known fourth cycle has been in progress. Its goal has been to address the challenges in adoption faced in the first two cycles. It hasn’t yet reached its product phase - but that’s about to change. Upcoming releases this year will creates an environment ripe once again for new product development.
If I were to add it to the list of cycles above, it would be represented as:
2022-??: Spring/Wharf/Middleware -> ??? products
It’s an opportunity to return to native product development with an entirely new suites of technologies. Advances and changes in our understanding of contract development with Spring, a better and easy developer experience with Wharf, and now a new onboarding and user experience with the projects over the past 1.33 years of Middleware. All huge benefits towards development that yet to be leveraged fully by any products.
This post focuses on the trajectory of the network and its priorities, and won’t cover the technologies themselves. If you’d like to read more about some of the recent tech that has been built, I’d invite you to read this post titled Sign in with Vaulta which describes one of these new experiences and how you could try it on Jungle 4 testnet.
Origins
This fourth cycle started development around the same time as EVM L2 development in mid-2022. Both of these initiative were in large part because of the same issue:
The native user experience and onboarding hindered product adoption.
It was an aspect of the core technology that had been ignored in many ways up until this point. By now hundreds of apps in all shapes and sizes had been launched using what little was available. The vast majority of apps had failed, in part because of the user experience. Some apps succeeded despite these challenges... often by avoiding the native experience all together and isolating from the network.
Future adoption would require overcoming these challenges. Leadership at this point decided to push ahead on two different paths:
EVM integration to adopt the industry standard and avoid the native experience.
Native overhaul by rebuilding the client side user experience from scratch.
The EVM path would quickly resulted in products and tangible things to be excited about, while the native improvements would take much longer to see the results of. Both serving as a hedge against the other, but both ultimately with the same long term goal in mind.
A shift into product
This fourth cycle is about to enter its product-ready phase. The work done over these past few years is being released and will be available to ease adoption and onboard the next generation of new Vaulta users.
It’s an all enabling technologies though, like the technologies from cycles past. Its success and impact on the network will depend on what product development comes next. In fact, it could be argued that Vaulta’s native evolution as a technology requires the feedback loop created by starting this type of product development.
So the challenge now is what is this technology going to enable? I could name a few existing good candidates, but the reality is there are not many products at the moment.
For that reason, it is my opinion is that the network increase focus on native product development once again. Start charting a path forward to take advantage of the effort invested in the native experience - without necessarily disrupting any existing products.
Next steps
I’d like to start discussions about what those could be and how they would benefit the network. I have a number of ideas I plan to talk about. Some are old ideas we should try again, some are partially developed, and some are brand new. They all are ideas though that get people involved and give them a reason to use the network - that doesn’t involve the networks core functionality or pure speculation.
If planning this all alone, I would start with at least one product that can serve as an example of what’s now possible. Move fast, release often, and lead by example. Build a monolith in an attempt to inspire others to try for themselves. Show people how it’s done.
For me personally, aside from a brief stint working on Shipload, it’s been like 8 years since I’ve done blockchain product development. I know I won’t escape developing the technology at this point, but a better balance between tech and product would be a refreshing change. Product development is the reason I started down this technology path so many years ago and it’s always been my intention to return. Now feels like an appropriate time.
Before I spent the time going down this road though I need to confirm there’s a will and a way. I’m not sure I understand exactly how to achieve consensus on this - but this post itself is an attempt to start that conversation as we approach 2026.
Please let me know if what you think about any of this, good or bad.
In fact, please let others know what you think as well - help me start the conversation.