Сторінка мінту написала «успіх». В оглядачі стоїть зелена галочка поруч із комісією, яку ви заплатили. А галерея гаманця порожня. Тут три системи відповідають на три різні запитання, і лише одна з них — ланцюг. Перш ніж вирішувати, що щось пішло не так, розділіть запитання про те, чи існує токен, і запитання про те, чи готовий застосунок його намалювати.
Що засвідчує успішна транзакція мінту
Підтверджена транзакція повідомляє, що ваш виклик потрапив у блок і що найзовнішня частина виконання не відкотилася. І це все. Успішний статус квитанції — це твердження про виклик, а не опис того, що виклик виробив.
Мінт — така сама функція контракту, як будь-яка інша. Вона може завершитися без відкату і при цьому не створити вам нічого: пакетний цикл пропустив ваш запис, контракт навмисно поглинув внутрішній виклик, оплачувана функція взяла комісію і записала токен на іншу адресу. Квитанція не відділяє ці випадки від звичайного мінту, бо її про це ніколи не просили.
Отже, питання не в тому, чи спрацювала транзакція. Питання в тому, чи існує тепер токен, за яким записана ваша адреса. Цей факт записаний в іншому місці, причому записаний двічі: один раз як подія в мить створення і один раз як значення, яким контракт відповість на запит.
Подія, яка каже, що токен створено
У стандарті токенів ERC-721 мінт не є окремою операцією. Це переказ без відправника. Стандарт визначає єдину подію Transfer, яка виникає, коли власність на будь-який NFT змінюється будь-яким механізмом, і зазначає, що ця подія виникає при створенні токенів і при їх знищенні: у першому випадку поле відправника дорівнює нулю, у другому нулю дорівнює поле отримувача.
Це дає вам точний предмет пошуку. Подія переказу на транзакції мінту, з нульової адреси, на вашу адресу, що несе ідентифікатор токена, — це ланцюг каже, що токен створено і закріплено за вами. Її відсутність так само промовиста.
ERC-1155 дотримується тієї самої домовленості у власних подіях: під час карбування токенів аргумент відправника має бути виставлений у нульову адресу. Тож форма доказу між двома стандартами не змінюється, навіть якщо підтримка з боку гаманців цілком може відрізнятися.
Читання, яке вирішує, чий це токен
Подія — це запис миті. Власність зараз — окреме читання, і ERC-721 відповідає на нього напряму. Викличте ownerOf з ідентифікатором токена, і контракт поверне адресу, яку він записав як власника. Стандарт додає, що токени, закріплені за нульовою адресою, вважаються недійсними і що запити про них викидають помилку, — тож виклик, який падає замість повернути адресу, сам по собі є відповіддю: токена з таким ідентифікатором зараз немає ні в кого.
Поруч із ним balanceOf рахує токени, які адреса тримає в цьому одному контракті. У колекції з 10 000 ідентифікаторів ownerOf відповідає рівно про той ідентифікатор, який ви назвали, а balanceOf відповідає, скільки токенів цього контракту лежить на вашій адресі, і вам не треба вгадувати ідентифікатори. Жодне з цих читань не залежить від того, чи доступні маркетплейс, галерея або зображення.
| Запитання, яке ви ставите | Де записана відповідь |
|---|---|
| Чи потрапила транзакція в блок | Номер блока у квитанції |
| Чи обійшовся найзовнішній виклик без відкату | Статус квитанції |
| Чи створено токен для мене | Подія переказу, у якої поле відправника — нульова адреса |
| Кому належить цей ідентифікатор зараз | Адреса, яку повертає для нього ownerOf |
| Скільки токенів колекції я тримаю | Число, яке повертає balanceOf для моєї адреси |
| Чи намалює його мій гаманець | У ланцюзі це не записано ніде |
Останній рядок і розв'язує всю цю ситуацію. У ланцюзі немає поля про те, чи показує застосунок ваш токен, і саме тому порожня галерея сама по собі ніколи не є свідченням про власність.
Чому токен може бути вашим, а гаманець не показує нічого
Галерея гаманця — не живе читання ланцюга. У жодному з двох стандартів немає нічого, що дозволяло б запитати в ланцюга всі токени, які адреса тримає в усіх контрактах, тож гаманці та маркетплейси тримають індексатори: ті дивляться на події переказу, записують побачене й віддають вам цей запис. Ви гортаєте їхню таблицю, а не контракт.
Чотири обставини здатні залишити цю таблицю порожньою, поки контракт каже інше. Індексатор міг ще не обробити ваш блок — тоді галерея заповниться сама. Колекція може бути відфільтрована як спам або як неперевірена: це правило показу, яке застосовує гаманець і яке можна вимкнути. Гаманець може індексувати один стандарт і не індексувати інший, і тоді токен, викарбуваний за ERC-1155, нічого не покаже у поданні, побудованому лише під ERC-721. А гаманець, який вимагає додавати колекцію вручну, не покаже за нею нічого, доки цього не зроблено.
Ніщо з цього не лагодиться повторним надсиланням чогось у ланцюг. Надіслати другу транзакцію через те, що галерея виглядає порожньою, — це ризик викарбувати заново і заплатити заново за токен, яким ви вже володієте.
Коли токен пішов в інше місце
Інша родина причин: мінт спрацював рівно так, як написаний, і токен перебуває не на тій адресі, на яку ви дивитеся.
Отримувача мінту вирішує контракт, а не інтерфейс. Функція, яка карбує тому, хто викликає, записує токен на ту адресу, що підписала транзакцію, тобто на акаунт, під'єднаний у той момент, а не на вибраний у гаманці зараз. Гаманець, виведений з однієї сид-фрази, тримає більше ніж одну адресу, і та, на яку ви дивитеся, може бути не тією, що карбувала.
Акаунти смартконтрактів додають другий варіант того самого розходження. ERC-721 вимагає, щоб безпечний переказ перевірив, чи є отримувач смартконтрактом, і, якщо є, викликав на ньому хук отримувача та викинув помилку, коли очікуване повернене значення не приходить. Контрактний акаунт, який цей хук реалізує, приймає токен звичайним чином, і токен після цього живе на адресі контракту. Будь-яке подання, наведене на підписувальний ключ, а не на сам акаунт, не покаже нічого, поки токен спокійно лежить там, куди його відправили.
Далі йде мережа. Та сама адреса існує в кожному ланцюзі, який використовує той самий формат адреси, тож гаманець, перемкнутий на одну мережу, малює порожню галерею для токена, викарбуваного в іншій. Токен не зник. Це подання відфільтроване на ланцюг, у якому токена ніколи не було.
Коли токен на місці й бракує лише картинки
Окремий симптом — плитка, яка є, але порожня, сіра або підписана іменем-заглушкою. Тут власність узагалі не під питанням: гаманець намалював токен, а отже, він проіндексував подію переказу та ідентифікатор.
За плиткою стоїть документ метаданих, а не токен, і інструмент для цього — оновлення метаданих, яке велить платформі перечитати вказівник і документ. Оновлення нічого не рухає в ланцюзі й не створює власності, тож воно правильний інструмент для застарілої картинки і неправильний — для токена, який узагалі не з'являється. Розвести ці два випадки до того, як щось робити, заощаджує ті години, що йдуть на оновлення токена, якого гаманець і не збирався малювати.
| Що ви бачите | Що при цьому насправді | Що це змінює |
|---|---|---|
| Галерея порожня, подія переказу на вашу адресу є | Індексатор відстав або фільтрує колекцію | Очікування, налаштування гаманця або додавання контракту вручну |
| Галерея порожня, події переказу на транзакції немає | Для вашої адреси нічого не створено | Прочитати контракт до будь-яких дій у ланцюзі |
| Токен видно, картинка-заглушка або її немає | Збережена копія метаданих відстала від поточної | Оновлення метаданих |
| Токен видно в оглядачі, у гаманці його немає | Гаманець не індексує цей стандарт або цю колекцію | Налаштування гаманця або інший переглядач |
| ownerOf повертає адресу, яка не ваша | Токен викарбувано або надіслано на інший акаунт | Дивитися на ту адресу |
Що перевіряти і в якому порядку
Відкрийте транзакцію в оглядачі блоків і читайте її логи, а не заголовок. Подія переказу з нульової адреси, з ідентифікатором токена, каже вам, що токен створено. Адреса в полі отримувача каже, чий він. Якщо цей розділ порожній, увесь подальший пошук — про контракт, а не про ваш гаманець.
Далі викличте ownerOf на контракті з цим ідентифікатором токена. Оглядачі дають читати контракт без підпису і без комісії, тож це нічого не коштує і повертає власну відповідь ланцюга, а не копію індексатора. Якщо адреса, що прийшла, — одна з ваших, токен ваш, і все, що лишилося, — питання відображення.
Далі перевірте те, на що ви дивитеся: вибрану в гаманці адресу, встановлену в ньому мережу і те, чи не прихована колекція. Ці три налаштування й пояснюють розрив між контрактом, який називає власником вас, і галереєю, яка не показує нічого.
Підсумок
Мінт, який підтвердився, доводить, що виклик не відкотився. Він не доводить, що токен існує, і не називає власника. Ці два факти живуть у події переказу на транзакції і в тому, що після цього повертає ownerOf, і обидва читаються без сприяння будь-якого застосунку.
Порожня галерея — це твердження про індексатор. Прочитайте подію, прочитайте ownerOf, потім перевірте адресу, мережу і фільтр колекцій. Якщо контракт називає власником вас, нічого не треба ні надсилати, ні підписувати, ні оплачувати заново. Щоб продовжити вивчати основи, читайте інші матеріали Bitbase Academy.
Схожі матеріали
Інші матеріали Bitbase на цю тему:
- Часткове володіння NFT і де криється ризик
- Процес розкриття NFT: що змінюється і коли
- Необов'язкові роялті NFT простими словами
- The DATA Foundation, раніше Story Protocol: міграція токена з IP на DATA
- Омнібус- і сегреговані гаманці та ризик повторного заставлення
Застереження: Ця стаття є освітнім матеріалом Bitbase Academy і надається лише для інформації. Вона не є інвестиційною, торговою, податковою чи фінансовою порадою. Криптоактиви волатильні — оцінюйте ризики самостійно. Написано станом на вересень 2026 року; орієнтуйтеся на найновішу офіційну інформацію.
Джерела
[1] Ethereum Improvement Proposals, EIP-721: Non-Fungible Token Standard, розділ специфікації eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-1155: Multi Token Standard, розділ специфікації eips.ethereum.org
