Alla dina Uniswap v3-likviditetsberäkningar är helt fel! Här är varför

2 x 2 = 5

Du vet att det är fel, men när du först ser det, gissar du dig själv och tänker: "Kanske är något fel med min beräkning". Höger?

Tja, det var precis så jag kände när jag upptäckte att likviditets- och TVL-siffrorna (Total Value Locked) som visas på Uniswap V3-användargränssnittet var helt fel.

Uniswap är det största decentraliserade finansprojektet ( DeFi ) på Ethereum och hela blockchain- industrin. Tusentals likviditetsleverantörer använder dessa siffror dagligen för att bygga sina investeringsstrategier. Så hur kan dessa siffror vara felaktiga?

Jag har ägnat timmar åt att försöka hitta ett misstag i mina beräkningar, och gissa vad? Jag gjorde inga misstag. Och situationen är ännu värre än bara felaktig TVL.

Men låt oss gå steg för steg och börja med problemet.

Problemet

För det första, vad är TVL och hur används det? Kort sagt, TVL defi som ett dollarvärde av alla kryptotillgångar som för närvarande delegerats av användare till en blockkedja eller protokoll. Till exempel kan dessa tillgångar vara den totala likviditeten för en decentraliserad börs, brygga eller utlåningsprotokoll, eller totala insatta tillgångar i PoS blockchain.

Kryptomarknadsinvesterare och andra deltagare använder TVL i flera fall:

1. Bedömning av protokollets hälsa. Det är därför populära protokoll har sin TVL på huvudsidan. Större TVL = mer användarförtroende = lägre risk = stabil vinst.
2. Jämförelse mellan protokoll. Om jag var en kryptohandlare skulle jag föredra att använda DeFi verktyg, som decentraliserade utbyten eller bryggor, med högre TVL.
3. Mätning av protokolltillväxt. Investerare som ser att ett protokolls eller projekts TVL växer snabbt anser det vara en signal att vara hausse om protokollets symboliska pris.

Det verkar som att det är viktigt att veta exakta TVL-nummer, eller hur?

Men vad händer om jag säger att den mest tillgängliga informationen om Uniswap v3 TVL är missvisande? Den största överraskningen för mig var dock att den officiella Uniswap Chart-appen också är ett problem! Så här fick jag reda på det.

Jag arbetade på ett likviditetsanalysprojekt, där jag jämförde officiella data om Uniswap v3 med mina beräkningar med hjälp av rå blockchain-data. Detta steg är avgörande för att uppfylla de högsta datakvalitetsstandarderna. För att påbörja verifieringen valde jag en populär likviditetspool, USDC-WETH (0,3 % avgiftsnivå).

Titta på pool 3 på Uniswap v3 – den har en imponerande TVL på $333m (baserat på Uniswap officiella listor i skrivande stund) och en hälsosam daglig volym på $61m.

Omedelbart stötte jag på ett problem: mitt beräknade TVL-värde var $176 miljoner istället för de $333 miljoner som rapporterades på Uniswap-webbplatsen. Ok, så det händer buggar. Men innan jag började felsöka bestämde jag mig för att verifiera TVL på den mest populära Ethereum blockchain explorer, Etherscan . Tekniskt sett är varje Uniswap v3-pool en smart trac . Så, blockchain-utforskaren kan visa tokensaldoerna i poolens ägo, vilket är vad TVL är.

Jag förväntade mig att poolens symboliska saldo skulle vara lite större än TVL som rapporterats av Uniswap. Det beror på att poolen har likviditet såväl som avgifter som har ackumulerats men ännu inte begärts. Men detta saldo var nästan hälften av det belopp som Uniswap rapporterade, och överraskande nog var det samma siffra som mina beräkningar!

Att jämföra likviditeten, tillgång för tillgång, visade också en enorm skillnad. Vid det här laget insåg jag att felet inte hade något att göra med mina matematikkunskaper.

Men hur kunde detta hända? Efter att ha undersökt fann jag att Uniswap förlitar sig på den decentraliserade blockchain-indexeringstjänsten The Graph . Med denna tjänst kan vilken utvecklare som helst lägga till en personlig analyskod (kallad subgraph) för specifika blockchain-dataanvändningsfall och göra analysen tillgänglig via API.

