Smart kontrakty rynku NFT obsługują oferty, propozycje, aukcje, rozliczenia, anulowanie, routing opłat, tantiemy oraz kontrole administracyjne. Choć standardy ERC-721 lub ERC-1155 opisują sam aktyw, samo stosowanie standardu tokena nie tworzy automatycznie bezpiecznego marketplace.

Twórcy powinni porównywać kontrakty marketplace z zachowaniem opłat i zleceń w OpenSea marketplace review, warstwami operacyjnymi w NFT marketplace infrastructure guide oraz mechanizmami uruchamiania płatności w NFT passive income models, ponieważ zdarzenia kontraktu stanowią źródło danych dla rozliczeń i procesów wsparcia.

Smart kontrakty NFT — wyjaśnienie

Smart kontrakt NFT to kod wdrożony na blockchainie, który tworzy tokeny i określa, w jaki sposób własność jest zapisywana i przenoszona. Podczas mintowania kontrakt przypisuje token ID do adresu właściciela. Gdy token jest sprzedawany lub przenoszony, kontrakt aktualizuje zapis własności dopiero po sprawdzeniu uprawnień nadawcy i obowiązujących reguł transferu.

Kontrakt zazwyczaj zapisuje właściciela tokena, podaż, zatwierdzenia, historię transferów oraz odwołanie do metadanych. Niekoniecznie przechowuje sam plik graficzny. Jak wyjaśnia Hedera's explanation of NFT smart contracts, token ID i metadane identyfikują aktywo, a logika smart kontraktu obsługuje mintowanie i zmiany własności. Co ważne, smart kontrakt jest wykonywalnym kodem komputerowym — nie stanowi automatycznie umowy prawnej dotyczącej praw autorskich, zwrotów czy praw handlowych.

Kontrakty NFT a kontrakty marketplace

Kontrakt NFT i kontrakt marketplace pełnią różne role. Kontrakt NFT definiuje aktywo, tworzy token ID, rejestruje własność i egzekwuje zatwierdzenia oraz transfery. Kontrakt marketplace koordynuje sprzedaż: weryfikuje ofertę lub propozycję, pobiera płatność, przenosi NFT, przekierowuje opłaty i zamyka lub anuluje zlecenie.

To rozdzielenie jest istotne, ponieważ posiadanie ważnego NFT nie oznacza, że jest ono aktywnie wystawione, a podpisanie zlecenia marketplace nie zmienia własności aż do skutecznego rozliczenia. Kupujący powinien więc zweryfikować oba adresy: kontrakt kolekcji identyfikuje NFT, a kontrakt marketplace lub spender identyfikuje oprogramowanie, które otrzymuje uprawnienie do transferu. Dla zespołów integrujących portfele, narzędzia wsparcia lub indexery to rozróżnienie określa również, które zdarzenia są traktowane jako źródło prawdy dla dostępności przedmiotu, zwrotów i realizacji.

Jak ERC-721 i ERC-1155 wpływają na projekt marketplace

ERC-721 jest zwykle używany wtedy, gdy każde token ID reprezentuje jeden, niezależnie posiadany przedmiot. Dobrze sprawdza się w przypadku dzieł 1/1, unikalnych aktywów z gier, działek gruntowych i kolekcjonerskich przedmiotów, których własność weryfikuje się token po tokenie. ERC-1155 może reprezentować wiele kopii tego samego token ID, co jest przydatne dla consumables w grach, biletów, edycji lub przedmiotów emitowanych w określonej liczbie.

Standard tokena zmienia zawartość zlecenia. Oferty ERC-721 zwykle obejmują sprzedaż jednego token ID. Oferta ERC-1155 może obejmować 20 kopii, podczas gdy kupujący nabywa tylko trzy, więc marketplace musi zaktualizować pozostałą liczbę bez zamykania całego zlecenia. Anulowanie musi unieważnić każdą pozostałą ilość, a zdarzenie rozliczenia musi wskazywać, ile jednostek zmieniło właściciela.

Mechanizmy zatwierdzeń także wyglądają inaczej. Zatwierdzenie specyficzne dla tokena ERC-721 może autoryzować pojedyncze NFT, podczas gdy zatwierdzenie operatora może obejmować każdy token z danej kolekcji. ERC-1155 zwykle używa zatwierdzenia operatora dla całego salda portfela w ramach kontraktu. Marketplace może wymagać szerszego uprawnienia dla wygody, ale okno portfela powinno jasno pokazywać zakres, a użytkownik powinien wiedzieć, jak je cofnąć.

Konstrukcje escrow i lazy listing

