En ETH-NFT-handelsbot behöver flera kontoposter som ett enkelt totalsaldo inte kan ersätta. ETH i nätverkets egen valuta finansierar nätverksaktivitet i konventionella Ethereum-transaktioner. WETH är en separat token för stödda handelsflöden. NFT-innehav har egna identifierare och mängdregler medan signerade order kan skapa åtaganden innan något saldo ändras.

Skillnaderna spelar roll även när gränssnittet visar alla värden i ETH-ekvivalenter. En värderingssammanfattning kan relatera tillgångar ekonomiskt utan att göra dem operativt utbytbara. Boten måste veta vilken tillgång en transaktion spenderar, vilken behörighet som används och vilka belägg som fastställer resulterande innehav.

Guiden fokuserar på Ethereum och använder fiktiva saldon, gasvärden och handelsexempel. Siffrorna är undervisningsantaganden. Andra EVM-nätverk och sponsrade eller abstraherade transaktionsvägar kan ha andra finansieringsarrangemang som kräver egna aktuella kontroller.

Definiera ETH-NFT-handelsbotens kontomodell

ETH-NFT-handelsbotens kontomodell bör skilja ETH i nätverkets egen valuta, fungibla betalningstoken, NFT-innehav och utestående handelsåtaganden. Varje post besvarar en annan fråga och bör behålla egna enheter och belägg.

Saldot i nätverkets egen valuta säger hur mycket ETH kontot håller. Ett WETH-saldo beskriver enheter av ett visst tokenkontrakt. NFT-innehavet identifierar tillgångar och mängder. Order beskriver möjliga framtida byten vars effekter kanske inte syns i något saldo ännu.

Koppla kedjeidentitet till varje post. Samma tokensymbol eller en bekant adress på ett annat nätverk fastställer inte samma tillgång eller tillgängliga medel. En instrumentpanel över flera nätverk ska inte låta en kombinerad total bli ett obelagt transaktionsantagande.

Modellen bör också skilja aktuella observationer från uppskattningar. En väntad inkommande betalning är inget tillgängligt saldo och en golvprisvärdering för en samling är ingen försäljningslikvid. Åtskillnaderna möjliggör senare avstämning när gränssnitt uppdateras vid olika tider.

Förstå åtskillnaden mellan ETH- och WETH-saldon

Åtskillnad mellan ETH- och WETH-saldon speglar en faktisk tillgångsskillnad. WETH representerar inpackad ETH genom sitt tokenkontrakt; det är inte bara en annan visningsetikett för saldot av nätverkets egen ETH. Stödd transaktionsväg avgör vilken form den använder.

OpenSeas WETH-förklaring beskriver rollen i Ethereum-NFT-bud. En bot bör bevara relevant tokenidentitet och verifiera aktuella routningskrav i stället för att anta att varje ETH-denominerad skärm kan spendera endera formen utan ytterligare operation.

Inpackning eller uppackning ändrar kontots tillgångssammansättning och kan medföra nätverksutgift. Den bör registreras som omvandling med tillhörande kostnader, inte handelsintäkt eller en ny lönsam NFT-transaktion.

Skillnaden påverkar också tillgänglighet. Ett konto med mycket WETH men lite ETH i nätverkets egen valuta kan behöva ett stött sätt att finansiera nästa nätverksoperation. En kombinerad total kan dölja den praktiska begränsningen.

Följ en hypotetisk inpackningstransaktion

Anta att ett konto börjar med 1,5 ETH och ingen WETH. I ett påhittat exempel packar det in 1,2 ETH och betalar 0,002 ETH i nätverksutgift. Efter operationen håller det 1,2 WETH och 0,298 ETH.

Vid en antagen ett-till-ett-planeringsvärdering är kombinerat belopp 1,498 ETH-ekvivalenter vilket speglar utgiften på 0,002 ETH. Värderingskonventionen slår inte samman saldon eller fastställer att endera direkt kan betala varje senare instruktion.

