Myter om kryptoinfrastruktur: Hvorfor fungerer ikke "bygg og de kommer"?

Forfatter: Saneel Sreeni

Kompilator: Deep Tide TechFlow

Følgende er en tweet fra Jason Yanowitz:

kan delvis være inspirert av følgende to ting:

(1) Mange av de nylig lanserte Layer-1-blokkjedene har underprestert, og

(2) den enestående suksessen til Hyperliquid og HyperEVM

For lesere som ikke er kjent med kryptoområdet, er Hyperliquid en desentralisert evigvarende kontrakts- og spothandelsplattform som raskt har dominert markedet, til og med overgått noen sentraliserte børser. De lanserte sin egen høyhastighets EVM-blokkjede basert på suksessen til handelsplattformen. I skrivende stund har Hyperliquid en markedsverdi på omtrent 11 milliarder dollar og en fullt utvannet verdsettelse (FDV) på 33 milliarder dollar.

Hyperliquid er et av de første tilfellene som lykkes med å lede utviklingen av en ny Layer-1-blokkjede gjennom sin primære inntektsstrøm-app. Jeg er generelt enig med Jason. De fleste nye Layer-1-blokkjeder starter imidlertid ikke med de samme fordelene som Hyperliquid; Grunnleggeren, Jeff, drev tidligere et av de beste høyfrekvente handelsfirmaene i kryptoområdet og har rikelig med reserver for å unngå behovet for å stole på ekstern finansiering.

Som et resultat har jeg kommet opp med noen ideer om strategi og go-to-market (GTM) for nye Layer-1-blokkjeder og alternative ideer for å bygge applikasjoner på toppen av dem, spesielt når du tar mer tradisjonelle veier som venturekapitalfinansiering og bygger helt ny infrastruktur (hvis Layer-1-blokkjeden din ikke har betydelig funksjonell differensiering og bare etterligner andre prosjekter, kan det hende at disse forslagene ikke fungerer for deg).

Mine synspunkter er i stor grad basert på min erfaring på bakken hos Ritual, samt nøye observasjon av strategien og utførelsen av andre Layer-1-blokkjeder med sterke økosystemer. Jeg lærer fortsatt, så jeg kan revidere synspunktene mine i fremtiden.

Oppsummert, her er noen av mine takes:

Proaktiv bootstrapping vs. "

Bygg og de kommer" var en strategisk tankegang som var utbredt i kryptoområdet før 2021, da infrastrukturen var langt fra tilstrekkelig. Kjernen i denne filosofien er at hvis du bygger en ny kjede eller Layer-2 (L2), vil utviklere komme spontant og prøve å tiltrekke seg nye brukere og fange verdi gjennom kjedens tokens. Denne strategien fungerte en tid, fordi teknologisk sunne kjeder med investeringsverdi var knappe på den tiden, og infrastruktursektoren nøt en langsiktig premie. Men over tid forsvinner denne premien, spesielt ettersom et stort antall nye kjeder mangler praktisk bruk og appell til applikasjoner (hvorav de fleste bare er imitasjoner eller gafler).

Åpenbart fungerer ikke denne strategien lenger, i hvert fall ikke for nye blokkjedeprosjekter. Et av få økosystemer som nylig har utført denne strategien er HyperEVM, men selv da skyldes ikke suksessen utelukkende denne strategien. Suksessen til HyperEVM er sterkt avhengig av Hyperliquid Core (utveksling) som en kjerneapplikasjon, og skaper reell verdi for $HYPE-innehavere og Hype-økosystemet (og beriker mange aktive brukere før Token Generation Event (TGE)).

Derimot ser vi nå et stort antall Layer-1 (L1) og Layer-2 (L2)-prosjekter som har tatt denne tilnærmingen fra starten, og tror at de kan gjøre opp for manglene ved å dele ut tilskudd og ren merkevarebygging, men til slutt mislykkes.

Når det er sagt, er det vanskelig å bygge "noe". Det er vanskelig å bygge infrastruktur, og det er vanskelig å utvikle applikasjoner. Spesielt i kryptoområdet handler bygging ikke bare om å distribuere kode – det er mye arbeid som må gjøres, inkludert go-to-market (GTM), drift, juridisk overholdelse og mer, som ofte undervurderes.

Når du bygger en Layer-1-blokkjede (forutsatt at du bygger en helt ny arkitektur i stedet for et enkelt gaffelprosjekt), er det både en stor teknisk utfordring og en enorm go-to-market (GTM)-oppgave. Ingen kan være helt sikre på hva en "killer-app" vil være, så det er din jobb å bygge produktet og samarbeide med utviklere for å støtte fødselen av apper av høy kvalitet så mye som mulig for å maksimere sannsynligheten for suksess for Layer-1 og utviklerne som stoler på deg.

