Myter om kryptoinfrastruktur: Varför fungerar det inte att "bygga och de kommer"?

Ursprunglig författare: Saneel Sreeni

Ursprunglig sammanställning: Deep Tide TechFlow

Följande är en tweet från Jason Yanowitz:

kan delvis inspireras av två saker:

(1) många av de nyligen lanserade Layer-1-blockkedjorna underpresterar, och

(2) Enastående framgång för Hyperliquid- och HyperEVMFör-läsare

som inte är bekanta med kryptorymden, Hyperliquid är en decentraliserad plattform för löpande kontrakt och spothandel som snabbt har dominerat marknaden och till och med överträffat vissa centraliserade börser. De lanserade sin egen höghastighets EVM-blockkedja baserad på framgången med handelsplattformen. I skrivande stund har Hyperliquid ett börsvärde på cirka 11 miljarder dollar och en fullt utspädd värdering (FDV) på 33 miljarder dollar.

Hyperliquid är ett av de första fallen som framgångsrikt leder utvecklingen av en ny Layer-1-blockkedja genom sin primära intäktsströmsapp. Jag håller i stort sett med Jason. De flesta nya Layer-1-blockkedjor börjar dock inte med samma fördelar som Hyperliquid; Dess grundare, Jeff, drev tidigare ett av de bästa högfrekvenshandelsföretagen i kryptorymden och har gott om reserver av medel för att undvika behovet av att förlita sig på extern finansiering.

Som ett resultat har jag kommit på några idéer om strategi och go-to-market (GTM) för nya Layer-1-blockkedjor och alternativa idéer för att bygga applikationer ovanpå dem, särskilt när man tar mer traditionella vägar som riskkapitalfinansiering och bygger helt ny infrastruktur (om din Layer-1-blockkedja inte har betydande funktionell differentiering och helt enkelt efterliknar andra projekt, kanske dessa förslag inte fungerar för dig).

Mina åsikter är till stor del baserade på min erfarenhet på plats på Ritual, samt nära observation av strategin och genomförandet av andra Layer-1-blockkedjor med starka ekosystem. Jag lär mig fortfarande, så jag kan komma att revidera mina åsikter i framtiden.

Sammanfattningsvis, här är några av mina uppfattningar:

Proaktiv bootstrapping kontra "

Bygg och de kommer" var ett strategiskt tankesätt som var utbrett i kryptorymden före 2021, när infrastrukturen var långt ifrån tillräcklig. Kärnan i denna filosofi är att om du bygger en ny kedja eller Layer-2 (L2) kommer utvecklare spontant och försöker locka nya användare och fånga värde genom din kedjas tokens. Denna strategi fungerade under en tid, eftersom det vid den tiden var ont om tekniskt sunda kedjor med investeringsvärde och infrastruktursektorn åtnjöt en långsiktig premie. Men med tiden försvinner denna premium, särskilt som ett stort antal nya kedjor saknar praktisk användning och attraktionskraft för applikationer (varav de flesta bara är imitationer eller gafflar).

Uppenbarligen fungerar denna strategi inte längre, åtminstone för nya blockchain-projekt. Ett av de få ekosystem som nyligen framgångsrikt har genomfört denna strategi är HyperEVM, men även då beror dess framgång inte helt på denna strategi. Framgången för HyperEVM är starkt beroende av Hyperliquid Core (utbyte) som en kärnapplikation, vilket skapar verkligt värde för innehavare av $HYPE och Hype-ekosystemet (och berikar många aktiva användare före Token Generation Event (TGE)).

Däremot ser vi nu ett stort antal Layer-1 (L1) och Layer-2 (L2) projekt som anammar detta tankesätt från början och tror att de kan kompensera för bristerna genom att dela ut bidrag och rent varumärke, men i slutändan misslyckas.

Med det sagt är det svårt att bygga "någonting". Det är svårt att bygga infrastruktur och det är svårt att utveckla applikationer. Särskilt i kryptorymden handlar byggande inte bara om att distribuera kod – det finns mycket arbete att göra, inklusive go-to-market (GTM), drift, regelefterlevnad med mera, som ofta underskattas.

När du bygger en Layer-1-blockkedja (förutsatt att du bygger en helt ny arkitektur snarare än ett enkelt gaffelprojekt) är det både en enorm teknisk utmaning och en enorm go-to-market-uppgift (GTM). Ingen kan vara helt säker på vad en "killer app" kommer att vara, så det är ditt jobb att bygga produkten och arbeta med utvecklare för att stödja födelsen av högkvalitativa appar så mycket som möjligt för att maximera sannolikheten för framgång för din Layer-1 och de utvecklare som litar på dig.

