En DEX-bot til limitordrer hjælper med at udtrykke en acceptabel tokenveksling og styrer ordren, mens markedsforholdene ændres. Det velkendte navn kan skjule forskellige mekanismer. Ét system kan offentliggøre signerede vilkår, som en anden deltager kan udføre. Et andet kan overvåge en pris og først indsende en swap, når en udløser aktiveres.

Begge kan være nyttige, men de skaber forskellige forpligtelser og fejlsituationer. En prisgrænse i en applikation er ikke automatisk en prisgrænse, der håndhæves under afregning. En ordre vist som aktiv er ikke nødvendigvis finansieret, mulig at finde eller attraktiv for nogen, der kunne udføre den.

Denne vejledning forklarer forskellene gennem originale fiktive eksempler. Den handler om veksling af spottokens frem for gearede positioner. Målet er at gøre ordrens betydning og resterende eksponering forståelig, herunder det fuldt mulige udfald, at en acceptabel handel aldrig sker.

Identificer mekanismen bag ordrebetegnelsen

Begynd med at spørge, hvad der eksisterer, efter at brugeren trykker på indsend. Der kan være en signeret off-chain ordre, en transaktion, der registrerer en ordre on-chain, en deponeret allokering eller en lokal overvågningsregel. Den faktiske mekanisme afgør, hvilken komponent der skal forblive tilgængelig, og hvor gyldigheden håndhæves.

En signeret ordre kan godkende en senere veksling uden at overføre aktiverne straks. En lokal udløser kan forblive blot en instruktion om at konstruere en fremtidig transaktion. En deponeringsløsning kan binde aktiver til en kontrakt, hvis hæve- og udførelsesregler kræver særskilt undersøgelse.

Udled ikke disse egenskaber af ordet decentraliseret. De relevante forhold er ordrevilkår, afregningskontrakt, opbevaring af aktiver, opdagelse og de parter, der kan handle. Forskellige løsninger foretager forskellige afvejninger uden at passe ind i én universel fortælling om opbevaring.

Vejledningen til limitordrer for meme-coins giver nyttig baggrund om udløsere og udløb. Denne artikel fokuserer på det yderligere spørgsmål om, hvad der skal forblive sandt, for at en udestående DEX-ordre kan udføres.

Definer prisbeskyttelse i en DEX-bot til limitordrer

Prisbeskyttelse i en DEX-bot til limitordrer bør beskrives som en grænse for den godkendte veksling med angivelse af dens præcise omfang. En sælger kan kræve mindst tolv kvoteringsenheder for hvert vekslet token. En køber kan godkende højst otte kvoteringsenheder pr. erhvervet token.

Grænsen lover ikke gennemførelse. Når ingen kan eller vil opfylde vilkårene, forbliver positionen eller det ubrugte budget. Det er en bevidst afvejning mellem acceptabel pris og sikkerhed for udførelse, ikke nødvendigvis en funktionsfejl.

Skeln også mellem vekselforholdet og det fuldstændige kontoudfald. Netværksgebyrer, gældende serviceomkostninger og usædvanlig tokenoverførselsadfærd kan ligge uden for en forenklet vist pris. Brugeren skal vide, om det angivne minimum henviser til kontraktbeløb eller faktisk modtagne aktiver.

En vurdering bør undersøge, hvad afregningsmekanismen kontrollerer, frem for at behandle grænsefladens betegnelse som bevis. Et overvåget mål kombineret med en uafhængigt valgt swaptolerance kan give en anden økonomisk grænse end det mål, brugeren husker.

Skriv vekslingen i entydige tokenbeløb

Hver ordre kræver præcise netværks- og aktividentifikatorer, retning, beløb og modtagere. Symboler er praktiske betegnelser, men dobbelte navne eller ensartet præsenterede aktiver kan gøre en tilsyneladende korrekt pris til en godkendelse af den forkerte veksling.

Udtryk vekslingen i menneskeligt læsbare enheder, og bevar samtidig de underliggende heltalsbeløb og decimalfortolkningen. Salg af 250 enheder af ét token for mindst 3.000 kvoteringsenheder indebærer tolv kvoteringsenheder pr. token. At vende forholdet om giver et andet tal med en anden enhed.

For en købsordre skal du afgøre, om brugeren fastlægger forbrugsbeløbet, den ønskede erhvervede mængde eller begge gennem et forhold. En maksimal pris fastlægger ikke i sig selv det samlede budget. En ordre kræver stadig et mængdeloft og en klar omkostningsbehandling.

