En arbejdsgang for en Aerodrome-bot på Base bør begynde med et bestemt vekslingsspørgsmål: Hvilken understøttet rute kan omsætte det tilsigtede input til det ønskede output på acceptable vilkår? Svaret afhænger af poolmodellen, de faktiske aktiver, beløbet og den aktuelle likviditet. Et velkendt handelssted eller en stor vist indskudssum kan ikke alene besvare spørgsmålet.

Aerodrome omfatter grundlæggende stabile og volatile pools samt infrastruktur til koncentreret likviditet. De markeder bør ikke reduceres til én generisk reserveformel. Denne vejledning følger et selvstændigt eksempel på rutevalg gennem aktivkontrol, modelvalg, omkostningssammenligning og endelig bogføring. Tallene er fiktive, og fokus er på tokenswaps frem for at optjene belønninger som likviditetsudbyder eller fremsætte en prognose om protokollens token.

Rutesammenligning for en Aerodrome-bot på Base

Rutesammenligning for en Aerodrome-bot på Base begynder med at fastholde brugerens mål. Registrer det præcise inputaktiv, det tilgængelige beløb, det ønskede outputaktiv og modtagerkontoen. To tilbud kan kun sammenlignes, når de besvarer stort set samme spørgsmål ved en tilstrækkeligt ensartet tilstand.

Antag, at en trader vil veksle 250 enheder af aktiv A til aktiv B. Det ene tilbud bruger en direkte pool, mens det andet går gennem aktiv C. Begge kan være kandidater, men deres viste output kræver samme behandling af udgifter og endelige modtagelser, før de kan rangeres.

Ændr ikke budgettet under sammenligning af ruter. En rute, der giver mere B, fordi den bruger 260 A, er ikke automatisk bedre end en, der bruger 250 A. Et forslag med præcist output kræver tilsvarende en sammenligning af det samlede input, der kræves for samme ønskede modtagelse.

Oversigten over Aerodrome-markeder introducerer de tilgængelige poolkategorier. En gentagelig sammenligning tilføjer den præcise handelshensigt og en registrering af, hvorfor hver kandidatrute blev godkendt eller afvist.

Identificer Base-aktiverne før deres symboler

Aktividentitet omfatter netværket og tokenkontrakten. Lignende navne kan beskrive ubeslægtede tokens, og et genkendeligt symbol beviser ikke, at kontrakten er det tilsigtede aktiv. Bevar den fulde identitet gennem opdagelse, tilbud, godkendelse og afstemning.

Vær særligt opmærksom på noteringsaktiver. Et token prissat i noget mærket som et dollaraktiv er ikke nødvendigvis prissat i netop det dollaraktiv, kontoen ejer. En forkert sammenkobling af de identiteter kan skabe en tilsyneladende rabat, der forsvinder, når den nødvendige konvertering medregnes.

Vejledningen til Base-tokens forklarer, hvorfor netværkssammenhæng hører sammen med tokenidentitet. Hvis kontoen aktuelt har aktivet et andet sted, er en overførsel mellem netværk en separat operation med egne antagelser om tilgængelighed og omkostninger.

En bot kan observere et attraktivt Base-marked uden at have midler, der straks kan bruges dér. Rutevælgeren bør bruge bekræftet kapacitet på det relevante netværk frem for at behandle en samlet porteføljesaldo som et brugsklart input på hver blockchain.

Vælg prismodellen før beregningen

Den grundlæggende volatile model bruger et konstant produkt. Stabile pools bruger en anden kurve beregnet til relativt korrelerede aktiver. Koncentrerede pools fordeler likviditet inden for intervaller. Forskellene påvirker, hvilken tilstand og beregning der er relevant for den tilsigtede handel.

En genvej baseret på reserveforholdet kan være en nyttig indledende forklaring på en forenklet volatil pool. Den er ikke en universel tilbudsmotor til ethvert Aerodrome-marked. Anvendelse på en ikke-understøttet model kan give et tal, der ser sandsynligt ud, men ikke har nogen pålidelig forbindelse til output, der kan eksekveres.

Bevar modelidentifikationen i ruteregistreringen. De samme tokens kan optræde i mere end én pool, og modellen kan være lige så vigtig som parret, når forskelle mellem tilbuddene skal forklares.

