Strona mintu napisała, że sukces. W eksploratorze widnieje zielony znacznik obok opłaty, którą zapłaciłeś. A galeria portfela jest pusta. Trzy systemy odpowiadają tu na trzy różne pytania i tylko jeden z nich to łańcuch. Zanim uznasz, że coś poszło źle, rozdziel pytanie o to, czy token istnieje, od pytania o to, czy aplikacja chce go narysować.
Co poświadcza udana transakcja mintu
Potwierdzona transakcja mówi ci, że twoje wywołanie trafiło do bloku i że najbardziej zewnętrzna część wykonania nie cofnęła się. To wszystko. Udany stan potwierdzenia to stwierdzenie o wywołaniu, a nie spis tego, co wywołanie wytworzyło.
Mint to funkcja kontraktu jak każda inna. Może dobiec do końca bez cofnięcia i mimo to nie stworzyć ci niczego: pętla wsadowa pominęła twój wpis, kontrakt celowo pochłonął wywołanie wewnętrzne, funkcja przyjmująca płatność wzięła opłatę i zapisała token na inny adres. Potwierdzenie nie odróżnia tych przypadków od zwykłego mintu, bo nigdy go o to nie proszono.
Pytanie nie brzmi więc, czy transakcja zadziałała. Brzmi ono, czy istnieje teraz token, przy którym zapisany jest twój adres. Ten fakt zapisany jest gdzie indziej, i to zapisany dwukrotnie: raz jako zdarzenie w chwili utworzenia i raz jako wartość, którą kontrakt poda na żądanie.
Zdarzenie, które mówi, że token powstał
W standardzie tokena ERC-721 mint nie jest osobną operacją. Jest transferem bez nadawcy. Standard definiuje jedno zdarzenie Transfer, które powstaje, gdy własność dowolnego NFT zmienia się dowolnym mechanizmem, i stwierdza, że to zdarzenie powstaje przy tworzeniu tokenów oraz przy ich niszczeniu: w pierwszym przypadku pole nadawcy jest ustawione na zero, w drugim na zero ustawione jest pole odbiorcy.
To daje ci dokładnie określoną rzecz do znalezienia. Zdarzenie transferu na transakcji mintu, z adresu zerowego, na twój adres, niosące identyfikator tokena, to łańcuch mówiący, że token powstał i został przypisany tobie. Jego brak jest równie wymowny.
ERC-1155 trzyma się tej samej konwencji we własnych zdarzeniach: przy mintowaniu tokenów argument nadawcy musi być ustawiony na adres zerowy. Kształt dowodu nie zmienia się więc między tymi dwoma standardami, choć obsługa po stronie portfeli już może się różnić.
Odczyt, który rozstrzyga, czyj to token
Zdarzenie jest zapisem pewnej chwili. Własność teraz to osobny odczyt i ERC-721 odpowiada na niego wprost. Wywołaj ownerOf z identyfikatorem tokena, a kontrakt zwróci adres, który zapisał jako właściciela. Standard dodaje, że tokeny przypisane do adresu zerowego uznaje się za nieważne i że zapytania o nie rzucają wyjątek, więc wywołanie, które kończy się błędem zamiast zwrócić adres, samo w sobie jest odpowiedzią: tokena o takim identyfikatorze nikt teraz nie ma.
Obok niego balanceOf liczy tokeny, które adres trzyma w tym jednym kontrakcie. W kolekcji 10 000 identyfikatorów ownerOf odpowiada dokładnie o ten identyfikator, który wskazałeś, a balanceOf odpowiada, ile tokenów tego kontraktu leży na twoim adresie, bez zgadywania identyfikatorów. Żaden z tych odczytów nie zależy od tego, czy dostępny jest marketplace, galeria albo grafika.
| Pytanie, które zadajesz | Gdzie zapisana jest odpowiedź |
|---|---|
| Czy transakcja trafiła do bloku | Numer bloku w potwierdzeniu |
| Czy najbardziej zewnętrzne wywołanie uniknęło cofnięcia | Stan potwierdzenia |
| Czy powstał dla mnie token | Zdarzenie transferu, którego pole nadawcy to adres zerowy |
| Do kogo należy teraz ten identyfikator | Adres, który zwraca dla niego ownerOf |
| Ile tokenów z kolekcji trzymam | Liczba, którą zwraca balanceOf dla mojego adresu |
| Czy mój portfel go narysuje | W łańcuchu nic tego nie zapisuje |
Ostatni wiersz jest tym, który rozstrzyga całą tę sytuację. W łańcuchu nie ma pola mówiącego, czy aplikacja pokazuje twój token, i właśnie dlatego pusta galeria sama z siebie nigdy nie jest dowodem w sprawie własności.
Dlaczego token może być twój, a portfel nic nie pokazuje
Galeria portfela nie jest odczytem łańcucha na żywo. W żadnym z dwóch standardów nie ma niczego, co pozwalałoby zapytać łańcuch o wszystkie tokeny, jakie adres trzyma we wszystkich kontraktach, więc portfele i marketplace prowadzą indeksatory: patrzą na zdarzenia transferu, zapisują to, co widzą, i podają ci ten zapis. Przewijasz ich tabelę, nie kontrakt.
Cztery rzeczy w tej tabeli mogą zostawić ją pustą, gdy kontrakt mówi co innego. Indeksator mógł jeszcze nie przetworzyć twojego bloku i wtedy galeria wypełni się sama. Kolekcja może być odfiltrowana jako spam albo jako niezweryfikowana, a to reguła wyświetlania, którą stosuje portfel i którą można wyłączyć. Portfel może indeksować jeden standard, a drugiego nie, i wtedy token zmintowany według ERC-1155 nie pokaże niczego w widoku zbudowanym wyłącznie pod ERC-721. A portfel, który wymaga ręcznego dodania kolekcji, nie pokaże dla niej nic, dopóki tego nie zrobisz.
Żadnej z tych rzeczy nie naprawia ponowne wysyłanie czegokolwiek do łańcucha. Wysłanie drugiej transakcji dlatego, że galeria wygląda na pustą, grozi ponownym zmintowaniem i ponownym zapłaceniem za token, który już masz.
Kiedy token trafił gdzie indziej
Druga rodzina przyczyn jest taka, że mint zadziałał dokładnie tak, jak został napisany, a token nie leży na adresie, na który patrzysz.
Odbiorcę mintu rozstrzyga kontrakt, a nie interfejs. Funkcja, która mintuje wywołującemu, zapisuje token na ten adres, który podpisał transakcję, czyli na konto podłączone w tamtej chwili, a nie na wybrane teraz w portfelu. Portfel wyprowadzony z jednej frazy seed trzyma więcej niż jeden adres, a ten, który oglądasz, może nie być tym, który mintował.
Konta smart kontraktów dokładają drugą wersję tego samego rozminięcia. ERC-721 wymaga, by bezpieczny transfer sprawdził, czy odbiorca jest smart kontraktem, a jeśli jest, wywołał na nim hak odbiorcy i rzucił wyjątek, gdy oczekiwana wartość zwrotna nie przychodzi. Konto kontraktowe, które ten hak implementuje, przyjmuje token normalnie, a token mieszka od tej pory na adresie kontraktu. Każdy widok wycelowany w klucz podpisujący, a nie w samo konto, nie pokaże niczego, podczas gdy token leży bezpiecznie tam, dokąd go wysłano.
Dalej jest sieć. Ten sam adres istnieje w każdym łańcuchu, który używa tego samego formatu adresu, więc portfel ustawiony na jedną sieć rysuje pustą galerię dla tokena zmintowanego w innej. Token nie zginął. To widok jest odfiltrowany do łańcucha, w którym tokena nigdy nie było.
Kiedy token jest, a brakuje tylko obrazka
Osobnym objawem jest kafelek, który jest, ale pusty, szary albo podpisany nazwą zastępczą. Tu własność w ogóle nie jest pod znakiem zapytania: portfel narysował token, a to znaczy, że zindeksował zdarzenie transferu i identyfikator.
Za kafelkiem stoi dokument metadanych, a nie token, i narzędziem do tego jest odświeżenie metadanych, które każe platformie przeczytać wskaźnik i dokument jeszcze raz. Odświeżenie niczego nie rusza w łańcuchu i nie tworzy własności, więc jest właściwym narzędziem na nieaktualny obrazek i niewłaściwym na token, który w ogóle się nie pojawia. Rozdzielenie tych dwóch spraw przed działaniem oszczędza godziny, które idą na odświeżanie tokena, którego portfel i tak nie zamierzał narysować.
| Co widzisz | Co jest pod spodem prawdą | Co to zmienia |
|---|---|---|
| Pusta galeria, zdarzenie transferu na twój adres istnieje | Indeksator jest w tyle albo filtruje kolekcję | Czekanie, ustawienie portfela albo ręczne dodanie kontraktu |
| Pusta galeria, na transakcji nie ma zdarzenia transferu | Dla twojego adresu nic nie powstało | Przeczytać kontrakt przed czymkolwiek w łańcuchu |
| Token widoczny z obrazkiem zastępczym albo bez grafiki | Zapisana kopia metadanych jest starsza niż bieżąca | Odświeżenie metadanych |
| Token widoczny w eksploratorze, nieobecny w portfelu | Portfel nie indeksuje tego standardu albo tej kolekcji | Ustawienie portfela albo inna przeglądarka |
| ownerOf zwraca adres, który nie jest twój | Token zmintowano albo wysłano na inne konto | Popatrzeć na tamten adres |
Co sprawdzić i w jakiej kolejności
Otwórz transakcję w eksploratorze bloków i czytaj jej logi, a nie nagłówek. Zdarzenie transferu z adresu zerowego, z identyfikatorem tokena, mówi ci, że token powstał. Adres w polu odbiorcy mówi, czyj on jest. Jeśli ta sekcja jest pusta, reszta poszukiwań dotyczy kontraktu, a nie twojego portfela.
Potem wywołaj ownerOf na kontrakcie z tym identyfikatorem tokena. Eksploratory udostępniają odczyty kontraktu bez podpisu i bez opłaty, więc nic to nie kosztuje i zwraca własną odpowiedź łańcucha, a nie kopię indeksatora. Jeśli adres, który wraca, jest jednym z twoich, token jest twój, a wszystko, co zostało, to kwestia wyświetlania.
Potem sprawdź to, na co patrzysz: adres wybrany w portfelu, sieć, na którą jest ustawiony, i to, czy kolekcja nie jest ukryta. Te trzy ustawienia tłumaczą lukę między kontraktem, który wskazuje ciebie jako właściciela, a galerią, która nic nie pokazuje.
Podsumowanie
Mint, który się potwierdził, dowodzi, że wywołanie się nie cofnęło. Nie dowodzi, że token istnieje, i nie wskazuje właściciela. Te dwa fakty żyją w zdarzeniu transferu na transakcji i w tym, co po niej zwraca ownerOf, a oba da się odczytać bez współpracy jakiejkolwiek aplikacji.
Pusta galeria to stwierdzenie o indeksatorze. Przeczytaj zdarzenie, przeczytaj ownerOf, potem sprawdź adres, sieć i filtr kolekcji. Jeśli kontrakt wskazuje ciebie jako właściciela, niczego nie trzeba ponownie wysyłać, podpisywać ani opłacać. Aby dalej poznawać podstawy, śledź kolejne materiały Bitbase Academy.
Powiązane artykuły
Inne artykuły Bitbase na ten temat:
- Ułamkowa własność tokena niewymiennego i gdzie leży ryzyko
- Proces ujawnienia NFT: co się zmienia i kiedy
- Opcjonalne tantiemy NFT wyjaśnione
- The DATA Foundation, dawniej Story Protocol: migracja tokena IP do DATA
- Portfele omnibusowe i wydzielone oraz ryzyko rehypotekacji
Zastrzeżenie: ten artykuł to treść edukacyjna Bitbase Academy, wyłącznie w celach informacyjnych. Nie stanowi porady inwestycyjnej, handlowej, podatkowej ani finansowej. Kryptoaktywa są zmienne — samodzielnie oceń ryzyko. Napisano w wrześniu 2026 r.; sprawdzaj aktualne oficjalne informacje.
Źródła
[1] Ethereum Improvement Proposals, EIP-721: Non-Fungible Token Standard, sekcja specyfikacji eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-1155: Multi Token Standard, sekcja specyfikacji eips.ethereum.org