Marketplace typu escrow przenosi NFT do kontraktu marketplace w momencie wystawienia przez sprzedawcę. Ułatwia to weryfikację dostępności, ale sprzedawca płaci więcej gas i traci możliwość korzystania z aktywa w czasie wystawienia. Lazy listing pozostawia NFT w portfelu sprzedawcy i zapisuje podpis off-chain zawierający token, cenę, łańcuch, termin wygaśnięcia, nonce oraz adres marketplace. Obniża to koszt wystawienia i zachowuje pieczę nad aktywem, ale kontrakt musi zweryfikować podpis, a sprzedawca nadal potrzebuje on-chainowej ścieżki unieważnienia.

W przypadku marketplace gier wybór ten wpływa nie tylko na koszty gas. Escrow może uniemożliwić wyposażenie przedmiotu w czasie wystawienia, natomiast lazy listing zachowuje aktywo gracza, ale wymaga od gry i marketplace obsługi oferty, która staje się niewykonalna po zmianie własności. Ta różnica operacyjna pokazuje też, dlaczego zespoły powinny testować przypadki brzegowe, takie jak transfery portfeli, aktualizacje kolekcji i unieważnianie ofert, jeszcze przed uruchomieniem, zamiast zakładać, że model wystawiania poradzi sobie z nimi automatycznie.

Cykl życia oferty i propozycji

Oferty o stałej cenie powinny przechodzić przez stany create, validate, buy, settle i cancel. Propozycje wymagają wygaśnięcia, nonce, chain ID, sprawdzeń spendera i anulowania. Każdy stan powinien emitować zdarzenia, które indexer może uzgodnić.

Propozycje potrzebują też modelu płatności, który kontrakt może rzeczywiście wykonać. Oferta w natywnej monecie zwykle nie może zostać później pobrana z portfela kupującego bez nowej podpisanej transakcji, podczas gdy zatwierdzony token ERC-20, taki jak WETH lub USDC, może być trzymany w escrow lub przeniesiony po akceptacji sprzedawcy. Rekord zlecenia powinien więc zawierać walutę, kwotę, termin wygaśnięcia, nonce, kupującego, sprzedawcę, token ID i status anulowania, a nie tylko nagłówkową cenę.

Rozliczanie aukcji wymaga własnej maszyny stanów. Aukcja angielska musi obsługiwać wyższe licytacje, zwroty, czas zakończenia oraz finalnego wywołującego rozliczenie; aukcja holenderska musi obliczać bieżącą cenę na podstawie czasu i odrzucać przeterminowane zakupy. Model zwrotu oparty na pull jest bezpieczniejszy niż natychmiastowe wysyłanie środków do każdego przebitego licytanta, ponieważ nieudane wywołanie zwrotu nie powinno blokować całej aukcji. Krótkie wydłużenie czasu zakończenia pomaga też ograniczyć ostatniosekundowe bid sniping.

Sprzedaż NFT za 0.5 ETH od podpisu do rozliczenia

Rozważmy NFT ERC-721 wystawione za 0.5 ETH na podstawie podpisanego zlecenia. Sprzedawca pozostawia NFT w portfelu, ale zatwierdza kontrakt marketplace do jego transferu. Podpisana oferta identyfikuje kontrakt kolekcji, token ID, sprzedawcę, cenę, termin wygaśnięcia, nonce, chain ID oraz adres marketplace. W chwili utworzenia podpisu nie dochodzi do zmiany własności.

Gdy kupujący składa zakup, kontrakt marketplace sprawdza, czy zlecenie nie wygasło ani nie zostało anulowane, czy podpis należy do sprzedawcy, czy sprzedawca nadal posiada NFT oraz czy zatwierdzenie transferu pozostaje ważne. Następnie oznacza zlecenie jako zrealizowane, przetwarza płatność, przekierowuje NFT do kupującego i emituje zdarzenia, których marketplace może użyć do aktualizacji strony przedmiotu.

Poniższy podział jest ilustracyjny, a nie stanowi opisu rzeczywistych opłat jakiegokolwiek marketplace.

Jeśli transfer NFT się nie powiedzie, płatność nie powinna pozostać zakończona przy niezmienionej własności. Jeśli odbiorca płatności nie może przyjąć ETH, najbezpieczniejsza reakcja zależy od projektu kontraktu: transakcja może zostać odrzucona albo kwota może zostać zaksięgowana jako saldo do wypłaty. Dlatego routing płatności, kolejność transferu, aktualizacje stanu i ochrona przed reentrancją muszą być testowane razem, a nie jako osobne pola kontrolne.

Tantiemy i routing opłat