Uniswap Labs har skapat sina egna subgrafer för Uniswap-protokollanalys och gjort dem tillgängliga via The Graph Hosted Service . Det som är bra är att dess kod är allmänt tillgänglig . Det dåliga är dock dess TVL-beräkningsfel.

En kort analys av koden visar att den står för alla swappar och likviditetshändelser men tar inte hänsyn till avgifter. Uniswappooler har en avgift på 0,01 % till 1 % på varje swap. Denna avgift dras av från omsatta tillgångar och tillfaller likviditetsleverantörer. Likviditetsleverantörer kan i sin tur ta in upplupna avgifter när som helst.

Den aktuella Uniswap v3-subgrafen visar dock siffrorna som om inga avgifter någonsin har samlats in och samlats in. Så Uniswap v3 TVL-siffrorna avvek från verkligheten med varje byte.

Du kanske undrar: "Sände du in en emissionsbiljett på GitHub innan du skrev den här artikeln?" Ja, det är min första avsikt efter att jag upptäckt felet. Och vet du vad? Det problemet är redan loggat , skapat av en kärnutvecklare i november 2021!

Så varför åtgärdades inte detta problem? Jag har ingen aning. Kanske var felet försumbart när det här felet upptäcktes. Detta är dock ett kumulativt fel som växer med varje byte. Så när avgiften och handelsvolymen i poolen växer, kommer den resulterande TVL-avvikelsen från felet att resultera i en större skillnad från verkligheten. Och vi kan se att i en stor pool som USDC-ETH med en högre avgift på 0,3 % – det har blivit utom kontroll! Det är för närvarande nästan dubbelt så mycket som sanna siffror.

Låt oss verifiera Total TVL

Ok, vi vet vid det här laget att TVL-talen i enskilda pooler är förvrängda. Vi kommer att undersöka hur detta kan påverka investeringsbeslut nedan. Men innan vi kommer till det, låt oss se hur dessa fel påverkar den totala TVL för Uniswap v3:s protokoll. Denna TVL rapporteras till nästan 12 miljarder dollar i skrivande stund.

Du behöver inte vara datavetare för att se att något är fel här.

Vi kan se ovan att TVL rapporterades som långsamt men stadigt växande från 500 miljoner USD till 4,5 miljarder USD den 6 mars 2022. Sedan hände något galet och TVL rapporterades som 254 miljarder USD den 7 mars 2022. Det är 2,5 gånger mer än högsta TVL för hela Ethereum -nätverket någonsin – på EN dag! Det är uppenbart att det är ett misstag i uppgifterna. Under de följande veckorna rapporterades TVL som $10-20b.

Vid det här laget tappade jag allt förtroende för Uniswap-analysdata. Men hur kan vi veta den sanna TVL? Jag hade 2 alternativ.

Alternativ 1—gaffel ut och fixa Uniswap v3-subgrafen. Det dåliga med det här alternativet är att det skulle ta dagar för subgrafen att återindexera. Och jag är inte ett fan av GraphQL-språket som The Graph använder.

Lyckligtvis hade jag alternativ 2— – Datamints högpresterande analytiska databaser för all Uniswap v3 och Ethereum -data, lätt tillgänglig för komplexa onlinefrågor.

Efter några experiment har jag skapat följande algoritm för korrekt TVL-beräkning. Kontrollera steg-för-steg-processen nedan.

1. Beräkna TVL för alla befintliga Uniswap v3-pooler med dessa två steg.
   1. Lägg till alla ERC-20-tokenöverföringar till och från poolkontraktet ( trac inkluderar alla outtagna avgifter) och matcha tokensaldoerna på Etherscan
   2. Lägg till alla likviditetshändelser, inkommande och utgående, och lägg sedan till alla swaphändelser för att ta hänsyn till avgifter
2. Jämför de två metoderna och se till att inga oförklarade avvikelser kvarstår
3. Ta bort övergivna och tomma pooler med mindre än 50 byten eller 0,00000000000001 tokenbelopp (med 7 863 pooler upptäckta (inklusive 2 083 par med stall), min algoritm tog bort 112 pooler som tomma/övergivna)
4. Hitta en väg till stabila mynt för varje token för att konvertera pool-TVL till USD-värde
5. Ta bort låglikviditetspooler med brutna USD-värden eftersom vissa pooler kan visa otillräckliga värden efter att ha tagit bort likviditeten helt (se nedanstående diagram som ett exempel)

