Crypto infrastructure myth: Why doesn’t it work if they build it?

Author: Saneel Sreeni

Compiled by: TechFlow

The following is a tweet from Jason Yanowitz:

This may be partly inspired by two aspects:

(1) Many of the recently launched Layer-1 blockchains have performed poorly, and

(2) Highlighted success of Hyperliquid and HyperEVM

For readers who don’t understand the crypto field, Hyperliquid is a decentralized perpetual contract and spot trading platform that quickly dominates the market, even surpassing some centralized exchanges. They launched their own high-speed EVM blockchain based on the successful trading platform. As of this writing, Hyperliquid has a market capitalization of approximately US$11 billion and a fully diluted valuation (FDV) of US$33 billion.

Hyperliquid is one of the first cases to successfully guide the development of the new Layer-1 blockchain through its main revenue source application. I generally agree with Jason. However, most new Layer-1 blockchains did not have the same advantages as Hyperliquid when they started; its founder Jeff previously operated one of the best high-frequency trading companies in the crypto field and had sufficient financial reserves to avoid the need to rely on external financing.

So, I have put forward some alternative ideas about the strategy and marketing (GTM) of the new Layer-1 blockchain and building applications on it, especially when taking more traditional paths like venture capital financing and building completely new infrastructure (if your Layer-1 blockchain does not have significant functional differentiation, just mimicking other projects, these suggestions may not work for you).

My perspective is based primarily on my field experience at Ritual and a close observation of other Layer-1 blockchain strategies and executions with a strong ecosystem. I'm still learning so I may modify my views in the future.

Anyway, here are some of my opinions:

Actively guide vs. "If you build it, someone will come"

"Build and they'll come" is a strategic thinking that is common in the crypto field before 2021, and the infrastructure was far from enough at that time. At the heart of this philosophy, if you build a new chain or Layer-2 (L2), the developer will come spontaneously, trying to attract new users and capture value through the tokens of your chain. This strategy worked for a time because chains with excellent technology and investment value were very scarce at that time, and the infrastructure field also enjoyed a long-term premium. However, over time, this premium gradually fades away, especially as a large number of new chains lack practical use and appeal (most of which are just imitations or forks) emerge.

Obviously, this strategy is no longer working now, at least for new blockchain projects. One of the few ecosystems that have successfully implemented this strategy recently is HyperEVM, but even so, its success is not entirely due to this strategy. The success of HyperEVM is primarily dependent on Hyperliquid Core (exchange) as its core application, creating real value for $HYPE holders and the Hype ecosystem (and allowing many active users before Token Generation Events (TGE) to gain wealth).

In contrast, we now see a large number of Layer-1 (L1) and Layer-2 (L2) projects adopt this idea from the beginning, believing that the shortcomings can be made up through the issuance of subsidies and simple brand promotion, but ultimately failed.

That being said, building "anything" is hard. Building infrastructure is difficult, and developing applications is also difficult. Especially in the field of encryption, building is not just about deploying code—and there is also a lot of supporting work to be done, including marketing (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 rather than a simple forked project), this is both a huge technical challenge and a huge marketing (GTM) task. No one can be completely sure what a "killer app" will be, so your job is to build a good product and work with developers to support the birth of high-quality apps as much as possible, thereby maximizing the possibility of success for your Layer-1 and developers who trust you.

This means the following options for infrastructure teams:

• Form a stronger team to do everything internally, including developing top-level applications:

This method may work, but there are the following problems:

• (a) Excellent talents are difficult to find.
• (b) Recruiting good talents internally means more money needs to be raised from investors, and investors are not buying it now. (I know Hyperliquid did it all with 10 people, but most founders don’t have the advantages and resources they had when they started out like Jeff. Even so, they were crazy.)
• Not only do you need to hire engineers, but you also need to recruit talent specialized in GTM, operations, marketing and legal affairs. While there may be cross-platform collaboration opportunities after scale, this will take a long time to achieve, especially since there may be huge differences between each application.
• Follow the old path of "building will bring someone" + issue a large number of development subsidies:

This strategy is usually used by some "subsidy hunters" with mediocre team strength and lack of differentiation in applications, and the effect is not good in the long run.

• Actively guide ecological development:

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

Developers want to see that you are not just talking, but really investing time and energy. Ultimately, no one knows its potential better in the early stages of the project than anyone who develops the infrastructure. In this way, you can:

(a) Showcase new and attractive applications;

(b) demonstrate the possibility that can be achieved on your infrastructure;

(c) Have a certain influence in the direction of promoting ecological development, not just by issuing funds.

Now, the (3) approach still requires the talent in building applications internally, but it is more of an active practice designed to help build real protocols from scratch without requiring a large investment in resources or affecting improvements in core infrastructure. Functionally, it's almost like providing platform support or incubation for these companies.

Could this approach be a more difficult, slower path? Yes. But I think it's a more long-term oriented approach for projects that are still refining their core infrastructure/in the early stages. This is exactly what we’re taking at Ritual, building the apps we want to see on Ritual through projects like Ritual Shrine and think that these apps can be killer applications in the crypto and artificial intelligence spaces.

But it’s not just us – Solana had a lot of active building activities in her early days working with FTX, Jump and some other teams. Several new projects that are popular on crypto-twitter (CT), such as Plasma, MegaETH, Monad, etc., have taken an active approach to create a core set of protocols native to their ecosystems based on existing protocols.

I expect this to be a dominant strategy (and add to the difficulty of really standing out above technical work).

In some cases, I hope we can fully build many Ritual Shrine prototypes internally and operate them on our own. But I also recognize that these projects require dedicated teams to succeed in product and GTM execution (these teams may be more market-friendly than we do, even if we have one of the most powerful cross-functional teams in the field, I think).

It's still a win if we can build alongside these teams while providing strong financial returns to external developers. This allows us to “own” it in a metaphorical sense while introducing new perspectives and new talent.

In short: Yes, it's great if you can have top-notch first-party apps on your new infrastructure. But if resources are limited, then try to actively guide your ecosystem in the form of prototypes and build it with them instead of lazily treating the process.