Vejledningen til Uniswap-markedet på Base forklarer, hvorfor blockchain-, aktiv- og poolidentitet betyder noget. En arbejdsgang til limitordrer fører disse identifikatorer videre fra opdagelse til den godkendelse, der kan forblive brugbar, efter at den oprindelige skærm lukkes.

Adskil en udløser fra afregningsgrænsen

Overvej en fiktiv applikation, der overvåger et token til ti kvoteringsenheder. Den har fået besked på at sælge, når en observation når tolv. Når betingelsen indtræffer, anmoder applikationen om et swaptilbud og forbereder en transaktion.

Hvis den resulterende transaktion tillader en effektiv veksling under tolv, var tolv en udløser, ikke det håndhævelige salgsminimum. Adfærden kan være tilsigtet, men brugeren bør se begge indstillinger, før de godkendes.

Omvendt kan en håndhævelig ordre, der kræver mindst tolv, forblive uudført, efter at grafen viser handel over tolv et andet sted. Det observerede handelssted, ordrestørrelsen, ruteomkostningerne og udførelsesmuligheden kan afvige fra de konkrete vilkår, der afventer afregning.

En nyttig test undersøger det ugunstige forløb: udløseren aktiveres, og derefter ændres den pris, der kan udføres, før afsendelse. Botten bør enten bevare den godkendte grænse eller anmode om en beslutning fastlagt i politikken. Stiltiende lempelse af grænsen for at få en gennemført handel ændrer brugerens økonomiske instruktion.

En handelsarbejdsgang på MegaETH tilføjer endnu en tidsmæssig forskel: hurtig udførelsesdokumentation og sequencerens forhåndsbekræftelse skal stadig adskilles fra senere afregning på Ethereum.

For en bevægelig udløser tilføjer opsætning af glidende stop på en DEX en varig registreret top og bevarer samtidig forskellen mellem signalet og en acceptabel modtagelse, der kan udføres.

Forstå finansiering uden at antage, at aktiver er låst

Nogle løsninger med signerede ordrer lader aktiverne blive i ordreudstederens wallet indtil udførelse. I den ordning kan kontoejeren skabe andre forpligtelser, der konkurrerer om samme saldo. En synlig ordre beviser ikke i sig selv, at hele beløbet stadig er tilgængeligt.

Andre mekanismer deponerer aktiver eller reserverer ressourcer gennem deres egen bogføring. Botten skal følge den faktiske løsning, herunder hvad der gør midler mulige at hæve, og om samme beholdning kan understøtte en anden handling.

Brug en intern forpligtelseshovedbog, selv når den underliggende mekanisme tillader overtegning. Hvis en konto ejer 500 tokens, og to ordrer, der kan udføres uafhængigt, hver tilbyder 400, bør grænsefladen forklare, at de ikke begge kan gennemføres som skrevet uden yderligere beholdning.

Stol ikke på midlertidig underfinansiering som en varig annulleringsmetode. Hvor den signerede godkendelse forbliver gyldig, kan senere opfyldning af kontoen genoprette dens mulighed for udførelse. Finansiering, godkendelse og annullering er separate tilstande, der kræver separate registreringer.

Behandl forbrugsgodkendelse og ordregodkendelse separat

I en ERC-20-arbejdsgang vedrører et tilladt tokenforbrugsbeløb ejerens tilladelse til, at en bestemt forbruger overfører dette token. ERC-20-specifikationen definerer den underliggende model for tilladte forbrugsbeløb. En ordre kan indføre yderligere signerede vilkår om beløb, modtagere og gyldighed.

Eksistensen af et tilladt forbrugsbeløb beviser ikke, at en bestemt ordre aktuelt er gyldig. Ligeledes fjerner annullering af én ordre ikke nødvendigvis enhver tokentilladelse givet til dens afregningsinfrastruktur. Brugeren bør forstå begge forhold.

Undersøg den tilsigtede forbruger, blockchain og token før godkendelse. Et velkendt brandnavn på en skærm erstatter ikke verificering af tilladelsens faktiske omfang. Ordrens modtager fortjener samme opmærksomhed som dens pris.

Tilladelsesændringer kan påvirke anden legitim aktivitet på samme konto. En bot bør beskrive konsekvenserne af tilbagekaldelse eller udskiftning frem for at behandle alle tilladelser som baggrundsindstillinger, der uden videre kan kasseres. Målet er en godkendelseskæde, der kan gennemgås, med hver tilladelse knyttet til den handling, der behøver den.

