Bot pro obchodování ERC-721: sledujte každý předmět a objednávku

Dejte botu pro obchodování ERC-721 účetní knihu na úrovni předmětů

Oficiální specifikace ERC-721 definuje rozhraní pro sledování a převádění jednotlivých NFT. Zahrnuje dotazy na vlastnictví, schválení pro konkrétní token a schválení provozovatelů. Metadata a výčet tokenů jsou volitelná rozšíření. Tato rozlišení jsou důležitá při rozhodování, co bot dokáže přímo ověřit a která další data potřebuje.

Jako klíč aktiva účtu používejte společně řetězec, adresu kontraktu a identifikátor tokenu. Identifikátor uchovávejte v podobě zachovávající jeho úplnou hodnotu. Může jej doprovázet označení srozumitelné člověku, nikdy by se však nemělo stát jediným odkazem spojujícím nabídku s držbou.

Vytvořte samostatný záznam pro každý předmět, který účet pořídil, převedl nebo se jej pokouší obchodovat. Zahrňte podklady zakládající záznam a časový či řetězcový kontext pozorování. Součet na úrovni kolekce pak lze odvodit z těchto záznamů předmětů místo jejich nahrazování.

Tato struktura umožňuje nesrovnalosti řešit. Pokud počet kolekce uvádí tři, ale účetní kniha předmětů obsahuje čtyři ověřené držené předměty, systém má konkrétní problém ověření a sladění. Bez totožností předmětů se nesoulad stává nevysvětleným číslem, které může pronikat do rozhodování o nabídkách a expozici.

Oddělujte vrstvu aktiv od vrstvy objednávek

Záznam aktiva popisuje token a pozorované vlastnictví. Záznam objednávky popisuje navrženou směnu za konkrétních podmínek. Mohou odkazovat na stejný předmět, aniž by popisovaly stejný stav. Nabízený token může zůstávat ve vlastnictví a nákupní nabídka může existovat bez získané držby.

Ukládejte totožnost objednávky, odkaz na aktivum, stranu, platební podmínky, vypršení a podklady o aktuálním stavu samostatně. Vyhněte se jedinému stavovému poli pokoušejícímu se učinit vlastnictví, nabídku k prodeji, nákupní nabídku a prodej vzájemně výlučnými. Některé z těchto podmínek mohou existovat současně, zatímco jiné vyžadují ověřené přechody, než se na ně účet může spolehnout.

Účet může například vlastnit fiktivní token 317 a mít s ním spojený prodejní pokyn. Předmět zůstává v držbě, dokud relevantní podklady neukážou jeho pozbytí. Jeho odstranění při vytvoření nabídky by podhodnocovalo expozici a mohlo by zkreslit dostupná aktiva účtu.

Podobně by zamýšlený nákup tokenu 418 měl podle situace zaujímat záznam závazku, aniž by se zobrazoval jako vlastnictví. Toto rozlišení pomáhá zabránit pozdějšímu návrhu prodeje předpokládat dokončení očekávaného pořízení. Objednávky vyjadřují záměry a závazky; záznam zásob vyžaduje podklady o skutečných změnách aktiv.

Vymezte rozsah podkladů o vlastnictví

Zvolte, jaké podklady postup vyžaduje před považováním tokenu za držený nebo pozbytý. Uchovávejte kontext pozorování, aby systém dokázal rozlišit aktuální kontrolu od starého záznamu indexu. Různé zdroje se mohou aktualizovat v různých časech a nesoulad by měl zůstat viditelný až do ověření a sladění.

Proces ověřování a slaďování vlastnictví ERC-721 by měl porovnávat účetní knihu předmětů s relevantními aktuálními podklady účtu. Pokud byl předmět přesunut mimo bota, účetní kniha musí tuto událost odrážet. Vlastní obchodní historie bota není úplným popisem účtu, který lze ovládat i prostřednictvím jiných nástrojů nebo zařízení.

Nevyvozujte, že chybějící výsledek vyhledávání prokazuje nepřítomnost předmětu. Zdroj dat může být neúplný nebo opožděný. Podobně obrázek uložený v mezipaměti rozhraní peněženky neprokazuje aktuální vlastnictví. Postup by měl určovat konkrétní podklady podporující přechod stavu místo spoléhání na známý vzhled.

Při rozporu pozorování pozastavte akce závislé na sporném předmětu. Nová nabídka nebo návrh převodu by neměly pokračovat, pokud si účet není jistý, zda token ovládá. Jiná nezávislá pozorování mohou pokračovat, nevyřešený nesoulad by však měl zůstat součástí provozního stavu.

Přezkoumávejte oprávnění jako samostatný stav účtu

