
Gavin, Founder of Polkadot, Announces Possible Cancellation of Parachain Auctions and Shift Toward Application-Centric Model in Latest Speech
TechFlow Selected TechFlow Selected

Gavin, Founder of Polkadot, Announces Possible Cancellation of Parachain Auctions and Shift Toward Application-Centric Model in Latest Speech
If Polkadot cannot maintain a certain level of resilience against changes in the world, then building Polkadot would be meaningless.
On June 28, Polkadot's annual flagship event, Polkadot Decoded, took place in Copenhagen, Denmark, where Web3 enthusiasts, builders, and investors from around the globe gathered to discuss the latest developments within the Polkadot ecosystem.
One of the most exciting highlights of this conference was undoubtedly the surprise appearance of Polkadot founder Gavin Wood, who delivered a highly significant keynote address.

Gavin shared his vision for Polkadot’s future direction and introduced a new way of understanding Polkadot: moving beyond traditional concepts like parachains and relay chains, focusing instead on the fundamental resources required by blockchains — computational cores (cores), reimagining Polkadot as a multi-core computer.
Furthermore, Polkadot is shifting from a chain-centric model to an application-centric one, aiming to build a resilient platform. The following text is compiled by PolkaWorld based on Gavin’s speech.
Polkadot 1.0
The current stage of Polkadot can be referred to as Polkadot 1.0.
At this stage, Polkadot is functionally complete, having achieved all features outlined in its whitepaper seven years ago, and is about to release the codebase for Polkadot 1.0.
So what exactly is Polkadot 1.0? In the original whitepaper, I wrote that "Polkadot is a scalable heterogeneous multichain." That means it's a blockchain with a unique consensus mechanism called BABE, which provides security for other blockchains (parachains).
Artistically speaking, it looks something like this:

In the center is the relay chain, responsible for Crowdloans, auctions, balance management, staking, governance, etc. It's a feature-rich relay chain. The small dots around it are parachains, whose security is guaranteed by the relay chain. These parachains can also communicate with each other.
What product does Polkadot offer? It comes in the form of slots, leased for six-month periods, with up to two years of slot usage available in advance, combined with the Crowdloan mechanism. Beyond that, there’s no other way to leverage Polkadot. In Polkadot 1.0, the only product available is the parachain slot.
A New Perspective on Polkadot: A Multi-Core Computer

This quote captures an essential truth: to truly understand the world, changing your perspective is crucial — even more so than traveling to distant places.
Therefore, we are now shifting our perspective to redefine what Polkadot really is.
Concepts like parachains and relay chains are useful; they were how I and many others initially understood Polkadot, and what we’ve been striving to build.
But over time, we realized that what we're actually building differs somewhat from our original vision. Sometimes, if you’re lucky or have a strong team, you end up creating something far greater than originally imagined.
In computer science, abstraction and generalization are key. We later discovered that the level of abstraction and generalization we achieved with Polkadot is much higher than previously thought.
So what is this new perspective on Polkadot?
Polkadot Is a Multi-Core Computer
First, what we're actually building isn't about chains per se, but about space — the underlying resources needed by chains.
Second, Polkadot is a platform for builders to create applications and for users to use them. At its core, it’s not a platform for hosting blockchains. Chains happen to be one way to make Polkadot useful, but perhaps not the only way.
Finally, it has strong resilience. I believe this term is more neutral than “unstoppable,” meaning the system resists attempts to make it do things it wasn’t designed for — resisting distortion of its original intent.
Overall, then, Polkadot is a resilient, general-purpose provider of continuous computation. Continuous computation means it’s not just completing isolated tasks and stopping; rather, it supports long-running processes that can pause and resume — similar to the “world computer” vision proposed around 2015–2016.
From this viewpoint, what is Polkadot? It is a multi-core computer, where multiple cores run different tasks simultaneously. When a blockchain runs on one of these cores, it becomes a parachain — essentially a continuously operating chain on a reserved core. This is how we now understand parachains under this new paradigm.
What Does the “Polkadot Supercomputer” Look Like?
Let’s dive deeper into this “Polkadot computer.”

The “Polkadot supercomputer” is multi-core and significantly more powerful than a standard computer. It currently runs around 50 cores in parallel, continuously active.
According to our predictive models, after extensive benchmarking and optimization in the coming years, the number of cores could scale up to 500–1,000.
Performance of Each “Core”