Om kontot senare packar upp 0,2 WETH och betalar ytterligare antagen utgift på 0,001 ETH faller WETH till 1,0 och ETH i nätverkets egen valuta stiger till 0,497. Operationen ökar tillgänglig ETH i nätverkets egen valuta men minskar inpackat saldo.

Bevara båda sidor av varje omvandling och faktisk transaktionsreferens. En rapport som bara visar inkommande ETH från uppackning kan felklassificera återlämnat kapital som inkomst. Underliggande ekonomisk historik förklarar varför saldot ändrades.

Håll gasreserver i tillgången som betalar dem

För en konventionell Ethereum-transaktion där kontot betalar nätverksavgiften direkt betalas gasutgiften i ETH. Ett WETH-saldo uppfyller inte automatiskt finansieringskravet i nätverkets egen valuta. Alternativa stödda betalningsarrangemang bör identifieras uttryckligen snarare än antas.

Boten bör reservera ett lämpligt belopp i nätverkets egen valuta för tillåtna operationer och kontoåterhämtning. Reserven är ett policyval skilt från en betalningstokenbudget för NFT-förvärv. Den bör förbli synlig i kontovyn.

Guiden till OpenSea-gasavgifter för handel undersöker hur olika åtgärder skapar nätverkskostnader. Här är viktig redovisningspunkt att tillgången för NFT:n och tillgången för nätverksoperationen kan skilja sig.

Beskriv inte reserven som utgift innan den faktiskt spenderats. Den minskar aktuell köptillåtelse för att ägaren skyddat den för ett annat syfte men förblir en kontotillgång. Förväxling av reserv och avgift kan förvränga både kontanttotaler och rapporterade resultat.

Beräkna gas i faktiska enheter

Ethereums gasdokumentation skiljer gasmängder från pris per gasenhet. Boten bör bevara enheterna i stället för att behandla en gasgräns som ett ETH-belopp eller en prisnotering som totalavgift.

För en fiktiv transaktion ger en gräns på 160 000 gasenheter och högsta avgift på 50 gwei per enhet ett högsta gaskostnadsmedgivande på 0,008 ETH. Beräkningen använder en gwei lika med en miljarddel av en ETH. Den betyder inte att hela medgivandet nödvändigtvis debiteras.

Om hypotetisk faktisk användning är 120 000 enheter vid effektivt pris 30 gwei är faktisk utgift 0,0036 ETH. Huvudboken bör registrera resultatet separat från tidigare reservation på 0,008 ETH.

Det är illustrativa Ethereum-beräkningar, inte typiska NFT-transaktionsstorlekar eller aktuella priser. Verkliga uppskattningar beror på operation och tillstånd och andra nätverk kan ha ytterligare avgiftskomponenter. Modellen bör använda relevant kedjas faktiska kvitto- och kostnadssemantik.

Håll WETH-åtaganden åtskilda från WETH-innehav

Ett betalningssaldo i plånboken kan stödja signerade bud som kan genomföras senare. Boten behöver spåra åtagandena utöver aktuellt tokensaldo. En saldofråga ensam förklarar inte hur mycket användarens handelspolicy redan tilldelat.

Anta att ett hypotetiskt Ethereum-konto håller 1,2 WETH och har två separat aktiva anskaffningsåtaganden på 0,45 och 0,50 WETH. Kombinerad möjlig utgift är 0,95 WETH vilket lämnar 0,25 WETH enligt en enkel fullt reserverad policy.

Plånboken kan fortfarande visa 1,2 WETH innan något bud genomförs. Visningen betyder inte att policyn bör tillåta ytterligare 1,2 WETH i skyldigheter. Reservationsberäkningen beskriver möjlig framtida användning av samma tillgångar.

Generalisera inte den plånbokshållna modellen till varje kedja. Solana-marknadsplatsbud kan använda andra finansieringsarrangemang. Guiden till ett flöde för NFT-handel med smarta kontrakt betonar verifiering av faktisk mekanism bakom gränssnittet i stället för en kontomodell överallt.

