Al uw Uniswap v3 Liquidity Farming-berekeningen zijn helemaal fout! Dit is waarom

2 x 2 = 5

Je weet dat het fout is, maar als je het voor het eerst ziet, twijfel je aan jezelf en denk je: "Misschien is er iets mis met mijn berekening". Rechts?

Nou, dat is precies hoe ik me voelde toen ik ontdekte dat de liquiditeits- en TVL-cijfers (Total Value Locked) die op de gebruikersinterface van Uniswap V3 werden weergegeven, volledig verkeerd waren.

Uniswap is de grootste gedecentraliseerde financiële (Defi) project op Ethereum en het geheel blockchain industrie. Duizenden liquiditeitsverschaffers gebruiken deze cijfers dagelijks om hun beleggingsstrategieën op te bouwen. Dus hoe kunnen deze cijfers mogelijk onnauwkeurig zijn?

Ik heb uren besteed aan het zoeken naar een fout in mijn berekeningen, en wat denk je? Ik heb geen fouten gemaakt. En de situatie is nog erger dan alleen onnauwkeurige TVL.

Maar laten we stap voor stap gaan en beginnen met het probleem.

Het probleem

Ten eerste, wat is TVL en hoe wordt het gebruikt? Kortom, TVL wordt gedefinieerd als een dollarwaarde van alle crypto-activa die momenteel door gebruikers zijn gedelegeerd aan een blockchain of protocol. Deze activa kunnen bijvoorbeeld de totale liquiditeit zijn van een gedecentraliseerd uitwisselings-, brug- of uitleenprotocol, of de totale ingezette activa van PoS-blockchain.

Crypto-marktinvesteerders en andere deelnemers gebruiken TVL voor meerdere gevallen:

1. Beoordeling van de protocolgezondheid. Dit is de reden waarom populaire protocollen hun TVL op de hoofdpagina pronken. Grotere TVL = meer gebruikersvertrouwen = lager risico = stabiele winst.
2. Vergelijking tussen protocollen. Als ik een cryptohandelaar was, zou ik liever DeFi-tools gebruiken, zoals gedecentraliseerde uitwisselingen of bruggen, met een hogere TVL.
3. Meting van protocolgroei. Beleggers die zien dat de TVL van een protocol of project snel groeit, beschouwen het als een signaal om optimistisch te zijn over de tokenprijs van het protocol.

Lijkt me belangrijk om te weten accuraat TVL-nummers, toch?

Maar wat als ik zeg dat de meest beschikbare gegevens over Uniswap v3 TVL misleidend zijn? De grootste verrassing voor mij was echter dat de officiële Uniswap Chart-app ook een probleem! Hier is hoe ik erachter kwam.

Ik werkte aan een liquiditeitsanalyseproject, waarbij ik officiële gegevens op Uniswap v3 vergeleek met mijn berekeningen met behulp van onbewerkte blockchain-gegevens. Deze stap is essentieel om te voldoen aan de hoogste normen voor gegevenskwaliteit. Om de verificatie te starten, koos ik een populaire liquiditeitspool, USDC-WETH (0,3% kostenniveau).

Kijk naar pool 3 op Uniswap v3 - het heeft een indrukwekkende TVL van $ 333 miljoen (gebaseerd op officiële Uniswap-hitlijsten op het moment van schrijven) en een gezond dagelijks volume van $ 61 miljoen.

Meteen liep ik tegen een probleem aan: mijn berekende TVL-waarde was $ 176 miljoen in plaats van de $ 333 miljoen die op de Uniswap-website wordt vermeld. Oké, er gebeuren dus fouten. Maar voordat ik naar debuggen ging, besloot ik de TVL te verifiëren op de meest populaire Ethereum blockchain-verkenner, Etherscan. Technisch gezien is elke Uniswap v3-pool een slim contract. De blockchain-verkenner kan dus de token-saldi in het bezit van de pool laten zien, wat TVL is.

