En NFT-bot er software, der udfører en defineret opgave med ikke-fungible tokens. Den kan overvåge salgsopslag, sammenligne priser, forberede et tilbud eller hjælpe med at afstemme køb. Ansvaret kan indgå i én arbejdsgang, men bør ikke betragtes som én udelelig handling. Observation af en genstand giver ikke tilladelse til at købe den, og en transaktionsanmodning fastslår ikke ejerskab.
Det mest nyttige udgangspunkt er én beslutning om en bestemt token. Følg dokumentationen fra første markedsobservation til den endelige kontoregistrering. Det viser, hvad softwaren ved, hvad den antager, og hvilke beføjelser den har brug for på hvert trin. Det gør også mislykkede og usikre udfald lettere at forklare.
Artiklen følger en fiktiv genstand ved navn Atlas Postcard 418. Alle samlinger, priser, gebyrer og kontogrænser er opdigtet til undervisning. Eksemplet bruger et køb af Ethereum-typen til at forklare forløbet; andre kæder og NFT-standarder kræver deres egne transaktions- og ejerskabskontroller.
Definer NFT-bottens beslutningsforløb
NFT-bottens beslutningsforløb begynder med en observation om et bestemt aktiv og slutter, når den økonomiske virkning er forstået. Mellem disse punkter ligger identitetskontrol, værdiansættelse, budgetgodkendelse, transaktionsforberedelse, indsendelse og afstemning. Hvert trin kræver dokumentation, som det foregående trin ikke alene kan levere.
For Atlas Postcard 418 er observationen et salgsopslag på 0.72 ETH. Tallet er en sælgers foreslåede pris for én identificeret genstand. Det er hverken en prognose for gensalgsværdi, en garanti for tilgængelighed eller bevis for, at kontoen bør bruge beløbet.
En nyttig arbejdsgang kan standse på ethvert trin med en klar begrundelse. Opslaget kan være forældet, aktivet udelukket, den anslåede omkostning højere end budgettet, eller kontoen kan have et andet uafklaret køb. En dokumenteret beslutning om ikke at handle er en del af forløbet frem for en manglende evne til at skabe aktivitet.
Gør opgaven snæver nok til at kunne forklares
En første automatiseringsopgave kan overvåge en defineret gruppe samlingskontrakter og rapportere nye observerede salgsopslag under en grænse. En anden opgave kan forberede et købsforslag efter kontrol af genstandens identitet og kontoens kapacitet. Det er forskellige opgaveomfang, som bør have forskellige tilladelser.
Undgå blot at beskrive opgaven som at finde rentable NFT'er. Udtrykket skjuler antagelser om værdiansættelse, ejertid og udførelsesforhold. En præcis opgave angiver, hvilke genstande der opfylder kravene, hvilken dokumentation der kræves, og hvilket resultat softwaren må frembringe.
Vejledningen til en NFT-handelsbot udvider dette forløb til beholdningsstyring. Her fastholdes fokus på én beslutning. Kan en kontrollant ikke forklare, hvorfor netop dette køb blev foreslået, vil flere samlinger eller samtidige ordrer gøre usikkerheden sværere at undersøge.
Fastslå genstandens identitet før prisen
Et samlingsnavn og et billede er visningsoplysninger, ikke fuldstændige aktividentifikatorer. Registreringen skal indeholde relevant kæde og tokenidentitet. For en almindelig EVM-NFT omfatter det normalt kontrakt og tokenidentifikator med korrekt fortolkning af tokenstandard og antal.
OpenSeas vejledning til genstandssiden henviser læsere til blockchainoplysninger og aktivitetshistorik. Oplysningerne hjælper med at forbinde en vist genstand med dens underliggende registrering. Et lignende navn på en anden kontrakt bør ikke ubemærket indgå i samme gruppe godkendte samlinger.
Den fiktive købsregistrering identificerer derfor Atlas Postcard 418 ved kæde, kontrakt og identifikator, før salgsprisen på 0.72 ETH tilknyttes. Den registrerer også, hvilket salgsopslag og hvilken sælger observationen kom fra. Ændres en identifikator under forberedelsen, bør systemet undersøge et nyt forslag frem for at antage, at det er samme genstand til en opdateret pris.
Bevar det, botten faktisk observerede
En købsregistrering for en bestemt token bør bevare udbudspris, betalingsaktiv, sælger, ordrereference og relevante tidsstempler. Tidspunktet, hvor markedspladsen rapporterer en hændelse, kan afvige fra tidspunktet, hvor botten modtager den. En senere gennemgang skal kunne vise, hvilke oplysninger der var tilgængelige, da beslutningen blev truffet.
Antag, at et salgsopslag offentliggøres kl. 14:00:00, modtages kl. 14:00:03 og vurderes kl. 14:00:05. Beslutningen bruger oplysninger, som allerede ligger fem sekunder efter offentliggørelsestidspunktet, forudsat at urene kan sammenlignes. En hurtig afsluttende beregning fjerner ikke den forudgående forsinkelse.
Bevar den oprindelige observation, selv hvis opslaget ændres. Udskiftning med en nyere værdi kan få den historiske beslutning til at se ud, som om den brugte oplysninger, den aldrig havde. Den nyere observation hører til en ny version af forslaget med eget tidspunkt og egen forklaring.
Behandl markedsfeeds som dokumentation med begrænsninger
En direkte forbindelse kan levere nyttige hændelser uden at garantere en fuldstændig historik. OpenSeas dokumentation til Stream API beskriver levering efter bedste evne og mulige problemer med rækkefølgen. Læseren bør ikke slutte, at ethvert overset salgsopslag automatisk dukker op efter genforbindelse.
I den hypotetiske arbejdsgang giver streaming anledning til at undersøge en kandidat. En kontrol af den aktuelle tilstand afgør derefter, om opslaget stadig er relevant. Konstruktionen med to trin er et teknisk valg: ét trin opdager ændringer, mens et andet fastslår den dokumentation, den foreslåede handling kræver.
Botten bør markere huller og usikre perioder i journalen. Var den afbrudt i ti minutter, beviser en tom hændelsesliste for perioden ikke, at intet skete. Forskellen betyder noget både for umiddelbare beslutninger og senere påstande om, hvor mange muligheder systemet fandt eller overså.
Gør en attraktiv udbudspris til et spørgsmål om værdi
Udbudsprisen på 0.72 ETH kan ligge under andre synlige salgsopslag, men disse priser beskriver sælgernes hensigter. De fastslår ikke, hvad en køber ville betale for Atlas Postcard 418. Botten behøver en særskilt forklaring af værdi og udtrædelsesforhold.
Relevant dokumentation kan omfatte sammenlignelige gennemførte salg, gyldige tilbud på genstanden og egenskaber, som købere synes at værdsætte. Hver type har begrænsninger. Et salg kan være gammelt, et tilbud kan udløbe, og en sjælden egenskab kan have ringe påvist efterspørgsel. Bevar begrænsningerne sammen med skønnet.
En værdiansættelsesregistrering bør beskrive et interval af plausible udfald frem for at gøre én gunstig sammenligning til sikkerhed. I eksemplet overvejer researcheren et muligt salg til 0.78 ETH, men også en udtræden til 0.64 ETH. Ingen af delene fremstilles som en aktuelt eksekverbar pris eller et forudsagt resultat.
Beregn hele det hypotetiske købs- og salgsforløb
Antag, at selve købet koster 0.72 ETH, og den faktiske netværksomkostning ved indgang er 0.008 ETH. Samlet anskaffelsespris er 0.728 ETH. Ved det illustrerede salg antages en samlet afgift på 3% af bruttoprovenuet og en særskilt netværksomkostning på 0.006 ETH ved udtræden.
Ved et bruttosalg på 0.78 ETH ville procentafgiften være 0.0234 ETH. Nettoprovenuet ville være 0.7506 ETH efter begge antagne fradrag. Fratrukket anskaffelsesprisen giver det 0.0226 ETH. Det lille positive resultat afhænger af den opdigtede salgspris og omkostningsantagelserne.
Ved en bruttoudtræden på 0.64 ETH ville procentafgiften være 0.0192 ETH, så der er 0.6148 ETH tilbage efter netværksomkostningen. Sammenholdt med de brugte 0.728 ETH ville tabet være 0.1132 ETH. En lav indledende udbudspris fjerner ikke muligheden for, at den endelige køber betaler mindre.
Hold gebyrantagelser adskilt fra gældende regler
Afgiften på 3% ovenfor er en opdigtet antagelse om samlede salgsomkostninger, ikke en angivelse af OpenSeas gældende gebyrplan. Et faktisk forslag skal identificere relevante markedspladsafgifter, skaberindtjening og netværksomkostninger uden at medregne samme komponent to gange.
Angiver en forhåndsvisning af udførelsen eksempelvis allerede sælgerens nettoprovenu efter betaling til skaberen, undervurderes resultatet, hvis betalingen trækkes fra igen. Omvendt overvurderes forventede modtagne beløb ved at bruge bruttoprovenuet og ignorere et relevant fradrag. Omkostningsregistreringen bør angive, hvilke tal der er brutto, og hvilke der er netto.
Valutaen betyder også noget. Et resultat i ETH og et resultat i dollar kan bevæge sig i forskellige retninger, når valutakursen ændres. Bevar beløb i det oprindelige aktiv samt omregningstidspunktet for enhver dollarrapport. En senere valutakurs bør ikke ubemærket erstatte transaktionens historiske omkostning.
Godkend købet under hensyn til eksisterende forpligtelser
Værdiansættelsen foreslår en handling; et kontotrin afgør, om den er tilladt. Antag, at den fiktive politik tillader højst 2 ETH i anskaffelsesforpligtelser i samlingen. Eksisterende beholdninger har 0.9 ETH i registreret anskaffelsespris, mens afventende køb reserverer yderligere 0.5 ETH.
Kun 0.6 ETH er tilbage under denne enkle politik. Den foreslåede anskaffelse på 0.728 ETH passer ikke ind, selv hvis walletens synlige saldo er stor nok til at betale. Den korrekte reaktion er afvisning efter den angivne regel frem for at behandle disponible kontanter som ubegrænset tilladelse.
Frigives en særskilt reservation på 0.3 ETH senere med endelig dokumentation, falder afventende forpligtelser til 0.2 ETH, og kapaciteten bliver 0.9 ETH. Et opdateret forslag kan så passe ind. Frigivelsen skal understøttes af dokumentation fra den oprindelige transaktion eller ordre; en ubesvaret annulleringsanmodning er utilstrækkelig.
Henvis og tjen USDC
Henvis og tjen USDCVores affiliateprogram udbetaler i realtid.
Giv et godkendt forslag en begrænset levetid
Et godkendt forslag beskriver en bestemt genstand, pris og kontotilstand på et bestemt tidspunkt. Det bør ikke blive en permanent tilladelse til at købe enhver senere version af salgsopslaget. Ændrer sælgeren betalingsaktivet eller det samlede vederlag, skal forberedelsestrinnet bringe forskellen tilbage til godkendelsesreglen.
Ejeren kan definere et gyldighedsinterval og en maksimalt tilladt omkostning. Kontrollerne besvarer forskellige spørgsmål: intervallet begrænser, hvor gamle oplysningerne må blive, mens omkostningsgrænsen afgrænser forbruget. At prisen fortsat ligger under grænsen, gør ikke ubegrænset gamle identitets- eller kontooplysninger acceptable.
Bevar et udløbet forslag i journalen med begrundelsen. Et opdateret forslag kan henvise til det tidligere, men bør bevare egne observationer og eget godkendelsesresultat. Historikken adskiller en bevidst revurdering fra et system, der ubemærket strækker tilladelsen for at gennemføre en gammel idé.
Skeln mellem dataadgang og forbrugsbeføjelser
En bot kan læse offentlige oplysninger om genstande uden beføjelser til at flytte brugerens aktiver. Den kan også forberede et usigneret forslag til gennemgang. Walletsignering og tokengodkendelser tilføjer forskellige evner, som hver især bør forstås før delegering.
Operatøren bør kunne identificere den signerende konto, aktivet der bruges, den tilsigtede modtager og enhver fortsat tilladelse, handlingen skaber. En venlig betegnelse som forbind eller aktiver beskriver ikke en signaturs fulde økonomiske virkning.
Ved vurdering af den bedste NFT-handelsbot til en bestemt opgave bør det undersøges, om tilladelserne passer til opgaven. En arbejdsgang med kun varsler bør bedømmes på observationer og notifikationer. En købsarbejdsgang kræver desuden klare signeringsgrænser, transaktionskontroller og en registrering af, hvem der godkendte handlingen.
Forbered en transaktion uden at kalde den et køb
Udførelsesdata er et forslag til, hvad en transaktion skal gøre. OpenSeas reference til opfyldelse af salgsopslag beskriver usignerede opfyldelsesdata for understøttede ruter. Modtagelse af dataene overfører ikke i sig selv NFT'en eller bruger købsbeløbet.
Den hypotetiske bot sammenligner den forberedte transaktion med den godkendte købsregistrering. Genstand, modtager, betalingsaktiv, beløb og tilladt rute bør stemme overens. En uoverensstemmelse kræver undersøgelse frem for automatisk signering, blot fordi dataene kom fra en velkendt tjeneste.
Samme princip gælder simulering. En vellykket simulering kan give nyttig dokumentation om en foreslået handling under en bestemt tilstand, men forhold kan ændres før udførelse. Systemet skal stadig følge den indsendte transaktion og fastslå dens faktiske resultat.
Følg den oprindelige indsendelse gennem usikkerhed
Gem efter indsendelse transaktionsreferencen og den tilsigtede virkning, før operatøren får præsenteret et udfald. Et netværk eller en tjeneste kan acceptere anmodningen, mens applikationen mister svaret. Fravær af synlig bekræftelse beviser ikke, at intet skete.
Får den fiktive bot timeout, bør den undersøge det oprindelige forsøg. En uafhængig ny købsinstruktion kan skabe yderligere forbrug eller forstyrre genopretningen. Gentagelsesadfærd skal følge kædens og rutens semantik frem for at behandle enhver kommunikationsfejl som tilladelse til en ny beslutning.
En usikker tilstand bør bevare sin budgetreservation og forblive synlig. Det kan midlertidigt hindre andre køb, men afspejler korrekt den manglende viden. Frigivelse af kapacitet blot for at holde arbejdsgangen i gang ville få kontoen til at se mindre forpligtet ud, end den faktisk kan være.
Adskil transaktionssucces fra korrekt beholdning
En transaktionsregistrering kan fastslå, at en operation blev udført, men bogføringen skal stadig verificere den tilsigtede genstand og modtager. Botten bør forbinde transaktionsdokumentation med den relevante ejerskabs- eller saldoregistrering for den pågældende NFT-standard.
Ved det fiktive køb af én genstand bør beholdningen indeholde Atlas Postcard 418 præcis én gang med anskaffelsespris og transaktionsreference tilknyttet. En dubleret hændelse bør opdatere dokumentationen om samme køb frem for at skabe en anden genstand i regnskabet.
Er walletvisningen, markedspladsvisningen og den lokale registrering uenige, skal forskellen og deres observationstidspunkter bevares. Én grænseflade kan opdatere senere end en anden. Opgaven er at afgøre, hvilken tilstand dokumentationen understøtter, frem for at tvinge totalerne til at stemme ved at slette en ubekvem registrering.
Bevar antallet, når aktivet har flere enheder
Det fiktive postkort behandles som én individuelt ejet genstand, men nogle NFT-standarder kan repræsentere flere enheder under én tokenidentifikator. I så fald beskriver et ja/nej-felt ikke ejerskabet tilstrækkeligt. Registreringen skal bevare, hvor mange enheder der blev anskaffet, overført eller solgt.
Køb af tre enheder efterfulgt af salg af én efterlader to enheder, selv om kæde og tokenidentifikator er uændrede. Omkostningsfordeling og mulige fremtidige modtagne beløb bør følge disse antal. Flere modtagne hændelser om samme køb af tre enheder øger ikke det anskaffede antal.
Verificer den faktiske standard og rutens semantik før udvidelse af arbejdsgangen. En ejerskabskontrol for én genstand bør ikke kopieres til en saldomodel med flere enheder uden tilpasning. Forløbet er fortsat nyttigt, men den dokumentation, der kræves for at fastslå sluttilstanden, ændres med aktivets repræsentation.
Definer NFT-bottens afstemning af ejerskab
NFT-bottens afstemning af ejerskab sammenligner det tilsigtede køb med de aktiv- og kontantændringer, som faktisk indtraf. Den undersøger, om den forventede NFT ankom, hvilken betaling der forlod kontoen, hvilke gebyrer der opstod, og om en tilknyttet forpligtelse stadig er åben.
Et mislykket forsøg kan stadig kræve en udgiftspost, hvis en netværksafgift blev betalt. Et forslag afvist før indsendelse kan være uden udgift på kæden. Tilfældene bør ikke sammenlægges til ét fejltal, da deres kontovirkninger er forskellige.
Vejledningen til en NFT-autohandler følger disse tilstande gennem genstarter og flere beholdninger. For ét køb er det væsentlige resultat en fuldstændig registrering, som en senere proces kan stole på. Næste beslutning bør ikke afhænge af, at en operatør husker, hvad en tidligere skærm viste.
Genskab beslutningen efter en genstart
En genstart bør begynde med at indlæse uafklarede beslutninger frem for straks at søge efter endnu et køb. Botten skal vide, hvilket forslag der blev godkendt, hvilken transaktion der blev indsendt, og hvilke reservationer der stadig repræsenterer muligt forbrug. Hukommelse, der forsvandt med processen, kan ikke fungere som kontoens driftsregistrering.
Forestil dig for Atlas Postcard 418, at applikationen genstarter efter indsendelse, men før registrering af ejerskab. Genopretningen finder den oprindelige transaktionsreference, undersøger status og kontrollerer den tilsigtede modtager. Derefter færdiggør den samme købsregistrering. Den bør ikke skabe en ny registrering, blot fordi notifikationen om salgsopslaget vises igen.
Det er en praktisk grund til at tildele økonomiske beslutninger stabile identifikatorer. Hændelsesbeskeder, transaktionsforsøg og ejerskabsobservationer kan alle henvise til ét tilsigtet køb. Samling af referencerne hindrer genstarten i at gøre gentagne oplysninger til gentagen økonomisk aktivitet.
Bevar begrundelsen for at beholde eller sælge
Når NFT'en er ejet, bliver den oprindelige købsregistrering udgangspunkt for en ny beslutning. Botten behøver en beholdnings- eller udtrædelsespolitik, der forklarer, hvilken dokumentation der er relevant, hvor længe positionen må være åben, og hvad der ville gøre den oprindelige værdiansættelse ugyldig.
En højere mindstepris i samlingen fastslår ikke automatisk en realiserbar gevinst på den ejede genstand. Spørgsmålet er, om en egnet køber kan handle på acceptable vilkår. En genstand kan se rentabel ud ved værdiansættelse efter udbudspriser og stadig være svær at sælge.
Registrer faktiske salg adskilt fra foreslåede salgsopslag og urealiserede værdiansættelser. Er genstanden udbudt til 0.9 ETH uden at få et acceptabelt tilbud, indeholder regnskabet stadig NFT'en. En ambitiøs udbudspris er ikke omsætning, og annullering af opslaget sletter ikke den oprindelige anskaffelsespris.
Gennemgå NFT-botten som en kæde af beslutninger
En afsluttende gennemgang bør identificere, hvor udfald afveg fra forventninger. Observationen kan være ankommet sent, værdiansættelsen kan have været for optimistisk, budgetreglen kan have afvist en sund kandidat, eller transaktionen kan være mislykkedes. Hver konklusion peger på en forskellig forbedring.
Vurder ikke arbejdsgangen alene efter gensalgsresultatet. Et rentabelt salg kan følge efter en dårligt kontrolleret beslutning, mens et omhyggeligt afgrænset køb kan miste værdi. Gennemgå dokumentationen og det økonomiske resultat sammen, og hold gunstigt held adskilt fra gentagelig proceskvalitet.
Det fuldstændige forløb efterlader et sporbart spor fra ét observeret salgsopslag til én verificeret kontovirkning. Sporet gør botten forståelig: det viser, hvad der blev foreslået, hvorfor det blev tilladt, hvad der blev forsøgt, og hvad kontoen faktisk ejer. Forskellene er fortsat nyttige, når arbejdsgangen vokser ud over sin første genstand.