Standard rozlišuje schválení pro jednotlivý token a schválení provozovatele pro tokeny vlastníka v příslušném kontraktu. Obchodní postup by měl jasně zobrazovat požadovaný rozsah a uchovávat pozorovaný stav oprávnění účtu. Úzký záměr nákupu nebo prodeje by neměl skrývat širší změnu oprávnění.

Přezkoumání rozsahu schválení ERC-721 je samostatným rozhodnutím od hodnocení ceny. Návrh může mít přijatelnou ekonomiku a současně žádat pravomoc mimo plán provozovatele. Přezkoumání by mělo určit účet, kolekci, oprávněnou stranu a zamýšlený účel před udělením oprávnění nebo spoléháním na ně.

Udržujte oprávnění propojená s cestou, která je potřebuje. Pokud strategie mění cestu provedení, nepředpokládejte trvající vhodnost stávajícího oprávnění jen proto, že se v rozhraní objevuje podobný název. Záznam pravomoci by měl používat ověřené identifikátory a vysvětlovat, proč oprávnění zůstává potřebné.

Po skončení experimentu přezkoumejte trvající pravomoci podle pravidel účtu. Zastavení smyčky strategie samo o sobě nevysvětluje stav dříve udělených oprávnění. Záznam účtu by měl rozlišovat vypnutou automatizaci a změněné oprávnění, aby provozovatel věděl, jaká kontrola byla skutečně odstraněna.

Ověřte zamýšleného příjemce a cestu převodu

Návrh převodu by měl určit cíl a jeho roli. Je příjemcem obchodní účet vlastníka, samostatná úschovní adresa nebo jiný účastník podle podmínek směny? Podobně vypadající adresy nebo známá označení neodstraňují potřebu ověřit tento vztah před povolením.

Standard ERC-721 poskytuje chování bezpečného převodu kontrolující přijímací rozhraní příjemce, který je chytrým kontraktem. Tento mechanismus je užitečný, neprokazuje však, že příjemce je adresa zamýšlená uživatelem nebo že jsou vhodné všechny širší obchodní podmínky. Návrh stále potřebuje smysluplné přezkoumání příjemce.

Uchovávejte cestu převodu předpokládanou návrhem provedení. Pokud postup očekává příchod pořízeného předmětu na jeden účet, ale skutečná cesta používá jiný, ověření a sladění vlastnictví by jinak hlásilo chybějící token. Záznam by měl vysvětlovat každého zprostředkujícího nebo určeného příjemce relevantního pro skutečnou transakci.

Při nácviku testujte zacházení s adresami pomocí jasně odlišitelných fiktivních účtů. Zahrňte návrh s nesprávným cílem a potvrďte, že jej přezkoumání zachytí. Cvičení kontrolující pouze částky může minout zásadnější chybu: správně oceněné pořízení doručené někam mimo zamýšlený model účtu.

Udržujte metadata užitečná, aniž by rozhodovala o vlastnictví

Názvy, obrázky a atributy pomáhají lidem porozumět tomu, co předmět představuje. Měly by zůstávat připojené ke klíči aktiva jako popisné informace místo nahrazování záznamu vlastnictví. Obnova metadat může změnit zobrazení, zatímco podkladová totožnost tokenu zůstává stejná.

Ukládejte verzi popisných informací použitou při rozhodování o ocenění. Pokud se vzhled nebo atributy později liší, provozovatel může přezkoumat, zda původní teze závisela na dřívější verzi. Bez verzování může být starý návrh nemožné vysvětlit, protože rozhraní nyní zobrazuje jiný popis.

Chybějící metadata řešte výslovně. Obchodní proces může vyžadovat popisné podklady k ocenění i tehdy, když dokáže token určit. V takovém případě jsou nedostupný obrázek nebo soubor atributů důvodem k pozastavení fáze oceňování, nikoli podkladem, že aktivum neexistuje nebo že se má předpokládat nízká cena.

Toto oddělení chrání také účetnictví. Aktualizace názvu nebo obrázku by neměla vytvořit novou držbu, zdvojit pořízení ani odpojit historii prodeje od předmětu. Stabilní klíč účetní knihy zachovává návaznost, zatímco popisná pole kolem něj se mění.

Vypočtěte náklady konkrétního předmětu

Přiřazujte pořizovací výdaje skutečnému předmětu a pokusu, které je způsobily. Částka zaplacená za token 317 se může podstatně lišit od částky za token 418, i když oba patří do stejné kolekce. Průměr kolekce může být užitečný pro vykazování, neměl by však mazat individuální záznamy nákladů.

U hypotetického nákupu za 0,60 ETH s přiřaditelnými výdaji 0,03 ETH činí pořizovací výdaj 0,63 ETH. Pokud se předmět později prodá za 0,70 ETH před prodejními výdaji 0,04 ETH, čistý příjem je 0,66 ETH a realizovaný zisk 0,03 ETH. Porovnání pouze dvou hlavních cen by vykázalo větší zisk.

