En handelsbot för ERC-1155 behöver både en mängdhuvudbok och en tillgångsidentifierare. En position kan innehålla flera enheter av en tokentyp, och en föreslagen försäljning kan bara gälla en del av positionen. Att behandla varje NFT-post som ett enda odelbart objekt kan därför förvränga tillgängliga innehav, genomsnittskostnader och utestående åtaganden.
Driftutmaningen är att bevara förhållandet mellan tokentyp, mängd, inköpshistorik och ordertillstånd. Ett antal samlingsbilder kan inte besvara hur många enheter som återstår efter en delvis avyttring. Ett totalt plånbokssaldo visar inte heller hur mycket av innehavet som redan är reserverat för andra instruktioner.
Guiden använder en fiktiv samling som heter Lantern Editions och hypotetiska mängder och ETH-priser. Den förklarar utformning av redovisning och kontroller snarare än en viss marknadsplatsimplementering. Varje faktisk genomförandeväg behöver egna verifierade villkor, kontroller av tillgångar som stöds och belägg för de resulterande kontoändringarna.
Bygg handelsboten för ERC-1155 kring tokentyper
Den officiella ERC-1155-specifikationen beskriver ett kontraktsgränssnitt som kan hantera flera tokentyper med saldon kopplade till ett konto och ett token-ID. Det omfattar enskilda överföringar och batchöverföringar, batchfrågor om saldon och operatörsgodkännanden. Förmågorna avgör inte hur en marknadsplats prissätter en upplaga eller om en viss order stöder delvis genomförande.
Använd kedjan, kontraktet och token-ID:t som typidentitet och lagra sedan mängden separat. Ett token-ID är inte den innehavda mängden. Åtskilda fält hindrar en visningsidentifierare från att tolkas som ett belopp och gör att flera inköpsposter kan bidra till ett aktuellt typsaldo.
Koppla en tydlig enhetsetikett till varje mängd. Ett förslag om fem upplageenheter ska inte förväxlas med fem olika tokentyper eller fem ETH i köpkraft. Gränssnittet kan sammanfatta positionen, men underlaget bör bevara tillräckliga detaljer för att återskapa exakt den avsedda överföringen.
Jämförelsen med en handelsbot för ERC-721 är användbar eftersom den visar ett viktigt modelleringsval. Programvara byggd kring ägande av enskilda objekt ska inte tyst återanvända det antagandet för mängdposter. Identifiera standarden som stöds innan tillgångar importeras till handelsboken.
Skilj innehavda, reserverade och tillgängliga mängder
Det observerade saldot besvarar hur många enheter kontot innehar enligt sin verifieringspolicy. Reserverad mängd besvarar hur många enheter flödet har bundit till aktiva försäljnings- eller överföringsavsikter. Tillgänglig mängd är en policyberäkning som tar hänsyn till åtagandena och eventuella olösta avvikelser.
Anta att ett hypotetiskt konto innehar 12 enheter av Lantern Edition 7. En aktiv instruktion reserverar fyra enheter, och en annan olöst åtgärd avser två. Med en försiktig policy som reserverar båda återstår bara sex tillgängliga enheter för en ny instruktion. Att redovisa alla 12 som fritt tillgängliga skulle bortse från flödets egna befintliga åtaganden.
Dokumentera vad som skapar och frigör en reservation. Ett utkast kanske inte förtjänar samma behandling som ett godkännande av en genomförbar order, men skillnaden måste vara avsiktlig. En annulleringsbegäran ska inte frigöra innehav innan systemet har de belägg som den faktiska genomförandeutformningen kräver.
Regler för mängdreservation i ERC-1155 bör bestå genom omstarter. Om reservationer bara finns i minnet kan en omstart få redan bundna innehav att verka tillgängliga igen. Återskapa reservationerna från beständiga avsikts- och utfallsposter innan nästa förslag får använda saldot.
Följ inköpspartier utan att hitta på fysiska serienummer
Ett inköpsparti dokumenterar när och till vilken kostnad kontot fick en mängd. Det är en redovisningspost, inte nödvändigtvis ett påstående om att enskilda enheter har separata serieidentiteter. Kontoboken kan bevara flera köps ekonomiska historik även när enheterna delar en tokentypidentitet.
Anta som illustration att kontot köper tre enheter till 0,10 ETH styck och senare två till 0,14 ETH styck före kostnader. Det totala köpvärdet är 0,58 ETH för fem enheter, vilket ger ett genomsnitt på 0,116 ETH per enhet enligt en enkel genomsnittskostnadsmetod. Originalpartierna bör förbli tillgängliga även om rapporterna visar genomsnittet.
Välj en konsekvent konvention för intern rapportering som fördelar inköpskostnad på avyttringar. Olika konventioner kan ge olika siffror per försäljning medan kontots totala aritmetik fortfarande går att stämma av. Presentera inte den valda metoden som universell skattehantering; guiden gäller intern strategianalys och bevarande av poster.
Bevara varje partis mängd och kostnader så att beräkningen kan ändras eller granskas senare utan att källbelägg förloras. Att slå samman varje köp till ett överskrivet genomsnitt gör det svårt att förklara en avvikelse eller undersöka vilken förvärvsperiod som skapade den aktuella exponeringen.
Skilj enhetspris från ordertotal
En annons kan uttrycka villkor på sätt som kräver noggrann tolkning. Förslaget måste identifiera om ett visat belopp gäller en enhet, en grupp enheter eller hela ordern. Härled aldrig skillnaden enbart från en NFT-bild eller en kort prisetikett.
I ett hypotetiskt exempel innebär ett erbjudande om att köpa sex enheter för totalt 0,48 ETH ett pris på 0,08 ETH per enhet före kostnader. Ett erbjudande om sex enheter till 0,48 ETH styck innebär 2,88 ETH före kostnader. Samma tal ger mycket olika exponering när prisenheten missförstås.
Visa både enhetsbeloppet och det totala åtagandet i granskningsposten. Ta med betalningstillgång, begärd mängd och hänförliga kostnader. En granskare bör kunna återskapa totalsumman med enkel aritmetik innan åtgärden godkänns.
Testa skillnaden med avsiktligt tvetydiga exempelposter. Om importören inte kan avgöra prisgrunden bör den avvisa förslaget eller lyfta det till granskning i stället för att välja en bekväm tolkning. En till synes billig upplaga kan vara ett dyrt köp när ett totalprisfält misstas för ett enhetsprisfält eller tvärtom.
Hantera delvis genomförande enligt den faktiska ordern
Tokenstandarden fastställer inte ensam att en order får fyllas delvis. Undersök genomförandevägen och ordervillkoren. När delvis genomförande stöds bör kontoposten skilja begärd mängd, genomförd mängd, återstående aktiv mängd och annullerad eller utgången mängd åt.
Anta att en hypotetisk order begär 10 enheter och att det verifierade resultatet fastställer fyra köpta enheter. Innehavsposten ökar med fyra, medan de återstående sex beror på orderns faktiska tillstånd. Att räkna 10 som innehavda hittar på innehav; att räkna hela ordern som färdig kan glömma ett kvarstående åtagande.
Redovisning av delvisa ERC-1155-orderfyllnader bör koppla varje genomförande till den ursprungliga avsikten utan att skriva över tidigare fyllnader. Om tre enheter kommer och två kommer senare bör posten visa båda händelserna och totalt fem. Historiken hjälper till att förklara kostnader och tidsskillnader under köpet.
Använd samma disciplin för försäljningar. En delvis avyttring minskar den innehavda mängden med det verifierade antalet och avslutar motsvarande del av redovisningspositionen. De återstående enheterna behåller egen exponering och kostnadspost. En försäljningsetikett får aldrig antyda att hela upplagepositionen försvann om inte mängdbeläggen stöder det.
Bevara batchkopplingar i varje granskning
När en föreslagen åtgärd innehåller flera tokentyper ska kopplingen mellan varje identifierare och dess mängd bevaras. En granskningsvy som listar alla identifierare på ett ställe och alla mängder på ett annat kan göra en avvikelse svår att upptäcka. Visa varje par som en semantisk enhet även om det underliggande gränssnittet använder arrayer.
För en fiktiv batch kan de avsedda paren vara Edition 7 med tre enheter, Edition 12 med en enhet och Edition 19 med sex enheter. Att byta plats på två mängder ändrar åtgärden även om identifieraruppsättningen och taluppsättningen är desamma. Valideringen måste kontrollera förhållandena, inte bara att värdena finns.
Definiera hur flödet representerar ett batchförsök och dess verifierade utfall. Anta inte att marknadsplatsens gruppering av genomförandet är identisk med tokenöverföringsgränssnittets gruppering. Kontot bör använda den faktiska vägens belägg för att avgöra vilka avsedda ändringar som skedde.
En granskning av en ERC-1155-batchöverföring bör också identifiera mottagaren och den totala ekonomiska exponeringen. En batch kan förenkla en åtgärd men öka följderna av en felaktig destination eller mängdkoppling. Bekvämlighet tar inte bort behovet att undersöka varje väsentligt annorlunda del av förslaget.
Fördela gemensamma kostnader transparent
En kombinerad åtgärd kan ge en kostnad utan separat uppdelning per typ. Kontoboken behöver en uttrycklig fördelningskonvention för intern analys och måste samtidigt bevara den faktiska totalsumman. Lika fördelning per enhet, fördelning efter köpvärde och direkt hänföring där den finns besvarar olika rapporteringsfrågor.
Betrakta ett hypotetiskt köp av två typer med värden på 0,20 och 0,80 ETH och en gemensam kostnad på 0,05 ETH. Fördelning efter köpvärde ger 0,01 respektive 0,04 ETH i kostnad. Lika fördelning mellan typerna ger 0,025 ETH till vardera. Ingen beräkning ändrar den totala utgiften på 1,05 ETH, men resultatrapporterna per typ skiljer sig.
Välj konventionen innan strategier jämförs, dokumentera den och tillämpa den konsekvent. Att ändra metoden för att förbättra hur en förlustposition ser ut gör analysen missvisande även om kontototalen fortfarande stämmer. Bevara tillräckliga rådata för att räkna om rapporterna enligt en annan rimlig konvention.
Håll också kostnader för misslyckade försök synliga. Om ett köpförsök inte ger innehav men kostar pengar har projektet ändå använt resurser. En rapport begränsad till lyckade partier underskattar driftbördan och kan få täta misslyckade försök att verka ekonomiskt harmlösa.
Modellera försäljningskapacitet för den avsedda mängden
Ett pris för en enhet fastställer inte att en större mängd kan säljas på samma genomsnittliga villkor. Flödet bör utvärdera den avsedda avyttringsstorleken och det tillgängliga relevanta köparintresset. En liten attraktiv offert kan bara beskriva en bråkdel av kontots position.
Anta att kontot innehar 20 hypotetiska enheter. Köpare erbjuder nu 0,10 ETH för de första två enheterna, 0,08 ETH för nästa tre och inga verifierade villkor för resten. Att värdera alla 20 till 0,10 ETH antar efterfrågan som beläggen inte visar. Posten bör skilja intäkter som stöds från den olösta återstoden.
Använd flera scenarier för belopp som kan återfås i innehavsrapporteringen. En modell kan visa resultatet av att snabbt sälja en liten mängd, sälja mer på sämre villkor eller hålla osålda enheter längre. Det är scenarier, inte löften om framtida likviditet.
Mängdkoncentration spelar roll även när enhetspriset verkar måttligt. Upprepade köp av samma upplaga kan binda betydande kapital till en köparkrets. En gräns per order bör därför kompletteras med en gräns för totala innehav och åtaganden per typ.
Håll handelsbotens ERC-1155-behörighetspost separat
Operatörsgodkännande i standarden har bredare omfattning än en lokalt beskriven affär. Flödet bör visa det relevanta kontraktet och den behöriga parten och förklara förhållandet mellan befogenheten och den avsedda åtgärden. Ett attraktivt pris är inget skäl att hoppa över behörighetsgranskningen.
Lagra behörighetsobservationer separat från orderstatus. En order kan löpa ut medan befogenheten finns kvar, och att inaktivera strategin beskriver inte i sig behörighetstillståndet. Kontots granskningsprocess bör synliggöra skillnaderna för den som ansvarar för plånboken.
Om genomförandevägen ändras ska dess befogenhetsbehov omprövas. Anta inte att en tidigare observerad behörighet är lämplig bara för att den nya vägen tjänar ett liknande syfte. Verifierade identifierare och aktuella krav bör styra beslutet.
Den bredare mandatdiskussionen om en NFT-handelsagent förklarar varför planering och befogenhet behöver separata kontroller. En mängdmedveten agent kan föreslå användbara innehavsåtgärder, men dess tillåtelse att genomföra dem bör förbli begränsad av uttryckliga regler för tillgångar, belopp och drift.
Stäm av externa överföringar och oväntade saldoändringar
Botens egen orderhistorik förklarar kanske inte varje kontorörelse. En person kan använda ett annat gränssnitt, ett annat godkänt flöde kan agera eller en tillgång kan komma utanför den väntade inköpsprocessen. Kontoboken bör upptäcka det ändrade saldot och undersöka ursprunget i stället för att pressa in det i närmaste kända affär.
Klassificera en rörelse som köp, avyttring, förvaringsöverföring eller olöst händelse bara när beläggen stöder klassificeringen. En inkommande mängd är inte automatiskt ett köp till aktuellt marknadspris. En utgående mängd är inte automatiskt en försäljning med intäkter motsvarande en visad offert.
Bevara den ursprungliga observationen och den senare förklaringen. Om en saldoavvikelse klarläggs efter granskning ska stödjande belägg läggas till i stället för att posten tyst ersätts. Det gör kontohistoriken användbar för att diagnostisera återkommande problem med datainsamling eller operatörssamordning.
Pausa nya åtgärder som berör den omtvistade typen när avvikelsen påverkar tillgänglig mängd. Fortsatta reservationer eller försäljningar från ett osäkert saldo kan skapa motstridiga åtaganden. Oberoende övervakning kan fortsätta medan det berörda innehavet granskas.
Testa mängdaritmetiken vid gränserna
Använd små begripliga exempel innan antalet typer eller enheter skalas upp. Ta med noll tillgänglig mängd, ett belopp över verifierat saldo, en delvis genomförd order och två samtidiga förslag som konkurrerar om samma enheter. Varje fall testar ett eget antagande i reservationsmodellen.
Testa hur mängder tolkas och lagras. En mängd ska inte tyst avrundas till ett annat godkänt belopp. Om vägen eller tillgången kräver heltalsenheter och förslaget innehåller en bråkdel som inte stöds ska det uttryckligen avvisas i stället för att användarens avsikt gissas.
En nybörjare kan gå igenom fallen tillsammans med en övning för en NFT-bot för nybörjare. Poängen är att synliggöra tillståndsändringarna med enkla tal så att operatören kan förklara varför tillgängliga innehav ändrades efter varje händelse.
Bevara exemplen som en regressionsuppsättning för senare ändringar. En ny visningskomponent eller importör kan införa mängdfel även när genomförandekoden är oförändrad. Testet bör verifiera de meningsfulla förhållandena mellan innehavda, reserverade och genomförda mängder, inte bara bekräfta att en knapp fortfarande visas.
Avsluta sessionen med avstämning av mängder och kassa
Koppla för varje typ samman ingående mängd, verifierade inflöden, verifierade utflöden och utgående mängd. Stäm sedan av relaterade betalningsrörelser och kostnader. Vyerna besvarar olika frågor och bör stämma med dokumenterade åtgärder utan att slås samman till en enda uppskattning av nettovärde.
Undersök skillnader innan en ny session börjar. En liten avvikelse kan visa en dubblerad orderfyllnad, en odokumenterad överföring eller ett tolkningsfel. Att upprepade gånger föra den vidare gör senare avstämning svårare eftersom varje ny åtgärd beror på ett redan osäkert ingående saldo.
Bevara osålda innehav separat från realiserade resultat. Ett hypotetiskt värde på återstående enheter är inte återvunnen kassa. Rapporter bör förklara hur mycket av strategins skenbara värde som beror på en uppskattning för tillgångar som fortfarande behöver köpare.
Den sista sessionsanteckningen bör identifiera olösta order, reserverade mängder och eventuella behörighetsändringar som fortfarande är relevanta. En tyst handelsslinga är inte ett fullständigt kontotillstånd. Operatören behöver tillräcklig information för att starta om sammanhängande utan att återupptäcka den förra sessionens avsikter.
Vanliga frågor om handel med upplagor
Betyder ett token-ID alltid en enhet?
Nej. Kontomodellen måste bevara den observerade mängden kopplad till tokentypen. Att behandla identifieraren som ett innehav av ett enda objekt kan ge fel innehavs- och orderkapacitet. Använd tillgångens och vägens faktiska semantik i stället för att härleda mängd från hur en marknadsplats visar bilden.
Är en batch alltid ekonomiskt bättre?
Inte nödvändigtvis. En batch kan ändra genomförandekostnader och driftkomplexitet, men resultatet beror på den faktiska vägen och det föreslagna innehållet. Jämför fullständiga kostnader och följderna av en misslyckad eller felaktig åtgärd. Bekvämlighet fastställer inte ensam ett bättre ekonomiskt utfall.
Kan jag sälja allt till det senaste enhetspriset?
Ett tidigare enhetspris fastställer inte aktuell efterfrågan på hela innehavet. Undersök genomförbara villkor för den avsedda mängden och håll intäkter utan stöd synligt osäkra. Stora upplagepositioner kan kräva en annan försäljningsplan än den som en liten nylig transaktion antyder.
Vilken första kontroll är viktigast?
Bekräfta att flödet skiljer tokentyp, mängd och prisgrund åt. Verifiera sedan att innehavda och reserverade mängder stämmer efter ett delvis utfall. Grunderna gör senare kostnads- och innehavsanalys meningsfull. Avancerad värdering kan inte reparera en kontomodell som inte vet hur många enheter den faktiskt kontrollerar.