From "Too Early" to "Just Right": Polkadot Is Welcoming Its Perfect Timing!

Hello everyone, thank you for attending this talk, and thanks to each of you who came to Sub0 today.

My name is Nico Arevalo, and I am the co-founder of Velocity Labs. Velocity Labs is an ecosystem growth and product incubation studio focused on Polkadot. We are core contributors to Polkadot, provide BD services for DeFi and infrastructure within the ecosystem, and also have our own product and engineering teams.

Today, I want to share three topics with you: the reconstruction of DeFi infrastructure, the advantages brought by scalability, and why specialized chains are rising so rapidly.

In recent years, the focus of DeFi has mostly been on the "product layer"—which, in a sense, is reasonable, as we have long lacked a product-oriented mindset. But the industry often swings to extremes: when all our attention is on products, important changes happening at the infrastructure layer are easily overlooked.

Today, I want to guide you to re-examine the profound changes occurring at this layer.

Today's agenda includes:

• The current state of DeFi infrastructure 
• We will discuss the inflection point that general-purpose chains are currently facing 
• We will talk about what the moat of "specialization" is in today's DeFi world 
• In this context of specialization, what role does "sovereignty" play, since now there are more choices than two or three years ago 
• Finally, we will discuss Polkadot's position in this landscape 

Why can't the current DeFi architecture support millions of users?

Let's start with the current state of DeFi. I think Dean's previous talk has already set the stage well for my main point—the user experience in DeFi is still very poor.

On one hand, L1s lack network effects, so many things have to be built from scratch; on the other hand, L2s fragment liquidity, splitting it more and more.

As deep crypto users, we may have gotten used to these inconveniences, but the reality is:

• Transaction fees are volatile, 
• The tokens used to pay transaction fees are themselves volatile. 

For applications, these are two fluctuating cost variables, equivalent to a company's "cost of sales" constantly changing, making it very difficult to build a sustainable business model under such conditions.

Even worse, under go-to-market and growth pressures, projects are forced to deploy on all chains simultaneously, opening "multi-chain stores" for users, liquidity, and revenue.

Additionally, developers in most cases prioritize building infrastructure over creating truly user-facing products.

Finally, the most critical layer in the infrastructure stack—the assets themselves—also faces the same problem: they are almost required to exist on all chains, but not every chain supports native assets. As a result, we see wrapped tokens and native tokens mixed across different chains.

In summary, although we have made progress, with this kind of user experience, we cannot achieve the "millions of users on-chain" that we have been talking about for years.

The Trend from General-Purpose Chains to Specialized Chains

Currently, general-purpose chains are at a very obvious inflection point.

Looking back at the DeFi Summer of 2020–2023, general-purpose chains almost played the role of the industry's testing ground: deploying applications was the easiest, testing ideas was the fastest, and it was easiest to see what worked and what didn't. But this model is now changing rapidly.

First, there is a clear oversupply of block space, and most—if not all—of this block space is almost indistinguishable from each other. Of course, there are technical differences between high-quality and low-quality block space, which I will mention later; but from the perspective of applications, they are almost "homogeneous resources."

Therefore, general-purpose L1s and L2s are being forced to differentiate through GTM (go-to-market) and execution strategies, rather than relying on technology itself to create a gap.

For this reason, I believe we are already at the end of this cycle! In the past, there were new L2s launching every week, but this phenomenon will significantly decrease in the future.

My personal judgment is that the last batch of L2s will be MONAD and MEGA ETH, both of which are taking a "retro-style" path, with one focusing on ultra-fast block times. So we will see the number of such new chains gradually decrease.

Another important change that must be mentioned is: those general-purpose smart contract platforms that once achieved widespread adoption in crypto are now beginning to face competition from specialized chains.

For example:

• Solana: With the rise of Hyperliquid, a large amount of trading volume and activity that originally belonged to Solana is migrating to Hyperliquid. 
• Ethereum: As the main issuance chain for DeFi, it is also starting to feel competition from stablecoin chains and RWA specialized chains. Although the degree is lighter, the trend is very clear. 

Stablecoins, Perpetual Contracts, RWA... Forcing Blockchains Towards Specialization

Why are "specialized chains" becoming the new moat?

For those familiar with Polkadot's architecture, this may not be difficult to understand; but for the broader crypto community, this is not so obvious.

The reason is simple: different application scenarios require completely different infrastructure capabilities.

For example:

• Stablecoin chains require monetary policy-level compliance and control capabilities; 
• Perpetual contract DEXs require deterministic latency, extremely fast block times, and high-priority oracle channels; 
• AMMs need predictable order flow (rather than block space itself) and effective MEV mitigation; 
• RWA chains must have comprehensive asset on/off-chain logic, compliance mechanisms, and privacy protection features. 

These needs simply cannot be fully met by general-purpose smart contract chains.

Next, I want to discuss some deeper examples. Stablecoin chains are a new narrative that has emerged recently, and those following this track should be familiar. Their development took some time to truly take shape, and their real traction after launch remains to be seen.

However, several noteworthy chains have already appeared:

• Tempo (a collaboration between Paradigm + Stripe) 
• Arc (from Circle) 
• Plasma (from USDT) 
• Codex (similarly supported by Ethereum USDC) 
• Stable (strongly supported by Tether) 

What are these chains mainly optimizing for?