Brug verificerede installerede kontrakter og en understøttet tilbudsmetode frem for at gætte ud fra poolens visningsnavn. En kopieret grænsefladeetiket fastslår ikke den underliggende factory, konfiguration eller udførelsessti, som botten faktisk vil kalde.

Kontrol af stabile pools for en Aerodrome-bot på Base

Kontrol af stabile pools for en Aerodrome-bot på Base vedrører forholdet mellem aktiverne såvel som kurven. Ordet stabil beskriver et tilsigtet prisforhold; det garanterer ikke indløsning, en permanent kursbinding eller en risikofri position.

Forestil dig to fiktive aktiver, der historisk handles tæt på samme værdi. Aktiv A handles nu til 0,94 enheder af B på flere aktuelle markeder. En bot bør undersøge ændringen, før den antager, at køb af A giver en sikker gevinst på seks cent. Afvigelsen kan afspejle et ændret økonomisk krav frem for en midlertidig prisfejl.

Poolen kan fortsat give gyldige tilbud, mens brugerens antagelse om aktiverne bliver forkert. Kontraktudførelse og investeringsbegrundelse er separate spørgsmål. En vellykket swap beviser ikke, at det forventede forhold vil blive genoprettet.

Registrer, hvorfor strategien forventer korrelation, og hvilken dokumentation der ville ugyldiggøre antagelsen. En rute valgt til veksling af korrelerede aktiver bør ikke ubemærket blive til en spekulativ handel på en genopretning, blot fordi det tilbudte output ser usædvanligt gavmildt ud.

Brug et eksempel på en volatil pool inden for dets begrænsninger

Betragt en fiktiv gebyrfri pool med konstant produkt, der indeholder 50.000 tokens og 100 noteringsenheder. Dens oprindelige reserveprodukt er 5.000.000. Tilføjelse af ti noteringsenheder giver 110 noteringsenheder, så den forenklede resterende tokenreserve er cirka 45.454,55. Køberen modtager cirka 4.545,45 tokens.

Det oprindelige reserveforhold antyder 500 tokens pr. noteringsenhed. Multipliceret med ti ville forholdet antyde 5.000 tokens, hvilket overstiger modellens faktiske output med cirka 454,55. Forskellen opstår, fordi handlen selv ændrer forholdet mellem reserverne.

Beregningen er en undervisningsmodel, ikke et aktuelt Aerodrome-tilbud. Faktisk udførelse omfatter gældende gebyrer, afrunding, tokenadfærd og den faktisk installerede rute. Eksemplet skal vise, hvorfor et spotforhold ikke kan erstatte et tilbud for den tilsigtede størrelse.

Det viser også, hvorfor en fordobling af det foreslåede beløb ikke nødvendigvis fordobler outputtet. En bot, der godkender en lille testmængde, bør indhente et nyt tilbud, før købet øges til hele budgettet.

Læs koncentreret dybde omkring den tilsigtede handel

I en koncentreret pool tildeles likviditet til prisintervaller. Det relevante spørgsmål er, hvor meget understøttet likviditet den foreslåede veksling møder på sin vej. Et fremhævet samlet beløb for hele poolen kan omfatte kapital uden for det område.

Antag, at to hypotetiske pools hver viser 100.000 enheder i indskudt værdi. Den ene understøtter en handel på 500 enheder med beskeden bevægelse, mens den anden krydser tyndt dækkede intervaller og giver et væsentligt dårligere resultat. Ens totaler gør ikke deres udførelsesvilkår ens.

Botten behøver ikke forudsige enhver fremtidig likviditetsændring for at genkende den aktuelle forskel. Den behøver en understøttet model og et beløbsspecifikt tilbud, der afspejler den tilstand, den vurderer.

Fortolk ikke et smalt interval som et løfte om, at likviditeten bliver dér. Udbydere kan ændre deres positioner, og prisen kan flytte sig. Rutebeslutningen er en vurdering af aktuelle udførbare vilkår med afgrænset tolerance, ikke en garanti om den tilgængelige dybde ved en senere udgang.

Behandl tickafstand og gebyrer som separate fakta

Koncentrerede pools bruger tickafstand til at begrænse de tilladte intervalgrænser. Konfigurationen indgår i forståelsen af poolen. Den bør ikke blive en udokumenteret genvej til et permanent swapgebyr eller en universel klassifikation af aktivrisiko.

