En handelsbot for Uniswap v4 må identifisere og forstå en bestemt pool før den kan automatisere en handel. Tokenparet alene er utilstrekkelig. Gebyrkonfigurasjon, avstand mellom prissteg og hook-adressen inngår også i poolens identitet, mens den omkringliggende kjeden og den utrullede forvalteren fastslår hvor identiteten har betydning.
Dette betyr noe fordi kjente antakelser fra tidligere automatiserte markedsskapere ikke overføres uendret. En v4-pool trenger ikke være en separat parkontrakt som holder egne lett tolkbare tokensaldoer. Hooks kan tilføre atferd, og et vist gebyrfelt beskriver ikke alltid det gjeldende gebyret på neste byttehandel. Veiledningen forklarer hvordan forskjellene vurderes uten å anta at hver pool eller hook støttes. Alle talleksempler er oppdiktede.
Poolidentitet i en Uniswap V4-handelsbot
Poolidentitet i en Uniswap v4-handelsbot begynner med riktig kjede og PoolManager-utrulling. I denne sammenhengen inneholder poolnøkkelen de ordnede valutaene, gebyrfeltet, avstanden mellom prissteg og hook-adressen. En endring i ett av feltene kan identifisere en annen pool selv når de to kjente tokensymbolene forblir identiske.
Lagre fullstendig identitet i handelsbeslutningen fremfor å rekonstruere den senere fra et søkeresultat. En graf for én pool bør ikke godkjenne en transaksjon mot en annen pool som tilfeldigvis veksler samme aktiva.
For eksempel veksler to hypotetiske markeder token A og B. Det ene bruker et fast gebyr og ingen ekstra hook-atferd. Det andre bruker et dynamisk gebyr og en hook med egen konfigurasjon. Å behandle dem som utbyttbare kan knytte det første markedets forskning til det andre markedets utførelse.
Markedsveiledningen for Uniswap forklarer den bredere oppdagelsesprosessen. V4 krever at oppdagelsesregistreringen beholder mer enn et parnavn før den blir en gjennomførbar instruksjon.
Forstå regnskapsmodellen med én felles kontrakt
PoolManager holder tilstanden til flere v4-pooler innenfor en felles kontraktsarkitektur. Å se på forvalterens tokensaldo isolerer derfor ikke reservene som er tilgjengelige for én bestemt pool. En eldre prosess basert på saldoavlesning fra en separat parkontrakt trenger en annen tolkning.
En nyttig analogi er et lager som betjener flere uavhengige kontoer. Hele beholdningen i bygningen avslører ikke mengden tildelt én kunde. Analogien er begrenset, men forklarer hvorfor felles oppbevaring og poolregnskap må undersøkes separat.
Boten bør bruke poolspesifikk tilstand og en støttet tilbudsmetode. Den bør også registrere hvilken tolkning den brukte, særlig når hooks kan påvirke regnskapsføringen utover en enkel visning av kjernelikviditet.
En uvanlig stor forvaltersaldo er ikke dokumentasjon på at den tiltenkte handelen har dyp likviditet. Hvis et oversiktspanel markedsfører totalen som tilgjengelig dybde i ett nytt tokenmarked, kan den tilsynelatende presisjonen skjule en grunnleggende regnskapsfeil.
Skill initialisering fra brukbar likviditet
En pool kan initialiseres før den har nyttig likviditet. Initialisering etablerer en starttilstand; den beviser ikke at en ordre av tiltenkt størrelse kan utføres til en akseptabel pris. Skillet betyr noe for systemer som reagerer på nylig observerte pooler.
Konsentrert likviditet gir enda et skille. Kapital knyttet til en pool er ikke nødvendigvis aktiv ved nåværende pris. En posisjon utenfor det relevante intervallet kan ikke behandles som identisk med umiddelbart tilgjengelig dybde rundt den foreslåtte vekslingen.
Anta at et oppdiktet marked viser en betydelig samlet innskuddsverdi, men et kjøp på 200 noteringsenheter gir en langt dårligere gjennomsnittspris enn et kjøp på 20. Det mindre tilbudet validerer ikke den større handelen. Boten trenger tiltenkt mengde, gjeldende intervallforhold og endelig forventet mottak.
Veiledningen om tidlig utførelse på Uniswap drøfter hvorfor oppdagelseshastighet ikke kan fastslå omsettelighet. En v4-implementasjon bør uttrykkelig skille en observasjon av poolopprettelse, en observasjon av finansiert tilstand og et aktuelt gjennomførbart tilbud.
Hook-kontroller i en Uniswap V4-handelsbot
Hook-kontroller i en Uniswap v4-handelsbot gjelder både tillatte callback-funksjoner og faktisk atferd. En hook kan delta på definerte punkter i pooloperasjoner. Å vite hvilke callback-funksjoner som er aktivert, forteller kontrolløren hvor ekstra logikk kan kjøre; det fastslår ikke at logikken er harmløs eller økonomisk gunstig.
Les den bekreftede implementasjonen og relevante konfigurasjonen for den konkrete hooken. Et gjenkjennelig prosjektnavn eller en kopiert adresse fra en gammel veiledning fastslår ikke at den nåværende ruten bruker den gjennomgåtte utrullingen.
Skill også hook-adressen fra atferden som er tilgjengelig gjennom den. En pools hook-adresse er del av identiteten, men en fast adresse beviser ikke i seg selv at hver implementasjon, administrativ innstilling eller avhengighet bak adressen er uforanderlig.
En fornuftig kompatibilitetsregistrering angir hvilke hook-atferder boten forstår, og hvilke som får den til å avstå fra utførelse. Støtte for en enkel pool betyr ikke automatisk støtte for vilkårlig hook-logikk. En betingelse som ikke støttes, bør forbli synlig fremfor å forsvinne bak en generell melding om vellykket pristilbud.
Behandle dynamiske gebyrer som nåværende tilstand
V4 skiller pooler konfigurert for faste gebyrer fra pooler konfigurert for dynamiske gebyrer. For en dynamisk pool kan det relevante gebyret avhenge av oppdateringer eller hook-atferd. Det identifiserende gebyrfeltet må ikke leses som om det alltid var den bokstavelige satsen på neste transaksjon.
Dette endrer hurtigbufring. En poolnøkkel kan forbli uendret mens økonomisk relevant gebyrtilstand endres. En hurtigbuffer indeksert bare etter de to tokenadressene kan bomme både på riktig pool og gjeldende utførelsesvilkår.
Se for deg en oppdiktet sammenligning med ellers lik økonomi før gebyrer. Rute A har to enheter i byttekostnad og fem enheter i nettverksutgift. Rute B har fire enheter i byttekostnad og én enhet i nettverksutgift. Samlede kostnader er henholdsvis sju og fem enheter. Det lavere viste byttegebyret gir ikke den billigste fullstendige ruten.
Eksemplet utelater prispåvirkning og ekstra atferd for å isolere regningen. En virkelig sammenligning må inkludere hver forstått kostnad og forventet endelig kontomottak, ikke bare ett fremtredende gebyrfelt.
Definer hva et pristilbud faktisk inkluderer
Et pristilbud bør identifisere innsatsmengde, mottaksanslag, rute, tilstandsreferanse og behandling av relevante kostnader. Hvis en hook kan innføre ekstra tokenbevegelser eller begrensninger, avgjør om tilbudsmetoden modellerer dem. Et tall returnert av et generelt grensesnitt er ikke automatisk en fullstendig økonomisk prognose.
Skill tilbudt mottak fra brukbart mottak. Verdiene kan avvike når tokenatferd eller rutespesifikke kostnader påvirker mottakerkontoen. Boten bør vite hvilken verdi beskyttelsen for minste mottak avgrenser.
Se for deg et tilbud på 10.000 enheter som blir 9.700 brukbare enheter etter et modellert fradrag. Sammenligning med en annen rute som leverer 9.850 brukbare enheter, krever konsekvente definisjoner. Å rangere den første etter det tidligere tallet 10.000 ville sammenligne forskjellige utførelsesstadier.
Når inkluderingen er usikker, rapporter usikkerheten og hold ruten utenfor automatisk utførelse. Å gjenta samme tilbud uten støtte oftere forbedrer verken omfang eller pålitelighet.
Les et sammenhengende sett med tilstand
En handelsbeslutning kombinerer pooltilstand, hook-konfigurasjon, tokenmetadata, lommebokkapasitet og rutetillatelser. Å lese disse på vidt forskjellige tidspunkter kan gi et sett opplysninger som aldri eksisterte samlet. Raskere avspørring erstatter ikke forståelse av forholdet mellom dem.
For eksempel kan en mellomlagret gebyrobservasjon komme før en administrativ oppdatering mens likviditetstilbudet kommer etter. Forklaringen som følger, kan tilskrive et mottak feil gebyrregime selv om selve byttehandelen lykkes.
Behold tilstandsreferanser og observasjonstidspunkter med beslutningen. Hvis støttet infrastruktur ikke kan gi et tilstrekkelig sammenhengende bilde for en bestemt hook, kan boten snevre inn støttet univers eller kreve et nytt verifiseringstrinn.
API-veiledningen for Ethereum forklarer hvorfor et svar er datert dokumentasjon fremfor varig sannhet. For v4 gjelder prinsippet tilleggstilstanden en hook innfører, så vel som vanlige saldoer og poolpris.
Utførelsesgrenser i en Uniswap V4-handelsbot
Utførelsesgrenser i en Uniswap v4-handelsbot bør knytte den faktiske ruten til den godkjente hensikten. Relevante felt inkluderer aktivaene, nøyaktig poolkontekst, forbruksbeløp, mottaker og akseptabelt mottak. En utløpsbetingelse er nyttig der valgt ruter støtter en; den bør ikke finnes på som en universell egenskap ved enhver kjerneoperasjon.
Skill hensikter med nøyaktig innsats fra nøyaktig mottak. Å bruke nøyaktig 100 enheter og kreve minst 9.000 tokener er forskjellig fra å motta nøyaktig 9.000 tokener og tillate forbruk opptil 104 enheter. Et grensesnitt bør ikke i det stille gjøre én instruks om til den andre.
Anta at et tilbud med nøyaktig innsats anslår 12.000 tokener og valgt minimum er 11.640. Det tillater 360 færre tokener, eller 3 % under anslaget. Det lover ikke utførelse ved anslaget og setter ikke et tak på ethvert mulig fremtidig tap i den anskaffede posisjonen.
Hold posisjonsgrenser utenfor tilbudet også. En teknisk gyldig rute kan fortsatt bryte kontoens eksponeringsregler når eksisterende beholdning og uavklarte forpliktelser tas med.
Henvis og tjen USDC
Henvis og tjen USDCPartnerprogrammet vårt betaler i sanntid.
Identifiser nettverksvaluta og innpakkede tokener presist
V4 støtter representasjon av nettverkets egen valuta, så en bot må skille nettverkets ETH fra et innpakket token selv når begge er knyttet til samme underliggende aktivum. Ruten og regnskapet bør identifisere hvilken form som brukes, mottas eller veksles.
Skillet påvirker tilgjengelige midler. En konto med nok innpakkede tokener til en handel kan fortsatt mangle tilstrekkelig nettverksvaluta til nettverksutgifter. Omvendt kan reservering av all nettverksvaluta som handelsinnsats etterlate utilstrekkelig kapasitet til den tiltenkte utførelsesveien.
Bruk separate regnskapskategorier for handelshovedstol, bevegelser ved innpakking eller utpakking og nettverkskostnader. Å flytte verdi mellom egen og innpakket form bør ikke automatisk fremstå som handelsgevinst.
I et oppdiktet eksempel starter en konto med 0,30 nettverksenheter og reserverer 0,02 til forventede driftsbehov. Tilgjengelig handelsbudsjett i nettverksvaluta er maksimalt 0,28 etter denne regelen, før andre forpliktelser. Et forslag på 0,29 overskrider regelen selv om en kontroll bare av saldo sier at tilstrekkelige midler finnes.
Knytt tillatelser til den faktiske aktøren med forbruksrett
Poolen, hooken, ruteren og fullmaktsmottakeren er ikke utbyttbare roller. En bot bør forklare hvilken komponent som kan flytte brukerens tokener, og hvorfor tillatelsen er nødvendig for den valgte veien. Å gjenkjenne poolen validerer ikke en uvedkommende godkjenningsforespørsel.
Gjennomgå tillatelsesomfang separat fra handelsstørrelse. Et tiltenkt kjøp på 100 enheter rettferdiggjør ikke å anta at en langt større fullmakt har samme praktiske eksponering. Kontoens beholdte nøkler fjerner heller ikke myndigheten som allerede er gitt en annen kontrakt.
Tillatelsesveiledningen for ERC-20 gir det underliggende fullmaktsskillet. Bruk det på den faktiske aktøren med forbruksrett i den støttede v4-ruten fremfor å godkjenne enhver adresse som vises i en praktisk grensesnittforespørsel.
Tillatelsesendringer trenger også egen status. En bekreftet godkjenning er ikke et fullført kjøp. Hvis den senere byttehandelen oppgis eller mislykkes, bør regnskap og grensesnitt bevare forskjellen mellom godkjent tokenbevegelse og faktisk tokenbevegelse.
Tolk flash-regnskap uten å finne på gratis kapital
V4s flash-regnskap følger saldoendringer under operasjoner og krever at relevante forpliktelser gjøres opp innen slutten av interaksjonen. Det kan redusere unødvendige mellomliggende overføringer i den støttede utførelsesflyten. Det skaper ikke garantert handelsfortjeneste.
En bot må fortsatt forstå hele handlingsrekken og de endelige forpliktelsene. En rekke hver for seg attraktive trinn kan etterlate et ugunstig sluttbeløp når gebyrer, avrunding og ruteatferd inkluderes.
Det gjør heller ikke uvedkommende transaksjoner atomiske. To separat innsendte operasjoner, eller handlinger på forskjellige kjeder, får ikke alt-eller-ingenting-atferd bare fordi én komponent bruker v4-regnskap.
Vurder atomisitet ved den faktiske transaksjonsgrensen. Hvis en strategi avhenger av en andre uavhengig transaksjon, beskriv hva som skjer når den første lykkes og den andre mislykkes. Eksponeringen hører hjemme i posisjonsplanen fremfor å skjules av et teknisk begrep knyttet til første operasjon.
Avstem kontoen fremfor den viste prisen
Det endelige regnskapsspørsmålet er hva kontoen brukte, mottok og fortsatt eier. En grafpris eller en melding om innsendt transaksjon kan ikke besvare spørsmålet alene. Bevar endelig transaksjonsstatus og relevante kontoendringer.
For et oppdiktet kjøp gir 100 noteringsenheter pluss to enheter i separat målt utgift en samlet anskaffelseskostnad på 102. Å selge hele den mottatte posisjonen senere for 110 nettoenheter gir åtte enheter i fortjeneste. En vist prisgevinst på 10 % endrer ikke resultatet på åtte enheter.
Hvis bare halvparten av posisjonen selges, fordel anskaffelseskostnaden konsekvent og bevar gjenværende beholdning. Ikke kall hele posisjonen lønnsom bare fordi den realiserte halvparten har et gunstig resultat mens den usolgte halvparten har forverret seg.
Der nettverksvaluta også betaler gas, skill hovedstolbevegelsen fra nettverksbelastningen. Ellers kan en metode basert på saldoforskjell forveksle driftsutgifter med ekstra kjøpsstørrelse eller skjule faktisk mottatt beløp ved et salg.
Hold eksponeringen felles på tvers av lignende pooler
Handel med samme token gjennom to forskjellige v4-poolnøkler skaper ikke to ubeslektede økonomiske eksponeringer. Poolidentitet betyr noe for utførelse, men porteføljeidentitet betyr også noe for risiko. Boten trenger begge perspektiver.
Anta at en konto allerede har 240 enheter i eksponering mot et token og et uavklart kjøp på 60 enheter. Et nytt forslag på 80 enheter gjennom en annen pool med hook ville øke bundet eksponering til 380. Under et tak på 350 enheter overstiger forslaget tilgjengelig kapasitet med 30.
Kansellering av én rute frigjør ikke reservasjonen før boten fastslår den resulterende tilstanden. En usikker transaksjon bør ikke telles som definitivt fraværende bare fordi en nyere pool nå tilbyr et bedre pristilbud.
Behold et felles budsjett på aktivanivå og samtidig rutespesifikke registreringer. Da kan en kontrollør forstå både hvorfor en bestemt pool ble valgt, og hvorfor en ellers attraktiv handel ble avvist på grunn av eksisterende forpliktelser andre steder.
Diagnostiser en reversering før handelen endres
En reversert transaksjon betyr ikke nødvendigvis at minste mottak var for strengt. Årsaken kan gjelde en hook-betingelse, inkompatibel tokenatferd, utilstrekkelig tillatelse eller en ruteforutsetning som ikke lenger samsvarer med gjeldende tilstand. Å øke toleransen uten å klassifisere feilen kan godkjenne en dårligere pris og samtidig la det faktiske problemet stå urørt.
Bevar den opprinnelige beslutningen og feildokumentasjonen. Sammenlign forventet vei med tilstanden og svaret observert under utførelse. Hvis årsaken forblir ukjent, bør et nytt forsøk ikke arve et ubegrenset forsøksbudsjett bare fordi forrige forsøk ikke anskaffet tokener.
Mislykkede forsøk kan fortsatt bruke nettverksressurser. I en hypotetisk økt bruker seks mislykkede transaksjoner til 0,40 enheter hver 2,40 enheter før et vellykket kjøp begynner å tjene eller tape noe. En senere handelsgevinst på tre enheter ville etterlate bare 0,60 etter disse målte forsøkene, forutsatt ingen andre kostnader.
Feilregnskapet hører derfor hjemme ved siden av posisjonsregnskapet. Det hjelper med å skille en strategi med akseptable utførte handler fra en implementasjon som bruker for mye på å nå utførelsene. En driftspause kan begrunnes med gjentatte feil ved inkompatibel tilstand selv når aktivumets markedsutsikter ikke er endret.
Gjennomgå endringer uten å omskrive fortiden
Hook-konfigurasjonsendringer fortjener daterte registreringer. Når en kontrollør sammenligner utfall før og etter en endring, bør strategien ikke late som hver handel brukte dagens innstillinger. Ellers kan en tilsynelatende forbedring bare gjenspeile andre utførelsesforhold som aldri ble registrert.
Behold poolidentiteten, den gjennomgåtte implementasjonskonteksten og relevant konfigurasjonsreferanse med hver fullført beslutning. Hvis en ny gjennomgang endrer hva boten støtter, bruk tillatelsen på senere handlinger fremfor å ommerke tidligere dokumentasjon som om den allerede oppfylte den nye standarden.
Et praktisk eksempel er en konto med tillatelse til å handle bare et snevert sett forståtte hooks. Å legge enda en hook til settet bør kreve en uttrykkelig kompatibilitetsbeslutning med begrunnelse. Et token som allerede holdes gjennom en eldre rute, godkjenner ikke automatisk den nye ruten.
Denne historikken støtter også tilbaketrekking av tillatelse. Når dokumentasjonen blir ufullstendig eller motstridende, kan systemet stoppe åpning av ny eksponering og samtidig bevare registreringene som trengs for å håndtere eksisterende beholdninger. Beslutningen om å slutte å legge til risiko og beslutningen om en eksisterende posisjon er beslektede, men separate.
Test tilfellene som ikke støttes, bevisst
En meningsfull simulering bør inkludere mer enn en vellykket byttehandel mot en kjent pool. Ta med et tilfelle med manglende likviditet, en utdatert gebyrobservasjon, en endret hook-konfigurasjon, utilstrekkelig driftsvaluta og en rute som gir mindre enn konfigurert minimum.
Test også identitetsfeil. Et gyldig tokenpar kombinert med feil hook-adresse eller avstand mellom prissteg bør ikke bestå fordi symbolene ser riktige ut. Forventet resultat er avvisning av hensikten som ikke samsvarer, med en nyttig forklaring.
Registrer omfanget til hver test. En vellykket simulering ved én tilstand etablerer dokumentasjon om denne tilstanden og ruten. Den beviser ikke varig kompatibilitet med alle fremtidige konfigurasjoner eller en annen hook med lignende callback-funksjoner.
Den praktiske standarden er en forklarlig utførelsesgrense. En godt spesifisert bot kan angi hvilke pooler den forstår, hvilke opplysninger som godkjenner en handel, hvilke grenser som avgrenser den, og hvilken endelig dokumentasjon som avslutter regnskapet. Pooler utenfor grensen forblir forskningskandidater til den manglende tolkningen er avklart.