USD Coin-koers

De positieve kant van de huidige discussie is dat de Solana DeFi-gemeenschap heel snel veel nadenkt over de kwaliteit van de uitvoering, en dat heel openbaar. De signaal-ruisverhouding is klein, dus ik wil dat verbeteren met deze post. Hier zijn enkele feiten voor degenen die nieuwsgierig zijn naar de technische kant van routervergelijkingen en uitvoeringkwaliteit. Quote prijs != gerealiseerde prijs. Te beginnen met het voor de hand liggende: het nummer dat je op het scherm ziet (quote) is niet noodzakelijkerwijs het nummer dat je krijgt (gerealiseerde handelsprijs). De gerealiseerde handelsprijs gebeurt enkele seconden nadat de quote is gegenereerd, zelfs als deze opnieuw is gesimuleerd. Gedurende die seconden bewegen de markten. Soms veel. Om dit aan te pakken, kan simulatie waardevol zijn. Gegeven een transactie, zal simulatie je vertellen wat de gerealiseerde prijs zou zijn als een enkele gebruiker de quote precies één keer uitvoert op de huidige laatste slot. De eenmalige aard van de quote hier is niet geweldig: wat gebeurt er als 5 mensen proberen de quote uit te voeren? Wat gebeurt er als 5000 mensen proberen die quote uit te voeren? Echter, de eenmalige aard van simulatie is niet het belangrijkste dat ter discussie staat in de algemene discussie van vandaag. De onderdelen die ter discussie staan zijn de volgende. Het simuleren van twee routes die op verschillende slots zijn gegenereerd, zal de recentere bevoordelen. Als je twee transacties hebt met verschillende leeftijden, wat betekent dat de routes zijn gegenereerd op verschillende slots, dan betekent het simuleren van beide en het vergelijken van de prijzen over het algemeen dat de recentere transactie de betere prijs heeft. Het bewijs is duidelijk als je naar de extremen kijkt. Verwacht je dat een transactie die 60 seconden geleden is gegenereerd, gunstiger vergeleken wordt met een transactie die op de meest recente beschikbare slot is gemaakt? Het is waarschijnlijker dat de quote van 60 seconden geleden de slippage-tolerantietest tijdens de simulatie niet doorstaat. Simulatieresultaten hebben een zeer snelle tijdsverval. Simulatie-gebaseerde meta-aggregatie heeft geen zin wanneer de transactie terug naar de klant wordt gestuurd en er seconden kunnen verstrijken voordat de transactie wordt verzonden om uitgevoerd te worden. Meta-aggregatie heeft alleen zin wanneer de meta-aggregator de laatste blik server-side heeft en de winnende transactie onmiddellijk kan uitvoeren. Nadat je de "beste" quote aan de klant hebt teruggegeven, en er seconden verstrijken, begint de simulatie-gebaseerde vergelijking weer ruis te hebben. Dit betekent dat simulatie-gebaseerde meta-aggregatiesystemen enige signalen aan klanten teruggeven (om duidelijk te zijn, het signaal is vanaf het begin bevooroordeeld vanwege verschillen in de leeftijd van de quotes), maar dat signaal vervalt zeer snel. Racecondities zijn onvermijdelijk, maar het correct interpreteren van de effecten van de racecondities is cruciaal. Het is gewoon de aard van de realiteit dat racecondities in markten bestaan. Het probleem ontstaat wanneer er claims worden gedaan alsof die racecondities niet bestaan. Ik zou alle meta-aggregator API's die claimen gelijke kansen tussen quotes te hebben aanmoedigen om hun eigen gegevens te analyseren die ten minste deze kolommen bevatten: de geselecteerde router en de leeftijd van elke kandidaatquote van elke router (als slot niet beschikbaar is, gebruik dan pakket-timestamps of wat dan ook ruwe schatting van de leeftijd beschikbaar is). De bias zal onmiddellijk duidelijk zijn. Bovendien, wanneer je gerealiseerde slippage op uitgevoerde transacties vergelijkt, moet je transacties opnemen die zijn geland maar zijn mislukt omdat die transacties de slippage-tolerantie overschreden. Anders is je dataset en conclusies opnieuw bevooroordeeld. Quotes kunnen niet letterlijk worden geïnterpreteerd. Quotes hebben twee dimensies: de kans op succesvolle landing en de gerealiseerde prijs. Routers kunnen hun systemen aanpassen om te optimaliseren voor het een of het ander, of een combinatie van beide, maar er moet nog steeds een weging worden toegepast over welke factor belangrijker is. Gepolitiseerde beslissingen die het routing systeem van DFlow maakt: Het routing systeem van DFlow optimaliseert voor twee dingen: de gerealiseerde prijs en het succes van de transactie. Hier is waarom: Optimaliseren voor gerealiseerde prijs is waar gebruikers om geven. DFlow kan gemakkelijk "verbeterde" quotes laten zien door een enkele parameter aan te passen en door dunne liquiditeit te routeren, maar we doen dat niet omdat de kans op transactie-falen toeneemt. Klanten willen een kleine hoeveelheid prijscompensatie voor een lagere variantie in transactie-succespercentages. En we ontwerpen onze systemen om miljoenen klanten te bedienen. Een transactie die landt genereert veel meer economische activiteit dan een transactie die misschien nog een paar atomen had kunnen persen maar niet landde. Hier zijn de twee belangrijkste manieren waarop we dit doen: Ten eerste, DFlow JIT-routing snijdt een verwachte ~1 bps in gerealiseerde slippage op SOL/USDC af. Dit is een enorme hoeveelheid voordeel die simpelweg niet opduikt in quote-vergelijkingen (en nooit kan). Ten tweede, we kiezen er ook alleen voor om te routeren door dikke, veerkrachtige liquiditeit waarvan we voorspellen dat deze on-chain zal blijven tegen de tijd dat de transactie landt, zelfs als veel gebruikers dezelfde quote uitvoeren. Tot slot denk ik dat de gesprekken die we nu hebben netto goed zijn voor het vooruit helpen van Solana DeFi, maar ik zou opnieuw aanmoedigen om de focus te leggen op het verhogen van de signaal-ruisverhouding. Iedereen profiteert als we ons puur richten op technische nauwkeurigheid.