I am currently preparing an on-chain wish-for-change track proposal to officially define the scope of Polkadot 2.0.
Through a series of discussions on several platforms the consensus that emerged so far is to define Polkadot 2.0 as Agile Coretime, Async Backing, and Elastic Scaling.
A draft for a proposal is here:
I’m asking to provide feedback on the definition
I plan to submit a consensus version on the WFC track next week Thursday.
I placed Ref 747 on Polkadot to make it official.
Looking for a 20k DOT decision deposit 
https://twitter.com/alice_und_bob/status/1788127462389391812
I don’t think 2.0 is an especially helpful term outside of the marketing sense of “OMG LOOK!1!! SOMETHING NEW!1!!”.
I’ve put my feelings on nomenclature here: https://hackmd.io/@polkadot/nomenclature
As it says, I’m not against having a version waypoint pre-JAM, but I’m not especially keen on calling that “2.0” and calling JAM “3.0” as it risks degrading the gravitas of the major version number months before we might wish to construe, outside of the ecosystem, the seriousness of the change.
I agree that major versions are primarily useful as communicative devices to signal significant improvements.
I think there is one crucial dynamic at play that speaks for signaling to the broader Web3 community that it is worth taking a closer look at Polkadot again: Sentiment towards Polkadot as a whole
While there is widespread agreement that Polkadot concepts and technology are exceptionally advanced, Polkadot is also seen as overly complex and impractical. It is an enormous task for chain developers to make something out of the substrate that they are given and developer support hasn’t been the best in the past. “End users” that have tried Polkadot (in the worst case through Polkadot.js) had bad experiences (and in the worst case have lost funds because they sent DOT to “their” CEX deposit address on AssetHub for which CEXes might deny support) have decided that Polkadot is not for them.
It is on us to mount a turnaround in sentiment and thus the question is how we can achieve it.
It took 7 years from whitepaper to Polkadot 1.0 (5 years to launch the first parachain on Kusama). But Polkadot 1.0 is only the base for parachains. Now it is the job of the ecosystem to make parachains actually buildable and usable and get the early kinks out of the way. Parachains still miss substantial tooling for development, QA, deployment, ops, and insights. All this tooling is developed as we speak and will be what makes Polkadot actually usable to developers and eventually users.
Our job for signaling to the broader Web3 community when to look at Polkadot again should not only revolve around JAM because the launch of JAM will not have a direct relation to when it will be practically usable for the developer and user. After the launch of JAM, we will “just” have a parachains/corechains service and for the outside observer everything will be the same and nothing will be new. Until we see JAM come into action, we will need CorePlay and other services to come live AND then actual constructs come live AND then become practically developable and usable.
It is thus my opinion that we should find a point in time to signal to the broader Web3 community when we have brought the existing parachain model into a state where it is easy, powerful, and fun to build with parachains and when users will have a UX that is judged as good.
The Web3 Foundation is undertaking an enormous campaign to bring Decentralized Futures teams into operations so that we can rewire agents in the ecosystem in a decentralized (and yet effective) manner. The folks at Parity, at the parachain teams, dapp teams, wallet teams, dashboard teams, etc… have spent a lot of work to improve UX, DevEx, and Marketing.
The situation for us out there is tough, as we try to uphold the best of Polkadot every day but have to fight against tendencies of teams leaving the ecosystems and long-standing community members turning their backs. We all believe that we can make Polkadot a success story and that our efforts will pay off.
But what we need is a rallying cry. Similar to the halving, on which you reflected in the Gray Paper interview. We need an opportunity to show off to the world that Polkadot has become better and that everyone should give it another try.
I believe that we need such a random point in time around which everyone can rally very soon. We need new devs, new attention, new community members, and new investments in the ecosystem soon.
Agile Coretime (+ Async Backing + Elastic Scaling) addresses one of the biggest pain points that the Polkadot 1.0 concept exhibited and also already points to a future of a highly efficient Polkadot. It already can offer a set of unique USPs that no other ecosystem can offer (high economic security + monthly guaranteed blockspace + scale to your needs).
Coretime with a finishing touch of Elastic Scaling is a huge thing and we should celebrate it as such.
Can you kindly share your feelings on “License” changes, and if/when that might be appropriate between Polkadot One / Too GNUv3 to Polkadot JAM / Play?
The concern/motivation is that we have seen many Substrate non-Polkadot chains (Avail, Bittensor, Cardano (?) …) with little value capture back to DOT holders in the 1.x era. Many other Web3 ecosystems attempt to capture value with Business Source Licenses (Uniswap, Arbitrum, Aave, Babylon, …) or at least give themselves a multi-year head start.
The desire is that the next wave of JAM / Play innovations have more serious value capture back to DOT holders, and to minimize trivial copycats (BSC, TRON, etc.) from JAM/Play/Solidity-to-PVM and so on. Can you imagine a Business Source License change being justified? Decided by a “Wish-for-Change”?
To echo Tommi’s statements, I believe Polkadot is at its first real crossroads that can signify to the broader crypto ecosystem that it’s no longer the “same old” Polkadot moving forward. There could have been other ways to signal this, but some of the community ran with this idea starting in late 2023 and folded it into a very public narrative about Polkadot 2.0. Trying to put the genie back in the bottle generally doesn’t work, so by creating a coherent story that highlights massive tech improvements, 2.0 can be used as a rallying point for developers, users, and supporters. We’re hoping to show the broader crypto community there are fundamental shifts underway within Polkadot and that they shouldn’t underestimate the community and tech here. Much of crypto is narrative-driven (for better or worse) and I believe 2.0 allows us to create that narrative vs. allowing outside circles to push a “same old” Polkadot story.
I respectfully understand you disagree with me from your high level technical viewpoint! You’re absolutely correct, it’s a Marketing term. Many organizations use these terms to market high achievements, even if not in line with certain debatable standards, in regard to upgrades. Since it has been used in relation to Polkadot it is giving the impression to us “normies” (majority of people) that milestone innovation isn’t currently occurring on Polkadot. As we know this is NOT the case! Everything Alice und Bob mentioned is true. Using roadmap terms like “2.0” signals tiny bits of information that people can easily absorb to explain a bulk upgrade narrative. It also psychologically signals to people to take a deeper dive (deeper look).
Jam being referred to as 3.0 is also an easy roadmap connection. It can have a deep mental connection to the term Web3, making it easier for people to understand and absorb the concept, in its entirety.
I am grateful that you’re doing this work for humanity, translating it for people to understand “why” these terms exist, it’s not an easy task, as we all have different technical competence levels. While I completely understand from your standards this doesn’t seem like a 2.0, for someone like me explaining it to people it does. I hope you can respectfully understand why I see this marketing transition as a useful tool for the mass majority.
Thank you for everything you’re doing and will continue to do! I cried happy tears on some pages of the Gray Paper.
Respectfully,
Hope
I’m very supportive of Tommi’s proposal to add some clarity around the “Polkadot 2.0” nomenclature. We’ve already seen a lot of interest in the term, inside and outside of the eco, because people want to know what the next wave of innovation will look like on Polkadot in the current market cycle. It has marketing utility for this purpose.
Very much understand the concerns around versioning and catering to the ‘marketingese’ nature of it. But like “Dotsama,” it’s already become so broadly used and adopted that the risk of NOT defining it will be that other people will lead this conversation. This is a narrative we can and should wholly own.
To give folks some sense of what I’m talking about, here are some search volume numbers (US-based, for the purposes of giving you a sample).
Searches for “polkadot 2.0” (monthly) = ~140/mo in the US
That’s a small percentage of overall searches for Polkadot (what we can assume are Polkadot Network-related searches, at least) but it shows a pretty strong interest and curiousity about the term and what’s next. Other than price chatter, the only categories where we see more interest than this are “polkadot staking” and “polkadot wallets” which isn’t terribly surprising.
Purely for comparison purposes, here is what the volume looks like for some other Polkadot-related terms (again, US-based just for simplicity)
Part of this, of course, will be promotion – how can we start amplifying some of these other features and storylines so that they get some visibility?
But I’m using this purely as a way to gauge demand and appetite for some very simplistic way to position “the next big wave” of Polkadot, and the 2.0 term does seem to have organic traction.
I think it’s a great idea to define Polkadot 2.0, tie some features to it, and also make it more tangible and discretely deliverable. Otherwise, the folks who are trying to figure out what’s next in this eco are depending on pay-to-play media sources to give them the information they’re looking for:
(pages 1-2ish of “polkadot 2.0” search results)
I don’t expect this will detract from the “holy shit!”-ness of JAM. Everyone I’ve spoken to has very much absorbed the potential impact that JAM could have, and IMO it would be underselling JAM to slap a “3.0” version on it. We (as marketing folks) need to find a better way to communicate just how many leagues ahead of current state JAM will bring us.
But in the meantime, Polkadot 2.0 brings us some much-needed tangibility for talking about the near-term upgrades and I for one am very excited that so many in the community are on board with putting some formality behind it.
Log in to HackMD, then you will
And for your proposal too please
As I say I’m not against using the term 2.0 per se and many of the provided arguments for using “2.0” are quite reasonable. Furthermore the three features that AliceundBob identifies are perfectly good features in their own right. They each make a tangible difference to Polkadot’s builder teams.
My point is simply that the three features which are proposed as “2.0” do not significantly alter the product model of 1.0 but merely make it faster (async backing & elastic scaling) and more streamlined (agile coretime). With them, the Polkadot proposition and network is still largely unchanged: it hosts only parachains, it still has a comparatively large amount of effort to write correctly on, deploy and maintain, still has limited capacity of around 50 slots/cores, benchmarks are still needed, synchronous composability is still not possible between chains, there is still just a single SDK made by a single development team in a single company, and still only one client which runs the whole network. If “2.0” is the big effort to request a re-appraisal of the Polkadot ecosystem, tech and network, then I fear it will be wasted. Furthermore if JAM, something which actually does reimagine what Polkadot’s limitations are, ends up having to be “3.0” to an uninspiring “2.0” then this will surely reduce its potential communications impact.
That all said, I’m not a marketing guru: I fully accept that it’s possible that timing is more important than meaning with naming major versions.