Ik had verwacht dat het token-saldo van de pool iets groter zou zijn dan de TVL die door Uniswap werd gerapporteerd. Dat komt omdat de pool zowel liquiditeiten als vergoedingen bevat die zijn opgebouwd maar nog niet zijn opgeëist. Maar dit saldo was bijna de helft van het bedrag dat Uniswap rapporteerde, en verrassend genoeg was het hetzelfde cijfer als mijn berekeningen!

Het vergelijken van de liquiditeit, asset per asset, liet ook een enorm verschil zien. Op dat moment realiseerde ik me dat de fout niets te maken had met mijn wiskundige vaardigheden.

Maar hoe kon dit gebeuren? Na onderzoek ontdekte ik dat Uniswap vertrouwt op de gedecentraliseerde blockchain-indexeringsservice De grafiek. Met deze service kan elke ontwikkelaar een persoonlijke analysecode (subgraph genaamd) toevoegen voor specifieke toepassingen van blockchain-gegevens en de analyse beschikbaar maken via API.

Uniswap Labs heeft zijn eigen subgrafieken voor Uniswap-protocolanalyses gemaakt en beschikbaar gesteld via: De door Graph gehoste service. Het goede ding is dat de code is publiekelijk verkrijgbaar. Het slechte is echter de TVL-berekeningsfouten.

Een korte analyse van de code laat zien dat deze rekening houdt met alle swaps en liquiditeitsgebeurtenissen, maar niet met vergoedingen. Uniswap-pools hebben een tarief van 0.01% tot 1% op elke swap. Deze vergoeding wordt afgetrokken van de verhandelde activa en toegerekend aan liquiditeitsverschaffers. Op hun beurt kunnen liquiditeitsverschaffers op elk moment opgebouwde vergoedingen innen.

De huidige Uniswap v3-subgrafiek geeft de cijfers echter weer alsof er nooit vergoedingen zijn opgebouwd en geïnd. De Uniswap v3 TVL-cijfers weken dus bij elke swap af van de werkelijkheid.

Je vraagt ​​​​je misschien af: "Heb je een probleemticket op GitHub ingediend voordat je dit artikel schreef?" Ja, dat is mijn eerste bedoeling na het ontdekken van de fout. En weet je wat? Dat probleem is: al ingelogd, gemaakt door een kernontwikkelaar in november 2021!

Dus waarom is dit probleem niet opgelost? Ik heb geen idee. Misschien was de fout verwaarloosbaar op het moment dat deze bug werd ontdekt. Dit is echter een cumulatieve fout die bij elke swap groeit. Dus naarmate de vergoeding en het handelsvolume in de pool groeien, zal de resulterende TVL-afwijking van de fout resulteren in een groter verschil met de werkelijkheid. En we kunnen zien dat in een grote pool zoals USDC-ETH met een hogere vergoeding van 0.3% - het uit de hand loopt! Het is momenteel bijna het dubbele van de werkelijke cijfers.

Laten we de totale TVL verifiëren

Ok, we weten inmiddels dat de TVL-nummers in individuele pools vervormd zijn. We zullen hieronder onderzoeken hoe dit van invloed kan zijn op investeringsbeslissingen. Maar voordat we daartoe komen, laten we eens kijken hoe deze fouten de totale TVL van het Uniswap v3-protocol beïnvloeden. Deze TVL wordt op het moment van schrijven gerapporteerd op bijna $ 12 miljard.

Je hoeft geen datawetenschapper te zijn om te zien dat hier iets niet klopt.

We kunnen hierboven zien dat TVL werd gerapporteerd als langzaam maar gestaag groeiend van $ 500 miljoen naar $ 4.5 miljard op 6 maart 2022. Toen gebeurde er iets geks, en TVL werd gerapporteerd als $ 254 miljard op 7 maart 2022. Dat is 2,5x meer dan de hoogste TVL van het hele Ethereum-netwerk ooit - in ÉÉN dag! Het is duidelijk een fout in de gegevens. In de volgende weken werd de TVL gerapporteerd als $ 10-20b.

