
The Myth of Crypto Infrastructure: Why "Build It and They Will Come" Doesn't Work
TechFlow Selected TechFlow Selected

The Myth of Crypto Infrastructure: Why "Build It and They Will Come" Doesn't Work
Building "anything" is hard.
Author: Saneel Sreeni
Translation: TechFlow
The following is a tweet by Jason Yanowitz:

This idea may have been partially inspired by two factors:
(1) The underperformance of many recently launched Layer-1 blockchains, and
(2) The standout success of Hyperliquid and HyperEVM
For readers unfamiliar with crypto, Hyperliquid is a decentralized perpetuals and spot trading platform that rapidly gained market dominance—even surpassing some centralized exchanges. Building on the success of its trading platform, it launched its own high-speed EVM blockchain. At the time of 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 examples of successfully bootstrapping a new Layer-1 blockchain through a primary revenue-generating application. I largely agree with Jason’s perspective. However, most new Layer-1 projects don’t start with the same advantages as Hyperliquid—its founder Jeff previously ran one of the top high-frequency trading firms in crypto and had ample capital reserves, eliminating reliance on external funding.
Therefore, I’d like to offer some alternative thoughts on strategy and go-to-market (GTM) for new Layer-1 blockchains, as well as application development on them—especially when taking more traditional paths such as venture funding and building entirely new infrastructure. (These suggestions may not apply if your Layer-1 lacks meaningful functional differentiation and is merely copying other projects.)
My views are primarily based on hands-on experience at Ritual, along with close observation of strategies and execution from other Layer-1 ecosystems with strong developer traction. I’m still learning, so my opinions may evolve over time.
In short, here are my thoughts:
Active Bootstrapping vs. "Build and They’ll Come"
"Build and they’ll come" was a prevailing strategic mindset in crypto before 2021, when infrastructure was severely lacking. The core idea was simple: if you build a new chain or Layer-2 (L2), developers will naturally come, attempt to attract users, and capture value via your chain’s token. This approach worked for a while because technically superior, investable chains were scarce, and the infrastructure sector enjoyed long-term premium valuations. Over time, however, that premium faded—especially as numerous new chains emerged with little real usage and applications that were mostly copies or forks of existing ones.
Clearly, this strategy no longer works—at least not for new blockchain projects. One of the few recent ecosystems to successfully execute it is HyperEVM, but even then, its success wasn’t solely due to this model. HyperEVM's traction stemmed primarily from Hyperliquid Core (the exchange) serving as a killer app, creating real value for $HYPE holders and the broader Hype ecosystem—and making many active pre-TGE users wealthy.
In contrast, we now see many Layer-1 (L1) and Layer-2 (L2) projects starting with this passive mindset, believing generous grants and brand marketing alone can compensate for lack of substance—only to fail in the end.
That said, building “anything” is hard. Building infrastructure is hard. Building applications is hard. In crypto especially, building isn't just about deploying code—it also involves massive amounts of often-underestimated work around GTM, operations, legal compliance, and more.
When building a Layer-1 blockchain (assuming you're creating novel architecture, not just forking), you face both a major technical challenge and a significant go-to-market (GTM) task. No one truly knows what the “killer app” will be, so your job is to build the product and collaborate closely with developers to support the emergence of high-quality applications—maximizing success potential for both your L1 and the developers who trust you.
This leaves infrastructure teams with several options:
-
Assemble a stronger team and do everything in-house, including building top-tier apps:
This could work, but comes with issues:
-
(a) Top talent is hard to find.
-
(b) Hiring top internal talent requires raising more funds from investors—who are currently uninterested in this model. (I know Hyperliquid pulled this off with just 10 people, but most founders don’t have Jeff’s starting advantages and resources. Even so, their execution was insane.)
-
You need not only engineers but also dedicated GTM, operations, marketing, and legal hires. While cross-platform synergies might exist at scale, achieving them takes a long time—especially given how different each application can be.
-
-
Go the old "build and they’ll come" route + heavy grant distribution:
This strategy tends to attract mediocre teams and “grant hunters” with undifferentiated apps, leading to poor long-term outcomes.
-
Actively bootstrap the ecosystem:
I mean taking a more proactive approach—building prototypes or lightweight apps on your infrastructure and co-developing them into full-scale products alongside external developers/partners.
Developers want to see that you’re not just talking, but actually investing time and effort. Ultimately, in the early stages, no one understands the potential of your infrastructure better than its builders. By doing this, you can:
(a) Showcase compelling new applications;
(b) Demonstrate what’s possible on your stack;
(c) Exert influence over ecosystem direction—not just through funding, but through active participation.
Now, the third approach still requires strong in-house app-building talent, but it functions more like hands-on practice: helping to build real protocols from scratch without requiring massive resource allocation or distracting from core infrastructure improvements. Functionally, it resembles platform support or incubation for these emerging projects.
Is this path potentially harder and slower? Yes. But I believe it’s a more sustainable, long-term-oriented strategy—especially for projects still refining their core infrastructure or in early stages. This is exactly the approach we’re taking at Ritual, building applications like Ritual Shrine that we hope will become killer apps at the intersection of crypto and AI.
And we’re not alone—Solana actively collaborated with FTX, Jump, and others during its early days. Several newer projects gaining traction on Crypto Twitter (CT), such as Plasma, MegaETH, Monad, etc., have taken proactive approaches, creating native core protocol suites built atop existing systems.
I expect this to become the dominant strategy—and increase the difficulty of truly standing out beyond just technical work.
In an ideal world, I’d love to build and operate many Ritual Shrine prototypes entirely in-house. But I also recognize that these projects require dedicated teams focused on product and GTM execution—teams that may be better positioned than us to succeed in the market (even though we believe we have one of the strongest cross-functional teams in the space).
If we can co-build with these teams while offering strong economic incentives to external developers, that’s still a win. It allows us to metaphorically “own” the outcome while bringing in fresh perspectives and new talent.
In summary: yes, having top-tier first-party apps on your new infrastructure is great. But if resources are limited, focus instead on actively guiding ecosystem growth through prototypes—building alongside others rather than passively waiting.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News