Den aktuelle Aerodrome-dokumentation beskriver gebyrjustering uafhængigt af pooltypen. En integration bør derfor undersøge den faktiske understøttede gebyrkonfiguration frem for at stole på en husket sammenhæng fra et ældre eksempel.

Forskellen betyder noget ved sammenligning af to ellers lignende kandidater. En velkendt etiket kan skjule en gebyrindstilling, der er ændret, siden botten sidst vurderede poolen. Cachen skal bevare den relevante konfiguration og sammenhængen for observationen.

Undgå at gøre en aktuel konfiguration til en permanent antagelse i strategibeskrivelsen. En nyttig regel angiver, hvilken dokumentation der fastslår gebyret i et tilbud, og hvad der udløser en opdatering. Den hævder ikke, at enhver pool med en bestemt etiket altid opkræver en identisk sats.

Sammenlign komplette ruter i ensartede enheder

Vend tilbage til det fiktive input på 250 enheder. En direkte rute anslår 24.500 outputtokens, mens en rute gennem to pools anslår 24.650. Den tilsyneladende fordel er 150 tokens. Hvis rapporteringsværdien er 0,02 enheder pr. outputtoken, er fordelen tre enheder værd ved den værdiansættelse.

Hvis den anden rute kræver yderligere fire enheder i målte udgifter, giver dens større tokenoutput ikke det bedste nettoresultat. Dens anslåede fordel bliver minus én enhed efter den ekstra udgift, forudsat at alle øvrige modellerede forhold er ens.

Bevar både de rå mængder og den værdiansættelse, der blev brugt i sammenligningen. Netværksudgift og outputtokens er forskellige aktiver, og en omregning kan blive forældet. En enkelt score for bedste rute bør ikke skjule den afhængighed.

Vejledningen til automatisk udførelse på Base beskriver forbindelsen mellem forslag og endelige kontoudfald. Rutevalg bør skelne på samme måde mellem en anslået bruttomodtagelse og den samlede omkostning ved at opnå den.

Undersøg mellemaktiver og restbeløb

En rute gennem flere pools kan udsætte transaktionen for et mellemaktivs adfærd, selv når brugeren kun interesserer sig for start- og sluttokens. Kontroller hele stien, og om den understøttede udførelsesmetode afvikler den som én transaktion eller som separate handlinger.

Separate handlinger skaber en yderligere tilstand, der skal håndteres. Hvis den første konvertering gennemføres, og den anden ikke gør, kan kontoen have mellemaktivet. Det udfald er hverken den oprindelige kontantposition eller den tilsigtede endelige investering.

Selv en understøttet enkelttransaktion fortjener kontrol af kvitteringen for tilbagebetalinger eller restsaldi. Hovedbogen bør ikke antage, at hver inputenhed blev brugt, eller at kontoen kun modtog det fremhævede outputtoken.

For eksempel kan et forslag reservere 250 enheder, mens den faktiske udførelse bruger 247 og returnerer tre. Anskaffelsesomkostningen bør afspejle den faktiske debitering og de målte udgifter. At regne hele det reserverede beløb som brugt ville overvurdere omkostningen med tre enheder i det forenklede tilfælde.

Gennemgang af udførelse for en Aerodrome-bot på Base

Gennemgang af udførelse for en Aerodrome-bot på Base forbinder det valgte tilbud med den transaktion, der godkendes. Kontroller de faktiske aktiver, rutekontrakter, modtager, inputbeløb og mindst acceptable modtagelse. Et gunstigt tilbud bør ikke godkende en uvedkommende tilladelsesanmodning eller en anden rute, der vælges senere uden gennemgang.

Hvor den understøttede router har en udløbsbetingelse, skal den knyttes til det tilsigtede beslutningsvindue. Et gammelt tilbud forbliver ikke egnet, blot fordi der stadig kan konstrueres en transaktion ud fra det.

Antag, at den valgte rute anslår 24.500 tokens, og det konfigurerede minimum er 24.010. Den tilladte reduktion er 490 tokens eller 2 %. Grænsen gælder for den relevante transaktions betydning. Den er ikke et løfte om, at handlen udføres, og den begrænser ikke senere markedstab på den anskaffede beholdning.

Hold tilbuddets eksisterende prispåvirkning adskilt fra denne yderligere tolerance. En handel kan allerede være økonomisk uattraktiv, før der sker nogen bevægelse mellem vurdering og udførelse.