Op dit punt verloor ik alle vertrouwen in de analysegegevens van Uniswap. Maar hoe kunnen we de ware TVL kennen? Ik had 2 opties.

Optie 1 - vork uit en repareer de Uniswap v3-subgrafiek. Het slechte van deze optie is dat het dagen zou duren voordat de subgrafiek opnieuw geïndexeerd is. En ik ben geen fan van de GraphQL-taal die The Graph gebruikt.

Gelukkig had ik optie 2— – Datamint's krachtige analytische databases voor alle Uniswap v3- en Ethereum-gegevens, direct beschikbaar voor complexe online vragen.

Na wat experimenten heb ik het volgende algoritme gemaakt voor nauwkeurige TVL-berekening. Bekijk het stappenplan hieronder.

1. Bereken TVL voor alle bestaande Uniswap v3-pools met behulp van deze twee stappen.
   1. Voeg alle ERC-20-tokenoverdrachten van en naar het poolcontract toe (inclusief alle niet-opgeëiste kosten) en match de tokensaldi op Etherscan
   2. Voeg alle liquiditeitsgebeurtenissen toe, inkomend en uitgaand, en voeg vervolgens alle ruilgebeurtenissen toe aan rekening houden met vergoedingen
2. Vergelijk de twee methoden en zorg ervoor dat er geen onverklaarbare verschillen blijven
3. Verwijder verlaten en lege pools met minder dan 50 swaps of 0.00000000000001 tokenbedrag (met 7,863 pools gedetecteerd (inclusief 2,083 paren met stallen), mijn algoritme verwijderde 112 pools als leeg/verlaten)
4. Vind een pad naar stabiele munten voor elk token om pool TVL om te zetten in USD-waarde
5. Verwijder pools met lage liquiditeit met gebroken USD-waarden, aangezien sommige pools ontoereikende waarden kunnen vertonen nadat de liquiditeit volledig is verwijderd (bekijk de onderstaande grafiek als voorbeeld)

6. Converteer TVL van alle resterende paren naar USD-waarde en voeg ze toe

Na meerdere kruiscontroles kwam ik tot een TVL-berekening. Ik begon eraan en wilde koffie halen terwijl de berekening werd uitgevoerd, maar het was afgelopen voordat ik opstond. Dit is het enige nadeel van het gebruik van een krachtige analytische database.

Ben je klaar om het resultaat te zien?

Het is bijna 4 keer minder dan de gerapporteerde $11,8b… Het is aan jou om een ​​conclusie te trekken.

Disclaimer: Mijn berekening kan fouten bevatten. In dataprojecten voor zakelijke klanten gebruiken we gedocumenteerde methodologie, autotests en vele andere tools om de hoogste datakwaliteit te bereiken. Deze tools zouden overdreven zijn voor een persoonlijk onderzoeksproject als dit. Dit onderzoek benadrukt de voor de hand liggende problemen in beschikbare gegevens in plaats van een definitieve oplossing te bieden.

Oké, we zullen TVL-berekeningen repareren - zal het helpen?

Het probleem is niet de onjuiste cijfers, maar de beslissingen die we nemen op basis van die cijfers. De meeste winstcalculators voor liquiditeitsverschaffers gebruiken deze cijfers bijvoorbeeld voor voorspellingen.

Het is echter niet zo moeilijk om de TVL-berekening vast te leggen. Ofwel Uniswap Labs repareert het in hun subgraafcode, of rekenmachineontwikkelaars beginnen andere gegevensbronnen te gebruiken. De kernvraag is of we erop kunnen vertrouwen dat rekenmachinevoorspellingen correct zijn.

Ik heb wat berekeningen gedaan en het korte antwoord is:niet eens in de buurt.

Een gewaagde bewering, ik weet het. Veel liquiditeitsverschaffers gebruiken bestaande rekenmachines en beïnvloeden beslissingen die tientallen miljoenen dollars kosten. Maar laten we de berekeningsstappen eens doornemen, zodat u uw eigen oordeel kunt vellen.