Følg en fiktiv livscyklus med delvise udførelser

Antag en hypotetisk mekanisme, der udtrykkeligt understøtter gentagne delvise udførelser. En konto tilbyder 1.000 eksempeltokens for mindst tre kvoteringsenheder hver. Den oprindelige salgsmængde er 1.000, og det oprindelige minimale bruttovederlag er 3.000 kvoteringsenheder.

En første afsluttet udførelse veksler 400 tokens til 1.220 kvoteringsenheder. Dens gennemsnitspris er 3,05. Den udestående salgsmængde bliver 600 tokens. En anden udførelse veksler yderligere 250 til 775 kvoteringsenheder, gennemsnitligt 3,10.

Den afsluttede mængde er nu 650, bruttovederlaget er 1.995, og den uudførte mængde er 350. Det samlede afsluttede gennemsnit er omtrent 3,0692 kvoteringsenheder pr. token. Gennemsnittet beskriver den udførte del; det værdiansætter ikke den resterende beholdning til samme pris.

Disse tal illustrerer kun delvise udførelser i en DEX-bot til limitordrer for en mekanisme, der understøtter adfærden. En enkelt atomar swap og en stående ordre, der kan udføres delvist, er forskellige modeller. Botten bør ikke opfinde en aktiv rest, når den underliggende handling enten blev gennemført fuldt ud eller rullet tilbage.

Hold delvis udførelse og bogføring i overensstemmelse

Fortsæt det fiktive eksempel med en samlet anskaffelsesomkostning på to kvoteringsenheder pr. token. De 650 afsluttede tokens bærer 1.300 enheder i allokeret kostpris under denne forenklede konvention pr. enhed. Antag tyve yderligere kvoteringsenheder i omkostninger, der kan henføres til de afsluttede salg.

Realiseret nettoprovenu er 1.975, hvilket giver en realiseret gevinst på 675. De resterende 350 tokens beholder 700 enheder i anskaffelsesomkostninger. Deres fremtidige værdi og endelige salgsudfald er fortsat ukendte.

Et dashboard, der anvender den afsluttede gennemsnitspris på alle 1.000 tokens, ville overdrive, hvad der er solgt. Et dashboard, der ignorerer den resterende beholdning, ville miste et økonomisk betydningsfuldt aktiv. Begge fejl opstår ved at reducere ordretilstand til én gennemførelsesprocent.

Registrer hver udførelses identifikator, tokenbevægelser og omkostningsbehandling, og afstem derefter summen mod kontoen. Vejledningen til udførelse på Pancakeswap diskuterer fortolkning af ruter og tilbud, som også hjælper med at forklare, hvorfor et vist forslag og et afsluttet walletprovenu kan afvige.

Undersøg, hvorfor en berørt pris måske ikke giver udførelse

En grafpris kan afspejle en lille transaktion, en anden pool eller et andet kvoteringsaktiv. Den kan fastslå, at en handel skete på et vist niveau, uden at fastslå, at brugerens hele ordre kunne udføres dér.

I et system, der afhænger af eksterne ordreudførere, skal nogen finde ordren og have en økonomisk grund til at afregne den under protokollens regler. Omkostninger, konkurrerende muligheder og tilgængelige ruter kan betyde noget, selv når det viste vekselforhold ser fordelagtigt ud.

Behandl dette som en mekanismespecifik forklaring, ikke som en påstand om, at enhver DEX bruger samme model med eksterne ordreudførere. En indbygget ordrebog eller en swap indsendt af applikationen har andre opdagelses- og udførelsesbegrænsninger.

Mål den nyttige størrelse: hvor ofte fik en gyldig, finansieret ordre en gennemførlig udførelsesmulighed ved dens faktiske størrelse? At tælle enhver berøring på grafen som en forpasset garanteret udførelse skaber misvisende resultatstatistik og kan opfordre brugere til at lempe begrænsninger af den forkerte grund.

Definer udløb som en del af den økonomiske beslutning

En ordres acceptable veksling kan blive forældet, når brugerens forhold ændres. Udløb sætter en grænse for, hvor længe godkendelsen skal forblive brugbar. Det bør være en del af den oprindelige beslutning, ikke et uklart felt arvet fra en standardindstilling.