Neúspěšné pokusy zaznamenávejte samostatně, pokud způsobují výdaje bez pořízení předmětu. Rozhodněte, jak tyto náklady vstupují do zprávy o výkonnosti experimentu, a metodu používejte jednotně. Jejich vynechání proto, že nepatří k dokončené držbě, vykresluje strategii jako levnější, než byla.

Pokud několik předmětů sdílí společný výdaj, zdokumentujte metodu rozdělení místo vymýšlení přesného přiřazení, které podklady nedokážou podpořit. Důležité jsou jednotnost a průhlednost. Recenzent by měl dokázat rekonstruovat celkový výdaj účtu, i když rozdělení mezi předměty zahrnuje výslovnou konvenci.

Zabraňte konfliktním akcím nad stejným tokenem

Jediný předmět může přitahovat několik navržených akcí z různých částí postupu. Jedna součást může připravovat prodej, zatímco jiná připravuje převod nebo revidovanou nabídku. Systém potřebuje koordinační pravidlo na úrovni předmětu, aby tyto záměry nepokračovaly nezávisle bez vzájemného povědomí.

Používejte trvalý záznam aktivních záměrů a jejich závislostí. Pokud je token 317 součástí nevyřešené akce, druhá akce by se měla přezkoumat vzhledem k tomuto stavu. Pravidlo by mělo přežít restart; dočasný příznak v paměti nestačí, pokud jej aplikace po přerušení zapomene.

Výsledky rušení a nahrazování udržujte výslovné. Žádost o zrušení sama neprokazuje, že dřívější objednávku již nelze provést. Návrh náhrady musí zohlednit skutečné chování protokolu a místa obchodování místo předpokladu, že místní označení odstranilo původní závazek.

To je jeden z důvodů, proč agent pro obchodování NFT potřebuje jasnou hranici mezi plánováním a povolováním. Plánovač může navrhovat několik alternativ, pravomoc provedení by však měla vybrat a sledovat soudržnou posloupnost akcí. Více věrohodných plánů neodůvodňuje současné konfliktní pokyny.

Před opakováním ověřte a slaďte nejistý nákup

Předpokládejte odeslání žádosti o nákup a selhání spojení před přijetím výsledku aplikací. Účet nyní má nejistý výsledek, nikoli potvrzené selhání. Opakování žádosti bez prověření může vytvořit další expozici nebo způsobit zbytečné výdaje podle cesty a návrhu.

Uložte dostupné identifikátory transakcí a objednávek s původním záměrem. Při obnově použijte tyto identifikátory a podklady účtu k určení skutečného průběhu. Pokud informace zůstávají neúplné, uchovejte nejistotu a blokujte závislé akce místo vyplnění mezery předpokladem.

Postup obnovy nákupu ERC-721 by měl propojit tři záznamy: co bot zamýšlel, co odeslal a co účet nyní prokazuje. Tyto záznamy se nemusejí shodovat okamžitě. Proces obnovy existuje k jejich ověření a sladění před pokračováním strategie, jako by byl předmět určitě přítomen nebo nepřítomen.

Přerušení záměrně nacvičte. Po hypotetickém odeslání restartujte aplikaci, ověřte, že si pamatuje nevyřešenou akci, a potvrďte, že automaticky nevytváří nové pořízení. Tento test zkoumá model účtu při realistickém selhání bez potřeby tržní ztráty k odhalení slabiny.

Odlišujte zásoby bota pro obchodování ERC-721 od edic

Nepoužívejte stejné předpoklady o předmětech pro každý standard tokenu jen proto, že rozhraní zobrazuje náhled NFT. Model účtu by měl určit standard a používat odpovídající význam množství a totožnosti podporovaný skutečným aktivem. Obecný záznam vynechávající toto rozlišení může chybně vykládat držbu a objednávky.

Průvodce botem pro obchodování ERC-1155 řeší typy tokenů nesoucí množství a související účetní otázky. Postup zaměřený na ERC-721 by měl výslovně omezit svůj rozsah, pokud tyto operace nepodporuje. Odmítnutí nepodporovaného aktiva je jasnější než jeho vnucení do záznamu navrženého pro jiný standard.

Tento rozsah uchovávejte také v nástrojích importu a objevování. Vyhledávání kolekce může vrátit několik druhů aktiv, vrstva provedení by však neměla odvozovat slučitelnost pouze z výsledku hledání. Navržená akce potřebuje projít kontrolami podporovaného aktiva před pokračováním oceňování nebo povolování.