6. Konvertera TVL för alla återstående par till USD-värde och lägg till dem

Efter flera korskontroller kom jag fram till en TVL-beräkning. Jag startade den och ville hämta kaffe medan beräkningen utfördes, men den tog slut innan jag ställde mig upp. Detta är den enda nackdelen med att använda en högpresterande analytisk databas.

Är du redo att se resultatet?

Det är nästan 4 gånger mindre än de rapporterade $ 11,8b... Det är upp till dig att dra en slutsats.

Friskrivningsklausul : Min beräkning kan innehålla fel. I dataprojekt för företagskunder använder vi dokumenterad metodik, autotester och många andra verktyg för att uppnå högsta datakvalitet. Dessa verktyg skulle vara överdrivet för ett personligt forskningsprojekt som detta. Denna forskning belyser de uppenbara problemen i tillgänglig data snarare än att ge en slutgiltig lösning.

Ok, vi fixar TVL-beräkningar — kommer det att hjälpa?

Problemet är inte felaktiga siffror utan snarare de beslut vi fattar baserat på dessa siffror. Till exempel använder de flesta vinstkalkylatorer för likviditetsleverantörer dessa siffror för förutsägelser.

Det är dock inte så svårt att fixa TVL-beräkningen. Antingen fixar Uniswap Labs det i sin subgrafkod, eller så börjar kalkylatorutvecklare använda andra datakällor. Kärnfrågan är om vi kan vara dent att räknarens förutsägelser är korrekta.

Jag gjorde några beräkningar, och det korta svaret är - inte ens i närheten .

Ett djärvt påstående, jag vet. Många likviditetsleverantörer använder befintliga miniräknare och påverkar beslut som kostar tiotals miljoner dollar. Men låt oss gå igenom beräkningsstegen så att du kan göra din egen bedömning.

Låt oss först se över några kärnkoncept i Uniswap v3-protokollet.

En av dess främsta innovationer är koncentrerad likviditet. I huvudsak, med Uniswap v3, kan du välja den prisklass du vill att dina pengar ska fungera som likviditetsleverantör. Detta är ett fantastiskt koncept som kan ge stort värde för protokollanvändare. Likviditetsleverantörer begränsar sin exponering för permanenta förluster, och handlare kan enj av mindre prisglidning när volatiliteten är låg. Men alla dessa potentiella fördelar har en kostnad – komplexitet .

Så vi vill förstå hur vinsten för Uniswap v3-likviditetsleverantören beräknas.

I Uniswap v3 väljer likviditetsleverantören prisintervallet att tillhandahålla likviditet till. Han kommer att få sitt snitt på swapavgifterna när priset är inom detta intervall. Vid första anblicken vill en likviditetsleverantör ha prisintervallet för sin likviditetsposition så brett som möjligt. Likviditeten fördelas dock proportionellt över detta intervall. Så ju bredare intervallet är, desto lägre är swapavgiften för varje affär.

I det här exemplet visar alternativ A att likviditetsleverantören väljer ett bredare prisintervall och alternativ 2 visar ett smalare med samma belopp. Förutsatt att priset i båda fallen ligger inom det valda prisintervallet får likviditetsleverantören 3 gånger fler avgifter i alternativ B. Men om priset är mer volatilt kan likviditetsleverantören sluta med en högre vinst i alternativ A.

Så, i verkligheten, är valet av rätt prisintervall beroende av att hitta den bästa balansen mellan risken att missa priset och att få en lägre avkastning på varje affär.

Ytterligare en parameter påverkar likviditetsleverantörens vinst och förbises ofta. Jag känner inte till någon LP-vinstkalkylator som anser det, och den här parametern kan förändra allt. Du undrar vad det här är vid det här laget. Det är distributionen av LP-skivorna. Tänk på följande exempel:

I det här exemplet har två likviditetsleverantörer (LP1 och LP2) positioner. LP1 har en smal position på $3. LP2 har en bred position på $5. I det här fallet, om priset inte lämnar intervallet för LP1:s position, kommer han att få 3 gånger högre avgifter än LP2. Det beror på att LP2 bara har $1 i det här intervallet. Och denna $1 konkurrerar med $3 av LP1.

Om du tittar på likviditetsfördelningen för en Uniswap v3-pool ser du att den inte är enhetlig.