Bevar netværkets egen valuta til driftsomkostninger

Base-transaktioner kræver netværksgebyrer betalt i netværkets egen ETH. Den officielle Base-dokumentation skelner mellem udførelsesrelaterede og datarelaterede gebyrkomponenter. En bot bør indhente et aktuelt estimat, der passer til dens transaktion, frem for at kopiere en fast omkostning fra en tidligere swap.

Denne udgift er adskilt fra at eje et ERC-20-token, der skal finansiere vekslingen. En wallet kan have nok inputtokens og stadig mangle netværkets egen valuta til at indsende den tilsigtede operation.

Definer en driftsreserve, der omfatter forventede opfølgende handlinger, ikke kun det indledende køb. Hvis en strategi bruger al tilgængelig driftsvaluta ved indgangen, kan det gøre senere håndtering unødigt vanskelig.

I et fiktivt budget har en konto 0,015 ETH og reserverer 0,004 til driftsbehov. Et foreslået input i netværkets egen valuta over 0,011 ville overstige det resterende budget, før andre forpligtelser medregnes. Reserven er en brugerpolitik i dette eksempel, ikke en påstand om et aktuelt netværksgebyr.

Hold swapbeføjelser adskilt fra andre aktiviteter

Aerodromes økosystem omfatter swaps, tilførsel af likviditet og styringsrelaterede handlinger. Aktiviteterne kan omfatte forskellige aktiver, kontrakter og tilladelser. En bot, der har til opgave at veksle tokens, bør ikke behandle en grænsefladeforbindelse som en bred beføjelse til at deltage i alle tilgængelige operationer.

Læs den faktiske modtager af godkendelsen og beløbet. Det velkendte tokenpar forklarer ikke, hvorfor en bestemt forbruger har brug for beføjelse, og en lille tilsigtet handel gør ikke en langt større forbrugstilladelse økonomisk tilsvarende.

Anskaffelse af et protokoldrevet token er tilsvarende ikke det samme som at tilføre likviditet eller låse en styringsposition. Deres pengestrømme og risici bør ikke sammenblandes i en resultatrapport, der hævder at måle swapudførelse.

Vejledningen til tokentilladelser forklarer forskellen mellem at godkende flytning og at gennemføre en handel. En bekræftet godkendelse kan fortsat være relevant, selv når det efterfølgende køb annulleres eller aldrig indsendes, så den fortjener en separat registrering.

Hold swapbeføjelser adskilt fra andre aktiviteterInput BudgetRouteReceiptNetworkExpenseResidualAssetsAccountResultREVIEW THE RESULT · IMPROVE THE PROCESSTRADING FIELD NOTESEDUCATIONAL RESOURCE
Sammenlign samlede kontoudfald i ensartede enheder frem for at vælge ruten med det største isolerede outputtal.

Vurder udgangen ved den faktiske beholdningsstørrelse

En købsrute fastslår dokumentation om én retning og mængde på ét tidspunkt. Den garanterer ikke, at den resulterende beholdning senere kan sælges til dens viste værdi. Opbyg en separat udgangsvurdering omkring de faktisk modtagne enheder.

Antag, at kontoen anskaffer 24.200 tokens efter udførelsen. Et omvendt tilbud for 100 tokens er ikke dokumentation for afvikling af alle 24.200. Den foreslåede udgang kan møde anden prispåvirkning, likviditet og tokenspecifik adfærd.

Sammenlign flere relevante udgangsstørrelser, hvis strategien forventer delsalg. Formålet er at forstå den aktuelle kapacitet, ikke at fremstille et gunstigt gennemsnit ved kun at indhente tilbud for en ganske lille del af beholdningen.

Skeln også mellem en udløst udgangsregel og et gennemført salg. En markedsobservation kan opfylde en målbetingelse, mens den tilgængelige rute ikke længere opfylder den mindst acceptable modtagelse. Kontoen ejer stadig den usolgte beholdning, indtil dokumentation for udførelsen fastslår andet.

Bogfør delsalg og omkostninger ved forsøg

Forestil dig en fiktiv anskaffelse til 250 enheder plus to enheder i udgift, hvilket giver et samlet anskaffelsesgrundlag på 252. Kontoen modtager 24.000 tokens. Salg af en fjerdedel betyder salg af 6.000 tokens og tildeling af 63 enheder af anskaffelsesgrundlaget efter en proportional metode.