Detta innebär flera alternativ för infrastrukturteam:

• Samla ett starkare team och gör allt internt, inklusive att utveckla applikationer på toppnivå:

  Detta tillvägagångssätt kan fungera, men det har följande problem:

• (a) Bra talanger är svåra att hitta.

• (b) Intern rekrytering av de bästa talangerna innebär att mer pengar måste samlas in från investerare, vilket investerare inte köper idag. (Jag vet att Hyperliquid gjorde allt med 10 personer, men de flesta grundare har inte styrkorna och resurserna för att komma igång som Jeff.) Trots det var deras prestation galen.

• Du behöver inte bara anställa ingenjörer, utan du måste också anställa personer som är specialiserade på GTM, drift, marknadsföring och juridik. Även om det kan finnas möjligheter till plattformssamarbete i stor skala, kommer detta att ta lång tid att materialisera, särskilt eftersom varje app kan variera dramatiskt.

• Följ den gamla vägen med "bygg det och någon kommer" + dela ut en massa utvecklingsbidrag:

Denna strategi används vanligtvis av vissa "bidragsjägare" med mediokra team och brist på applikationsdifferentiering, och det fungerar inte bra i längden.

• Aktivt leda ekosystemet:

Jag innebär att ta ett mer proaktivt tillvägagångssätt genom att bygga prototyper eller några lätta applikationer ovanpå din infrastruktur och arbeta med andra utvecklare/partners för att driva dessa applikationer till full användning.

Utvecklare vill se att du inte bara pratar, utan faktiskt lägger ner din tid och ansträngning på det. När allt kommer omkring finns det ingen som förstår potentialen i denna infrastruktur bättre än de människor som har utvecklat den. På så sätt kan du:

(a) visa upp nya och engagerande applikationer;

(b) visa sannolikheten för att det är möjligt att uppnå på din infrastruktur;

c) ha ett visst inflytande i den ekologiska utvecklingens riktning, och inte bara genom fördelningen av medel.

Nu kräver metod (3) fortfarande stor talang för att skapa applikationer internt, men det är mer av en proaktiv praxis som är utformad för att hjälpa till att bygga ett verkligt protokoll från grunden utan att kräva betydande resursinvesteringar eller påverka förbättringar av kärninfrastrukturen. Funktionellt sett är det nästan som att tillhandahålla plattformsstöd eller inkubation för dessa företag.

Kan detta tillvägagångssätt vara en svårare, långsammare väg? Ja. Men jag tror att det är ett mer långsiktigt tillvägagångssätt för projekt som fortfarande håller på att förfina sin kärninfrastruktur/är i ett tidigt skede. Det är detta tillvägagångssätt som vi har använt på Ritual och byggt appar som vi vill se på Ritual med projekt som Ritual Shrine som vi tror kan bli mördarappar inom krypto och AI.

Men det är inte bara vi – Solana hade mycket aktiv byggaktivitet i början när hon arbetade med FTX, Jump och några andra team. Flera nya projekt som är populära på krypto Twitter (CT), som Plasma, MegaETH, Monad och andra, har tagit ett proaktivt tillvägagångssätt för att skapa en kärnuppsättning protokoll som är inbyggda i deras ekosystem ovanpå befintliga protokoll.

Jag förväntar mig att detta kommer att bli en dominerande strategi (och öka svårigheten att verkligen sticka ut på toppen av det tekniska arbetet).

I vissa fall önskar jag att vi kunde skapa prototyper av många rituella helgedomar internt och driva dem själva. Men jag inser också att dessa projekt kräver dedikerade team för att lyckas med produkt- och GTM-utförandet (vilket kan passa bättre för marknaden än vad vi är, även om vi har vad jag anser vara ett av de starkaste tvärfunktionella teamen inom området).

Om vi kan bygga sida vid sida med dessa team samtidigt som vi ger starka ekonomiska belöningar till externa utvecklare är det fortfarande en vinst. Detta gör att vi kan "äga" det i bildlig mening, samtidigt som vi introducerar nya perspektiv och nya talanger.

Kort sagt, kort sagt: ja, det är bra om du kan ha förstklassiga förstapartsappar på din nya infrastruktur. Men om resurserna är begränsade kan du försöka att aktivt styra ditt ekosystem i form av prototyper och bygga med dem, snarare än att lata dig i processen.