• Fast finality and short block times, which are essential for stablecoin-centric payment scenarios. 
• Optional privacy protection features
• Stablecoin-denominated transaction fees, allowing users to pay gas directly with stablecoins in the future. 
• Compliance capabilities
• Block space reserved for payment behavior priority

Clearly, these chains are all customizing infrastructure around specific scenarios and redesigning their system architecture based on the needs of those scenarios.

Another typical category is perpetual contract specialized chains (Perp DEX Chains).

Noteworthy projects include: HyperLiquid, Lighter, Bullet, Astar—these chains are fiercely competing in the perpetual contract market.

Their requirements are also very clear:

• Fast finality 
• Extremely short block times 
• Healthy and stable order flow 
• MEV-aware handling of "order placement vs. execution" at the protocol layer 
• No fees for placing/canceling orders 
• On-chain order books 
• Heavy reliance on oracles 

These requirements form a very clear and highly specialized set of technical demands, and it is precisely these needs that are driving the rise of "specialized chains."

In the Wave of Specialization, Developers' Choices: Independent Chain or Ecosystem Chain?

In this new stage, what does "sovereignty" really mean, and what role does it play?

As I have repeatedly emphasized, the market has very clearly shifted toward "specialization." But within the specialization framework, should developers—whether application or chain developers—choose to build a completely independent chain, or integrate into a mature ecosystem? There is currently no one-size-fits-all answer.

In fact, these two paths are not mutually exclusive. The crypto industry is essentially about building various tools, and different teams need different tools.

I want to build a judgment framework: who is suitable for which set of tools?

We will discuss Polkadot's position in this paradigm later. But before that, we need to roughly divide teams into two extremes:

① Large teams with abundant resources

These teams have several obvious characteristics:

First, they usually have their own distribution channels—this is the most critical point. They do not rely on the existing user base of Ethereum or Solana, nor do they need to leverage the liquidity of these ecosystems; they can attract users from Web2 or outside the crypto community.

Second, they are not afraid of technical challenges. On one hand, they have abundant resources and do not need to rush to capture the market; on the other hand, ample funding allows them to withstand a longer go-to-market cycle without runway pressure.

Third, they place great importance on complete control over the technology stack.

Take Tempo as an example—it is clearly unafraid of technical challenges. We have already seen some institutions that are not traditional protocol development teams. For example, Paradigm and Circle have begun actively acquiring teams with core protocol development and consensus design capabilities.

Tempo recently made a large strategic investment in Commonwealth; Circle acquired Strange Labs, which comes from the Cosmos ecosystem and previously worked at ConsenSys.

These moves show that they are willing to invest significant resources because they see a high enough return on investment.

② Small, experimental startup teams with limited resources

On the other end are smaller, less funded startup teams:

First, they must build a user base from scratch, so they are highly dependent on the existing user base of the deployment location. Building traffic from zero is almost impossible.

Second, with limited resources and short time to market, they need to leverage existing infrastructure as much as possible. For example, not having to build their own oracles, explorers, or cross-chain bridges can greatly speed up their launch.

They are also more inclined to rely on interoperability, outsourcing non-core services such as identity, certain basic capabilities, and engineering components; and they do not have the ability, nor will they attempt, to build their own economic security layer.

Typical examples include:

• Codex (stablecoin chain) 
• Katana (DeFi specialized chain deployed on Polygon) 
• Bob (chain built on Bitcoin) 

As you can see, the market has actually formed a clear distinction between these two extremes, and this distinction comes from the vastly different product needs of different teams. The blockchain ecosystem should also be able to meet these needs in different ways.

From "Too Early" to "Just Right": Polkadot's Second Right Timing

Many people will say: Polkadot actually had these capabilities very early on.

Looking back at history, Acala was one of the earliest stablecoin chains. Many people may not realize that it was one of the first chains to natively embed stablecoins at the protocol layer and build a complete service system around them.

Polkadot was also one of the earliest blockchains to design for trading scenarios in a specialized way.

The problem was: we were "too early."

At least in my view, at that time we provided tools for entrepreneurs, but those who used these tools were mostly "experimental, resource-limited" teams—the second type of team I mentioned earlier. And Polkadot at that time did not provide the necessary network effects that an ecosystem should have.

In other words:

• Higher technical barriers compared to smart contract applications 
• Longer time to market 
• Lack of mature infrastructure 
• Lack of an existing user base 

So, where is Polkadot today?

I am very confident about this.

In the past few years, we have focused our main efforts on solving the hardest problems: scalability, decentralization, and interoperability. In these areas, we already have mature, stable, and battle-tested tools.

And now, we can finally go back and address those things that should have been done at an earlier stage: ensuring that people building products on Polkadot can truly succeed.

This is the meaning of Polkadot Hub, at least in my view.

The core purpose of Polkadot Hub is to fill in the "basic capabilities" that the ecosystem has been missing, allowing Polkadot to catch up with the basic facilities provided by other mature ecosystems:

• Infrastructure 
• Liquidity 
• Direct user-facing entry points 

Once these basic capabilities are in place, they will in turn strengthen Polkadot's existing product matrix.

Our North Star goal is clear: to enable excellent teams to quickly launch and succeed on Polkadot, and to provide the smoothest path for their future migration to independent parachains or connected parachains.

I believe the future of Polkadot is very bright.

We are taking the right actions to drive the adoption and growth we hope to see in Polkadot and the entire DeFi field.

Of course, everything still needs time to be proven.

Original video: https://www.youtube.com/watch?v=l3oAR08plBw