Hvis salget giver 70 nettoenheder, er den realiserede gevinst syv. De resterende 18.000 tokens beholder 189 enheder i anskaffelsesgrundlag. Hvis deres senere nettosalg giver 180, taber den del ni, og den samlede position ender med et tab på to enheder.

Resultatet kan ikke beskrives korrekt ved kun at rapportere det første rentable salg. Det kræver også eventuelle særskilte omkostninger ved forsøg, som ikke allerede indgik i nettobeløbene.

Vejledningen til bogføring af handelsoverskud forklarer den bredere sondring i hovedbogen. Ved ruteanalyse skal anslået output bevares ved siden af endelige modtagelser, så revieweren kan skelne markedsresultat fra udførelseskvalitet og driftsudgift.

Undersøg rutefejl efter deres årsag

En mislykket swap kan afspejle flere forskellige problemer: forældede forhold, utilstrækkelig forbrugstilladelse, ikke-understøttet tokenadfærd, utilgængelig likviditet eller en ugyldig antagelse om ruten. Automatisk forhøjelse af tolerancen behandler årsagerne, som om de alle var prisbevægelse.

Klassificer fejlen, før en ny handling foreslås. Hvis ruten ikke kan understøtte et tokens adfærd, fastslår en bredere tilladelse for minimumsoutput ikke kompatibilitet. Hvis kontoen mangler netværkets egen driftsvaluta, løser et nyt tilbud ikke finansieringsproblemet.

Bevar udgifter fra mislykkede forsøg. Fire mislykkede operationer til 0,30 enheder hver bruger 1,20 enheder. En senere vellykket handel med en gevinst på én enhed før forsøgene er stadig minus 0,20 efter den fulde bogføring.

En nyttig stopregel kan reagere på gentagne uforklarede fejl uafhængigt af markedssignalet. En pause i nye forslag giver systemet mulighed for at afklare sine tilstandsantagelser frem for gentagne gange at betale for en udførelsessti, det ikke længere forstår.

Undgå at tælle flere pools som flere investeringer

Et token kan optræde på et stabilt, volatilt eller koncentreret marked uden at blive til tre forskellige porteføljeeksponeringer. Udførelsesmæssig variation og aktivvariation besvarer forskellige spørgsmål. Kontoen bør samle den underliggende beholdning, selv mens den bevarer separate registreringer for hver rute.

For eksempel optager 180 enheder, der allerede ejes gennem én rute, og et uafklaret køb på 70 enheder gennem en anden tilsammen 250 enheder af samme aktivbudget. Et nyt forslag på 100 enheder ville nå 350, selv hvis dets pool har et andet navn. Under et loft på 300 enheder er der kun 50 enheders kapacitet tilbage.

Brug dette fælles budget før valget af den billigste rute. Ellers kan hver uafhængig ruteproces overholde sin egen lokale grænse, mens deres samlede handlinger overstiger kontoens tilsigtede eksponering. En ny pool er et udførelsesalternativ, ikke en automatisk nulstilling af positionsgrænsen.

Gennemgå rutevalg som en reproducerbar beslutning

Den endelige journal bør forbinde det oprindelige mål, kandidatruter, afvisningsårsager, den valgte sti og de endelige kontoændringer. En reviewer bør kunne se, hvorfor en rute vandt, uden at være afhængig af et skærmbillede af en midlertidig rangering.

Medtag kandidater, der blev afvist. Hvis registreringen kun bevarer vellykkede udførelser, kan den ikke forklare, hvor ofte tilbuddet for den tilsigtede størrelse var uegnet, eller hvor meget kapacitet strategien faktisk krævede.

Gennemgå sammenligningen ved en fast rapporteringshorisont. Den bedst udførte rute beviser ikke, at køb af aktivet var en god investering, ligesom et urentabelt aktiv ikke beviser, at rutevælgeren valgte dårligt blandt de tilgængelige stier.

En effektiv Aerodrome-vurdering holder spørgsmålene adskilt. Aktivtesen forklarer, hvorfor eksponeringen var ønsket. Poolmodellen og tilbuddet for den konkrete størrelse forklarer, hvordan vekslingen blev vurderet. Den endelige hovedbog fastslår, hvad kontoen faktisk betalte og modtog.

Lær mere

Udforsk alle ressourcer