Dette betyr flere alternativer for infrastrukturteam:

1. Sett sammen et sterkere team og gjør alt internt, inkludert utvikling av applikasjoner på toppnivå:

   Denne tilnærmingen kan fungere, men den har følgende problemer:

   1. (a) Gode talenter er vanskelig å finne.

   2. (b) Intern rekruttering av de beste talentene betyr at det må skaffes mer penger fra investorer, som investorer ikke kjøper i dag. (Jeg vet at Hyperliquid gjorde alt med 10 personer, men de fleste gründere har ikke styrkene og ressursene til å komme i gang som Jeff.) Likevel var opptredenen deres vanvittig.

   3. Ikke bare trenger du å ansette ingeniører, men du må også ansette folk som spesialiserer seg på GTM, drift, markedsføring og juss. Selv om det kan være muligheter for samarbeid på tvers av plattformer i stor skala, vil dette ta lang tid å materialisere seg, spesielt siden hver app kan variere dramatisk.

2. Følg den gamle veien med «bygg det og noen vil komme» + gi ut mange utviklingstilskudd:

Denne strategien brukes vanligvis av noen «tilskuddsjegere» med middelmådige team og mangel på applikasjonsdifferensiering, og den fungerer ikke bra i det lange løp.

1. Aktivt lede økosystemet:

Jeg mener å ta en mer proaktiv tilnærming ved å bygge prototyper eller noen lette applikasjoner på toppen av infrastrukturen din og samarbeide med andre utviklere/partnere for å drive disse applikasjonene i full bruk.

Utviklere vil se at du ikke bare snakker, men faktisk legger tid og krefter i det. Til syvende og sist er det ingen som forstår potensialet til denne infrastrukturen bedre enn menneskene som utviklet den. På denne måten kan du:

(a) vise frem nye og engasjerende applikasjoner;

(b) demonstrere sannsynligheten for at det er oppnåelig på infrastrukturen din;

(c) Ha en viss innflytelse i retning av økologisk utvikling, og ikke bare gjennom fordeling av midler.

Nå krever tilnærming (3) fortsatt store talenter internt for å bygge applikasjoner, men det er mer en proaktiv praksis designet for å hjelpe til med å bygge en virkelig protokoll fra grunnen av uten å kreve en betydelig investering av ressurser eller påvirke forbedringer av kjerneinfrastrukturen. Funksjonelt er det nesten som å tilby plattformstøtte eller inkubasjon for disse selskapene.

Kan denne tilnærmingen være en vanskeligere, langsommere vei? Ja. Men jeg tror det er en mer langsiktig tilnærming for prosjekter som fortsatt foredler kjerneinfrastrukturen sin/er i de tidlige stadiene. Det er denne tilnærmingen vi har tatt i Ritual, og bygger apper som vi ønsker å se på Ritual med prosjekter som Ritual Shrine som vi tror kan være fantastiske apper innen krypto og AI.

Men det er ikke bare oss – Solana hadde mye aktiv byggeaktivitet i de første dagene da de jobbet med FTX, Jump og noen få andre team. Flere nye prosjekter som er populære på krypto-Twitter (CT), som Plasma, MegaETH, Monad og andre, har tatt en proaktiv tilnærming til å lage et kjernesett med protokoller som er hjemmehørende i økosystemet deres på toppen av eksisterende protokoller.

Jeg forventer at dette vil bli en dominerende strategi (og øke vanskeligheten med å virkelig skille seg ut på toppen av det tekniske arbeidet).

I noen tilfeller skulle jeg ønske at vi kunne prototype mange rituelle helligdommer internt og drive dem selv. Men jeg erkjenner også at disse prosjektene krever dedikerte team for å lykkes med produkt- og GTM-utførelse (som kan passe bedre for markedet enn vi er, selv om vi har det jeg anser for å være et av de sterkeste tverrfunksjonelle teamene på feltet).

Hvis vi kan bygge side om side med disse teamene samtidig som vi gir sterke økonomiske belønninger til eksterne utviklere, er det fortsatt en seier. Dette lar oss "eie" det i overført betydning, samtidig som vi introduserer nye perspektiver og nye talenter.

Kort sagt: ja, det er flott hvis du kan ha førsteklasses førstepartsapper på den nye infrastrukturen din. Men hvis ressursene er begrenset, så prøv å aktivt veilede økosystemet ditt i form av prototyper, bygg med dem, i stedet for å late nærme deg prosessen.