Now let’s examine each individual “core.”
These cores resemble CPU cores. They have various characteristics and attributes — fundamentally, they are computational units much like CPU cores.
-
Bandwidth: total data throughput in and out of the core is approximately 1 MB/s.
-
Underlying compute power: computational capacity, measured at around 380 on Geekbench 5.
-
Latency: interval between two consecutive operations, roughly 6 seconds.
These metrics will improve over time with hardware advancements.
Previously, the only way to utilize these cores was through parachains. But there are other ways to use them — ways that are more inclusive and accessible to everyone.
Polkadot Needs More Flexible Allocation
What does this mean?
Cores are inherently flexible. They don’t need to perform a single fixed task forever; they can easily switch tasks, just like a CPU. Since cores are flexible, acquiring access to them should also be flexible.
The slot auction model lacks flexibility; it was designed under Polkadot’s original paradigm — long-running single chains. Later, parathreads were introduced as a supplement, but this was only a small step toward the right direction.
This model sets a high barrier to entry for the Polkadot ecosystem. If I were someone like myself — a tinkerer who enjoys experimenting with tech — I wouldn’t want to deal with fundraising or marketing; I’d just want to deploy some code and see if it works. Under the current model, we’re likely missing out on many potential collaborators like me.
A Possible Future — Flexible Polkadot
Below, I propose a possible future path — call it “Flexible Polkadot.”
We can abandon the lease and slot model and instead view Polkadot as a collection of “cores.” The time available on these cores — now referred to as “core time” (previously known as “block space”) — could be periodically sold, allowing users to purchase and use core time directly.
My suggestion is this: for primary market sales of native Polkadot core time, we introduce two models — bulk purchases and on-demand purchases.
Bulk purchases would occur once per month, granting usage for 4 weeks.
On-demand purchases work similarly to the pay-as-you-go model of parathreads — usage-based procurement. The cost of using Polkadot — specifically, the cost of using its cores — would fluctuate based on market conditions. There might be several available cores, or none at all — that’s how markets work. For immediate needs, core time would be continuously offered.
In short, we maximize flexibility and let the market decide the rest.
What Does This Mean for Existing Parachains?
-
Existing parachain leases will continue as normal. For example, if you’ve secured a two-year slot, it remains valid.
-
Pricing for bulk purchases will be determined by governance.
-
I personally believe pricing should start low to lower the barrier to entry.
-
We’ll set floor prices, rent controls, and rights of first refusal to ensure long-term price stability. Currently, we guarantee usage for up to two years, but in theory, indefinite renewal could become possible.
Additionally, parachains will gain more flexible block production timing.
Currently, parachains have fixed block times — around 12 seconds, potentially optimized down to 6 seconds. In the future, block intervals could become more dynamic.
Each parachain will have a “base speed”. For instance, a parachain may share a core with one or more others, producing a block every 12 or 18 seconds. When higher throughput is needed, additional core time can be purchased via the instant market or OTC deals on enterprise chains.
Core time can also be compressed (by trading bandwidth for lower latency). Multiple parachain blocks can be packed into a single relay chain block, reducing latency at the cost of increased bandwidth — since you must pay for both block opening and closing.
Core time can also be combined (by adding extra cores to boost performance and reduce latency). You can allocate two concurrent cores to produce two full parachain blocks, cutting block time from 12 seconds to 6, or even down to 3 seconds.
From Chain-Centric to Application-Centric
Polkadot 1.0 follows a chain-centric paradigm: isolated chains can send messages to each other, similar in essence to single chains connected via cross-chain bridges — except here, all parachains connect to the same relay chain. This results in a fragmented user experience. Users may interact with an app on one chain, yet wish to use it on another — adopting a multi-chain approach to applications.
If we maintain a chain-centric paradigm, we inevitably get chain-centric user experiences. When an application isn’t tied to a specific chain, everything becomes harder. To fully unlock Polkadot’s potential, apps need seamless cross-chain deployment — ideally invisible to both users and developers.
Here’s an artistic representation of what “Polkadot looks like” today:

System-level functions are now shifting toward cross-chain deployment. System chains are becoming more common, and the relay chain handles less and less. Applications need to span across these chains without compromising user experience.
This diagram I drew half an hour ago better illustrates my updated understanding of “what Polkadot is.”