Verificér, hvordan mekanismen vurderer tidsfristen. En lokal timer, en on-chain gyldighedsbetingelse og en tjenestes frist for opdagelse er ikke indbyrdes udskiftelige. Det relevante spørgsmål er, hvornår et afregningsforsøg ikke længere kan opfylde de faktiske ordrevilkår.

En bot bør skelne mellem en bekræftet udløbet ordre og en skærm, der er holdt op med at vise den. Bevar den oprindelige tidsfrist, tidskonvention og observerede slutstatus, så en bruger kan forklare, hvorfor en senere udførelse skete eller ikke skete.

Fornyelse er en ny økonomisk beslutning. Automatisk genskabelse af en udløbet ordre på ubestemt tid undergraver formålet med en tidsgrænse, medmindre den fornyelsespolitik udtrykkeligt blev valgt. Kontrollér den resterende mængde, aktuelle finansiering og fortsatte hensigt igen, før endnu en gyldighedsperiode godkendes.

Håndter annulleringskapløb i en DEX-bot til limitordrer

Annullering i en DEX-bot til limitordrer kræver dokumentation for, at den resterende godkendelse ikke længere kan udføres under dens regler. At trykke på annuller eller modtage en afsendelsesbekræftelse kan begynde processen uden at fuldføre den.

Vend tilbage til den fiktive ordre med 350 udestående tokens. Mens en annullering afventer, veksler endnu en gyldig udførelse 100 tokens til 305 kvoteringsenheder. Når den udførelse og annulleringen er afklaret, er 750 tokens solgt, og 250 forbliver usolgte.

Det annullerede beløb er derfor 250 i dette scenarie, ikke de 350, der blev vist, da annulleringen begyndte. At rapportere det større tal ville slette en virkelig udførelse og efterlade beholdningsregistreringer i uoverensstemmelse med kontoen.

Forskellige mekanismer bruger forskellige annulleringsmetoder. Nogle kræver en on-chain ugyldiggørelse, mens en rent lokal usendt regel kan deaktiveres i applikationen. Systemet bør forklare, hvilket tilfælde der gælder, og bør ikke behandle sletning af en lokal række som universel annullering af tidligere distribuerede signerede vilkår.

Håndter annulleringskapløb i en DEX-bot til limitordrerPrice ReachedValid and FundedFill UneconomicExpired TermsNo CompletionTRADING FIELD NOTESEDUCATIONAL RESOURCE
At en graf berører den ønskede pris, fastslår ikke, at den faktiske ordre kan eller vil blive udført.

Udskift en ordre uden at fordoble forpligtelsen

Ændring af den ønskede pris kan kræve annullering eller ugyldiggørelse af den gamle godkendelse og oprettelse af en ny. Hvor udskiftning ikke er atomar, kan begge versioner midlertidigt forblive mulige at udføre. Overlappet hører til i beholdnings- og finansieringsberegningen.

Antag, at ejeren vil erstatte et salg af 300 tokens til fire kvoteringsenheder med et salg af de samme 300 til 3,80. At offentliggøre erstatningen, før den oprindelige ordre er afklaret, kan skabe to særskilte salgsforpligtelser frem for én opdateret ordre.

Den korrekte håndtering afhænger af mekanismens faktiske regler for udskiftning og ugyldiggørelse. Botten bør bevare versionsforhold og vide, om de gamle vilkår stadig har en mulig virkning, før deres reserverede mængde frigives.

Prisændringer bør også bevare brugerens tilsigtede omkostningsgrænse. Hvis skærmen viser et anslået nettoresultat, leverer ændring af et bruttovekselforhold alene måske ikke nettobeløbet efter gældende omkostninger. Genberegn forhåndsvisningen, og gør den ændrede godkendelse forståelig.

Omsæt et nettomål til forenelige vilkår

Antag, at en separat fiktiv sælger ønsker mindst 120 kvoteringsenheder efter salg af ti tokens og betaling af en antaget fast omkostning på to kvoteringsenheder. Under disse forenklede antagelser skal salget give mindst 122 kvoteringsenheder brutto eller 12,20 pr. token. En bruttogrænse på tolv ville ikke opfylde det angivne nettomål.

Faktiske omkostninger kan variere, og delvis udførelse kan ændre, hvordan et fast gebyr fordeles over den afsluttede mængde. Forhåndsvisningen bør angive sine antagelser frem for at præsentere én omregnet pris som en permanent garanti for nettoprovenu.

