Как проверить подлинность коллекции

Подлинность коллекции устанавливается одним признаком: адресом контракта в конкретной сети, взятым с официального ресурса проекта. Название, символ, картинка и число предметов подлинность не доказывают, потому что всё это задаёт автор контракта произвольно и повторяет кто угодно за несколько минут работы. Метка площадки вторична. Сверяют адрес, потом смотрят остальное, и такой порядок закрывает основную часть схем с двойниками, которые копируют страницу оригинала целиком, вплоть до описания и внешних ссылок.

Что происходит с сегментом сейчас

Копии живут рядом с оригиналами. Площадки принимают любой контракт, соответствующий стандарту, и ничто не мешает выпустить коллекцию с тем же названием, тем же символом и теми же изображениями, подменив в написании один знак или заменив латинскую букву на похожую кириллическую. Отличие в адресе. Внешне страница подделки воспроизводит оригинал вплоть до описания и ссылок, а покупатель сравнивает картинки.

Вторая особенность — скорость копий. Коллекция, о которой написали, обрастает двойниками в течение часов, и часть из них создаётся не ради продажи предметов, а ради одобрения доступа к кошельку. Проверка идёт до нажатия. Сначала адрес, потом интерес, и такой порядок экономит больше, чем любая экономия на комиссиях, а участие в бесплатной раздаче предметов разобрано отдельно именно потому, что раздачи копируют чаще прочего.

Как устроена операция технически

Идентификатор коллекции — пара из сети и адреса. Стандарт ERC-721 требует от контракта набор функций владения и переводов, а вот расширение с названием и символом помечено в тексте как необязательное: «name», «symbol» и «tokenURI» вынесены в optional metadata extension. Уникальности этих строк стандарт не обещает. Два контракта с одинаковым названием — нормальное состояние сети, а не аномалия.

Дальше важна судьба картинки. Функция tokenURI возвращает адрес описания предмета, а в самом описании лежит ссылка на изображение, то есть картинка в блокчейне обычно не хранится вовсе и живёт на стороннем хранилище. Стандарт это допускает прямо. Текст говорит: «The URI MAY be mutable», значит изображение и описание способны поменяться после покупки.

У стандарта ERC-1155 правило строже. Там событие URI обязано сопровождать смену адреса метаданных, когда изменение выразимо событием, и в тексте это записано так: «Changes to the URI MUST emit the URI event if the change can be expressed with an event». Ещё одна особенность — подстановка идентификатора: строку «{id}» клиент обязан заменить на номер предмета в шестнадцатеричном виде, строчными знаками, без префикса и с дополнением до 64 знаков. Формулировки сверены 17 октября 2026 года.

Издержки: комиссии, роялти и газ при ошибке

Чтение не стоит ничего. Запрос состояния контракта в обозревателе сети и сверка адреса газа не требуют, потому что это чтение, а не транзакция. Ошибка стоит всей суммы. Покупка предмета из контракта-двойника означает, что уплаченная цена, комиссия площадки и газ ушли безвозвратно, а на руках остался предмет, к заявленной коллекции отношения не имеющий.

Отдельная статья расходов связана с роялти. Их размер задаёт контракт коллекции, а удержание зависит от площадки, поэтому одинаковый предмет на двух площадках обходится по-разному, и разбор комиссий площадки показывает, из чего складывается итоговая сумма. Подделки этим пользуются. Двойник выставляет нулевые роялти и выглядит выгоднее оригинала, и такая выгода — сигнал проверить адрес, а не поспешить со сделкой.

Пошаговый сценарий проверки

Порядок не меняется. Первоисточник, адрес, сверка, и только потом страница площадки. Обратный порядок приводит к тому, что адрес берут с той же страницы, подлинность которой проверяют.

1. Откройте официальный ресурс проекта и найдите раздел с адресом контракта и названием сети.
2. Скопируйте адрес целиком и сверьте его с адресом на странице коллекции посимвольно, начало и конец адреса недостаточны.
3. Откройте контракт в обозревателе сети: убедитесь, что это коллекция предметов, а не токен другого типа.
4. Прочитайте tokenURI одного предмета и посмотрите, куда ведёт описание и где лежит изображение.
5. Проверьте историю событий переводов: дата создания контракта и первые переводы говорят о возрасте коллекции.
6. Сохраните адрес в заметке с датой — при следующей покупке сверка займёт секунды.

Второй шаг недооценивают сильнее всех. Сравнение по первым и последним знакам адреса подделывается подбором, и двойники с совпадающим началом и концом встречаются регулярно, поэтому сверять нужно всю строку или пользоваться копированием из первоисточника. Знаки в середине решают. Привычка копировать адрес, а не набирать его, снимает этот риск целиком. Та же проверка работает и за пределами коллекций: NFT-билеты и ликвидация чёрного рынка — случай, где подлинность записи решает допуск на событие.

Риски и мошеннические схемы сегмента

• Адрес контракта взят с официального ресурса проекта, а не со страницы площадки.
• Адрес сверен целиком, а не по первым и последним знакам.
• Сеть совпадает: та же коллекция в другой сети — другой контракт.
• Описание предмета ведёт на хранилище, заявленное проектом.
• Дата создания контракта соответствует истории коллекции.
• Нулевые роялти и подозрительно низкая цена проверены отдельно.

Двойники работают на спешке. Объявление о раздаче или о скором закрытии продаж подталкивает к сделке до проверки, и в обращениях читателей это главный сюжет последних месяцев. Спешка и есть инструмент. Полезно помнить, что модели хранения данных различаются: цифровые артефакты на базовом слое Bitcoin устроены иначе, и привычные приёмы проверки там применяются по-другому.

Итог

Вся подлинность сводится к адресу контракта и сети, и других доказательств не существует. Название, символ, изображение и число предметов задаются автором контракта произвольно, а метаданные по тексту стандарта допускают изменение, поэтому совпадение внешних признаков не говорит ни о чём. Адрес берут у проекта. Сверяют целиком, сохраняют в заметку и используют при каждой следующей сделке.

Частые вопросы

Первоисточники: текст стандарта ERC-721 — необязательность расширения метаданных и допустимость изменения адреса описания; текст стандарта ERC-1155 — событие смены адреса метаданных и правило подстановки идентификатора. Сверено 17 октября 2026 года.