Laten we eerst enkele kernconcepten van het Uniswap v3-protocol bekijken.

Een van de belangrijkste innovaties is geconcentreerde liquiditeit. In wezen kunt u met Uniswap v3 de prijsklasse selecteren waarin u wilt dat uw geld als liquiditeitsverschaffer werkt. Dit is een geweldig concept dat van grote waarde kan zijn voor protocolgebruikers. Liquiditeitsverschaffers beperken hun blootstelling aan tijdelijk verlies, en handelaren kunnen profiteren van een kleinere prijsdaling wanneer de volatiliteit laag is. Maar al deze potentieel voordelen hebben een prijs-ingewikkeldheid.

We willen dus begrijpen hoe de inkomsten van de Uniswap v3-liquiditeitsaanbieder worden berekend.

In Uniswap v3 selecteert de liquiditeitsverschaffer de prijsklasse waaraan liquiditeit moet worden verstrekt. Hij krijgt zijn deel van de swapvergoedingen zodra de prijs binnen dit bereik ligt. Een liquidity provider wil op het eerste gezicht de prijsrange van zijn liquiditeitspositie zo breed mogelijk hebben. De liquiditeit wordt echter proportioneel over deze bandbreedte verdeeld. Dus hoe groter het bereik, hoe lager de swapvergoeding voor elke deal.

In dit voorbeeld toont optie A de liquiditeitsverschaffer die een bredere prijsklasse kiest, en optie 2 toont een smallere prijsklasse met hetzelfde bedrag. Op voorwaarde dat de prijs in beide gevallen binnen de gekozen prijsklasse ligt, krijgt de liquidity provider 3x meer vergoedingen in optie B. Als de prijs echter volatieler is, kan de liquidity provider een hogere winst behalen in optie A.

Dus in werkelijkheid is het selecteren van de juiste prijsklasse afhankelijk van het vinden van de beste balans tussen het risico om de prijs te missen en een lager rendement op elke deal.

Nog een parameter beïnvloedt de winst van de liquidity provider en wordt vaak over het hoofd gezien. Ik ken geen enkele LP-winstcalculator die hiermee rekening houdt, en deze parameter kan alles veranderen. Je vraagt ​​je af wat dit nu is. Het is de distributie van de LP's. Beschouw het volgende voorbeeld:

In dit voorbeeld hebben twee liquidity providers (LP1 en LP2) posities. LP1 heeft een smalle positie van $3. LP2 heeft een brede positie van $5. In dit geval, als de prijs niet buiten het bereik van de positie van LP1 komt, krijgt hij 3x meer vergoedingen dan LP2. Dat komt omdat LP2 slechts $ 1 in dit bereik heeft. En deze $1 concurreert met $3 van LP1.

Als u naar de liquiditeitsverdeling van een Uniswap v3-pool kijkt, ziet u dat deze niet uniform is.

Hoe hoger de lat, hoe hoger de concurrentie. Liquiditeitsaanbieders moeten de balans vinden tussen het kiezen van concurrerende bandbreedtes en het bereik met een lagere kans op een prijstreffer. Daarom speelt deze verdeling een grote rol bij het voorspellen van de winst van LP en het opbouwen van een strategie. Het enige probleem is... ik weet niet zeker of deze verdeling goed is berekend.

Alsof dat niet genoeg is - Liquidity Snipers

Een liquiditeitsverschaffer zijn, gaat over het raden van de prijs, de concurrentiestatus en het handelsvolume. Als een LP een wens zou hebben, zou het zijn om de toekomst van de transacties te kennen om vooraf liquiditeitsposities aan te passen.

Maar wat als ik je vertel dat het mogelijk is?

Tijdens het onderzoek trokken enkele ongebruikelijke liquiditeitsverschaffers mijn aandacht. Ze hebben vele malen per dag aanzienlijke liquiditeitsposities (meer dan $ 10 miljoen) toegevoegd en verwijderd. Nog verrassender is dat ze altijd liquiditeit in hetzelfde blok hebben toegevoegd en verwijderd.

