Obchodní bot Uniswap v4 potřebuje před automatizací obchodu určit konkrétní pool a rozumět mu. Samotný pár tokenů nestačí. Konfigurace poplatků, rozestupy ticků a adresa hooku také tvoří identitu poolu, zatímco okolní blockchain a nasazený správce určují, kde má identita význam.
To je důležité, protože známé předpoklady dřívějších automatizovaných tvůrců trhu se nepřenášejí beze změny. Pool v4 nemusí být samostatným kontraktem páru držícím vlastní snadno vyložitelné zůstatky tokenů. Hooky mohou přidávat chování a zobrazené pole poplatku nepopisuje vždy aktuální poplatek dalšího swapu. Průvodce vysvětluje hodnocení těchto rozdílů bez předpokladu podpory každého poolu nebo hooku. Všechny číselné příklady jsou fiktivní.
Identita poolu obchodního bota Uniswap V4
Identita poolu obchodního bota Uniswap v4 začíná správným blockchainem a nasazením PoolManager. V tomto kontextu obsahuje klíč poolu uspořádané měny, pole poplatku, rozestupy ticků a adresu hooku. Změna jednoho pole může určit jiný pool, i když dva známé symboly tokenů zůstanou stejné.
Úplnou identitu ukládejte do obchodního rozhodnutí místo pozdější rekonstrukce z výsledku hledání. Graf jednoho poolu nemá povolovat transakci vůči jinému poolu, který náhodou směňuje stejná aktiva.
Například dva hypotetické trhy směňují tokeny A a B. Jeden používá pevný poplatek bez dalšího chování hooku. Druhý dynamický poplatek a hook s vlastní konfigurací. Jejich zaměňování by mohlo přiřadit výzkum prvního trhu k provádění druhého.
Průvodce trhy Uniswap vysvětluje širší vyhledávání. V4 vyžaduje v záznamu více než název páru před vznikem proveditelné instrukce.
Pochopte model evidence sdíleného správce
PoolManager drží stav více poolů v4 ve sdílené architektuře kontraktu. Pohled na tokenový zůstatek správce proto neodděluje rezervy dostupné konkrétnímu poolu. Starší postup založený na čtení zůstatků samostatného kontraktu páru potřebuje jiný výklad.
Užitečnou analogií je sklad obsluhující několik nezávislých účtů. Celkové zásoby uvnitř budovy neodhalují množství přidělené jednomu zákazníkovi. Analogie má omezení, ale vystihuje potřebu samostatně zkoumat společnou úschovu a evidenci poolů.
Bot má používat stav konkrétního poolu a podporovanou metodu kotace. Má také zaznamenat použitý výklad, zvláště pokud hooky mohou ovlivňovat evidenci nad rámec jednoduchého pohledu na základní likviditu.
Neobvykle velký zůstatek správce není důkazem hluboké likvidity zamýšleného obchodu. Pokud panel propaguje součet jako dostupnou hloubku jednoho nového trhu tokenu, zdánlivá přesnost může skrývat základní účetní chybu.
Oddělte inicializaci od použitelné likvidity
Pool může být inicializován před získáním užitečné likvidity. Inicializace ustavuje počáteční stav; nedokazuje proveditelnost objednávky zamýšlené velikosti za přijatelnou cenu. Rozlišení je důležité pro systémy reagující na nově pozorované pooly.
Koncentrovaná likvidita přidává další rozdíl. Kapitál spojený s poolem nemusí být při aktuální ceně aktivní. Pozice mimo příslušný rozsah nemůže být považována za totožnou s okamžitě dostupnou hloubkou kolem navrhované směny.
Předpokládejme fiktivní trh s velkou celkovou vloženou hodnotou, ale nákup za 200 kotovacích jednotek vytváří výrazně horší průměrnou cenu než nákup za 20. Menší kotace neověřuje větší obchod. Bot potřebuje zamýšlené množství, aktuální podmínky rozsahů a konečný očekávaný příjem.
Průvodce časným prováděním na Uniswap rozebírá, proč rychlé vyhledání nedokládá obchodovatelnost. Implementace v4 má výslovně rozlišovat pozorování vytvoření poolu, financovaného stavu a aktuální proveditelnou kotaci.
Kontroly hooků obchodního bota Uniswap V4
Kontroly hooků obchodního bota Uniswap v4 se týkají povolených zpětných volání i skutečného chování. Hook se může účastnit definovaných bodů operací poolu. Znalost zapnutých zpětných volání říká hodnotiteli, kde může běžet další logika; nedokládá její neškodnost ani ekonomickou příznivost.
Přečtěte ověřenou implementaci a příslušnou konfiguraci konkrétního hooku. Rozpoznatelný název projektu nebo adresa zkopírovaná ze starého návodu nedokládají, že aktuální trasa používá prověřené nasazení.
Rozlišujte také adresu hooku a chování dosažitelné jejím prostřednictvím. Adresa hooku patří do identity poolu, ale pevná adresa sama nedokazuje neměnnost každé implementace, administrátorského nastavení nebo závislosti za ní.
Rozumný záznam kompatibility uvádí, kterým chováním hooků bot rozumí a která vedou k odmítnutí provedení. Podpora prostého poolu automaticky neznamená podporu libovolné logiky hooků. Nepodporovaná podmínka má zůstat viditelná místo zmizení za obecným označením úspěšné kotace.
Považujte dynamické poplatky za aktuální stav
V4 rozlišuje pooly nastavené pro pevné a dynamické poplatky. U dynamického poolu může příslušný poplatek záviset na aktualizacích nebo chování hooku. Identifikační pole poplatku se nesmí číst jako vždy doslovná sazba příští transakce.
To mění ukládání do mezipaměti. Klíč poolu může zůstat stejný, zatímco ekonomicky významný stav poplatku se mění. Mezipaměť indexovaná pouze dvěma adresami tokenů může minout správný pool i aktuální podmínky provedení.
Uvažujme fiktivní srovnání s jinak stejnou ekonomikou před poplatky. Trasa A účtuje dvě jednotky nákladu swapu a pět síťových výdajů. Trasa B čtyři jednotky nákladu swapu a jednu síťového výdaje. Celkové náklady jsou sedm a pět jednotek. Nižší zobrazený poplatek swapu nevytváří levnější úplnou trasu.
Příklad vynechává cenový dopad a další chování pro oddělení výpočtu. Skutečné porovnání musí zahrnovat každý pochopený náklad a očekávaný konečný příjem účtu, nikoli jen jediné hlavní pole poplatku.
Definujte skutečný obsah kotace
Kotace má určit vstupní množství, odhad výstupu, trasu, referenci stavu a zacházení s příslušnými náklady. Pokud hook může zavést další pohyby tokenů nebo omezení, zjistěte, zda je metoda kotace modeluje. Číslo vrácené obecným rozhraním není automaticky úplnou ekonomickou předpovědí.
Oddělte kotovaný výstup od použitelného příjmu. Hodnoty se mohou lišit, když chování tokenu nebo poplatky trasy ovlivňují přijímající účet. Bot má vědět, kterou hodnotu ochrana minimálního výstupu omezuje.
Představte si kotovaných 10 000 jednotek měnících se po modelované srážce na 9 700 použitelných jednotek. Porovnání s trasou dodávající 9 850 použitelných jednotek potřebuje jednotné definice. Řazení první trasy podle dřívějších 10 000 by porovnávalo různé fáze provedení.
Při nejistotě zahrnutí ji ohlaste a ponechte trasu mimo automatické provádění. Častější opakování stejné nepodložené kotace nezlepšuje její rozsah ani spolehlivost.
Čtěte soudržnou sadu stavu
Obchodní rozhodnutí spojuje stav poolu, konfiguraci hooku, metadata tokenu, kapacitu peněženky a oprávnění trasy. Jejich čtení ve velmi různých okamžicích může vytvořit soubor skutečností, které nikdy neexistovaly společně. Rychlejší dotazování nenahrazuje pochopení vztahu.
Například uložené pozorování poplatku může předcházet administrátorské aktualizaci, zatímco kotace likvidity následuje po ní. Výsledné vysvětlení může výstup přiřadit nesprávnému poplatkovému režimu, i když swap uspěje.
Reference stavu a časy pozorování uchovávejte s rozhodnutím. Pokud podporovaná infrastruktura nedokáže poskytnout dostatečně soudržný pohled na konkrétní hook, bot může zúžit podporovaný soubor nebo vyžadovat nový ověřovací krok.
Průvodce API Etherea vysvětluje, proč je odpověď časově určeným podkladem, nikoli trvalou pravdou. U v4 princip platí pro další stav zavedený hookem i pro běžné zůstatky a cenu poolu.
Limity provedení obchodního bota Uniswap V4
Limity provedení obchodního bota Uniswap v4 mají svázat skutečnou trasu s povoleným záměrem. Relevantní pole zahrnují aktiva, přesný kontext poolu, utrácenou částku, příjemce a přijatelný příjem. Podmínka vypršení je užitečná, kde ji vybraný router podporuje; nemá být vymyšlená jako univerzální vlastnost každé základní operace.
Rozlišujte záměry přesného vstupu a přesného výstupu. Útrata přesně 100 jednotek s požadavkem nejméně 9 000 tokenů se liší od získání přesně 9 000 tokenů s povolenou útratou až 104 jednotek. Uživatelské rozhraní nemá tiše převádět jeden pokyn na druhý.
Předpokládejme kotaci přesného vstupu odhadující 12 000 tokenů a zvolené minimum 11 640. Dovoluje o 360 tokenů méně, tedy 3 % pod odhadem. Neslibuje provedení za odhad ani neomezuje každou možnou budoucí ztrátu pořízené pozice.
Limity pozice držte také mimo kotaci. Technicky platná trasa stále může porušovat pravidla expozice účtu při zahrnutí existující držby a nevyřešených závazků.
Doporučujte a vydělávejte USDC
Doporučujte a vydělávejte USDCNáš partnerský program vyplácí v reálném čase.
Přesně určete nativní měnu a zabalené tokeny
V4 podporuje reprezentaci nativní měny, takže bot musí odlišovat nativní ETH a zabalený token, i když oba souvisejí se stejným podkladovým aktivem. Trasa a evidence mají určit utrácenou, přijímanou nebo převáděnou podobu.
Rozlišení ovlivňuje dostupné prostředky. Účet vlastnící dost zabalených tokenů na obchod stále může postrádat nativní měnu pro síťové výdaje. Naopak rezervování veškeré nativní měny jako obchodního vstupu může ponechat nedostatečnou kapacitu zamýšlené cesty provedení.
Používejte samostatné evidenční kategorie obchodní jistiny, pohybů zabalení nebo rozbalení a síťových nákladů. Přesun hodnoty mezi nativní a zabalenou podobou nemá automaticky vypadat jako obchodní zisk.
Ve fiktivním příkladu účet začíná s 0,30 nativní jednotky a rezervuje 0,02 na očekávané provozní potřeby. Dostupný nativní obchodní rozpočet je podle těchto pravidel nejvýše 0,28 před dalšími závazky. Návrh 0,29 překračuje pravidla, i když kontrola samotného zůstatku ukazuje dostatek.
Mapujte oprávnění ke skutečnému subjektu oprávněnému nakládat s tokeny
Pool, hook, router a subjekt oprávněný nakládat s tokeny nejsou zaměnitelné role. Bot má vysvětlit, která součást může přesouvat tokeny uživatele a proč zvolená cesta toto oprávnění potřebuje. Rozpoznání poolu neověřuje nesouvisející žádost o schválení.
Rozsah oprávnění kontrolujte samostatně od velikosti obchodu. Zamýšlený nákup za 100 jednotek neopravňuje předpokládat stejnou praktickou expozici mnohem většího povoleného objemu. Ponechané klíče účtu také neodstraňují pravomoc již udělenou jinému kontraktu.
Průvodce oprávněními ERC-20 poskytuje základní rozlišení povoleného objemu. Použijte jej na skutečný subjekt oprávněný nakládat s tokeny podporované trasy v4 místo schvalování libovolné adresy z pohodlné výzvy rozhraní.
Také změny oprávnění potřebují vlastní stav. Potvrzené schválení není dokončeným nákupem. Pokud následný swap opustíte nebo selže, evidence a rozhraní mají zachovat rozdíl povoleného a skutečného pohybu tokenů.
Vykládejte průběžné vyrovnávání bez vymýšlení bezplatného kapitálu
Průběžné vyrovnávání v4 neboli flash accounting sleduje změny zůstatků během operací a vyžaduje vypořádání příslušných závazků do konce interakce. Může snížit zbytečné mezilehlé převody v podporovaném postupu provedení. Nevytváří zaručený obchodní zisk.
Bot stále potřebuje rozumět úplné posloupnosti akcí a konečným závazkům. Série jednotlivě přitažlivých kroků může po zahrnutí poplatků, zaokrouhlování a chování trasy zanechat nepříznivou konečnou částku.
Také nečiní nesouvisející transakce atomickými. Dvě samostatně odeslané operace nebo akce na různých blockchainech nezískávají chování vše, nebo nic jen proto, že jedna součást používá evidenci v4.
Atomicitu hodnoťte na skutečné hranici transakce. Pokud strategie závisí na druhé nezávislé transakci, popište situaci úspěchu první a selhání druhé. Tato expozice patří do plánu pozice, nikoli za technický pojem první operace.
Sesouhlasujte účet místo zobrazené ceny
Konečnou účetní otázkou je, co účet utratil, přijal a stále vlastní. Cena grafu nebo zpráva transakce odeslána samy neodpovídají. Zachovejte konečný stav transakce a příslušné změny účtu.
U fiktivního nákupu vytváří 100 kotovacích jednotek plus dvě samostatně měřené jednotky výdaje celkový pořizovací náklad 102. Pozdější prodej celé přijaté pozice za čistých 110 jednotek vytváří zisk osm jednotek. Zobrazený cenový zisk 10 % tento výsledek nemění.
Pokud se prodá jen polovina pozice, rozdělujte pořizovací náklad jednotně a zachovejte zbývající držbu. Nenazývejte celou pozici ziskovou jen kvůli příznivému výsledku realizované poloviny, zatímco neprodaná polovina se zhoršila.
Kde nativní měna platí také gas, oddělte pohyb jistiny od síťového odepsání. Jinak metoda rozdílu zůstatků může zaměnit provozní výdaje za další velikost nákupu nebo zamlžit skutečně přijatou částku výstupu.
Sdílejte expozici napříč podobnými pooly
Obchodování stejného tokenu přes dva různé klíče poolu v4 nevytváří dvě nesouvisející ekonomické expozice. Identita poolu je důležitá pro provedení, ale identita portfolia také pro riziko. Bot potřebuje oba pohledy.
Předpokládejme účet již držící expozici 240 jednotek tokenu s nevyřešeným nákupem 60 jednotek. Nový návrh 80 jednotek přes jiný pool s hookem by zvýšil vázanou expozici na 380. Při stropu 350 jednotek překračuje dostupnou kapacitu o 30.
Zrušení jedné trasy neuvolňuje rezervaci, dokud bot nezjistí výsledný stav. Nejistá transakce se nemá počítat jako určitě neexistující jen proto, že novější pool nabízí lepší kotaci.
Udržujte společný rozpočet aktiva při zachování záznamů konkrétních tras. Hodnotitel tak pochopí důvod výběru poolu i odmítnutí jinak přitažlivého obchodu kvůli existujícím závazkům jinde.
Diagnostikujte vrácení transakce před změnou obchodu
Vrácená transakce nemusí znamenat příliš přísný minimální výstup. Příčina může zahrnovat podmínku hooku, nekompatibilní chování tokenu, nedostatečné oprávnění nebo předpoklad trasy již neodpovídající aktuálnímu stavu. Zvýšení tolerance bez klasifikace selhání může povolit horší cenu a ponechat skutečný problém nedotčený.
Zachovejte původní rozhodnutí a podklady selhání. Porovnejte očekávanou cestu se stavem a odpovědí pozorovanými při provedení. Při neznámé příčině nemá nový pokus dědit neomezený rozpočet opakování jen proto, že předchozí nepořídil tokeny.
Neúspěšné pokusy mohou stále spotřebovávat síťové prostředky. V hypotetické relaci šest neúspěšných transakcí po 0,40 jednotky spotřebuje 2,40 před jakýmkoli výdělkem nebo ztrátou úspěšného nákupu. Pozdější obchodní zisk tři jednotky by po těchto měřených pokusech ponechal jen 0,60 za předpokladu žádných dalších nákladů.
Evidence selhání proto patří vedle evidence pozic. Pomáhá rozlišit strategii s přijatelnými vyplněnými obchody a implementaci utrácející příliš na jejich dosažení. Opakovaná selhání nekompatibilního stavu mohou odůvodnit provozní pozastavení, i když tržní výhled aktiva zůstává stejný.
Posuzujte změny bez přepisování minulosti
Změny konfigurace hooku si zaslouží časově označené záznamy. Při srovnání výsledků před změnou a po ní nemá strategie předstírat dnešní nastavení u každého obchodu. Jinak zdánlivé zlepšení může jen odrážet jiné nezaznamenané podmínky provedení.
S každým dokončeným rozhodnutím uchovejte identitu poolu, kontext prověřené implementace a příslušnou referenci konfigurace. Pokud nová kontrola mění podporu bota, použijte oprávnění pro následné akce místo přeznačení dřívějších podkladů, jako by již splňovaly nový standard.
Praktickým příkladem je účet povolený k obchodování pouze úzkého souboru pochopených hooků. Přidání dalšího má vyžadovat výslovné rozhodnutí kompatibility s důvodem. Token již držený přes starší trasu automaticky nepovoluje novou trasu.
Historie podporuje i odvolání oprávnění. Při neúplných nebo rozporných podkladech může systém zastavit otevírání nové expozice a zachovat záznamy potřebné ke správě existující držby. Rozhodnutí nepřidávat riziko a rozhodnutí o existující pozici jsou související, ale samostatná.
Záměrně testujte nepodporované případy
Smysluplná simulace má zahrnovat více než úspěšný swap se známým poolem. Zařaďte chybějící likviditu, zastaralé pozorování poplatku, změněnou konfiguraci hooku, nedostatečnou provozní měnu a trasu vytvářející méně než nastavené minimum.
Testujte také chyby identity. Platný pár tokenů s nesprávnou adresou hooku nebo rozestupy ticků nemá projít díky správně vypadajícím symbolům. Očekávaným výsledkem je odmítnutí nesouhlasného záměru s užitečným vysvětlením.
Zaznamenejte rozsah každého testu. Úspěšná simulace v jednom stavu poskytuje podklady tohoto stavu a trasy. Nedokazuje trvalou kompatibilitu se všemi budoucími konfiguracemi nebo jiným hookem s podobnými zpětnými voláními.
Praktickým standardem je vysvětlitelná hranice provádění. Dobře specifikovaný bot umí uvést pooly, kterým rozumí, skutečnosti povolující obchod, omezující limity a konečné podklady uzavírající evidenci. Pooly mimo hranici zůstávají výzkumnými kandidáty do vyřešení chybějícího výkladu.