Drift-exploiten raderade ut Carrot. Här är varför din yield farm fortfarande är i riskzonen

Jag har tillbringat de senaste åren med att se folk jaga den högsta möjliga procentuella avkastningen, och ofta ignorerar de helt rörsystemet under protokollet. Den senaste kollapsen av Carrot efter Drift-exploiten är ett skolboksexempel på varför det här är så farligt. Om du försöker förstå hur man identifierar en riskabel yield farm måste du sluta stirra på APY och istället börja titta på beroenden.

Det korta svaret

Kollapsen av Carrot hände på grund av smitta. Carrot hade inte nödvändigtvis någon bugg i sin egen kod, men de förlitade sig på Drift för sin avkastning. När Drift blev exploaterat försvann värdet som backade Carrot. I DeFi-världen är det enkelt: om Protokoll B använder Protokoll A för att tjäna pengar, är Protokoll B bara lika säkert som Protokoll A.

Så fungerade smittan i praktiken

För att förstå det här måste du sluta tänka på DeFi-protokoll som isolerade öar. De är mer som ett korthus. Många yield-optimerare eller "vaults" genererar faktiskt inte sin egen avkastning. Istället tar de dina insättningar och flyttar dem till andra protokoll för att hitta den bästa räntan.

I det här fallet hade Carrot ett tungt beroende av Drift. När Drift-exploiten skedde drabbades inte bara de som hade pengar direkt på Drift. Det skapades ett vakuum. Eftersom Carrots avkastning i princip härstammade från Drifts ekosystem, rasade Carrots underliggande tillgångar eller värdet på deras reward-tokens i samma sekund som Drift föll.

Jag har sett det här mönstret förut. Det är samma logik som drev Terra Luna-kraschen, bara i mindre skala. Du har ett lager av risk, och sedan staplar du ett annat lager av risk ovanpå. Om det understa lagret går sönder faller allt ovanpå.

Där folk går fel

Det största misstaget jag ser är "yield-blindhet". Folk ser 20 % eller 50 % APY och slutar ställa frågor. De antar att protokollet är säkert för att det har en snygg dashboard eller många följare på Twitter.

En annan vanlig missuppfattning är att ett protokoll är "audited" och därför säkert. En audit är bara en ögonblicksbild av koden vid ett specifikt tillfälle. Det skyddar dig inte mot smitta. En granskning av Carrot kanske visade att deras kod var felfri, men det stoppade inte Carrot från att kollapsa när protokollet de satte in pengar i blev hackat.

Så identifierar du riskabla yield farms

Om du vill undvika nästa Carrot behöver du göra lite detektivarbete innan du sätter in dina pengar. Här är vad jag letar efter.

Kolla var avkastningen kommer ifrån

Fråga dig själv: var kommer pengarna egentligen ifrån? Om protokollet säger att de använder "avancerade strategier" betyder det oftast att de placerar dina pengar i andra protokoll. Om du inte hittar en tydlig lista på var medlen förvaras är risken för hög.

Se upp för rekursiva loopar

Var vaksam på protokoll som använder sin egen token som säkerhet för att låna mer av samma token för att farma mer yield. Det skapar en feedback-loop. När priset sjunker utlöses en kaskad av likvidationer som kan radera ut hela systemet på några minuter.

Bedöm beroendekedjan

Jag försöker alltid mappa ut "beroendeträdet". Om jag sätter in pengar i Protokoll X, och Protokoll X sätter dem i Protokoll Y, och Protokoll Y använder en bridge för att flytta dem till Protokoll Z, är jag nu exponerad mot tre olika felkällor. Jag föredrar enklare strategier.

Att sätta det i praktiken

Om du är trött på att jaga yield och bara vill hålla dina kärntillgångar säkra är det bästa draget att flytta dem från börser till cold storage. Jag använder personligen Ledger Nano X eftersom jag kan hantera min portfölj via Bluetooth på mobilen utan att offra säkerheten med en hårdvarusignatur. Det är betydligt svårare att förlora sina livsbesparingar i en smittohändelse när dina privata nycklar inte ligger i en hot wallet eller på en riskabel farm.

Om du fortfarande vill farma bör du bara använda pengar som du är helt okej med att förlora. I min erfarenhet är en "säker" avkastning på 5 % alltid bättre än en "kanske" 50 % som slutar på 0 % efter en exploit.