Сторінка маркетплейсу показує вам ім'я, зображення, колекцію, а іноді й попередження про те, що предмет заявлено як викрадений. Жодне з цих чотирьох тверджень блокчейн не записує. Ланцюг записує, який контракт тримає який token ID і кому він належить просто зараз; усе інше на сторінці — це твердження маркетплейсу або того, хто цей предмет викарбував. Безпечно читати лістинг означає розділяти ці дві речі.
Чим насправді є лістинг на маркетплейсі
Лістинг — це пропозиція продати на заявлених умовах, і в конструкції з підписаними ордерами він є повідомленням, а не транзакцією. Продавець залишає предмет у себе, підписує умови своїм гаманцем, а маркетплейс зберігає цей підпис. Токен рухається лише тоді, коли покупець надсилає транзакцію, яка виконує пропозицію. EIP-712, стандарт Ethereum для хешування та підпису типізованих структурованих даних, було написано саме під цей шаблон: його заявлена мета — покращити зручність підпису повідомлень поза ланцюгом для використання в ланцюзі, бо так економиться газ і зменшується кількість транзакцій у блокчейні.
З того, що пропозиція живе поза ланцюгом, випливають два висновки. Маркетплейс може показати лістинг, сховати його або відмовитися його віддавати, і жодна з цих дій не торкається самого токена. А оскільки виконання мусить вивести предмет із гаманця продавця, продавець мав заздалегідь надати контракту маркетплейсу дозвіл, тобто звичайне схвалення токенів, яке ERC-721 описує як надання оператору змоги керувати всіма активами того, хто викликає.
Чому переконлива підробка коштує майже нічого
Карбування відкрите. Будь-хто може розгорнути контракт, що дотримується того самого стандарту токенів, що й наявна колекція, дати йому те саме ім'я та той самий символ, спрямувати кожен предмет на ті самі зображення й викарбувати 10 000 штук. Стандарт цьому не заважає, бо він задає, як токен передається і кому належить, і нічого не каже про те, що токену дозволено зображати.
Саме тут унікальність NFT доводиться формулювати точно. Токен унікальний: ERC-721 ідентифікує кожен NFT унікальним ідентифікатором uint256 усередині його власного контракту, і цей запис не можна ані продублювати, ані поділити. Зображення, на яке запис вказує, такого захисту не має. Унікальність — властивість запису в реєстрі, а не твору.
Дешевою копію роблять метадані. У розширенні метаданих функція tokenURI повертає окремий уніфікований ідентифікатор ресурсу для заданого активу, і стандарт зазначає, що цей ідентифікатор може вказувати на файл JSON, який відповідає ERC721 Metadata JSON Schema. Ідентифікатор — це вказівник. Два різні контракти можуть вказувати на той самий файл, а той, хто контролює місце призначення, може згодом змінити те, що там лежить.
Єдиний ідентифікатор, який не можна скопіювати
Адреса контракту — та частина, яку копія забрати не може. ERC-721 стверджує, що пара з адреси контракту та token ID є глобально унікальним і повністю визначеним ідентифікатором конкретного активу в мережі Ethereum. Дві колекції можуть ділити ім'я, символ і кожне зображення; ділити адресу вони не можуть.
Тому перевірка, яка вирішує питання підробленого лістингу, не є візуальною. Візьміть адресу контракту з лістингу й порівняйте її символ за символом з адресою, яку проєкт публікує на каналі, до якого ви дійшли самостійно. Якщо вони різні, предмет перед вами належить до іншої колекції, хоч би що було написано вище на сторінці.
Визначення інтерфейсів цього розриву не закриває. ERC-165 створює стандартний метод публікувати й визначати, які інтерфейси реалізує смартконтракт, а той, хто викликає, може викликати supportsInterface, щоб з'ясувати, чи реалізує контракт інтерфейс, яким він може скористатися. Це каже вам, що контракт поводиться як контракт NFT. Це не каже вам, що контракт саме той, який ви мали на увазі.
Чим є значок верифікації і чим він не є
Значок — це засвідчення з боку маркетплейсу. Він повідомляє, що обліковий запис або колекція пройшли ту перевірку, яку цей маркетплейс проводить, а отже, є твердженням про власні записи маркетплейсу: виданий цим майданчиком, чинний на цьому майданчику і знімається цим майданчиком.
Значок тому не подорожує. Той самий контракт може нести значок на одному майданчику й не мати його на іншому, і токен в обох випадках однаковий, бо нічого зі значка не записано в ланцюг. Читайте його як один із кількох вхідних сигналів, а вирішальним лишайте порівняння адрес.
Значки до того ж приваблюють окремий різновид видавання себе за інших. Знімок екрана зі значком, назва колекції з одним заміненим символом або профіль, скопійований зі справжнього облікового запису, коштують дешевше за отримання справжнього значка й спрацьовують на кожному, хто припиняє читати на значку.
Чим є позначка про крадіжку і що вона зупиняє
Позначка — це нотатка у власній базі даних маркетплейсу, додана після того, як хтось повідомив, що предмет у нього забрали. Це повідомлення є твердженням людини, і позначка фіксує, що твердження отримано й прийнято до розгляду, а не що якийсь суд щось вирішив.
У ланцюзі еквівалентного поля немає. Інтерфейс, який визначає ERC-721, охоплює баланси, володіння, перекази та схвалення, і на цьому спиняється: функція ownerOf відповідає, хто тримає токен, і жодна функція не відповідає, як він до нього потрапив. Блокування в цьому інтерфейсі теж немає. Специфікація каже, що реалізація може викидати виняток і в інших ситуаціях, і наводить заборону певній адресі отримувати NFT як один із таких необов'язкових варіантів, а це вміщує рішення всередину конкретного контракту, а не в стандарт, спільний для всіх колекцій.
Цей розрив вирішує, що позначка може зробити. На власних поверхнях маркетплейс може сховати предмет, вимкнути купівлю й продаж і попередити кожного, хто відкрив сторінку. Поза цими поверхнями важеля в нього немає: власник і далі може викликати transferFrom, інший майданчик веде окремі записи й може показувати той самий предмет як звичайний, а позначка не повертає предмет тому, хто його втратив. Якщо переказ колись і буде заблоковано на рівні контракту, спрацює власний код колекції, а не позначка маркетплейсу.
Звідси випливають дві ситуації. Якщо ви тримаєте позначений предмет, ваш шлях іде через апеляційну процедуру самого маркетплейсу, бо позначка живе в маркетплейсі. Якщо ви збираєтеся такий предмет купити, зрозумійте, чим володітимете: предметом, який ланцюг вважає вашим і який майданчик, де ви його купили, не дасть вам перепродати.
| Питання про предмет | Де зберігається відповідь | Чи їде разом із токеном |
|---|---|---|
| Кому він належить просто зараз | У контракті, через ownerOf | Так |
| Який це контракт і який token ID | У самому ланцюзі | Так |
| Чи є колекція офіційною | У власних записах маркетплейсу | Ні |
| Чи заявлено його як викрадений | У власних записах маркетплейсу | Ні |
| Чи дозволено вам ним тут торгувати | У власних правилах маркетплейсу | Ні |
Лістинг, який насправді є запитом на підпис
Деякі підроблені лістинги нічого не продають. Сторінка існує, щоб поставити перед вами запит на підпис, і запит просить схвалення на всю вашу колекцію, а не покупку. Підпишіть його, і контрагент зможе вивести кожен предмет, який це схвалення охоплює, і це механізм, що стоїть за drainer гаманців.
Історія стандарту підпису пояснює, чому це важко впіймати оком. EIP-712 було написано тому, що підписувані повідомлення до того були непрозорим шістнадцятковим рядком, показаним користувачеві майже без контексту про елементи, з яких повідомлення складається. Структурований підпис це покращив, а водночас дав шахрайству легітимну на вигляд оболонку, тож захистом є читання розшифрованого вмісту, а не довіра до форми запиту.
Дві звички це скорочують. Заходьте на маркетплейс за адресою, яку зберегли самі, а не за посиланням, що надійшло; і читайте, що саме запит дозволяє: покупка коштує грошей і рухає один токен, тоді як схвалення в момент підпису не коштує нічого й видає постійний дозвіл на багато.
Що перевірити перед покупкою
| Що перевірити | З чим порівняти | Про що каже розбіжність |
|---|---|---|
| Адреса контракту | З адресою, яку публікує сам проєкт | Це інша колекція, хоч би що казала назва |
| Token ID | З предметом, який ви збираєтеся купити | Лістинг вказує на інший предмет |
| Метадані та зображення | З файлами, які публікує колекція | Зображення позичене, а не своє |
| Запит на підпис | З дією, яку ви задумали | Ви видаєте доступ, а не купуєте |
| Торговий статус на майданчику | З тим, чи додано до предмета повідомлення | Перепродаж на цьому майданчику може бути закритий |
Порядок тут важливий. Порівняння адрес іде першим, бо це єдиний рядок, що спирається на ланцюг, тоді як кожен інший рядок — запис, який хтось веде. Пройдіть його перш ніж дивитися на ціну, на рідкісність або на те, скільки часу, за словами сторінки, лишилося.
Підсумок
Сторінка маркетплейсу змішує два види тверджень. Ланцюг вносить невеликий перевірюваний набір: який контракт, який token ID і кому він належить зараз. Решту вносить маркетплейс, зокрема назви колекцій, значки та будь-яку позначку про крадіжку, і все це його власний запис, а не властивість токена.
Підроблені лістинги живуть із першої суміші: копіюють усе, що копіюється безкоштовно, і розраховують, що адресу ви так і не перевірите. Позначки належать до другої: справжня інформація, яку тримає один майданчик, без жодної влади над ланцюгом і над іншими майданчиками. Порівнюйте адресу контракту перш за все інше, читайте, що запит просить вас підписати, і сприймайте позначку як сигнал про записи одного маркетплейсу, а не як вирок предмету. Щоб продовжити вивчати основи, читайте інші матеріали Bitbase Academy.
Схожі матеріали
Інші матеріали Bitbase на цю тему:
- Шахрайство зі ставками на NFT і підроблені токени в пропозиціях
- Маніпуляції мінімальною ціною на маркетплейсах NFT
- Безпека входу в крипті: як захистити свій акаунт
- Індикатори завантаженості мережі та що вимірює кожен із них
- Що таке біткоїн-адреса решти? Куди йде ваша решта
Застереження: Ця стаття є освітнім матеріалом Bitbase Academy і надається лише для інформації. Вона не є інвестиційною, торговою, податковою чи фінансовою порадою. Криптоактиви волатильні — оцінюйте ризики самостійно. Написано станом на вересень 2026 року; орієнтуйтеся на найновішу офіційну інформацію.
Джерела
[1] Ethereum Improvement Proposals, ERC-721: Non-Fungible Token Standard, статус Final eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-712: Typed structured data hashing and signing, статус Final eips.ethereum.org
[3] Ethereum Improvement Proposals, ERC-165: Standard Interface Detection, статус Final eips.ethereum.org
