The following content is a tweet from Jason Yanowitz:
This may be partially inspired by the following two aspects:
(1) Many recently launched Layer-1 blockchains have performed poorly, and
(2) The notable success of Hyperliquid and HyperEVM
For readers unfamiliar with the cryptocurrency space, Hyperliquid is a decentralized perpetual contract and spot trading platform that has quickly dominated the market, even surpassing some centralized exchanges. They have launched their own high-speed EVM blockchain based on the success of their trading platform. As of the time of writing this article, Hyperliquid's market capitalization is approximately $11 billion, with a fully diluted valuation (FDV) of $33 billion.
Hyperliquid is one of the first cases to successfully guide the development of new Layer-1 blockchains through its main revenue-generating application. I largely agree with Jason's point of view. However, most new Layer-1 blockchains do not have the advantages that Hyperliquid had at the start; its founder Jeff previously operated one of the best high-frequency trading firms in the crypto space and has ample financial reserves, avoiding the need to rely on external financing.
Therefore, I have proposed some strategies and go-to-market (GTM) ideas for new Layer-1 blockchains and alternative thoughts on building applications on them, especially when adopting more traditional paths such as venture capital financing 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 effective for you).
My perspective is mainly 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 modify my views in the future.
In summary, here are some of my views:
Proactive guidance vs. "If you build it, they will come"
"Build and they'll come" was a strategic mindset that was prevalent in the crypto space prior to 2021, when the infrastructure was far from adequate. At the heart of this philosophy is that if you build a new chain or Layer-2 (L2), developers will spontaneously come and try to attract new users and capture value through your chain's tokens. This strategy worked for a time, as technologically sound chains with investment value were scarce at the time, and the infrastructure sector enjoyed a long-term premium. However, over time, this premium fades away, especially as a large number of new chains lack practical use and appeal for applications (most of which are just imitations or forks).
Clearly, this strategy no longer works today, at least for new blockchain projects. One of the few ecosystems that has recently successfully implemented this strategy is HyperEVM, but even so, its success cannot be solely attributed to this strategy. HyperEVM's success mainly 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 approach from the very beginning, believing that they can make up for shortcomings through the issuance of grants and simple brand promotion, but ultimately they have failed.
That said, building "anything" is difficult. Building infrastructure is hard, and developing applications is also challenging. Especially in the crypto space, building is not just as simple as deploying code—there's a significant amount of supporting work to be done, including go-to-market (GTM) strategies, operations, legal compliance, etc., which is often underestimated.
When you are building a Layer-1 blockchain (provided that you are building a brand new architecture and not just a simple fork project), this is both a huge technical challenge and a massive go-to-market (GTM) task. No one can be entirely sure 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 as much as possible, thereby maximizing the chances of success for your Layer-1 and the developers you trust.
This means the following options for the infrastructure team:
Build a stronger team to accomplish everything in-house, including developing top-tier applications:
This method may be effective, but there are the following problems:
(a) Excellent talent is hard to find.
(b) Internal recruitment of outstanding talent means needing to raise more funds from investors, and nowadays investors are not buying into it. (I know Hyperliquid accomplished all this with 10 people, but most founders do not have the advantages and resources at the start like Jeff does. Even so, their performance can only be described as crazy.)
You not only need to hire engineers, but also recruit talents specifically responsible for GTM, operations, marketing, and legal affairs. While there may be cross-platform synergies after scaling, it will take a long time to achieve this, especially since there may be significant differences between each application.
Follow the old path of "build it and they will come" + issue a large number of development subsidies:
This strategy is often exploited by some teams with mediocre strength and a lack of differentiation in their applications, and it does not yield good results in the long run.
Proactively guide ecological development:
What I mean is to take a more proactive approach by building prototypes or some lightweight applications on your infrastructure, collaborating with other developers/partners to promote the comprehensive implementation of these applications.
Developers want to see that you are not just talking the talk, but truly investing time and effort. After all, in the early stages of a project, no one knows its potential better than the people who are building the infrastructure. In this way, you can:
(a) showcases an attractive new application;
(b) proof of the possibilities that can be realized on your infrastructure;
(c) has a certain influence in promoting the direction of ecological development, not just by guiding through the distribution of funds.
Now, the (3) method still requires excellent talent internally to build applications, but this is more like a proactive practice aimed at helping to build real protocols from scratch, without the need for a large resource investment or affecting improvements in core infrastructure. Functionally, it is almost like providing platform support or incubation for these companies.
Is this method possibly a more difficult and slower path? Yes. But I think for projects that are still refining their core infrastructure / in the early stages, this is a more long-term oriented approach. This is precisely the approach we are taking at Ritual, building the applications we hope to see on Ritual through projects like Ritual Shrine, and we believe these applications can become killer apps in the fields of cryptocurrency and artificial intelligence.
But it's not just us—Solana had a lot of positive building activities early on while collaborating 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 their ecosystem's native core protocol set based on existing protocols.
I expect this will 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 prototypes of the Ritual Shrine internally and operate them ourselves. But I also recognize that these projects require specialized 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 for external developers, that would still be a victory. It allows us to "own" it in a metaphorical sense while bringing in new perspectives and new talent.
In short, to put it simply: yes, it’s great if you can have top-tier first-party applications on your new infrastructure. But if resources are limited, then you should strive to actively guide the development of your ecosystem in prototype form, building together with them, rather than being lazy about the process.
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Encryption infrastructure myth: Why does "If we build it, they will come" not work?
Author: Saneel Sreeni
Compiled by: Deep Tide TechFlow
The following content is a tweet from Jason Yanowitz:
This may be partially inspired by the following two aspects:
(1) Many recently launched Layer-1 blockchains have performed poorly, and
(2) The notable success of Hyperliquid and HyperEVM
For readers unfamiliar with the cryptocurrency space, Hyperliquid is a decentralized perpetual contract and spot trading platform that has quickly dominated the market, even surpassing some centralized exchanges. They have launched their own high-speed EVM blockchain based on the success of their trading platform. As of the time of writing this article, Hyperliquid's market capitalization is approximately $11 billion, with a fully diluted valuation (FDV) of $33 billion.
Hyperliquid is one of the first cases to successfully guide the development of new Layer-1 blockchains through its main revenue-generating application. I largely agree with Jason's point of view. However, most new Layer-1 blockchains do not have the advantages that Hyperliquid had at the start; its founder Jeff previously operated one of the best high-frequency trading firms in the crypto space and has ample financial reserves, avoiding the need to rely on external financing.
Therefore, I have proposed some strategies and go-to-market (GTM) ideas for new Layer-1 blockchains and alternative thoughts on building applications on them, especially when adopting more traditional paths such as venture capital financing 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 effective for you).
My perspective is mainly 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 modify my views in the future.
In summary, here are some of my views:
Proactive guidance vs. "If you build it, they will come"
"Build and they'll come" was a strategic mindset that was prevalent in the crypto space prior to 2021, when the infrastructure was far from adequate. At the heart of this philosophy is that if you build a new chain or Layer-2 (L2), developers will spontaneously come and try to attract new users and capture value through your chain's tokens. This strategy worked for a time, as technologically sound chains with investment value were scarce at the time, and the infrastructure sector enjoyed a long-term premium. However, over time, this premium fades away, especially as a large number of new chains lack practical use and appeal for applications (most of which are just imitations or forks).
Clearly, this strategy no longer works today, at least for new blockchain projects. One of the few ecosystems that has recently successfully implemented this strategy is HyperEVM, but even so, its success cannot be solely attributed to this strategy. HyperEVM's success mainly 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 approach from the very beginning, believing that they can make up for shortcomings through the issuance of grants and simple brand promotion, but ultimately they have failed.
That said, building "anything" is difficult. Building infrastructure is hard, and developing applications is also challenging. Especially in the crypto space, building is not just as simple as deploying code—there's a significant amount of supporting work to be done, including go-to-market (GTM) strategies, operations, legal compliance, etc., which is often underestimated.
When you are building a Layer-1 blockchain (provided that you are building a brand new architecture and not just a simple fork project), this is both a huge technical challenge and a massive go-to-market (GTM) task. No one can be entirely sure 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 as much as possible, thereby maximizing the chances of success for your Layer-1 and the developers you trust.
This means the following options for the infrastructure team:
Build a stronger team to accomplish everything in-house, including developing top-tier applications:
This method may be effective, but there are the following problems:
(a) Excellent talent is hard to find.
(b) Internal recruitment of outstanding talent means needing to raise more funds from investors, and nowadays investors are not buying into it. (I know Hyperliquid accomplished all this with 10 people, but most founders do not have the advantages and resources at the start like Jeff does. Even so, their performance can only be described as crazy.)
You not only need to hire engineers, but also recruit talents specifically responsible for GTM, operations, marketing, and legal affairs. While there may be cross-platform synergies after scaling, it will take a long time to achieve this, especially since there may be significant differences between each application.
Follow the old path of "build it and they will come" + issue a large number of development subsidies:
This strategy is often exploited by some teams with mediocre strength and a lack of differentiation in their applications, and it does not yield good results in the long run.
Proactively guide ecological development:
What I mean is to take a more proactive approach by building prototypes or some lightweight applications on your infrastructure, collaborating with other developers/partners to promote the comprehensive implementation of these applications.
Developers want to see that you are not just talking the talk, but truly investing time and effort. After all, in the early stages of a project, no one knows its potential better than the people who are building the infrastructure. In this way, you can:
(a) showcases an attractive new application;
(b) proof of the possibilities that can be realized on your infrastructure;
(c) has a certain influence in promoting the direction of ecological development, not just by guiding through the distribution of funds.
Now, the (3) method still requires excellent talent internally to build applications, but this is more like a proactive practice aimed at helping to build real protocols from scratch, without the need for a large resource investment or affecting improvements in core infrastructure. Functionally, it is almost like providing platform support or incubation for these companies.
Is this method possibly a more difficult and slower path? Yes. But I think for projects that are still refining their core infrastructure / in the early stages, this is a more long-term oriented approach. This is precisely the approach we are taking at Ritual, building the applications we hope to see on Ritual through projects like Ritual Shrine, and we believe these applications can become killer apps in the fields of cryptocurrency and artificial intelligence.
But it's not just us—Solana had a lot of positive building activities early on while collaborating 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 their ecosystem's native core protocol set based on existing protocols.
I expect this will 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 prototypes of the Ritual Shrine internally and operate them ourselves. But I also recognize that these projects require specialized 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 for external developers, that would still be a victory. It allows us to "own" it in a metaphorical sense while bringing in new perspectives and new talent.
In short, to put it simply: yes, it’s great if you can have top-tier first-party applications on your new infrastructure. But if resources are limited, then you should strive to actively guide the development of your ecosystem in prototype form, building together with them, rather than being lazy about the process.