Skilj betalningsmedgivanden från NFT-behörigheter

Ett spenderingsmedgivande för en fungibel token ger en viss spenderare befogenhet enligt tokenens regler. NFT-behörigheter tillåter specifika överföringar eller en operatör enligt NFT-standard och kontraktsbeteende. De ska inte dela ett tvetydigt godkänd-fält i kontomodellen.

Boten bör identifiera kedja, tokenkontrakt, spenderare eller operatör och relevant omfattning. Ett godkännande att spendera WETH betyder inte att ett orelaterat kontrakt får flytta NFT:er. Ett NFT-operatörsgodkännande fastställer inte att kontot har tillräckligt betalningstoken för köp.

Kontots strategipolicy förblir en separat begränsning. Tekniskt godkännande kan tillåta bredare åtgärder än botens tillåtna samlingsuppsättning eller pristak. Transaktionsvägen behöver upprätthålla smalare regler före användning av tillgängliga behörigheter.

Bevara belägg och tid när en behörighet ändras. En lokal växel ska inte visas som återkallande på kedjan om inte stödd åtgärd faktiskt slutfördes. Befintliga order och väntande operationer kan fortfarande behöva separat avstämning.

Identifiera ERC-721-objekt med kontrakt och token

ERC-721-standarden definierar ett gränssnitt för individuellt identifierade token, inklusive ägande- och överföringsoperationer. En handelspost bör bevara kontrakt och tokenidentifierare tillsammans med kedjan.

Två samlingar kan använda samma numeriska identifierare utan att avse samma NFT. Ett objektnummer som 42 saknar därför fullständig betydelse utan kontraktssammanhang. Visningsnamn och bild är ytterligare metadata snarare än ersättningar för identiteten.

Använd lämpliga ägandebelägg för faktiskt kontrakt. Ett tokenantal på samlingsnivå fastställer inte att kontot äger just objektet det avser lista. Boten måste verifiera den specifika tillgång som är relevant för den föreslagna åtgärden.

Bevara också historik när ett objekt lämnar och senare återkommer. Identifieraren är samma men anskaffningskostnad och innehavsepisod kan ändras. Överskrivning av gammal post skulle radera tidigare affärs ekonomiska resultat.

Använd mängdredovisning för ERC-1155

Mängdredovisning för ERC-1155 behöver saldon för varje relevant tokenidentifierare. ERC-1155-standarden stöder flera tokentyper och överföringsmängder inom ett kontrakt. En ägandemarkering för ett objekt kan inte korrekt representera varje sådant innehav.

En bot bör bevara kontrakt, identifierare, konto och mängd i innehavsposten. En överföring av vissa enheter kan lämna ett restsaldo under samma identifierare. Att objektet visas i plånboken efteråt betyder inte att ursprunglig mängd är oförändrad.

Batchoperationer behöver också noggrann tolkning. En transaktion kan påverka flera identifierare eller mängder. Redovisningsprocessen bör återskapa faktiska tillgångsändringar i stället för att tilldela hela transaktionen till objektet gränssnittet visar först.

Standardetiketten är en indata till ägandemodellen, inte bevis för att varje kontrakt eller marknadsplatsväg stöder varje möjlig operation. Verifiera stött beteende relevant för avsett köp eller försäljning och avvisa tydligt fall som inte stöds.

Följ ett köp av flera enheter genom en delförsäljning

Betrakta ett separat fiktivt köp av åtta enheter till 0,035 ETH-ekvivalenter vardera med 0,004 ETH-ekvivalenter i tilldelad köputgift. Total anskaffningskostnad är 0,284 ETH-ekvivalenter. Vid lika fördelning bär varje enhet 0,0355 i kostnad.

Anta att tre enheter senare säljs för 0,05 vardera. Bruttolikviden är 0,15. Ett påhittat avdrag på 3 % är 0,0045 och en separat tilldelad försäljningsutgift på 0,002 lämnar nettolikvid 0,1435.