Prisintervaller kan skabe endnu et omsætningsproblem. Hvis en mekanisme kun accepterer priser i hundrededele af en enhed, kan et beregnet sælgerminimum på 12,347 ikke repræsenteres præcist. Afrunding til 12,34 lemper minimumskravet, mens 12,35 bevarer en strengere grænse. En købers maksimum har det modsatte retningshensyn.

Brug mekanismens faktiske beløbs- og præcisionsregler, som kan udtrykke et forhold frem for et almindeligt pristrin. Det vigtige princip er, at formatering og afrunding ikke stiltiende må godkende en veksling uden for brugerens grænse. Hvis de ønskede vilkår ikke kan repræsenteres, skal de justerede vilkår forklares, før ordren oprettes.

Mål uudførte ordrer som en del af strategien

En vurdering, der kun rapporterer afsluttede ordrer, kan skjule strategiens udvælgelseseffekter. Grænser, der ser fordelagtige ud, kan blive udført under ugunstige forhold, mens andre forslag forbliver urørte. Den afsluttede stikprøve alene kan ikke fastslå, hvad hele beslutningsprocessen opnåede.

Bevar uudførte og udløbne ordrer i researchregistreringen sammen med deres oprindelige hensigt. For et salg kan beholdelse af aktivet give senere gevinster eller tab. For et køb kan ubrugte midler bevare kapital eller forpasse en mulighed. Disse udfald hører til strategisammenligningen, selv når der ikke var et transaktionsgebyr.

Sammenlign alternativer med samme beslutningstidspunkter og tilgængelige dokumentation. En markedsorienteret veksling, en afgrænset stående ordre og ingen handling eksponerer kontoen mod forskellige forløb. Tildel ikke den uudførte limitordre en hypotetisk fordelagtig udførelse, blot fordi en senere graf ser ud til at krydse dens pris.

Det gør udførelsesraten til et beskrivende mål frem for et mål, der skal maksimeres for enhver pris. En lav udførelsesrate kan afsløre uegnede vilkår, men at lempe vilkårene ændrer strategien og kræver sin egen vurdering.

Forklar vedvarende gyldighed, når grænsefladen lukkes

En lokal overvågning kan kræve en kørende proces for at observere sin udløser og konstruere en transaktion. En tidligere distribueret signeret ordre kan følge en anden livscyklus, fordi andre deltagere kan beholde en kopi og forsøge afregning under dens gyldighedsregler.

Derfor bør lukning af en browser, afbrydelse af en walletvisning eller stop af en bot ikke automatisk beskrives som annullering af enhver udestående ordre. Brugeren skal vide, hvilke godkendelser der består, og hvilke overvågningsopgaver der stopper.

Gendannelse bør genopbygge sættet af udestående ordrer fra varige registreringer og passende afregningsdokumentation. En manglende lokal cache er ikke en ren tavle, hvis tidligere signerede vilkår fortsat er brugbare. Afstem afsluttede mængder, før den resterende forpligtelse genskabes.

Samme princip gælder ved flytning mellem grænseflader. Eksportér nok information til at identificere ordrer og deres sluttilstande, og verificér derefter uafklarede godkendelser gennem den relevante mekanisme. En ny grænseflade bør ikke antage, at den gamle tog sine økonomiske forpligtelser med sig, da den forsvandt.

Vurder løsningen med ugunstige tilfælde

En nyttig vurdering omfatter en uudført gyldig ordre, utilstrækkelig finansiering, ændret tilladelse, udløb, en delvis udførelse og et annulleringskapløb. Disse tilfælde afslører mere om løsningen end en enkelt vellykket transaktion til en fordelagtig pris.

Test regnestykker med fiktive registreringer, før du stoler på dem med væsentlige midler. Registreringen bør bevare forholdet mellem oprindeligt beløb, afsluttet beløb og afklaret rest. Omkostninger bør optræde én gang, og viste gennemsnit bør kun gælde for den mængde, de faktisk beskriver.

Test også et token eller en rute, som mekanismen ikke understøtter. Det passende resultat kan være en klar afvisning. En bot, der forsøger at håndtere ethvert aktiv gennem samme antagelser, kan give mindre nyttig adfærd end en, der forklarer sit snævrere omfang.

En DEX-bot til limitordrer gør sig fortjent til tillid ved at bevare brugerens vekselvilkår og forklare hver uafklaret forpligtelse. Prisgrænsen er én del af arbejdet. Finansiering, gyldighed, delvis udførelse og annullering afgør, om grænsen forbliver meningsfuld gennem hele ordrens liv.

Lær mere

Udforsk alle ressourcer