Informacje o tantiemach mogą opierać się na EIP-2981, a biblioteki kontraktowe, takie jak OpenZeppelin ERC-721 i OpenZeppelin ERC-1155, pomagają implementować standardowe zachowanie aktywów. Egzekwowanie po stronie marketplace nadal wymaga jednak świadomej polityki produktu.

EIP-2981 sprawia, że informacje o tantiemach są odczytywalne, ale nie uniwersalnie egzekwowalne. Marketplace może zapytać o adres twórcy i wysokość tantiem, ale inna platforma może wybrać inną politykę albo całkowicie zignorować wynik. Jeśli przychód twórcy jest kluczowy, twórcy powinni testować rzeczywistą ścieżkę transferu, wybrany marketplace, zachowanie agregatora i logikę egzekwowania kolekcji, zamiast traktować pole tantiem jako gwarantowaną płatność.

Testy bezpieczeństwa

Testy krytyczne obejmują reentrancję, replay, wygasłe zlecenia, podpisy z niewłaściwego łańcucha, kompromitację klucza administracyjnego, zachowanie pauzy oraz częściowe realizacje. Celem nie jest długi audytowy checklist, lecz udowodnienie, że marketplace domyślnie odrzuca niebezpieczne zlecenie.

Najbardziej wartościowe testy powinny odzwierciedlać awarie, których kupujący lub sprzedawca rzeczywiście mogą doświadczyć. Zakup powinien odrzucać zmianę ceny zamiast wykonywać bait-and-switch; podpisane zlecenie powinno być powiązane z chain ID i adresem marketplace; a anulowany lub zużyty nonce nie powinien wykonać się ponownie. W kodzie rozliczającym należy aktualizować stan zlecenia przed wywołaniami zewnętrznymi i stosować reentrancy guard wokół ścieżek płatności i transferu.

Użytkownik Polygon oceniający Rarible zgłosił, że doświadczenie sieciowe nie obejmowało wsparcia dla własnych kontraktów i freeze metadanych w ramach network-specific contract review, zebranej 11 sierpnia 2026. Nie jest to dowód, że kontrakt marketplace jest niebezpieczny, a wyniki mogą zależeć od sieci i wersji produktu. Nadal jest to jednak użyteczna granica implementacyjna: przetestuj zakres obsługi kontraktów, niezmienność metadanych i zachowanie aktualizacji na dokładnym łańcuchu wybranym do wdrożenia.

Wnioski

Kontrakt marketplace należy oceniać przez pryzmat cyklu życia zlecenia i zachowania w sytuacjach awaryjnych. Jeśli artykuł pomaga twórcy testować wygasłe zlecenia, podpisy z niewłaściwego łańcucha, routing tantiem i indeksowanie zdarzeń, zrobił więcej niż tylko powtórzył standardy tokenów. Następnym krokiem inżynieryjnym jest test cyklu życia zlecenia. Bezpieczna ścieżka kontraktu obsługuje tworzenie, wygaśnięcie, anulowanie, rozliczenie, tantiemy, indeksowanie i zachowanie pauzy bez polegania na założeniach.

Najczęściej zadawane pytania

Jakie informacje są przechowywane w smart kontrakcie NFT?

Kontrakt zwykle zapisuje token ID, własność, salda, zatwierdzenia, reguły transferu, podaż oraz URI metadanych. Obraz lub wideo często są przechowywane oddzielnie i odnoszone przez metadane.

Czy kontrakt NFT obsługuje również oferty marketplace?

Niekoniecznie. Kontrakt NFT zarządza tokenem, a oddzielny kontrakt marketplace zwykle zarządza ofertami, propozycjami, aukcjami, płatnościami, opłatami i rozliczeniem.

Czy marketplace może przenieść NFT bez uprawnień?

Wymaga do tego uprawnienia wynikającego z własności, zatwierdzenia specyficznego dla tokena lub zatwierdzenia operatora rozpoznawanego przez kontrakt NFT. Kupujący i sprzedawcy powinni sprawdzić zatwierdzonego spendera przed podpisaniem.

Czy pole tantiem NFT gwarantuje płatność?

Nie. Standard tantiem może przekazać informacje o odbiorcy i kwocie, ale rzeczywista płatność zależy od polityki marketplace i ścieżki rozliczenia.

Zastrzeżenie: Ten artykuł służy wyłącznie do celów badawczych i redakcyjnych. Nie stanowi porady finansowej, inwestycyjnej, prawnej ani podatkowej. Narzędzia NFT, marketplace, opłaty, wsparcie łańcuchów i bieżąca dostępność mogą szybko się zmieniać, dlatego przed podjęciem jakiejkolwiek decyzji dotyczącej środków, aktywów lub kluczy prywatnych należy zweryfikować aktualne warunki na oficjalnej platformie.