Automatický nákupní bot pro NFT potřebuje vědět, kolik účet ještě může utratit, než rozhodne, o kterou prodejní nabídku se pokusí. Viditelný zůstatek peněženky je pouze částí této otázky. Čekající transakce, podepsané nákupní závazky, provozní prostředky a stávající expozice vůči kolekci mohou všechny omezovat další úkon.
Obtížné případy nastávají, když přichází několik kandidátů najednou nebo pokus o nákup nemá jasný výsledek. Rozpočet započítávající pouze dokončené nákupy může schválit příliš mnoho ještě před vyřešením těchto pokusů. Rozpočet, který po restartu zapomene rezervace, může stejnou chybu zopakovat s přehledem, který vypadá zcela čistě.
Průvodce sleduje smyšlená nákupní pravidla vyjádřená pro plánování v dolarech. Skutečné transakce musí také splňovat požadavky na nativní aktiva a platební tokeny. Všechny částky a výsledky transakcí jsou smyšlené a pravidla jsou účetním příkladem, nikoli doporučením konkrétního investičního rozdělení.
Rozpočet automatického nákupu NFT vymezte srozumitelně
Rozpočet automatického nákupu NFT má uvádět, co omezuje. Může zastropovat celkové pořizovací závazky, útratu během období, expozici vůči jedné kolekci nebo maximální náklad jedné položky. Tato měřítka se překrývají, ale nejsou zaměnitelná.
V příkladu vlastník povoluje nejvýše 1 000 USD pořizovacích závazků vůči kolekci, včetně zaznamenaných nákladů držených položek a rezervovaných možných nákupů. Vlastník také chrání 50 USD na provozní potřeby. Jde o záměrně jednoduchá pravidla, jejichž složky lze prozkoumat.
Pravidlo používá pořizovací náklad místo současných ocenění podle nejnižších prodejních nabídek. Rostoucí nabídková cena proto automaticky nevytváří novou nákupní kapacitu. Zvolí-li vlastník jiné měřítko expozice, má být pojmenováno a důsledně uplatňováno.
Rozpočet je oprávnění, nikoli předpověď cenové dostupnosti nebo výnosů. Peněženka může obsahovat více peněz, než pravidla dovolují botovi utratit. Může také obsahovat příliš málo správného platebního aktiva, i když rozpočtový výpočet ukazuje nevyužitou kapacitu.
Oddělte provozní prostředky od nákupních
Postup může potřebovat nativní aktiva pro síťové operace, údržbu účtu nebo podporované úkony zrušení. Utracení každé dostupné jednotky za NFT může účtu znemožnit pohodlně spravovat pozdější kroky. Provozní rezerva má mít vymezený účel.
Ve smyšlených pravidlech se nepředpokládá okamžité utracení chráněných 50 USD. Jsou vyloučeny z kapacity nových nákupů, aby zůstaly dostupné pro uvedené provozní potřeby. Nepočítejte je současně jako skutečný výdaj a pokračující peněžní rezervu.
Pozornost potřebuje také odpovídající zůstatek nativního aktiva. Rezerva v dolarovém ekvivalentu nezaručuje dostatek ETH, SOL nebo jiného požadovaného aktiva v okamžiku operace. Přepočítací kurzy a požadavky cesty se mohou měnit.
Rezervu ponechte viditelnou v pohledu na účet. Jinak může bot opakovaně hlásit zdánlivý nesoulad mezi povolenou útratou a zůstatkem peněženky a svádět provozovatele k odstranění záměrné kontroly jen kvůli shodnému vzhledu součtů.
Stávající držbu započítávejte podle zvolených pravidel
Předpokládejte, že účet již drží NFT se zaznamenanými pořizovacími náklady 450 USD. Tato částka spotřebovává část stropu závazků 1 000 USD. Zůstává relevantní po dobu držení položek, i když jejich současná ocenění podle nabídkových cen rostou nebo klesají.
Nákladový záznam má zahrnovat složky vymezené pravidly, například skutečné vstupní výdaje. Důslednost je důležitější než volba příznivého zacházení pro každou položku. Rozpočet založený na neúplných pořizovacích záznamech může podhodnotit kapitál, který účet zavázal.
Položka převedená na účet může mít neznámý historický náklad. Bot nemá předpokládat, že je zdarma, jen proto, že pozorovaný převod neprovázela platba. Pravidla potřebují uvedený postup pro nevyřešený nákladový základ nebo položky pořízené externě.
Dokončený prodej mění záznam držby, ale zacházení s výslednou kapacitou závisí na pravidlech. Strop expozice vůči kolekci, denní limit hrubé útraty a limit ztráty mohou na stejný prodej reagovat různě. Bot nemá vymýšlet jedno univerzální pravidlo obnovení.
Možné nákupy rezervujte před odesláním
Rezervace čekajícího nákupu představuje finanční účinek, který ještě může nastat. Rezervace má vzniknout dříve, než souběžné úkoly mohou využít stejnou kapacitu, a má odkazovat na konkrétní ekonomický záměr.
Předpokládejte, že stávající čekající nákupy rezervují 250 USD. S pořizovacími náklady držených položek 450 USD a provozní rezervou 50 USD zbývá účtu podle jednoduchých pravidel s limitem 1 000 USD dalších 250 USD. Rezervace se započítává, i když NFT ještě nepřišla.
Částka má pokrývat povolený maximální náklad navrhovaného úkonu, nikoli pouze nejpříznivější odhad. Pokud skutečná transakce později stojí méně, lze nevyužitý rozdíl uvolnit, jakmile to podpoří výsledek.
Průvodce botem pro nabídky na OpenSea zkoumá závazky vytvořené nabídkami. Ať postup používá nabídky, nebo okamžité nákupy, model účtu musí určit, které povinnosti stále mohou pořídit aktiva a jak se ovlivňují s dostupným rozpočtem.
Strop uplatňujte na úplný pořizovací náklad
Předpokládejte novou položku nabízenou za 240 USD a povolené dodatečné vstupní náklady 12 USD. Úplná navrhovaná částka je 252 USD a překračuje zbývajících 250 USD o 2 USD. Samotná cena položky se vejde, ale schvalované pořízení nikoli.
Pokud obnovený platný návrh místo toho obsahuje cenu položky 238 USD a stejnou rezervu 12 USD, přesně se vejde do kapacity 250 USD. To nezaručuje, že konečná transakce bude provedena nebo využije celou povolenou částku. Uvádí to maximum, které by pravidla pro danou verzi dovolila.
Pokud požadované náklady po schválení vzrostou, bot má návrh obnovit nebo odmítnout. Nemá potichu chápat strop jako platný jen pro zobrazovanou cenu NFT. Rozpočet by jinak selhal právě při zdražení transakčních podmínek.
Odhadovaný, maximální schválený a skutečný náklad zaznamenávejte odděleně. Tyto hodnoty podporují různé otázky: zda návrh vypadá smysluplně, zda je povolen a co účet nakonec utratil. Jediná částka nedokáže vysvětlit všechny tři fáze.
Koordinujte souběžné kandidáty
Dva kandidáti mohou samostatně projít kontrolou zůstatku a přitom nevyhovět společnému rozpočtu. Předpokládejte dva úkoly, z nichž každý kontroluje stejnou zbývající kapacitu 250 USD a navrhuje nákup vyžadující 180 USD. Dohromady by zavázaly 360 USD a překročily kapacitu o 110 USD.
Proces schvalování má krok rezervace provádět postupně nebo jej jinak koordinovat. Jakmile jeden návrh za 180 USD rezervuje svou částku, zbývá na další rozhodnutí podle stejných pravidel pouze 70 USD. Oba úkoly mají vidět aktualizovaný stav účtu.
Rezervace má být dostatečně trvalá, aby přežila přerušení procesu. Pokud existuje jen v paměti a zmizí před zjištěním výsledku transakce, restartovaný bot může zdánlivě dostupných 180 USD znovu utratit za jiného kandidáta.
Jde o rozpočtový požadavek nezávislý na rychlosti trhu. Rychlejší objevování kandidátů zvyšuje význam koordinace, protože více návrhů může soupeřit o stejné prostředky. Dobré výběrové pravidlo nenapraví alokační postup, který každému úkolu dovolí předpokládat, že je jediným kupujícím.
Zachovávejte identitu zamýšleného nákupu
Rezervace má určovat přesné aktivum, cestu, účet a navrhované množství. Bot musí umět rozlišit, zda se nová zpráva týká stejného nákupního záměru, nebo skutečně jiného kandidáta. Duplicitní pozorování nemají opakovaně spotřebovávat kapacitu.
U jednojednotkového NFT mohou opakovaná upozornění na prodejní nabídku odkazovat na jedinou položku, i když se jejich časová razítka liší. U vícejednotkového aktiva záleží také na množství. Rozpočet má sledovat skutečné množství, které lze pořídit podle navrhované instrukce.
Přiřaďte stabilní interní odkaz na rozhodnutí a propojte s ním pozdější odkazy na objednávky nebo transakce. Účet tak může přecházet od návrhu přes pokus k výsledku bez vytváření nesouvisejících záznamů, z nichž každý zdánlivě vyžaduje nové prostředky.
Změněná cena nebo příjemce mohou vyžadovat novou verzi návrhu. Zachovejte vztah k dřívější verzi a současně vyjasněte, která instrukce, pokud vůbec nějaká, zůstává proveditelná. Přejmenování záznamu na náhradu samo neruší původní povinnost.
Vedle plánovací měny zachovejte limity nativních aktiv
Dolarový rozpočet může pomáhat porovnávat expozice, ale transakce utrácí konkrétní aktiva v konkrétních jednotkách. Schvalovací záznam proto má zahrnovat plánovací ocenění i maximální nativní částku nebo množství tokenu povolené pro úkon.
Předpokládejte, že plánovací výpočet používá jeden snímek směnného kurzu a příprava transakce pozdější kurz. Bot nemá dovolit neomezený růst nativní částky pro zachování dolarového cíle. Uveďte, jak pohyb kurzu ovlivňuje návrh a kdy je třeba nové schválení.
Podobně mají ETH a WETH odlišné provozní role, i když oceňovací model propojuje jejich množství. Zůstatek platebního tokenu a nativní zůstatek na gas nemají být sloučeny do jediného údajně použitelného čísla bez podporované převodní cesty.
Správná kontrola se ptá, zda účet má skutečná potřebná aktiva a zda jejich použití nadále vyhovuje pravidlům. Příznivý dolarový součet nevyváží nedostupné platební aktivum ani nepodporovanou cestu.
Doporučujte a vydělávejte USDC
Doporučujte a vydělávejte USDCNáš partnerský program vyplácí v reálném čase.
Neuvolňujte prostředky kvůli chybějící odpovědi
Vypršení časového limitu znamená, že aplikaci chybí úplná odpověď. Nedokládá neúspěch nákupu. Transakce mohla být úspěšně odeslána a odpověď ztracena, nebo se aplikace mohla zastavit před zaznamenáním výsledku.
Obnova nejisté transakce začíná odkazem na původní pokus a zamýšleným účinkem. Zachovejte související rezervaci při získávání podkladů potřebných k určení, co se stalo. Nejistotu zobrazujte výslovně místo její proměny v optimistický nulový závazek.
Vytvoření nového nákupu jiné položky může utratit prostředky, které dřívější pokus stále může potřebovat. Opakované odeslání nebo náhrada také podléhají pravidlům konkrétního řetězce a nemají být chápány jako univerzální řešení chybějících informací.
Rozpočet může během zkoumání zůstat dočasně omezen. Toto omezení odráží skutečnou nejistotu účtu. Automatické uvolnění po libovolném počtu sekund by nahradilo časovačem podklady o tom, zda finanční účinek ještě může nastat.
Zrušení chápejte jako proces vyžadující podklady
Žádost o zrušení vyjadřuje záměr zastavit povinnost. Její praktický účinek závisí na typu objednávky, cestě a načasování. Konkurenční plnění nebo již autorizovaná transakce mohou výsledek zkomplikovat.
Referenční dokumentace offchain rušení OpenSea obsahuje výhradu týkající se dříve vydané autorizace plnění. Rozpočtová logika proto má prozkoumat příslušný mechanismus místo předpokladu stejné konečnosti každé odpovědi na zrušení.
Pokud se nákup dokončí během rušení, přesuňte skutečný náklad do držby a odsouhlaste případnou nevyužitou rezervaci. Skutečnost, že provozovatel chtěl zastavit, nemaže pořízenou položku ani vzniklý výdaj.
Průvodce automatickým nabízejícím na OpenSea zvažuje souhru zastaralých ocenění a opakovaného podávání nabídek. Pro automatický nákup je základním účetním pravidlem, že rozhodnutí o náhradě nesmí záviset na volných prostředcích, dokud stav dřívější povinnosti tento závěr nepodporuje.
Závazky přesouvejte do držby bez dvojího započtení
Po ověření nákupu má rozpočtový záznam nahradit příslušnou čekající rezervaci skutečným pořizovacím nákladem. Nemá obojí ponechávat neomezeně dlouho, jako by účet financoval dva nákupy.
Předpokládejte rezervaci až 250 USD a dokončené pořízení za 246 USD. Podle příkladových pravidel se 246 USD přesouvá do pořizovacích nákladů držby a nevyužité 4 USD se stávají dostupnými. Původní rozhodovací záznam zůstává pro audit, i když jeho rezervace již nepředstavuje budoucí povinnost.
Pokud skutečný náklad překročí schválenou částku, zachovejte nesoulad a prozkoumejte jej. Dodatečná úprava schválení tak, aby odpovídalo výsledku, by skryla selhání kontroly. Evidence má odlišovat povolené od toho, co se skutečně stalo.
Přechod potřebuje také ošetření duplicit. Dvojí přijetí stejného ověřeného nákupu nemá přidat dalších 246 USD držby ani dvakrát uvolnit 4 USD. Opakovaný podklad odkazuje na jednu ekonomickou událost a rozpočet se kvůli ní má změnit jednou.
Započítejte známé neúspěchy a zbytkové náklady
Prokazatelně neúspěšný nákup může uvolnit část rezervace, kterou již nelze utratit za položku. Může však zanechat síťový výdaj patřící do nákladového záznamu účtu.
Pro smyšlenou rezervaci 250 USD předpokládejte, že nákup nenastane, ale vznikne skutečný transakční výdaj 3 USD. Rozdíl 247 USD již tento pokus nepotřebuje, zatímco 3 USD zůstávají realizovaným výdajem. Pravidla mají uvádět, které limity útraty či ztráty jej nadále započítávají.
Odmítnutí před odesláním nemusí mít vůbec žádný onchain výdaj. Zacházení s oběma případy jako s totožnými neúspěchy skrývá důvod rozdílu skutečných zůstatků peněženky od původního rozpočtu. Uchovejte fázi, v níž proces skončil.
To také zlepšuje budoucí odhady. Opakované neúspěchy s významnými náklady mohou odůvodnit jiná provozní pravidla nebo užší soubor kandidátů. Kontrola má zkoumat úplné výdaje, nikoli pouze náklady úspěšných pořízení.
Vklady a vratky nenechte přepisovat pravidla
Příchozí vklad zvyšuje dostupná aktiva účtu, ale automaticky nezvyšuje uživatelem schválený strop útraty. Vlastník může zamýšlet dodatečné prostředky pro jiný úkol nebo jen pro obnovení provozní rezervy.
Podobně nejsou prostředky vrácené z vypršelého či zrušeného závazku obchodním ziskem. Jde o uvolnění dříve zavázaných zdrojů se zohledněním skutečných nákladů. Evidence má zachovat tento vztah místo předkládání každého kladného peněžního pohybu jako příjmu.
Průvodce strategií nabídek OpenSea zkoumá ekonomickou roli nabídek. Rozpočet automatického nákupu má sledovat skutečný model financování své cesty, včetně toho, zda byly prostředky drženy odděleně, nebo nadále podléhaly možnému utracení v peněžence.
Změny pravidel si zaslouží vlastní záznamy. Zvýší-li vlastník strop z 1 000 USD na jinou částku, uchovejte, kdy a proč rozhodnutí nastalo. Obnovení zůstatku nemá stejnou změnu provádět potichu.
Vymezte limity období bez vynulování nejistoty
Denní či týdenní pravidlo útraty potřebuje časovou hranici, ale nevyřešený nákup ji může překročit. Bot nemá zapomenout na jeho možný finanční účinek jen proto, že kalendář začíná nové období.
Uveďte, které časové razítko určuje přiřazení období: například schválení, odeslání nebo ověřené pořízení. Různé účely mohou vyžadovat různé zprávy. Pravidla se mají vyhnout dvojímu započtení jednoho nákupu i mezeře, v níž se nezapočítává nikam.
Limity expozice zachovejte souvislé napříč obdobími. Držené NFT zůstává drženou položkou po půlnoci a čekající transakce zůstává nejistá, dokud ji podklady nevyřeší. Kalendářní souhrny jsou pohledy na účet, nikoli obnovení jeho ekonomického stavu od nuly.
Pokud provozovatel změní vykazovací časové pásmo, zachovejte tuto změnu. Jinak se stejná činnost může přesunout mezi obdobími a útrata může zdánlivě zmizet z jedné zprávy. Jasný rozpočet závisí na konzistentních časových definicích i správné aritmetice.
Před dalším nákupem obnovte stav ze záznamu účtu
Restartovaný bot má nejprve načíst držbu, nevyřešené závazky a nedávné transakční podklady. Potom může určit, zda jeho místní rozpočet souhlasí s doloženým stavem účtu. Zahájení nového hledání před tímto odsouhlasením může vést ke zbytečnému zavázání prostředků nad povolený rámec.
Do kontroly zahrňte ruční aktivitu. Vlastník mohl během výpadku bota koupit položku nebo přijmout nabídku přes jiné rozhraní. Model účtu musí tuto změnu zahrnout, i když postrádá místní odkaz na návrh.
Nevysvětlené rozdíly mají podle pravidel omezit nové oprávnění. Bot může během zkoumání účtu nadále sbírat tržní data. Užitečné rozhraní odlišuje nedostupnou nákupní kapacitu od neschopnosti pozorovat kandidáty.
Tuto obnovu otestujte na záměrně přerušených příkladech. Zastavte po rezervaci, po odeslání a po provedení před místním zaznamenáním. Každý restart má obnovit jednu konzistentní ekonomickou historii místo vytvoření dalšího nákupu nebo falešně prázdného rozpočtu.
Rozpočet automatického nákupu NFT porovnejte se skutečnými výsledky
Konečná kontrola rozpočtu má ukazovat schválené částky, skutečné náklady, uvolněné rezervace a zbývající povinnosti. Čtenář má umět vysvětlit každý rozdíl mezi počátečním přídělem a současným stavem účtu.
U smyšlených pravidel není důležitým výsledkem počet položek, které bot pořídil. Je jím to, zda každé pořízení vyhovělo jasnému pravidlu a zda nejistota zůstala započítána až do vyřešení. Odmítnutý kandidát může doložit, že limit fungoval podle záměru.
Odhady porovnávejte s výsledky ke zlepšení provozního přídělu a nákladového modelu. Uchovejte původní záznamy, aby upravené pravidlo bylo možné hodnotit na pozdější činnosti. Změna historických předpokladů podle příznivých výsledků by odstranila podklady potřebné k učení.
Automatický nákupní bot pro NFT má použitelný rozpočet tehdy, když další rozhodnutí odráží jak stávající držbu účtu, tak to, co ještě může pořídit. Tato disciplína brání tomu, aby souběžní kandidáti, zpožděná potvrzení a restarty proměnili zdánlivý zůstatek ve větší oprávnění utrácet, než vlastník zamýšlel.