En Uniswap v4-handelsbot skal identificere og forstå en bestemt pool, før den kan automatisere en handel. Tokenparret alene er utilstrækkeligt. Gebyrkonfiguration, tickafstand og hookadresse indgår også i poolens identitet, mens den omgivende blockchain og installerede manager fastslår, hvor identiteten har betydning.
Det betyder noget, fordi velkendte antagelser fra tidligere automatiske market makers ikke overføres uændret. En v4-pool behøver ikke være en separat parkontrakt med egne letfortolkelige tokensaldi. Hooks kan tilføje adfærd, og et vist gebyrfelt beskriver ikke altid det aktuelle gebyr på næste swap. Denne vejledning forklarer, hvordan forskellene vurderes uden at antage, at enhver pool eller hook understøttes. Alle taleksempler er fiktive.
Poolidentitet i en Uniswap V4-handelsbot
Poolidentitet i en Uniswap v4-handelsbot begynder med den korrekte blockchain og PoolManager-installation. Inden for den sammenhæng indeholder poolnøglen de ordnede valutaer, gebyrfelt, tickafstand og hookadresse. En ændring af et af felterne kan identificere en anden pool, selv når de to velkendte tokensymboler forbliver identiske.
Gem hele identiteten i handelsbeslutningen frem for senere at genskabe den fra et søgeresultat. En graf for én pool bør ikke godkende en transaktion mod en anden pool, der tilfældigvis veksler samme aktiver.
For eksempel veksler to hypotetiske markeder tokens A og B. Det ene bruger et fast gebyr og ingen yderligere hookadfærd. Det andet bruger et dynamisk gebyr og en hook med sin egen konfiguration. At behandle dem som udskiftelige kunne knytte det første markeds research til det andets udførelse.
Vejledningen til Uniswap-markeder forklarer den bredere opdagelsesproces. V4 kræver, at opdagelsesregistreringen bevarer mere end et parnavn, før den bliver en instruktion, der kan udføres.
Forstå singleton-bogføringsmodellen
PoolManager indeholder tilstanden for flere v4-pools i en fælles kontraktarkitektur. At se på managerens tokensaldo isolerer derfor ikke de reserver, der er tilgængelige for én bestemt pool. En ældre proces bygget på læsning af en separat parkontrakts saldi kræver en anden fortolkning.
En nyttig analogi er et lager, der betjener flere uafhængige konti. Den samlede beholdning i bygningen afslører ikke det beløb, der er tildelt én kunde. Analogien er begrænset, men indfanger, hvorfor fælles opbevaring og poolbogføring skal undersøges separat.
Botten bør bruge poolspecifik tilstand og en understøttet tilbudsmetode. Den bør også registrere den anvendte fortolkning, især når hooks kan påvirke bogføring ud over et enkelt billede af kernelikviditeten.
En usædvanligt stor managersaldo er ikke dokumentation for, at den tilsigtede handel har dyb likviditet. Hvis et dashboard fremmer summen som den tilgængelige dybde i ét nyt tokenmarked, kan dets tilsyneladende præcision skjule en grundlæggende bogføringsfejl.
Adskil initialisering fra brugbar likviditet
En pool kan initialiseres, før den har nyttig likviditet. Initialisering etablerer en begyndelsestilstand; den beviser ikke, at en ordre af den tilsigtede størrelse kan udføres til en acceptabel pris. Forskellen betyder noget for systemer, der reagerer på nyobserverede pools.
Koncentreret likviditet tilføjer endnu en forskel. Kapital knyttet til en pool er ikke nødvendigvis aktiv ved den aktuelle pris. En position uden for det relevante interval kan ikke behandles som identisk med umiddelbart tilgængelig dybde omkring den foreslåede veksling.
Antag, at et fiktivt marked viser betydelig samlet indskudt værdi, men et køb på 200 kvoteringsenheder giver en markant dårligere gennemsnitspris end et køb på 20. Det mindre tilbud validerer ikke den større handel. Botten kræver den tilsigtede mængde, aktuelle intervalforhold og endelig forventet modtagelse.
Vejledningen til tidlig Uniswap-udførelse diskuterer, hvorfor opdagelseshastighed ikke kan fastslå handelsmulighed. En v4-implementering bør udtrykkeligt skelne mellem en pooloprettelsesobservation, en observation af finansieret tilstand og et aktuelt tilbud, der kan udføres.
Hookkontroller i en Uniswap V4-handelsbot
Hookkontroller i en Uniswap v4-handelsbot vedrører både tilladte callbackfunktioner og faktisk adfærd. En hook kan deltage på definerede punkter i poolhandlinger. Viden om aktiverede callbackfunktioner fortæller revieweren, hvor ekstra logik kan køre; den fastslår ikke, at logikken er harmløs eller økonomisk fordelagtig.
Læs den verificerede implementering og relevante konfiguration for den konkrete hook. En genkendelig projektbetegnelse eller en kopieret adresse fra en gammel vejledning fastslår ikke, at den aktuelle rute bruger den gennemgåede installation.
Skeln også mellem hookadressen og den adfærd, som er tilgængelig gennem den. En pools hookadresse er en del af identiteten, men en fast adresse beviser ikke i sig selv, at enhver implementering, administrativ indstilling eller afhængighed bag adressen er uforanderlig.
En fornuftig kompatibilitetsregistrering angiver, hvilke hookadfærdsmønstre botten forstår, og hvilke der får den til at afvise udførelse. Understøttelse af en enkel pool betyder ikke automatisk understøttelse af vilkårlig hooklogik. En ikke-understøttet betingelse bør forblive synlig frem for at forsvinde bag en generisk tilbud lykkedes-betegnelse.
Behandl dynamiske gebyrer som aktuel tilstand
V4 skelner mellem pools konfigureret til faste gebyrer og pools konfigureret til dynamiske gebyrer. For en dynamisk pool kan det relevante gebyr afhænge af opdateringer eller hookadfærd. Det identificerende gebyrfelt må ikke læses, som om det altid var den bogstavelige sats for næste transaktion.
Det ændrer caching. En poolnøgle kan forblive uændret, mens økonomisk relevant gebyrtilstand ændres. En cache kun indekseret efter de to tokenadresser kan overse både den korrekte pool og de aktuelle udførelsesvilkår.
Overvej en fiktiv sammenligning med ellers ens økonomi før gebyrer. Rute A opkræver to enheder i swapomkostning og fem i netværksudgift. Rute B opkræver fire enheder i swapomkostning og én i netværksudgift. Deres samlede omkostninger er henholdsvis syv og fem enheder. Det lavere viste swapgebyr giver ikke den billigste fulde rute.
Eksemplet udelader prispåvirkning og yderligere adfærd for at isolere regnestykket. En virkelig sammenligning skal omfatte enhver forstået omkostning og den forventede endelige kontomodtagelse, ikke blot ét fremhævet gebyrfelt.
Definer, hvad et tilbud faktisk omfatter
Et tilbud bør identificere sin inputmængde, sit outputskøn, rute, tilstandsreference og behandling af relevante omkostninger. Hvis en hook kan indføre yderligere tokenbevægelser eller begrænsninger, skal det afgøres, om tilbudsmetoden modellerer dem. Et tal returneret af en generel grænseflade er ikke automatisk en fuldstændig økonomisk prognose.
Adskil tilbudt output fra disponibel modtagelse. Værdierne kan afvige, når tokenadfærd eller rutespecifikke gebyrer påvirker modtagerkontoen. Botten bør vide, hvilken værdi dens minimumsoutputbeskyttelse begrænser.
Forestil dig tilbudte 10.000 enheder, der bliver 9.700 disponible enheder efter et modelleret fradrag. Sammenligning med en anden rute, der leverer 9.850 disponible enheder, kræver konsekvente definitioner. At rangere den første efter dens tidligere tal på 10.000 ville sammenligne forskellige udførelsestrin.
Når inkluderingen er usikker, skal usikkerheden rapporteres, og ruten holdes uden for automatisk udførelse. Hyppigere gentagelse af samme ikke-understøttede tilbud forbedrer hverken dets omfang eller pålidelighed.
Læs et sammenhængende sæt tilstande
En handelsbeslutning kombinerer pooltilstand, hookkonfiguration, tokenmetadata, walletkapacitet og rutetilladelser. Aflæsning på vidt forskellige tidspunkter kan give et sæt forhold, der aldrig eksisterede samtidigt. Hurtigere polling erstatter ikke forståelse af deres forhold.
For eksempel kan en cachelagret gebyrobservation ligge før en administrativ opdatering, mens likviditetstilbuddet kommer efter den. Den resulterende forklaring kan tilskrive et output den forkerte gebyrordning, selv hvis swappen selv lykkes.
Bevar tilstandsreferencer og observationstidspunkter sammen med beslutningen. Hvis den understøttede infrastruktur ikke kan give et tilstrækkeligt sammenhængende billede for en bestemt hook, kan botten indsnævre sit understøttede univers eller kræve et nyt verificeringstrin.
Vejledningen til Ethereum-API'er forklarer, hvorfor et svar er dateret dokumentation frem for permanent sandhed. For v4 gælder princippet den yderligere tilstand, en hook indfører, såvel som almindelige saldi og poolprisen.
Udførelsesgrænser i en Uniswap V4-handelsbot
Udførelsesgrænser i en Uniswap v4-handelsbot bør knytte den faktiske rute til den godkendte hensigt. Relevante felter omfatter aktiver, præcis poolsammenhæng, forbrugsbeløb, modtager og acceptabel modtagelse. En udløbsbetingelse er nyttig, hvor den valgte router understøtter den; den bør ikke opfindes som en universel egenskab ved enhver kernehandling.
Skeln mellem hensigter med præcist input og præcist output. At bruge præcis 100 enheder og kræve mindst 9.000 tokens adskiller sig fra at opnå præcis 9.000 tokens og tillade et forbrug på op til 104 enheder. En brugergrænseflade bør ikke stiltiende omsætte den ene instruktion til den anden.
Antag, at et tilbud med præcist input anslår 12.000 tokens, og det valgte minimum er 11.640. Det tillader 360 færre tokens eller 3 % under skønnet. Det lover ikke udførelse ved skønnet og begrænser ikke ethvert muligt fremtidigt tab på den erhvervede position.
Bevar også positionsgrænser uden for tilbuddet. En teknisk gyldig rute kan stadig krænke kontoens eksponeringspolitik, når eksisterende beholdning og uafklarede forpligtelser medregnes.
Henvis og tjen USDC
Henvis og tjen USDCVores affiliateprogram udbetaler i realtid.
Identificer netværkets egen valuta og indpakkede tokens præcist
V4 understøtter repræsentation af netværkets egen valuta, så en bot skal skelne mellem ETH i sin oprindelige form og et indpakket token, selv når begge vedrører samme underliggende aktiv. Ruten og bogføringen bør identificere, hvilken form der bruges, modtages eller omveksles.
Forskellen påvirker tilgængelige midler. En konto med nok indpakkede tokens til en handel kan stadig mangle tilstrækkelig egen netværksvaluta til netværksudgifter. Omvendt kan reservation af al netværksvaluta som handelsinput efterlade utilstrækkelig kapacitet til den tilsigtede udførelsesvej.
Brug separate hovedbogskategorier for handelshovedstol, indpaknings- eller udpakningsbevægelser og netværksomkostninger. Flytning af værdi mellem oprindelige og indpakkede former bør ikke automatisk fremstå som en handelsgevinst.
I et fiktivt eksempel begynder en konto med 0,30 netværksenheder og reserverer 0,02 til forventede driftsbehov. Dens tilgængelige handelsbudget i netværksvaluta er højst 0,28 under den politik før andre forpligtelser. Et forslag på 0,29 overskrider politikken, selv hvis en ren saldokontrol siger, at der er tilstrækkelige midler.
Knyt tilladelser til den faktiske forbruger
Pool, hook, router og modtager af tilladt forbrugsbeløb er ikke udskiftelige roller. En bot bør forklare, hvilken komponent der kan flytte brugerens tokens, og hvorfor tilladelsen kræves til den valgte vej. Genkendelse af poolen validerer ikke en uvedkommende godkendelsesanmodning.
Gennemgå tilladelsesomfang adskilt fra handelsstørrelse. Et tilsigtet køb på 100 enheder retfærdiggør ikke antagelsen om, at et langt større tilladt forbrugsbeløb har samme praktiske eksponering. Kontoens bevarede nøgler fjerner heller ikke den beføjelse, der allerede er givet til en anden kontrakt.
Vejledningen til ERC-20-tilladelser giver den underliggende forskel for tilladte forbrugsbeløb. Anvend den på den faktiske forbruger brugt af den understøttede v4-rute frem for at godkende den adresse, der vises i en praktisk grænsefladedialog.
Tilladelsesændringer kræver også deres egen status. En bekræftet forbrugsgodkendelse er ikke et afsluttet køb. Hvis den efterfølgende swap opgives eller mislykkes, bør hovedbog og grænseflade bevare forskellen mellem godkendt tokenbevægelse og faktisk tokenbevægelse.
Fortolk flash-bogføring uden at opfinde gratis kapital
V4's flash-bogføring sporer saldoændringer under handlinger og kræver, at de relevante forpligtelser afregnes ved interaktionens slutning. Det kan reducere unødvendige mellemliggende overførsler i det understøttede udførelsesforløb. Det skaber ikke en garanteret handelsgevinst.
En bot skal stadig forstå hele handlingssekvensen og de endelige forpligtelser. En række hver for sig attraktive trin kan efterlade et ugunstigt slutbeløb, når gebyrer, afrunding og ruteadfærd medregnes.
Det gør heller ikke uvedkommende transaktioner atomare. To separat indsendte handlinger eller handlinger på forskellige blockchains får ikke alt-eller-intet-adfærd, blot fordi én komponent bruger v4-bogføring.
Vurder atomicitet ved den faktiske transaktionsgrænse. Hvis en strategi afhænger af en anden uafhængig transaktion, skal det beskrives, hvad der sker, når den første lykkes og den anden mislykkes. Eksponeringen hører til i positionsplanen frem for at skjules af et teknisk begreb knyttet til første handling.
Afstem kontoen frem for den viste pris
Det endelige bogføringsspørgsmål er, hvad kontoen brugte, modtog og stadig ejer. En grafpris eller en transaktion indsendt-besked kan ikke alene besvare det. Bevar den endelige transaktionsstatus og relevante kontoændringer.
For et fiktivt køb giver 100 kvoteringsenheder plus to enheder i særskilt målt udgift en samlet anskaffelsesomkostning på 102. Salg af hele den modtagne position senere for 110 nettoenheder giver otte enheder i gevinst. En vist prisstigning på 10 % ændrer ikke resultatet på otte enheder.
Hvis kun halvdelen af positionen sælges, skal anskaffelsesomkostningen fordeles konsekvent, og den resterende beholdning bevares. Kald ikke hele positionen rentabel, blot fordi den realiserede halvdel har et fordelagtigt resultat, mens den usolgte halvdel er forringet.
Hvor netværkets egen valuta også betaler gas, skal hovedstolsbevægelsen adskilles fra netværksdebiteringen. Ellers kan en metode baseret på saldoforskelle forveksle driftsudgifter med yderligere købsstørrelse eller skjule det faktisk modtagne beløb ved en udgang.
Del eksponeringen på tværs af lignende pools
Handel med samme token gennem to forskellige v4-poolnøgler skaber ikke to uvedkommende økonomiske eksponeringer. Poolidentitet betyder noget for udførelse, men porteføljeidentitet betyder også noget for risiko. Botten kræver begge synsvinkler.
Antag, at en konto allerede har 240 enheder i eksponering mod et token og et uafklaret køb på 60 enheder. Et nyt forslag på 80 enheder gennem en anden pool med hooks ville bringe bundet eksponering op på 380. Under et loft på 350 enheder overskrider forslaget den tilgængelige kapacitet med 30.
Annullering af én rute frigiver ikke dens reservation, før botten fastslår den resulterende tilstand. En usikker transaktion bør ikke tælles som helt sikkert fraværende, blot fordi en nyere pool nu giver et bedre tilbud.
Bevar et fælles budget på aktivniveau og samtidig rutespecifikke registreringer. Det lader en reviewer forstå både, hvorfor en bestemt pool blev valgt, og hvorfor en ellers attraktiv handel blev afvist på grund af eksisterende forpligtelser andre steder.
Diagnosticér en tilbagerulning før ændring af handlen
En tilbagerullet transaktion betyder ikke nødvendigvis, at minimumsoutputtet var for strengt. Årsagen kan vedrøre en hookbetingelse, uforenelig tokenadfærd, utilstrækkelig tilladelse eller en ruteantagelse, der ikke længere passer til aktuel tilstand. Højere tolerance uden klassifikation af fejlen kan godkende en dårligere pris og samtidig lade det faktiske problem være urørt.
Bevar den oprindelige beslutning og dens fejldokumentation. Sammenlign den forventede vej med den tilstand og det svar, der blev observeret under udførelse. Hvis årsagen stadig er ukendt, bør et nyt forsøg ikke arve et ubegrænset genforsøgsbudget, blot fordi det tidligere forsøg ikke erhvervede tokens.
Mislykkede forsøg kan stadig bruge netværksressourcer. I en hypotetisk session bruger seks mislykkede transaktioner til 0,40 enheder hver 2,40 enheder, før et vellykket køb begynder at tjene eller tabe noget. En senere handelsgevinst på tre enheder ville kun efterlade 0,60 efter de målte forsøg, forudsat ingen andre omkostninger.
Fejlhovedbogen hører derfor til ved siden af positionshovedbogen. Den hjælper med at skelne en strategi med acceptable udførte handler fra en implementering, der bruger for meget på at nå dem. En driftspause kan være berettiget af gentagne fejl i uforenelig tilstand, selv når aktivets markedsudsigter ikke har ændret sig.
Gennemgå ændringer uden at omskrive fortiden
Hookkonfigurationsændringer fortjener daterede registreringer. Når en reviewer sammenligner udfald før og efter en ændring, bør strategien ikke lade, som om hver handel brugte dagens indstillinger. Ellers kan en tilsyneladende forbedring blot afspejle andre udførelsesforhold, der aldrig blev registreret.
Bevar poolidentitet, gennemgået implementeringssammenhæng og relevant konfigurationsreference sammen med hver afsluttet beslutning. Hvis en ny gennemgang ændrer det, botten understøtter, skal tilladelsen anvendes på efterfølgende handlinger frem for at omdøbe tidligere dokumentation, som om den allerede opfyldte den nye standard.
Et praktisk eksempel er en konto, der kun må handle med et snævert sæt forståede hooks. Tilføjelse af endnu en hook bør kræve en udtrykkelig kompatibilitetsbeslutning med en begrundelse. Et token, der allerede ejes gennem en ældre rute, godkender ikke automatisk den nye rute.
Historikken understøtter også tilbagetrækning af tilladelse. Når dokumentation bliver ufuldstændig eller modstridende, kan systemet stoppe åbning af ny eksponering og samtidig bevare de registreringer, der kræves til styring af eksisterende beholdninger. Beslutningen om at stoppe tilføjelse af risiko og beslutningen om en eksisterende position er beslægtede, men separate.
Test bevidst de ikke-understøttede tilfælde
En meningsfuld simulering bør omfatte mere end en vellykket swap mod en velkendt pool. Medtag et tilfælde med manglende likviditet, en forældet gebyrobservation, en ændret hookkonfiguration, utilstrækkelig driftsvaluta og en rute, der giver mindre end det konfigurerede minimum.
Test også identitetsfejl. Et gyldigt tokenpar sammen med forkert hookadresse eller tickafstand bør ikke bestå, fordi symbolerne ser korrekte ud. Det forventede resultat er afvisning af den ikke-matchende hensigt med en nyttig forklaring.
Registrer omfanget af hver test. En vellykket simulering ved én tilstand giver dokumentation om den tilstand og rute. Den beviser ikke permanent kompatibilitet med alle fremtidige konfigurationer eller med en anden hook, der udstiller lignende callbackfunktioner.
Den praktiske standard er en forklarlig udførelsesgrænse. En velspecificeret bot kan angive, hvilke pools den forstår, hvilke forhold der godkender en handel, hvilke grænser der begrænser den, og hvilken endelig dokumentation der lukker hovedbogen. Pools uden for grænsen forbliver researchkandidater, indtil den manglende fortolkning er afklaret.