De tre sålda enheterna bär 0,1065 i anskaffningskostnad vilket ger realiserad vinst på 0,037. Fem enheter återstår med 0,1775 i tilldelad kostnad. Deras slutliga utfall är fortfarande öppet och ska inte räknas som realiserad vinst.

Exemplet använder en gemensam planeringsenhet för läsbarhet. En faktisk huvudbok bevarar betalningstoken och utgifter i nätverkets egen valuta separat före en angiven värderingsmetod. Det hindrar en praktisk total från att dölja vilka tillgångar som faktiskt kom in på eller lämnade kontot.

Bevara heltalsbelopp och tokenidentifierare

Värden på kedjan använder ofta heltalsbasenheter medan gränssnitt visar decimalbelopp. Boten bör göra medvetna omvandlingar med relevant tillgångs decimaler och bevara exakta värden för transaktionskonstruktion. Binära flyttalsapproximationer kan vara olämpliga för exakta monetära gränser.

Tokenidentifierare behöver också exakt hantering. De är identifierare, inte värden att avrunda för presentation eller analys. En stor identifierare bör överleva lagring, export och uppslag utan att ändras av en datatyp vald för bekvämlighet.

Intern post kan ge människoläsbar formatering tillsammans med exakt värde. Det hjälper operatören granska ett förslag utan förlorad precision som behövs för transaktionsverifiering. Visningsformatering ska inte ändra underliggande godkänt belopp.

En liten testuppsättning kan omfatta en bråkbetalning, en stor tokenidentifierare och två tillgångar med olika decimalkonventioner. Förväntade resultat bör vara kända före verktygskörning så ett omvandlingsfel syns snarare än absorberas i en rimlig total.

Bevara heltalsbelopp och tokenidentifierareERC-721 identityERC-1155 balancePayment allowanceNFT operator approvalTRADING FIELD NOTESEDUCATIONAL RESOURCE
NFT-identitet och mängdregler skiljer sig från betalningsmedgivanden och operatörsbehörigheter; varje del behöver egna kontobelägg.

Tolka signerade order och transaktionsresultat separat

En signerad listning eller ett bud uttrycker villkor som kan fullföljas enligt tillämpligt protokoll. Det är inte i sig belägg för att ägande eller betalning redan ändrats. Boten bör hålla orderstatus och kontoeffekter som sammankopplade men skilda poster.

Granska faktiska tillgångsändringar, mottagare och köpeskilling när genomförande sker. En generell indikator på transaktionsframgång förklarar inte i sig varje ekonomisk effekt i en transaktion med flera operationer.

Håll osäkra inskickanden synliga tills relevanta kedjebelägg klarlägger dem. En timeout ska inte automatiskt frigöra reservationen eller skapa ett annat oberoende förvärv. Återhämtningsprocessen börjar med ursprunglig avsikt och transaktionsreferens.

Skillnaden förbättrar också gränssnittet. En order kan vara aktiv medan kontot fortfarande håller NFT:n eller ett förvärv verifierat medan ett marknadsplatsindex inte uppdaterats. Skärmen bör beskriva tillstånden snarare än komprimera dem till en vilseledande slutförd-etikett.

Håll kedjeidentitet uttrycklig över EVM-nätverk

Ett Ethereum-kompatibelt adressformat gör inte saldon eller kontrakt utbytbara mellan nätverk. Boten bör inkludera kedjeidentitet när tokenkontrakt, behörigheter, ordervägar och transaktionsreferenser lagras.

Guiden till en Polygon-NFT-bot ger en användbar jämförelse. EVM-kompatibilitet kan göra vissa programvarubegrepp välbekanta medan gasvalutor, driftsatta kontrakt och stödda marknadsplatsvägar fortfarande kräver separat verifiering.

