The following content is a tweet by Jason Yanowitz:
This may be partially inspired by the following two aspects:
(1) Many recently launched Layer-1 blockchain networks are currently underperforming, and
(2) The outstanding success of Hyperliquid and HyperEVM
For readers unfamiliar with the crypto field, 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 time of writing, Hyperliquid's market cap is around $11 billion, with a fully diluted valuation (FDV) of $33 billion.
Hyperliquid is one of the first cases where a primary revenue-generating application successfully guided the development of a new Layer-1 blockchain. I largely agree with Jason's perspective. However, most new Layer-1 blockchains do not have the same advantages as Hyperliquid at the start; its founder Jeff previously operated one of the best high-frequency trading companies in the crypto space and had sufficient funding reserves, avoiding the need for external financing.
Therefore, I propose some alternative ideas about strategies and go-to-market (GTM) for new Layer-1 blockchains and building applications on them, especially when taking a more traditional path such as venture capital financing and building entirely new infrastructure (these suggestions may be ineffective if your Layer-1 blockchain lacks significant functional differentiation and merely mimics other projects).
My views are primarily based on my hands-on experience at Ritual and close observation of strategies and execution of other Layer-1 blockchains with robust ecosystems. I am still learning and may modify my perspectives in the future.
In summary, here are my thoughts:
Proactive Guidance vs. "Build and They Will Come"
"Build and they will come" was a strategic mindset prevalent in the crypto field before 2021 when infrastructure was far from sufficient. The core of this idea was that if you build a new chain or Layer-2 (L2), developers would spontaneously come to try to attract new users and capture value through the chain's token. This strategy once worked because technologically excellent and investment-worthy chains were extremely rare, and the infrastructure field enjoyed long-term premiums. However, over time, this premium gradually disappeared, especially with the emergence of numerous new chains lacking practical use and attractive applications (most chain applications were merely imitations or forks).
Clearly, this strategy no longer works, at least for new blockchain projects. One of the few ecosystems that recently successfully executed this strategy is HyperEVM, but even then, its success was not entirely due to this strategy. HyperEVM's success primarily relied on Hyperliquid Core (the exchange) as its core application, creating actual value for $HYPE holders and the Hype ecosystem (and generating wealth for many active users before the token generation event).
In contrast, we now see numerous Layer-1 (L1) and Layer-2 (L2) projects adopting this approach from the beginning, believing they can compensate for shortcomings through grants and simple brand promotion, but ultimately failing.
That said, building "anything" is difficult. Building infrastructure is hard, and developing applications is hard. Especially in the crypto field, building is not simply deploying code - there are numerous accompanying tasks including go-to-market, operations, legal compliance, etc., which are often underestimated.
When building a Layer-1 blockchain (premise being you're building a completely new architecture, not a simple fork), it's both a massive technical challenge and a huge go-to-market task. No one can definitively predict what the "killer app" will be, so your job is to build a good product and collaborate with developers to support the birth of high-quality applications, thereby maximizing the chances of success for your Layer-1 and the developers who trust you.
This means infrastructure teams have the following options:
1. Assemble a stronger team and complete everything internally, including developing top-tier applications:
This approach might work but has the following issues:
(a) Excellent talent is hard to find.
(b) Internal recruitment of top talent means needing to raise more funds from investors, who are not receptive to this nowadays. (I know Hyperliquid accomplished this with 10 people, but most founders don't have Jeff's initial advantages and resources. Even so, their performance was crazy.)
You not only need to hire engineers but also recruit talent specifically for go-to-market, operations, marketing, and legal affairs. While cross-platform synergy opportunities might exist after scaling, this takes a long time to achieve, especially because applications might differ dramatically.
2. Follow the old "build and they will come" path + massive development grants:
This strategy is usually exploited by mediocre teams with undifferentiated applications, and its long-term effect is not good.
3. Actively guide ecosystem development:
By this, I mean taking a more proactive approach by building prototypes or lightweight applications on your infrastructure, collaborating with other developers/partners to comprehensively implement these applications.
Developers want to see that you're not just talking but truly investing time and effort. Fundamentally, in the early stages of a project, no one understands its potential better than those developing the infrastructure. Through this approach, you can:
(a) Showcase attractive, novel applications;
(b) Demonstrate possibilities achievable on your infrastructure;
(c) Have some influence in driving ecosystem development, rather than just guiding through funding.
Now, approach (3) still requires internal talent capable of building applications, but it's more of an active practice aimed at helping build real protocols from scratch without massive resource investment or affecting core infrastructure improvements. Functionally, it's almost like providing platform support or incubation for these companies.
Is this potentially a more difficult and slower path? Yes. But I believe for projects still refining their core infrastructure/in early stages, this is a more long-term oriented method. At Ritual, we're adopting this approach by building projects like Ritual Shrine to construct applications we hope to see on Ritual and believe could be killer apps in crypto and AI.
But it's not just us - Solana had many proactive building activities when collaborating with FTX, Jump, and other teams in the early stages. Several new projects popular on Crypto Twitter (CT), such as Plasma, MegaETH, Monad, etc., have taken an active approach, building their ecosystem's native core protocol set on existing protocols.
I anticipate this will become a leading strategy (and increase the difficulty of truly standing out on top of technical work).
In a certain sense, I hope we could completely prototype and self-operate many Ritual Shrine internally. But I also recognize that these projects need dedicated teams to succeed in product and GTM execution (these teams might be more market-suited than us, 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 rewards for external developers, that would still be a victory. This allows us to "own" it metaphorically while introducing new perspectives and new talent.
In summary, briefly: yes, it's great if you can have top-tier first-party applications on your new infrastructure. But if resources are limited, you should actively guide your ecosystem development through prototypes, build together with them, rather than treating this process lazily.