Ju högre ribban, desto högre konkurrens. Likviditetsleverantörer måste hitta balansen mellan att välja konkurrenskraftiga intervall och intervall med lägre sannolikhet för en pristräff. Det är därför denna distribution spelar en stor roll i LP-vinstprognoser och strategibygge. Det enda problemet är... Jag är inte säker på att den här fördelningen är korrekt beräknad.

Som om det inte räcker – Likviditetssnipers

Att vara likviditetsleverantör handlar om att gissa pris, konkurrensläge och handelsvolym. Om en LP hade en önskan skulle det vara att veta framtiden för affärerna för att justera likviditetspositioner i förväg.

Men tänk om jag säger att det är möjligt?

Under efterforskningen fångade några ovanliga likviditetsleverantörer min uppmärksamhet. De lade till och tog bort betydande likviditetspositioner (över 10 miljoner USD) många gånger om dagen. Ännu mer överraskande, de har alltid lagt till och tagit bort likviditet i samma block.

Låt oss titta på ett exempel:

Vi har tre transaktioner, alla i block 15413416, positioner 3-5, utförda i ordning nedifrån och upp. Den första transaktionen, med Execute-metoden, är en trac som heter "MEV Bot", som lägger till 22 miljoner USD i likviditet till USDC-WETH-poolen.

Den andra transaktionen är ett byte från USDC till DogeChain genom WETH. Detta är en vanlig swap med ett värde av cirka 16 500 $.

Den tredje transaktionen är "MEV Bot" igen, vilket tar bort $22m likviditet från USDC-WETH poolen.

Det som hände i exemplet kallas "likviditetssniping". Låt mig förklara hur detta fungerade:

1. Någon skickade en transaktion för att byta USDC till DogeChain
2. MEV Bot upptäckte denna transaktion i mempoolen och aktiverade en privat länk med en gruvpool med Flashbots-teknik eller något liknande
3. MEV Bot betalade gruvarbetare för att inkludera en swaptransaktion och två transaktioner i en specifik ordning som möjliggjorde trac
4. MEV Bot lade till så mycket likviditet (22 miljoner USD) till ett mycket snävt prisintervall, så effektivt att alla avgiftsvinster från den specifika USDC-DogeChain-handeln tillföll honom
5. MEV Bot tog sedan bort likviditeten och intjänade avgifter (cirka $35)

Så hans bruttovinst efter bensinavgifter var cirka 30 dollar. Inte så mycket? Ja, men han kör den här strategin flera gånger i minuten, vilket sammanlagt räcker. Du kan kolla upp det själv .

Vad betyder detta för dig som likviditetsgivare? Det betyder att likviditetsprickskyttar kan ta en betydande minskning av din avgiftsvinst.

Slutsats

Låt mig sammanfatta mina forskningsresultat:

1. TVL-siffror i Uniswap v3-diagram är grovt felaktiga. Samma fel finns i alla analysverktyg som förlitar sig på den officiella Uniswap v3-subgrafen.
2. Total Uniswap v3 TVL är $3,14b vs $11,8b rapporterade av den officiella webbplatsen (i skrivande stund).
3. Miniräknare för Uniswap v3-likviditetsleverantörer har lite värde för verkliga strategier eftersom de inte tar hänsyn till konkurrens- och likviditetssnipers.

Lyckligtvis kan du nu bättre förstå hur Uniswap v3 likviditetspooler fungerar i verkligheten och kan justera din forskning därefter.

Jag är inte i stånd att ge finansiell rådgivning, men jag ser bara två alternativ för att bygga en framträdande likviditetsförsörjande strategi:

1. ENKEL . Använd historisk prestandadata. Prova några likviditetspositioner med små insatser och se vilka alternativ som fungerar bättre. Uppenbarligen fungerar detta endast under antagandet att marknaden är stabil.
2. AVANCERAD . Utför forskning och optimera LP-strategin därefter. Som vi diskuterade ovan kräver det en djupgående förståelse av Uniswap v3-protokollet, matematik och spelteorikompetenser och ett kraftfullt dataanalysverktyg för att bearbeta enorma mängder data i realtid.

Båda alternativen har en sak gemensamt – du baserar dina beslut på data snarare än en magkänsla eller slumpmässiga verktyg. Ibland är det svårt att arbeta med data, men det lönar sig.

Må data vara med dig!