Toto oddělení také zlepšuje vykazování. Počet jednotlivých předmětů ERC-721 by se neměl slučovat s množstvími jiného typu aktiva do neoznačeného „zůstatku NFT“. Provozovatel potřebuje vědět, co každé číslo měří, než je použije k posouzení koncentrace zásob nebo dostupné prodejní kapacity.

Navrhněte záznam výstupu uzavírající správné pořízení

Při prodeji nebo jiném pozbytí předmětu propojte událost s jeho původním záznamem držby. Zahrňte skutečné příjmy, výdaje, případný relevantní cíl a podklady o změně vlastnictví. Samotný prodejní pokyn by neměl uzavírat pořízení v účetní knize.

Uchovávejte rozlišení prodeje a převodu bez prodeje. Přesun předmětu mezi účty může změnit úschovu bez vytváření obchodních příjmů. Pokud systém vykazování považuje každý odchozí převod za prodej, může vymýšlet tržby nebo zkreslovat realizovanou výkonnost. Záznam potřebuje důvod přesunu s vyznačenou nejistotou, pokud důvod není znám.

Pokud je stejný token později znovu pořízen, vytvořte novou epizodu pořízení a současně uchovejte dřívější historii. Opětovné používání jediného nákladového pole po celou dobu by mazalo rozdíl mezi prvním a druhým obdobím držení. Stabilní totožnost tokenu i samostatné epizody vlastnictví účtu by měly zůstat viditelné.

Na konci každé relace ověřte a slaďte otevřenou držbu, nevyřešené akce a dokončená pozbytí. Součty by měly odpovídat podkladům účtu a pohybům peněz. Správný seznam názvů tokenů nestačí, pokud účetní kniha nedokáže vysvětlit utracené a zpět získané peníze.

Nacvičujte s malým souborem záměrných případů

K testování modelu účtu použijte fiktivní kolekci a několik identifikátorů tokenů. Zahrňte jedno přímočaré pořízení, jeden externí převod, jeden neúspěšný pokus a jednu nejistou odpověď. Účelem je ověřit přechody stavů a záznamy, nikoli simulovat ziskovou kolekci.

Záměrně přidejte nesoulad: objednávku odkazující na jiný identifikátor tokenu než zobrazovaný předmět. Postup by ji měl odmítnout před povolením. Testujte také zastaralé pozorování vlastnictví a návrh spoléhající na pravomoc mimo uvedený rozsah. Každý případ zkoumá jinou hranici návrhu.

Bot NFT pro začátečníky může poskytnout širší výchozí bod k učení těchto rozlišení. Cvičení ERC-721 by je pak mělo konkretizovat na úrovni jednotlivých předmětů, aby provozovatel dokázal přesně vysvětlit, kterého aktiva a oprávnění se každá akce týká.

Uložte případy a očekávané výsledky jako přezkumný soubor pro pozdější změny. Pokud nová funkce mění ukládání zásob nebo import objednávek, znovu spusťte relevantní případy. Malý srozumitelný soubor příkladů selhání může odhalit regrese, které by rozsáhlý přehled úspěšných historických obchodů minul.

Časté otázky k automatizaci ERC-721

Prokazuje soulad se standardem hodnotu NFT?

Ne. Standard se týká rozhraní a chování aktiv, nikoli ekonomické poptávky nebo záruky dalšího prodeje. Ocenění vyžaduje samostatné podklady a zůstává nejisté. Technicky podporovaný token může být pro obchodní strategii stále nevhodný kvůli nepřitažlivé ceně, likviditě nebo předpokladům doby držení.

Stačí k obchodování zůstatek kolekce?

Pro akce cílené na konkrétní předmět nestačí. Postup potřebuje relevantní totožnost tokenu a aktuální podklady o vlastnictví nebo proveditelných podmínkách objednávky. Počet v kolekci může podporovat ověření a sladění, nedokáže však určit, které pořízení uzavírá konkrétní prodej nebo zda je zamýšlený předmět dostupný.

Mohu každý odchozí převod považovat za prodej?

Ne. Odchozí převod může představovat změnu úschovy nebo jinou akci bez prodeje. Podklady a důvod zaznamenávejte odděleně od příjmů. Pokud účel není znám, uchovejte tuto nejistotu místo vymýšlení prodejní ceny nebo odstranění události z historie účtu.

Co prokazuje připravenost na pokus pod dohledem?

Provozovatel by měl dokázat určit token, vysvětlit požadovanou pravomoc, rekonstruovat navržené náklady a obnovit zpracování nejistého výsledku z uložených podkladů. Nácvik by měl také ukazovat odmítání konfliktních nebo nepodporovaných akcí. Tyto schopnosti zakládají srozumitelný proces; nezaručují ziskový obchod.