Polkadot shouldn’t appear as a central relay chain surrounded by peripheral parachains — at least not to those entering the ecosystem. In reality, Polkadot should be seen as an integrated system — a computer running many applications.
Yes, there are boundaries between business logic components (i.e., parachains), but these may matter less to users than we assume. What matters more is that users can achieve their goals easily, clearly, and quickly.
The dots in the image represent applications. The dashed lines dividing them are “paras” — I avoid saying “parachains” because that invites the mental trap of “one core per parachain.” That’s been Polkadot’s model so far, but it’s not the only option.
Under normal circumstances, these application dots should be able to communicate freely, almost as easily as within the same dashed region.
XCM
How do we achieve this? Enter XCM. XCM is a language, while the actual message transmission layer is called XCMP — admittedly, the names are somewhat confusing.
What does XCM do? It abstracts common functionalities across chains, creating a descriptive language to express intentions — what you want to do or have happen.
In Polkadot, we face similar challenges. XCM is a language of intent. WebAssembly expresses the rules parachains must follow on Polkadot — think of it like the European Court of Justice (ECJ), ensuring parachains adhere to their declared logic. However, this doesn’t prevent a parachain from legally modifying its logic to reject XCM instructions.
XCM expresses intent — e.g., “I intend to transfer assets” or “I intend to vote.” Among mutually trusting system chains, this works fine. But when governance processes and legislative frameworks differ, issues arise. We can do better within the Polkadot ecosystem.
Accord (Agreement)
Here I introduce a new concept: Accord (Agreement). An Accord is a voluntary treaty spanning multiple chains — akin to saying, “I voluntarily commit to this business logic, and nothing I do will alter that commitment.” A chain cannot unilaterally break the logic of an Accord.
Polkadot ensures faithful execution of this logic. Accords apply to specific functions. Any chain joining an Accord must comply with its rules for that function. To keep entry barriers low, proposing an Accord is permissionless. Since participation is voluntary, it doesn’t affect anyone until formally adopted and registered.
This diagram isn’t perfectly precise, but conveys the idea. The outer ring represents Polkadot, containing smaller dots — imagine this laid out horizontally. An Accord is a sovereign, self-governing mechanism ruling over its local domain.

Accords cannot exist in every system. As far as I know, Polkadot is the only system capable of supporting them, due to its uniformly strong security layer and ability to provide specific state transition functions for each shard. These features enable cooperation patterns impossible in other architectures — such as bridge-based systems.
Those familiar with Polkadot may have heard of “SPREE” — SPREE is the technology enabling Accords.
Project CAPI
Briefly, Project CAPI improves the user interface — enabling smooth, high-quality UX for Polkadot applications spanning multiple chains, even when using light clients.
Hermit Relay
This involves migrating all user-level functions from the relay chain to system chains — including balances, staking, governance & identity, and core leasing. Ultimately, Polkadot’s functionality will span multiple parachains, freeing up relay chain capacity.
Building a Resilient Application Platform
In closing, I want to reiterate what we’re building and why. It’s all about resilience. The world keeps changing, but when people have clear intentions, it’s vital those intentions are respected. The systems we currently use lack resilience — they’re built on outdated paradigms.
How do we build a system resistant to such threats? First, build a decentralized, cryptographically secure system grounded in sound game theory. But specifically, what steps do we take?
While we constantly preach “decentralization,” it’s not truly decentralized if everything depends on a single RPC provider. True decentralization requires multiple layers:
- Use of light clients: Smoldot and CAPI will enable high-performance UIs based on light clients.
- ZK primitives: Building a rich, high-performance library of ZK primitives. The first library is nearly complete, offering privacy protection for on-chain collectives (including Fellowship).
- Sassafras consensus: A new leaderless block production consensus algorithm. Enhances security and randomness, enables high-performance transaction routing, improves parachain performance and UX, prevents front-running via encrypted transactions, and unlocks potential MEV benefits.
- Mixnet / onion routing: Prevents leakage of transaction IP information. Acts as a universal messaging system between users, chains, and OCWs.
- Human decentralization: Bringing in diverse participants. Encourage involvement through governance, treasury spending, salaries, grants, and actively preserving collective knowledge.
Finally, I want to reaffirm our初心. Polkadot doesn’t exist to build any single specific application, but to provide a platform where diverse applications can be deployed, interoperate, leverage each other’s capabilities, and ultimately enhance the well-being of users worldwide. And we must ensure this vision is realized as soon as possible — that is Polkadot’s mission.
If Polkadot cannot remain resilient against changes in the world, then building it would be meaningless. These changes include alternative approaches achieving the same ends, or external threats from organizations hostile to trustless systems.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News