Använd inte ett kombinerat panelsaldo för att godkänna en transaktion på ett nätverk om inte en stödd finansieringsväg ingår i faktiskt förslag. Medel på annan plats är inte automatiskt tillgängliga vid destinationen bara för att symbolerna matchar.

Om en nätverksöverskridande väg används avsiktligt, dokumentera steg och faktiska kostnader. En väntande överföring mellan nätverk är en annan olöst kontooperation, inte en ursäkt att anta att destinationssaldot redan ökat.

Stäm av överföringar utan att hitta på handelsinkomst

Inpackning, uppackning och rörelse mellan ägarens plånböcker kan ändra saldon utan lönsam NFT-försäljning. Huvudboken behöver klassificering som bevarar skillnaderna och undviker att behandla varje inkommande tillgång som intäkt.

En NFT mottagen utan känd köppost kan ha olöst historisk kostnad. Registrera tillgången och saknad information i stället för att tilldela nollkostnad enbart för att ingen betalning syntes i samma transaktion.

På samma sätt kan en utgående NFT representera intern överföring snarare än försäljning. Försäljningslikvid kräver belägg för köpeskilling och sammanhang. Tokenrörelsens riktning ensam fastställer inte finansiellt resultat.

Disciplinen gör granskning av hela kontot mer trovärdig. ETH-utgifter i nätverkets egen valuta, betalningstokenändringar och NFT-överföringar bör stämma av till en sammanhängande historik med okända poster synliga snarare än dolda i en justering som gör slutsaldot praktiskt.

Testa kontomodellen med avsiktliga felmatchningar

Ett användbart test omfattar nog med WETH för ett bud men otillräckliga medel i nätverkets egen valuta för avsedd direktbetald nätverksoperation. Förväntat resultat är finansieringsavslag eller en separat granskad stödd lösning, inte påståendet att kombinerat saldo räcker.

Ett annat testfall kan omfatta en ERC-1155-delförsäljning och dubbel överföringsobservation. Återstående mängd och kostnadsfördelning bör ändras en gång för faktisk försäljning. Upprepade belägg får inte skapa extra enheter eller extra likvid.

Testa också fel kedja och ett betalningsmedgivande till fel spenderare. Felen bör identifieras före signering med tillräckligt sammanhang för att operatören ska förstå felmatchningen. Ett generellt fel efter inskickande är en svagare kontroll.

Testerna fastställer beteende inom angiven omfattning. De validerar inte en värderingsstrategi och garanterar inte framtida kompatibilitet. Värdet är att visa att programvaran bevarar skillnaderna som krävs för att förstå kontot.

En ERC-721-handelsbot bör bevara kedje-, kontrakts- och tokenidentitet genom ägandekontroller, godkännanden, order och bekräftade överföringar.

Håll ETH-NFT-handelsbotens huvudbok förklarlig

Slutlig kontovy bör låta läsaren skilja disponibel ETH i nätverkets egen valuta, betalningstokensaldon, möjliga orderåtaganden, verifierade NFT-mängder och realiserade utgifter. En gemensam värderingstotal kan ligga ovanför posterna utan att ersätta dem.

Spåra ett överraskande resultat till underliggande tillgångsändringar. En WETH-minskning kan finansiera ett förvärv, en ETH-minskning betala gas och en partiell NFT-försäljning lämna en betydande öppen position. Huvudboken bör förklara varje relation i egna enheter.

Granska uppskattningar och faktiska kostnader när transaktioner slutförs och bevara ursprungligt godkännande. Skillnader kan förbättra senare planering men omskrivning av gammalt förslag till utfallet skulle dölja om kontrollen fungerade.

En ETH-NFT-handelsbot blir lättare att lita på när den inte suddar ut tillgångar, standarder eller tillstånd. Tydlig åtskillnad stöder korrekt godkännande och ärlig finansiell granskning inklusive slutsatsen att kontot saknar rätt medel eller belägg för nästa föreslagna affär.

Fortsätt lära dig

Utforska alla resurser