NFT-handel med smartkontrakter er en rekke tillatelser og tilstandsendringer, ikke én handling kalt å koble til en lommebok. En tokenkontrakt registrerer eiendeler, en handelsprotokoll tolker en ordre, betalingskontrakter flytter støttede token, og en lommebok autoriserer bestemte meldinger eller transaksjoner. Forståelse av rollene gjør det endelige økonomiske resultatet lettere å bekrefte.
En signert ordre kan eksistere uten et salg. En godkjenning kan eksistere uten en ordre. En transaksjon kan sendes inn uten å fullføre den tiltenkte overføringen. Omvendt kan en transaksjon som utføres vellykket, følge de signerte instruksene nøyaktig og samtidig gi en økonomisk dårlig handel. Teknisk gyldighet og investeringskvalitet er separate spørsmål.
Veiledningen forklarer grensene med EVM-NFT-eksempler og skiller dem uttrykkelig fra Solana-programmer. Alle tallfestede fordelinger og handelsverdier er hypotetiske. Målet er å lese hva en handelshandling faktisk autoriserer, og erkjenne hvilke garantier som stopper ved grensen til en bestemt transaksjon.
NFT-handel med smartkontrakter involverer flere kontrakter
Begynn med NFT-kontrakten. For et typisk EVM-objekt skiller kombinasjonen av kjede, kontraktadresse og tokenidentifikator ut eiendelen. Bildet og samlingsnavnet er nyttige beskrivelser, men erstatter ikke identifikatorene. To kontrakter kan vise nesten identisk kunst og samtidig registrere forskjellige token.
En markedsplassprotokoll har en annen rolle. Den kontrollerer støttede ordrevilkår og samordner spesifiserte overføringer når gjennomføring er gyldig. Seaport er et viktig EVM-eksempel; ordremodellen skiller tilbudte eiendeler fra påkrevd vederlag. Strukturen kan representere mer enn et enkelt bytte av én NFT mot én betaling.
En betalingstokenkontrakt legger til en annen grense når handelen bruker en ERC-20-eiendel som WETH. Lommebokens opprinnelige ETH-saldo og WETH-saldo er forskjellige. Påkrevd betalingseiendel må samsvare med ordren, og relevant overføringstillatelse må være gyldig når den trengs.
Ytterligere komponenter kan håndheve overføringsbegrensninger, skaperinntekter eller andre støttede vilkår. Tilstedeværelsen bør forstås fra faktisk rute fremfor å utledes fra et kjent samlingsnavn. Et generelt diagram med kjøper, selger og markedsplass kan skjule flere meningsfulle kontroller.
OpenSeas Seaport-oversikt gir grunnleggende ordforråd for tilbud og vederlag. Bruk det til å identifisere eiendeler og mottakere i en EVM-ordre, samtidig som gjeldende implementasjonsdetaljer kontrolleres gjennom den bestemte støttede flyten.
Tokenstandarder endrer hva mengde betyr
En ERC-721-tokenidentifikator identifiserer vanligvis en særskilt NFT med én nåværende eier under standardens eierskapsmodell. En handelsinstruks bør identifisere tiltenkt token fremfor bare samlingen. Eierskap til token 17 fastslår ikke eierskap til token 18.
ERC-1155 støtter flere tokentyper i én kontrakt og mengder for hver identifikator. En ordre på én enhet av en identifikator kan derfor skille seg fra en ordre på hver enhet lommeboken eier. En oppføringsvisning må bevare valgt mengde så vel som token-ID.
Ethereums ERC-721-dokumentasjon og ERC-1155-dokumentasjon beskriver de forskjellige grensesnittene. De bidrar til å forklare hvorfor en generell NFT-saldoteller er utilstrekkelig ved transaksjonsgjennomgang.
Se på en fiktiv lommebok med fem enheter av én ERC-1155-identifikator. Et foreslått salg av to enheter bør etterlate tre hvis det utføres som tiltenkt og ingen andre relevante endringer skjer. En rapport som markerer hele identifikatoren som solgt, ville viske ut gjenværende beholdning.
Standarden påvirker også støttede godkjenninger og mottakeratferd. En overføring kan mislykkes fordi destinasjonen eller kallvilkårene er uforenlige, selv når vist navn og beløp ser riktige ut. Gjennomgå faktisk eiendel og rute fremfor å anta at hver NFT følger samme overføringsfunksjon.
En godkjenning er tillatelse, ikke et kjøp
En godkjenning autoriserer en operatør til å handle innen et definert omfang. Det er ikke det samme som å signere en kjøpspris, legge ut en salgsoppføring eller bekrefte at et salg skjedde. Å skille begrepene bidrar til å forklare hvorfor en lommebok kan be om mer enn én autorisasjon i en arbeidsflyt.
For ERC-721 kan tillatelser omfatte godkjenning for et bestemt token eller operatørgodkjenning på tvers av eierens token i kontrakten. ERC-1155 bruker operatørgodkjenning under standardgrensesnittet. Betalingstokenfullmakter har egen betydning for beløp og part med bruksfullmakt. Nøyaktig tillatelse bør kontrolleres før den gis.
Godkjenninger ved NFT-handel med smartkontrakter bør derfor gjennomgås etter kontrakt, operatør og omfang. «Godkjenn markedsplass» er en praktisk merkelapp, men spørsmålet med konsekvenser er hvilken adresse som får hvilken evne over hvilke eiendeler. En kjent logo besvarer ikke det.
En eksisterende godkjenning kan bestå etter at en bestemt handel er ferdig. Å fjerne en salgsoppføring tilbakekaller ikke nødvendigvis en tokentillatelse, og tilbakekalling av en tillatelse sletter ikke den historiske oppføringsregistreringen. De er relaterte kontroller med forskjellige virkninger.
Den praktiske gjennomgangen står i forhold til handlingen. Forstå tillatelsen tiltenkt rute trenger, bekreft forespørselskonteksten og bevar nok informasjon til å inspisere eller tilbakekalle den senere gjennom støttede midler. Ingen handelsstrategi trenger en hemmelig nøkkel kopiert til et undersøkelsesnotat for å forklare grensene.
En signert ordre beskriver et betinget bytte
En signert ordre registrerer vilkår en motpart kan være i stand til å oppfylle mens ordren er gyldig. Betydningen kan omfatte eiendelsidentifikatorer, beløp, mottakere, gyldighetstider og kriterier. Den er ikke bare en melding om at signatøren liker nåværende pris.
Ved salg undersøker du hva som forlater selgeren, og hva selgeren eller andre angitte mottakere må motta. Ved et kjøpstilbud undersøker du hvilke eiendeler budgiveren betaler, og hvilke NFT-kriterier som kan oppfylle byttet. Retningen endres, men behovet for å lese begge sider består.
Signerte ordrer ved NFT-handel med smartkontrakter kan få konsekvenser etter at signeringsgrensesnittet lukkes. En motpart kan handle senere mens nødvendige vilkår fortsatt gjelder. Derfor hører varighet, finansiering, eierskap og kanselleringstilstand til den løpende kontooversikten.
Ordreidentifikatorer og transaksjonshasher besvarer forskjellige spørsmål. Ordren identifiserer betingede vilkår. En gjennomføringstransaksjon identifiserer et bestemt forsøk på å utføre dem. Flere statusoppdateringer om én ordre bør ikke telles som flere uavhengige handler.
Ikke likestill en signaturforespørsel med harmløs innlogging bare fordi den ikke straks belaster gass. Det viktige er hva den signerte meldingen autoriserer. Et godt utformet grensesnitt bør vise domene, vilkår og tiltenkt virkning i en form signatøren kan forstå.
Les vederlaget som et fullstendig betalingskart
Et salg kan sende deler av brutto betaling til forskjellige mottakere. Beløpet kjøperen gir, er ikke alltid beløpet selgeren beholder. Forskjellen betyr noe både for transaksjonsgjennomgang og fortjenesteregnskap.
Tenk deg et oppdiktet kjøp med samlet vederlag på 1,20 ETH. Det spesifiserte betalingskartet sender 1,128 til selgeren, 0,024 til én gebyrmottaker og 0,048 til en skapermottaker. De tre beløpene summerer seg til 1,20. Anta at kjøperen separat bruker 0,007 ETH på nettverksutførelse.
Kjøperens samlede utlegg i øvelsen er 1,207 ETH. Å legge til 0,024 og 0,048 igjen oppå 1,20 ville dobbeltelle beløp som allerede inngår i vederlaget. Selgerens bruttomottak fra betalingskartet er 1,128, ikke 1,20.
De fiktive prosentene er ikke gjeldende OpenSea-gebyrer. Formålet er å vise hvorfor faktisk transaksjonsoversikt må identifisere betaler, mottaker og gebyrgrunnlag. En visning som sier «gebyrer inkludert», bør avstemmes mot overføringene fremfor å tolkes som at ingen mottaker får et gebyr.
Påkrevde og valgfrie skaperbetalinger trenger også separat behandling. OpenSeas referanse for gjennomføring av salgsoppføringer skiller valgfri inkludering fra allerede påkrevde skapergebyrer. En valgfri innstilling bør ikke antas å fjerne et påkrevd vederlagsbeløp.
Et tydelig betalingskart gjør handelen kontrollerbar før signering og regnskapet reproduserbart etterpå. Det viser også uventede mottakere en fremhevet kjøpspris ikke ville avsløre.
NFT-handel med smartkontrakter har atomisitetsgrenser
En atomisk tilstandsovergang betyr at relevante endringer innen transaksjonen skjer etter utførelsesreglene eller tilbakestilles når transaksjonen mislykkes. Dette kan beskytte forholdet mellom en betaling og en NFT-overføring i et korrekt utformet bytte.
Ved vurdering av NFT-handel med smartkontrakter med atomisk oppgjør identifiserer du nøyaktig transaksjon hvis virkninger må lykkes sammen. Grensen er faktisk transaksjon og kontraktatferd. Den omfatter ikke automatisk en separat godkjenning gitt tidligere, et fremtidig videresalg eller en overføring på et annet nettverk. En strategi med flere transaksjoner kan derfor ende i en mellomtilstand selv om hver individuell transaksjon følger reglene.
For eksempel kan en godkjenning lykkes, og et kjøp deretter mislykkes fordi objektet ble solgt et annet sted. Godkjenningen kan bestå selv om NFT-en ikke ble anskaffet. Å behandle hele brukerreisen som én atomisk handling ville gi feil kontotolkning.
Samleoperasjoners atferd trenger også gjennomgang. Noen støttede ruter kan behandle tilgjengelige ordrer mens utilgjengelige forblir uutført. En vellykket ytre transaksjon bør ikke automatisk leses som bekreftelse på at hvert objekt brukeren opprinnelig valgte, ble kjøpt. Avstem faktiske overføringer og mengder.
Det avgjørende spørsmålet er hvilke virkninger det innsendte kallet krever sammen, og hvilke det tillater å lykkes uavhengig. En knapp kalt sweep, batch eller execute fastslår ikke garantien. Transaksjonens støttede virkemåte gjør det.
Henvis og tjen USDC
Henvis og tjen USDCPartnerprogrammet vårt betaler i sanntid.
Et vellykket kjøp låser ikke et videresalg
Gå tilbake til den hypotetiske anskaffelsen som kostet 1,207 ETH. Anta at en separat potensiell kjøper nå tilbyr 1,30 for samme kvalifiserende NFT. Med et oppdiktet samlet selgerfradrag på 6 % og 0,005 ETH i utgangskostnader ville netto videresalgsproveny være 1,217 ETH.
Hvis begge handler faktisk fullføres på vilkårene, er modellert resultat gevinst på 0,010 ETH. Kjøpstransaksjonens atomiske oppgjør kan sikre eget påkrevd bytte, men bevarer ikke den senere kjøperens tilbud mens traderen får eierskap og forbereder videresalget.
Hvis tilgjengelig videresalg faller til 1,05 før andre handling, etterlater samme hypotetiske kostnader 0,982 ETH i nettoproveny. Salg der ville tape 0,225 ETH mot anskaffelsen på 1,207. Første kjøp kan ha vært teknisk korrekt mens samlet sekvens blir ugunstig.
Dette er risiko mellom sekvensielle handelsledd. Den oppstår når strategien bygger på en fremtidig handling som ikke inngår i samme bekreftede atomiske utførelsesgrense. Raskere programvare kan redusere noe tidsbruk uten å gjøre separate handlinger til en felles garanti.
En gyldig arbitrasjeforklaring må derfor identifisere faktisk støttet utførelsesstruktur. Hvis ruten ikke kan gjøre nødvendige ledd betinget av hverandre, fortjener mellomliggende beholdning og mulig tap uttrykkelig analyse. Å kalle komponentene smartkontrakter fjerner ikke eksponeringen.
Simulering beskriver en bestemt tilstand
En transaksjonssimulering kan bidra til å identifisere forventede overføringer og utførelsesfeil under tilstanden simuleringen bruker. Den er verdifull dokumentasjon, særlig når foreslått handling inneholder flere kontrakter eller mottakere. Den er fortsatt en observasjon om et bestemt sett forhold.
Eierskap, saldoer, bruksfullmakter og ordregyldighet kan endres før inkludering. En oppføring som ble simulert vellykket, kan gjennomføres av noen andre først. En gebyrfølsom operasjon kan møte et annet nettverkskostnadsmiljø når den sendes. Simuleringsresultatet bør beholde tidspunkt og antakelser.
Bruk simulering til å sammenligne foreslåtte virkninger med brukerens autorisasjon. Kommer tiltenkt token til tiltenkt mottaker? Forlater forventet betaling kontoen i riktig eiendel? Finnes andre godkjenninger eller overføringer som ikke inngikk i undersøkelsesbeslutningen?
Ikke tolk vellykket simulering som bevis på at eiendelen er ekte, verdifull eller sannsynligvis vil stige. Det er andre spørsmål. En forfalsket samling kan inneholde en teknisk gjennomførbar transaksjon, og en økonomisk dårlig ordre kan simuleres perfekt.
Hvis en rute endres etter simulering, gjenta relevant gjennomgang. Gjenbruk av et gunstig resultat fra andre kalldata eller en annen mottaker ville teste feil instruks. Det nyttige grunnlaget er en kobling mellom godkjent intensjon, gjennomgått transaksjon og faktisk utførelse.
Feil kan fortsatt koste
En tilbakestilt utførelse kan la tiltenkte eiendelsoverføringer være ugjort og likevel bruke nettverksressurser. Ethereums gassdokumentasjon forklarer at utførelsesfeil kan bruke gass. Mislykkede forsøk hører derfor hjemme i handelsregnskapet selv når ingen NFT anskaffes.
Skill en forespørsel avvist før en transaksjon inkluderes fra en transaksjon som utføres og tilbakestilles. De er forskjellige tilstander med potensielt forskjellige kostnader. En generell feilmerkelapp kan skjule skillet og gjøre samlede utgiftsanslag upålitelige.
I et oppdiktet eksempel legger tre mislykkede forsøk som hver koster 0,004 ETH, 0,012 ETH til strategiens utgifter. Hvis en senere vellykket handel tjener 0,010 etter egne kostnader, er sekvensen fortsatt ned 0,002 når de tidligere forsøkene tilhører samme vurderte virksomhet.
Et nytt forsøk bør begynne med dokumentasjon om det opprinnelige. Et tidsavbrudd fra en tjeneste beviser ikke at nettverket aldri mottok transaksjonen. Bevar transaksjonsidentifikatoren og undersøk status før en ny økonomisk handling bygges.
Veiledningen til en OpenSea Stream API-bot forklarer samspillet mellom hendelseslevering og rekonstruksjon av kontotilstand. En strømmelding kan være nyttig dokumentasjon, men programmet bør fortsatt avstemme faktiske transaksjons- og eierskapsvirkninger før regnskapet ferdigstilles.
Bekreftelse og endelighet er forskjellige dokumentasjonsnivåer
En transaksjonshash identifiserer et forsøk. Inkludering i en blokk dokumenterer at transaksjonen ble behandlet i blokken. Utførelsesresultatet og utsendte virkninger viser deretter hva som faktisk skjedde. Ytterligere bekreftelse eller endelighet endrer sikkerheten for at observert kjedehistorikk vil bestå.
Passende bekreftelsesregler avhenger av nettverk og aktivitet. Unngå et universelt antall sekunder eller blokker for hver NFT-arbeidsflyt. En visning som oppdateres raskt, definerer ikke i seg selv programmets endelighetsstandard.
Ethereums transaksjonsdokumentasjon beskriver livssyklusen fra signert transaksjon gjennom nettverksbehandling. Et kontoverktøy bør synliggjøre relevant trinn fremfor å bruke én suksessmerkelapp for hvert punkt i livssyklusen.
En etterfølgende handling bør oppgi hvilken dokumentasjon den krever. Et undersøkelsesvarsel kan med rimelighet vises før en overføring er endelig, forutsatt at det merkes. En økonomisk rapport som hevder oppgjort eierskap, trenger et sterkere og uttrykkelig definert grunnlag.
Hold rettelser mulige i lokale registreringer. Hvis en tidligere observert virkning ikke lenger inngår i akseptert kjedehistorikk, bør programmet ikke i det stille beholde den som et ubestridt salg. Tilstandsrekonstruksjon krever mer enn å samle hendelsesmeldinger én gang.
Solana trenger sin egen programmodell
EVM-eksemplene ovenfor beskriver ikke hvert OpenSea-støttet nettverk. Solana bruker en annen konto- og programmodell, og NFT-representasjoner kan variere innen økosystemet. En integrasjon må kontrollere faktisk eiendelsstandard og støttet rute.
En Solana-mintidentifikator, tokenkonto og eier har forskjellige roller. Komprimerte NFT-er krever ytterligere representasjonshensyn fremfor å tvinges inn i en enkel EVM-modell med kontrakt og token-ID. Et kjent markedskort visker ikke ut skillene.
Gjeldende OpenSea-støtte skiller også synlige Solana-oppføringer fra dem som kan kjøpes gjennom støttede ruter. En transaksjonsbygger bør validere kvalifikasjon fremfor å behandle hver vist salgspris som gjennomførbar. Dette er et spørsmål om produktstøtte i tillegg til kjedetilstand.
Veiledningen til å tjene penger på handel med Solana-NFT-er kobler skillene til kostnader og videresalgsantakelser. Felles økonomiske prinsipper gjelder fortsatt, men tillatelser, finansiering og transaksjonsvalidering bør følge relevant nettverk.
Rapportering på tvers av nettverk kan bruke et felles regnskapsformat og samtidig beholde nettverksspesifikk dokumentasjon. Fellesfelt forklarer det økonomiske resultatet; kjedespesifikke felt forklarer hvorfor registreringen er troverdig. Å fjerne de sistnevnte for visuell enkelhet svekker kontohistorikken.
Gjennomgå det fullførte byttet som et sett virkninger
Etter en handel identifiserer du nøyaktig mottatt eller levert eiendel, betalingstokenbeløp, mottakere, nettverkskostnad og gjenværende tillatelser eller aktive ordrer. Sammenlign virkningene med godkjent intensjon. En transaksjonskvittering uten sammenligningen kan være teknisk detaljert, men økonomisk lite opplysende.
For det hypotetiske kjøpet på 1,20 ETH bør registreringen forklare betalingskomponentene 1,128, 0,024 og 0,048 og den separate nettverkskostnaden på 0,007. Den bør ikke telle både bruttototalen og de samme mottakeroverføringene som separate utgifter.
For en eiendel med mengde bekrefter du gjenværende saldo. For en operasjon med flere objekter registrerer du hver faktisk overføring. For en mislykket handling bevarer du kostnaden og uavklart myndighet som gjenstår selv om den ønskede NFT-en ikke kom.
OpenSea-handelsopplæringen plasserer bekreftelsen i en full brukerarbeidsflyt. Forståelse av smartkontraktgrenser gjør hvert trinn mer bevisst: tillatelse, signerte vilkår, forsøkt utførelse og endelige kontovirkninger er relaterte, men hver trenger egen dokumentasjon.
En nyttig forståelse av NFT-handel med smartkontrakter ender med evnen til å forklare dokumentasjonskjeden i vanlig språk. Koden kan håndheve vilkårene den mottar. Brukeren må fortsatt vite at det er de tiltenkte vilkårene, og at fullført økonomisk resultat samsvarer med dem.