The Myth of Crypto Infrastructure: Why "If You Build It, They Will Come" Doesn't Work?

Author: Saneel Sreeni

Compiled by: Deep Tide TechFlow

The following content is a tweet by Jason Yanowitz:

This may be partially inspired by two factors:

(1) The poor performance of many recently launched Layer-1 blockchains, and

(2) The outstanding success of Hyperliquid and HyperEVM.

For readers unfamiliar with the crypto space, Hyperliquid is a decentralized perpetual contract and spot trading platform that has quickly dominated the market, even surpassing some centralized exchanges. They launched their own high-speed EVM blockchain based on the success of their trading platform. As of the writing of this article, Hyperliquid has a market cap of approximately $11 billion, with a fully diluted valuation (FDV) of $33 billion.

Hyperliquid is one of the first cases where a new Layer-1 blockchain's development has been successfully guided by its primary revenue-generating application. I generally agree with Jason's viewpoint. However, most new Layer-1 blockchains do not have the advantages that Hyperliquid possesses at the outset; its founder Jeff previously operated one of the best high-frequency trading firms in the crypto space and has ample capital reserves, avoiding the need to rely on external financing.

Therefore, I propose some alternative ideas regarding the strategies and go-to-market (GTM) approaches for new Layer-1 blockchains and building applications on them, especially when adopting more traditional paths like venture capital funding and building entirely new infrastructure (if your Layer-1 blockchain does not have significant functional differentiation and merely mimics other projects, these suggestions may not be applicable to you).

My perspective is primarily based on my hands-on experience at Ritual and close observation of the strategies and execution of other Layer-1 blockchains with strong ecosystems. I am still learning, so I may revise my views in the future.

In summary, here are some of my thoughts:

Proactive Guidance vs. "Build it and they will come"

"Build it and they will come" was a prevalent strategic mindset in the crypto space before 2021, when infrastructure was severely lacking. The core of this idea is that if you build a new chain or Layer-2 (L2), developers will spontaneously come, trying to attract new users and capture value through your chain's tokens. This strategy once worked because there were very few technically excellent and investment-worthy chains, and the infrastructure space enjoyed a long-term premium. However, over time, this premium has gradually disappeared, especially with the emergence of numerous new chains lacking actual usage and attractive applications (most applications on these chains are merely imitations or forks).

Clearly, this strategy is no longer effective, at least for new blockchain projects. One of the few ecosystems that has successfully executed this strategy recently is HyperEVM, but even so, its success is not entirely attributable to this strategy. HyperEVM's success primarily relies on Hyperliquid Core (the exchange) as its core application, creating real value for $HYPE holders and the Hype ecosystem (and allowing many active users before the token generation event (TGE) to gain wealth).

In contrast, we now see a large number of Layer-1 (L1) and Layer-2 (L2) projects adopting this mindset from the start, believing they can compensate for shortcomings through grant distributions and mere brand promotion, but ultimately failing.

That said, building "anything" is hard. Building infrastructure is difficult, and developing applications is also challenging. Especially in the crypto space, building is not just about deploying code—there is a lot of supporting work to be done, including go-to-market (GTM), operations, legal compliance, etc., which are often underestimated.

When you are building a Layer-1 blockchain (provided that you are building a completely new architecture and not just a simple fork), it is both a massive technical challenge and a huge go-to-market (GTM) task. No one can be entirely sure what the "killer application" will be, so your job is to build a good product and work with developers to support the emergence of high-quality applications as much as possible, thereby maximizing the chances of success for your Layer-1 and the developers you trust.

This means several options for infrastructure teams:

• Build a stronger team to do everything in-house, including developing top applications:

This approach may be effective, but it has the following issues:

• (a) Finding excellent talent is difficult.
• (b) Recruiting top talent internally means needing to raise more funds from investors, which they are currently reluctant to do. (I know Hyperliquid accomplished this with 10 people, but most founders do not have the advantages and resources that Jeff had at the start. Even so, their performance is nothing short of insane.)
• You not only need to hire engineers but also need to recruit people specifically responsible for GTM, operations, marketing, and legal affairs. While there may be cross-platform synergies after scaling, it takes a long time to achieve this, especially since there can be significant differences between applications.
• Follow the old path of "build it and they will come" + distribute a large number of development grants:

This strategy is often exploited by some mediocre teams with undifferentiated applications, known as "grant hunters," and tends to perform poorly in the long run.

• Actively guide ecosystem development:

What I mean is to take a more proactive approach by building prototypes or some lightweight applications on your infrastructure and collaborating with other developers/partners to drive the full implementation of these applications.

Developers want to see that you are not just talking the talk but are genuinely investing time and effort. Ultimately, in the early stages of a project, no one knows the potential of this infrastructure better than the people building it. By doing this, you can:

(a) Showcase attractive new applications;

(b) Prove the possibilities that can be achieved on your infrastructure;

(c) Have some influence in guiding the direction of ecosystem development, rather than just directing through funding.

Now, the third method still requires having excellent talent internally to build applications, but it is more like a proactive practice aimed at helping to build real protocols from scratch without needing a large resource investment or affecting improvements to the core infrastructure. Functionally, it is almost like providing platform support or incubation for these companies.

Is this method potentially a more difficult and slower path? Yes. But I believe it is a more long-term oriented approach for projects that are still refining their core infrastructure/are in the early stages. This is precisely the approach we are taking at Ritual, building the applications we hope to see on Ritual through projects like Ritual Shrine, believing these applications can become killer applications in the fields of crypto and artificial intelligence.

But it's not just us—Solana had many positive building activities early on when collaborating with FTX, Jump, and other teams. Several new projects that have gained popularity on Crypto Twitter (CT), such as Plasma, MegaETH, Monad, etc., have taken proactive approaches to create their ecosystem's native core protocol set based on existing protocols.

I expect this to become a dominant strategy (and increase the difficulty of truly standing out above the technical work).

In some cases, I hope we can fully build many Ritual Shrine prototypes internally and operate them ourselves. But I also recognize that these projects need dedicated teams to succeed in product and GTM execution (these teams may be better suited to the market than we are, even though we have what I believe is one of the strongest cross-functional teams in the field).

If we can build alongside these teams while providing strong economic returns to external developers, that would still be a win. This allows us to "own" it in a metaphorical sense while bringing in new perspectives and new talent.

In summary, to put it simply: yes, it would be great if you could have top first-party applications on your new infrastructure. But if resources are limited, then strive to actively guide the development of your ecosystem in the form of prototypes, building alongside them rather than treating the process lazily.