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

Проверка контракта коллекции — это чтение его полномочий по проверенному исходному коду: какие действия доступны привилегированному адресу помимо обычных переводов между владельцами.

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

Решение принимают по картинке. Страница коллекции показывает изображение, цену и число владельцев, а условия владения заданы кодом, который на странице не виден и в описание не попадает. Разрыв здесь принципиальный. Покупатель уверен, что получает предмет с неизменным описанием и фиксированными правилами, тогда как контракт нередко оставляет автору право поменять и описание, и правила.

Стандарт в этом не помогает и помогать не должен. Текст ERC-721 описывает владение, переводы и одобрения, а полномочий владельца контракта, остановки переводов, чёрных списков, роялти и порядка выпуска в нём нет вовсе: эти вопросы вынесены за рамки стандарта. Выводится из этого один практический вывод. Соответствие стандарту ничего не говорит о правах автора, и участие в бесплатной раздаче предметов тоже не отменяет чтения кода, потому что раздаваемый предмет живёт по тем же правилам.

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

Начинают с проверки исходного кода. Опубликованный текст сопоставляется с кодом, который работает в сети, и у этой сверки две степени: точное совпадение, когда «the bytecode of the deployed contract is byte-by-byte the same (excluding libraries and immutables)» вместе с совпадением отпечатка метаданных, и обычное совпадение, при котором сходится всё, кроме отпечатка. Разница практическая. При обычном совпадении исходный текст способен отличаться комментариями и именами, то есть читается не обязательно тот же файл, который компилировали.

Дальше ищут привилегии. Распространённая конструкция описана в документации библиотеки контрактов так: «there’s an account that is the owner of a contract and can do administrative tasks on it», и рядом живут функции передачи и отказа от этого права. Вторая конструкция — роли. О главной из них документация предупреждает прямо: роль администратора по умолчанию «carries significant risk», поскольку «it is also its own admin», то есть сама себе администратор и снимается только собой.

Третье, что смотрят, — остановка. Механизм пауз описывается как «A common emergency response mechanism that can pause functionality while a remediation is pending», и наличие такого механизма само по себе не изъян: он задуман для аварийных ситуаций. Вопрос в том, кто его включает. Если пауза доступна одному адресу без ограничений по времени и без оповещения, переводы предмета останавливаются по единоличному решению, и владелец предмета об этом узнаёт в момент попытки перевода.

Полномочие Как выглядит в коде Что позволяет держателю права Чем проверить
Права владельца контракта Ограничитель доступа на функциях, передача и отказ от права Выполнять административные действия, перечисленные в коде Проверенный исходный код, чтение текущего владельца
Роли с администратором по умолчанию Выдача и отзыв ролей, роль-администратор над собой Назначать и снимать исполнителей привилегированных функций Список адресов с ролями в состоянии контракта
Остановка переводов Переключатель состояния и условие на функциях перевода Прекратить переводы предметов до обратного решения Наличие переключателя и адрес, которому он доступен
Чёрный список адресов Набор адресов и проверка в функциях перевода Запретить операции конкретным адресам Поиск проверки адреса в функциях переводов
Изменяемый адрес метаданных Функция установки базового адреса описаний Поменять описание и изображение после продажи Текст стандарта допускает изменяемость, деталь ищут в коде
Дополнительный выпуск Функция выпуска без ограничения по числу предметов Увеличить число предметов в коллекции после продаж События выпуска в истории и условия в коде функции

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

Роялти задаются контрактом, а платятся по доброй воле. Стандарт отчислений предусматривает функцию royaltyInfo с идентификатором получателя и суммой, и прямо оговаривает: «The royalty payment must be voluntary», потому что обычный перевод между кошельками продажей не является. Площадкам отчисления лишь рекомендованы. Отсюда и расхождение итоговых сумм между площадками, которое разбирает материал о комиссиях площадки.

Условный пример, числа условны. Предмет продан за единицу. Контракт заявляет роялти 7,5 процента, площадка удерживает 2,5 процента комиссии, газ за перевод оплачивает отправитель отдельно. Если площадка отчисления не поддерживает, 7,5 процента автору не поступают, а условия владения при этом не меняются. Выводов о цене не делают.

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

Пошаговый сценарий чтения контракта

Порядок устойчивый. Сначала статус исходного кода, потом привилегии, затем метаданные и роялти. Нарушение порядка приводит к чтению текста, который в сети не работает.

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

Шестой пункт даёт неожиданные находки. В стандарте ERC-1155 выпуск опознаётся по событию, где источник указан нулевым адресом, а списание — по нулевому адресу получателя, и это правило записано в тексте прямо. История событий читается без знания языка контрактов. Видно дату, число предметов и адрес, который выпуск инициировал, а дальше остаётся сравнить это с заявленным объёмом коллекции. Иная модель обходится без контракта с полномочиями вовсе: цифровые артефакты на базовом слое Bitcoin устроены по другому принципу, и привычные проверки там заменяются другими совсем.

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

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

Третий пункт решает больше. Широкие права, которыми управляет схема из нескольких подписей, и те же права у одного неизвестного адреса — разные ситуации при одинаковом коде. В коде этого нет. Её ищут в документации проекта и в объявлениях, а при отсутствии записывают как пропуск раскрытия, не делая выводов о намерениях.

Итог

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

Материалы по теме

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

Что делать, если исходный код контракта не проверен?

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

Возможность остановить переводы — это всегда плохой признак?

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

Можно ли полагаться на роялти, прописанные в контракте?

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

Как понять, что описание предмета могут поменять после покупки?

По функции установки адреса. Текст ERC-721 изменяемость адреса допускает, поэтому запрета здесь нет, и всё решает код конкретного контракта. В ERC-1155 правило строже: смена адреса обязана сопровождаться событием, если изменение выразимо событием. Жёстко заданный адрес предсказуемее.

Вердикт

Чтение контракта перед покупкой — работа на двадцать минут, которая отвечает на вопрос, что именно вы приобретаете и какие решения остаются за автором коллекции. Стандарт о полномочиях не говорит, поэтому ни соответствие стандарту, ни метка на площадке, ни число владельцев предмета это чтение не заменяют. Шесть пунктов списка закрывают основное. Разборы контрактов коллекций публикуем в Telegram-канале Cryptium.

Первоисточники: текст стандарта отчислений ERC-2981 — функция royaltyInfo и оговорка о добровольности платежа; описание степеней совпадения кода в документации Sourcify — разница между точным и обычным совпадением. Сверено 17 октября 2026 года.