Laten we een voorbeeld bekijken:

We hebben drie transacties, allemaal in blok 15413416, posities 3-5, uitgevoerd in bottom-up volgorde. De eerste transactie, met de Execute-methode, is een contract met de naam "MEV Bot", waarmee $ 22 miljoen aan liquiditeit wordt toegevoegd aan de USDC-WETH-pool.

De tweede transactie is een swap van USDC naar DogeChain via WETH. Dit is een gewone swap met een waarde van ongeveer $ 16,500.

De derde transactie is opnieuw "MEV Bot", waarbij $ 22 miljoen aan liquiditeit uit de USDC-WETH-pool wordt verwijderd.

Wat in het voorbeeld gebeurde, wordt "liquidity sniping" genoemd. Laat me uitleggen hoe dit werkte:

1. Iemand heeft een transactie gestuurd om USDC om te wisselen naar DogeChain
2. MEV Bot detecteerde deze transactie in de mempool en activeerde een privélink met een mijnpool met behulp van Flashbots-technologie of iets dergelijks
3. MEV Bot betaalde miners om een ​​swaptransactie en twee transacties in een specifieke volgorde op te nemen die waardeextractie mogelijk maakten
4. MEV Bot voegde zoveel liquiditeit ($ 22 miljoen) toe aan een zeer smalle prijsklasse, zo effectief dat alle vergoedingswinsten van die specifieke USDC-DogeChain-transactie aan hem werden toegerekend
5. MEV Bot verwijderde vervolgens de liquiditeit en verdiende vergoedingen (ongeveer $ 35)

Dus zijn brutowinst na gaskosten was ongeveer $ 30. Niet heel erg? Ja, maar hij voert deze strategie meerdere keren per minuut uit, wat allemaal optelt. Jij kan bekijk het zelf.

Wat betekent dit voor u als liquidity provider? Het betekent dat liquiditeitssluipschutters een aanzienlijke verlaging van uw vergoedingswinst kunnen nemen.

Conclusie

Laat me mijn onderzoeksresultaten afronden:

1. TVL-cijfers in Uniswap v3-grafieken zijn schromelijk onnauwkeurig. Dezelfde fouten bestaan ​​in alle analytische tools die vertrouwen op de officiële Uniswap v3-subgrafiek.
2. Totale Uniswap v3 TVL is $ 3,14 miljard versus $ 11,8 miljard gerapporteerd door de officiële website (op het moment van schrijven).
3. Rekenmachines voor Uniswap v3-liquiditeitsaanbieders hebben weinig waarde voor real-life strategieën omdat ze geen rekening houden met concurrentie en liquiditeitssluipschutters.

Gelukkig kun je nu beter begrijpen hoe Uniswap v3-liquiditeitspools in het echte leven werken en kun je je onderzoek daarop aanpassen.

Ik ben niet in een positie om financieel advies te geven, maar ik zie slechts 2 opties om een ​​prominente liquiditeitsverschaffende strategie op te bouwen:

1. EENVOUDIG. Gebruik historische prestatiegegevens. Probeer enkele liquiditeitsposities met kleine inzetten en kijk welke opties beter werken. Uiteraard werkt dit alleen in de veronderstelling dat de markt stabiel is.
2. ADVANCED. Onderzoek doen en de LP-strategie dienovereenkomstig optimaliseren. Zoals we hierboven hebben besproken, vereist dat een diepgaand begrip van het Uniswap v3-protocol, wiskunde- en speltheoriecompetenties en een krachtige tool voor gegevensanalyse om enorme hoeveelheden gegevens in realtime te verwerken.

Beide opties hebben één ding gemeen: u baseert uw beslissingen op gegevens in plaats van een onderbuikgevoel of willekeurige tools. Werken met data is soms moeilijk, maar het loont.

Bij Datamint zijn we er altijd om u te helpen met uw aangepaste dataprojecten.

Mogen de gegevens bij u zijn!