Originally Posted by: Saneel Sreeni
Original translation: TechFlow
Here’s a tweet from Jason Yanowitz:
This may be partly inspired by the following two aspects:
(1) Many recently launched Layer-1 blockchains have performed poorly, and
(2) The outstanding success of Hyperliquid and HyperEVM
For readers who are not familiar with the crypto space, Hyperliquid is a decentralized perpetual contract and spot trading platform that has quickly become dominant in the market, even surpassing some centralized exchanges. They launched their own high-speed EVM blockchain based on the success of the trading platform. As of this writing, Hyperliquid has a market cap of approximately $11 billion and a fully diluted valuation (FDV) of $33 billion.
Hyperliquid is one of the first cases of a new Layer-1 blockchain that successfully bootstrapped its development through an application that was its primary source of revenue. I generally agree with Jasons point of view. However, most new Layer-1 blockchains do not have the advantages that Hyperliquid had when they started; its founder Jeff previously ran one of the best high-frequency trading companies in the crypto space and had sufficient financial reserves to avoid the need to rely on external financing.
Therefore, I offer some alternative ideas about strategy and go-to-market (GTM) for new layer-1 blockchains and applications built on them, especially when taking more traditional paths such as venture capital financing and building entirely new infrastructure (if your layer-1 blockchain has no significant functional differentiation and is simply imitating other projects, these suggestions may not work for you).
My opinions are based primarily on my on-the-ground 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 opinions in the future.
Anyway, here are some of my thoughts:
Proactive Guidance vs. “Build it and they will come”
Build and theyll come was a strategic mindset that was prevalent in the crypto space before 2021, when infrastructure was far from adequate. The core of this philosophy is that if you build a new chain or Layer-2 (L2), developers will come spontaneously to try to attract new users and capture value through your chains tokens. This strategy worked for a while because technically excellent and investment-worthy chains were very scarce at the time, and the infrastructure sector also enjoyed a long-term premium. However, over time, this premium has gradually disappeared, especially with the emergence of a large number of new chains that lack actual use and attractive applications (most of the applications on the chain are just imitations or forks).
Obviously, this strategy no longer works today, 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 due to this strategy. HyperEVMs success mainly relies on Hyperliquid Core (the exchange) as the core application, creating real value for $HYPE holders and the Hype ecosystem (and making many active users before the Token Generation Event (TGE) rich).
In contrast, we now see a large number of Layer-1 (L1) and Layer-2 (L2) projects adopting this approach from the beginning, thinking that they can make up for the shortcomings through grants and pure branding, but ultimately fail.
That being said, building “anything” is hard. Building infrastructure is hard, and building applications is hard. Especially in crypto, building is not just about deploying code — there is a lot of supporting work that needs to be done, including go-to-market (GTM), operations, legal compliance, etc., which are often underestimated.
When you build a Layer-1 blockchain (assuming you are building a completely new architecture, not a simple forked project), it is both a huge technical challenge and a huge go-to-market (GTM) task. No one is completely sure what the killer app will be, so your job is to build a good product and work with developers to support the birth of high-quality applications as much as possible, thereby maximizing the possibility of success for your Layer-1 and the developers who trust you.
This means several options for infrastructure teams:
Build a stronger team and do everything in-house, including developing top-notch apps:
This approach may work, but it has the following problems:
(a) Good talent is hard to find.
(b) Hiring great people internally means raising more money from investors, and investors today are not buying into this. (I know Hyperliquid did it with 10 people, but most founders don’t have the advantages and resources that Jeff had when they started. Even so, their performance is insane.)
Not only do you need to hire engineers, you also need to hire people dedicated to GTM, operations, marketing, and legal. While there may be cross-platform synergy opportunities after scale, it will take a long time to achieve, especially because each app may be very different.
Following the old path of build it and they will come + massive development subsidies:
This strategy is often used by “subsidy hunters” with mediocre teams and undifferentiated applications, and it does not work well in the long run.
Actively guide ecological development:
What I mean is taking a more proactive approach by 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 the talk, but are actually investing time and effort. At the end of the day, in the early days of a project, no one understands the potential of the infrastructure better than the people who are developing it. This way, you can:
(a) Demonstrate new and attractive applications;
(b) demonstrate that it is feasible on your infrastructure;
(c) Have a certain influence on the direction of ecological development, rather than just guiding it by distributing funds.
Now, approach (3) still requires having great talent in-house to build applications, but this is more of a proactive practice designed to help build real protocols from scratch without requiring a large investment of resources or impacting core infrastructure improvements. Functionally, this is almost like providing platform support or incubation for these companies.
Is this approach likely to be the harder, slower path? Yes. But I think it’s a more long-term oriented approach for projects that are still rounding out their core infrastructure/are in the early stages. We’re taking exactly this approach at Ritual, with projects like Ritual Shrine to build the applications we want to see on Ritual and think can be the killer apps in crypto and AI.
But it’s not just us — Solana has had a lot of active building activity early on with FTX, Jump, and a few other teams. Several new projects trending on Crypto Twitter (CT), like Plasma, MegaETH, Monad, and others, have taken an aggressive approach to creating core sets of protocols native to their ecosystems on top of existing protocols.
I expect this to become a dominant strategy (and increase the difficulty of truly standing out above the technical jobs).
At some point, I wish we could build many of the Ritual Shrine prototypes completely in-house and run them ourselves. But I also recognize that these projects require dedicated teams to succeed in product and GTM execution (teams that may be better suited to the market than we are, even though we have what I consider to be one of the strongest cross-functional teams in the space).
If we can build alongside these teams while providing strong financial rewards to external developers, that’s still a win. It lets us “own” it metaphorically while bringing in new perspectives and new talent.
Anyway, in short: yes, it’s great if you can have top 1st party apps on your new infrastructure, but if resources are limited, then work hard to actively lead your ecosystem with prototypes, build with them, and don’t be lazy about it.
