Смарт-контракты NFT-маркетплейсов управляют листингами, офферами, аукционами, расчетами, отменой, маршрутизацией комиссий, роялти и административными полномочиями. Хотя стандарты ERC-721 или ERC-1155 описывают сам актив, соблюдение стандарта токена не создает автоматически безопасный маркетплейс.

Разработчикам следует сравнивать маркетплейс-контракты с поведением комиссий и ордеров в обзоре маркетплейса OpenSea, с операционными слоями в руководстве по инфраструктуре NFT-маркетплейса и с триггерами платежей в моделях пассивного дохода от NFT, поскольку события контракта служат исходными данными для расчетов и процессов поддержки.

Смарт-контракты NFT: объяснение

NFT smart contract — это код, развернутый в блокчейне, который создает токены и управляет тем, как фиксируется и передается право собственности. При минтинге контракт назначает token ID адресу владельца. Когда токен продается или передается, контракт обновляет запись о владении только после проверки полномочий отправителя и применимых правил передачи.

Обычно контракт записывает владельца токена, supply, approvals, историю переводов и ссылку на metadata. Само изображение или видео он хранит не обязательно. Как отмечается в объяснении NFT smart contracts от Hedera, token ID и metadata идентифицируют актив, а логика smart contract отвечает за minting и изменения владения. Важно, что смарт-контракт — это исполняемый компьютерный код, а не автоматически юридическое соглашение о copyright, возвратах или коммерческих правах.

NFT-контракты и маркетплейс-контракты

NFT-контракт и маркетплейс-контракт выполняют разные функции. NFT-контракт определяет актив, создает token ID, фиксирует владение и обеспечивает approvals и transfers. Маркетплейс-контракт координирует продажу: проверяет листинг или оффер, принимает оплату, передает NFT, маршрутизирует комиссии и закрывает или отменяет ордер.

Это разделение важно, потому что владение действительным NFT не означает, что он активно выставлен, а подпись под ордером маркетплейса не меняет владельца до успешного завершения расчета. Поэтому покупателю следует проверять оба адреса: collection contract идентифицирует NFT, а marketplace contract или spender — ПО, которому выдано разрешение на перевод. Для команд, интегрирующих кошельки, support-инструменты или indexers, это различие также определяет, какие события считать источником истины для доступности товара, возвратов и исполнения.

Как ERC-721 и ERC-1155 влияют на дизайн маркетплейса

ERC-721 обычно используют, когда каждый token ID представляет один отдельный и независимый объект владения. Он хорошо подходит для уникального искусства, уникальных игровых активов, земельных участков и коллекционных предметов, право собственности на которые проверяется по каждому токену. ERC-1155 может представлять несколько копий одного и того же token ID, что полезно для игровых расходников, билетов, editions или предметов, выпускаемых в количестве.

Стандарт токена меняет то, что должен содержать ордер. Листинг ERC-721 обычно продает один token ID. Листинг ERC-1155 может предлагать 20 копий, при этом покупатель приобретает только три, поэтому маркетплейсу нужно обновлять оставшееся количество, не закрывая весь ордер. Отмена должна аннулировать оставшийся объем, а событие расчета должно показывать, сколько единиц перешло из рук в руки.

Механизмы approvals тоже отличаются. Специфическое для токена ERC-721 approval разрешает один NFT, тогда как operator approval может покрывать все токены этой коллекции. В ERC-1155 operator approval обычно используется для всего баланса кошелька в рамках контракта. Для удобства маркетплейс может требовать более широкое разрешение, но окно кошелька должно явно показывать его объем, а пользователь должен понимать, как его отозвать.

Модели escrow и lazy listing

Escrow-маркетплейс переводит NFT в контракт маркетплейса в момент, когда продавец размещает листинг. Это упрощает проверку доступности, но продавец платит больше gas и теряет возможность использовать актив, пока он выставлен. Lazy listing оставляет NFT в кошельке продавца и записывает off-chain подпись, содержащую token, цену, chain, expiry, nonce и адрес маркетплейса. Это снижает стоимость листинга и сохраняет контроль над активом, но контракт должен проверять подпись, а у продавца все равно должен быть on-chain путь для ее аннулирования.

Для игрового маркетплейса этот выбор влияет не только на gas. Escrow может не позволить экипировать предмет, пока он выставлен; lazy listing сохраняет актив игрока, но требует, чтобы игра и маркетплейс умели обрабатывать листинг, который становится невыполнимым при смене владельца. Поэтому перед запуском следует тестировать граничные случаи, такие как переводы кошельков, обновления коллекции и аннулирование листинга, а не предполагать, что модель листинга справится с ними автоматически.

Жизненный цикл листинга и оффера

Фиксированный листинг должен проходить состояния create, validate, buy, settle и cancel. Для офферов нужны expiry, nonce, проверка chain ID, проверки spender и отмена. Каждое состояние должно эмитировать события, которые indexer сможет согласовать.

Офферам также нужна платежная модель, которую контракт действительно может исполнить. Оффер в нативной монете обычно нельзя позднее вывести из кошелька покупателя без новой подписанной транзакции, тогда как утвержденный ERC-20 токен, такой как WETH или USDC, может храниться в escrow или переводиться при принятии продавцом. Поэтому запись ордера должна включать currency, amount, expiry, nonce, buyer, seller, token ID и статус отмены, а не только заголовочную цену.

Для аукциона требуется отдельная state machine. English auction должен обрабатывать более высокие bids, возвраты, время окончания и конечного вызывающего для расчета. Dutch auction должен вычислять текущую цену по прошедшему времени и отклонять устаревшие покупки. Возврат через pull-based balance безопаснее, чем немедленная отправка средств каждому перебитому участнику, поскольку неудачный callback возврата не должен блокировать весь аукцион. Небольшое продление времени окончания также помогает снизить риск последнего момента bid sniping.

Продажа NFT за 0.5 ETH от подписи до расчета

Рассмотрим ERC-721 NFT, выставленный за 0.5 ETH через подписанный ордер. Продавец оставляет NFT в кошельке, но выдает маркетплейс-контракту approval на его передачу. Подписанный листинг содержит collection contract, token ID, seller, price, expiry, nonce, chain ID и адрес маркетплейса. В момент создания подписи смены владельца не происходит.

Когда покупатель отправляет запрос на покупку, маркетплейс-контракт проверяет, не истек ли ордер и не был ли он отменен, принадлежит ли подпись продавцу, по-прежнему ли NFT находится у продавца и остается ли действительным approval на передачу. Затем контракт помечает ордер как выполненный, обрабатывает платеж, направляет NFT покупателю и эмитирует события, которые маркетплейс может использовать для обновления страницы товара.

Приведенное распределение комиссии иллюстративно и не является описанием реальных комиссий какого-либо конкретного маркетплейса.

Если передача NFT не удалась, платеж не должен оставаться завершенным при неизменившемся владении. Если получатель платежа не может принять ETH, наименее рискованная реакция зависит от дизайна контракта: транзакция может быть reverted, либо сумма может быть зачислена на withdrawable balance. Именно поэтому маршрутизацию платежей, порядок перевода, обновление состояния и защиту от reentrancy нужно тестировать вместе, а не как отдельные галочки функций.

Роялти и маршрутизация комиссий

Информация о роялти может следовать EIP-2981, а контрактные библиотеки, такие как OpenZeppelin ERC-721 и OpenZeppelin ERC-1155, помогают реализовать стандартное поведение актива. Однако enforcement на уровне маркетплейса все равно требует осознанной продуктовой политики.

Полезен конкретный пример: покажите, что происходит с одним листингом от обнаружения до подписи и расчета, а затем объясните, где в этом пути появляются комиссии, роялти и approvals.

EIP-2981 делает информацию о роялти читаемой, но не универсально исполнимой. Маркетплейс может запросить адрес создателя и размер роялти, однако другая площадка может выбрать иную политику или проигнорировать результат. Если доход создателя критически важен, проверяйте фактический путь перевода, выбранный маркетплейс, поведение агрегатора и логику enforcement конкретной коллекции, а не считайте поле роялти гарантированным платежом.

Тесты безопасности

Проверьте reentrancy, replay, просроченные ордера, подписи не от той chain, компрометацию admin key, поведение pause и частичные fills. Цель не в длинном audit checklist, а в доказательстве того, что маркетплейс закрывается при небезопасном ордере.

Наиболее ценные тесты должны моделировать сбои, с которыми реально может столкнуться покупатель или продавец. Покупка должна отклонять измененную цену, а не подменять ее; подписанный ордер должен быть привязан к chain ID и адресу маркетплейса; отмененный или использованный nonce не должен срабатывать повторно. В коде расчетов обновляйте состояние ордера до внешних вызовов и используйте reentrancy guard вокруг путей платежа и передачи.

Пользователь Polygon, оставивший отзыв о Rarible, сообщил, что в этом сетевом обзоре контракта не хватало поддержки custom-contract и freezing metadata, и этот отзыв был собран 11 августа 2026 года. Это не доказывает, что маркетплейс-контракт небезопасен, и выводы могут зависеть от сети и версии продукта. Тем не менее это полезная граница реализации: тестируйте покрытие контрактов, неизменяемость metadata и поведение обновлений именно на той сети, на которой планируется запуск.

Заключение

Маркетплейс-контракт следует оценивать по его жизненному циклу ордера и поведению при сбоях. Если статья помогает разработчику проверять просроченные ордера, подписи не от той сети, маршрутизацию роялти и индексацию событий, она делает больше, чем просто повторяет стандарты токенов. Следующая инженерная проверка — тест жизненного цикла ордера. Безопасный путь контракта обрабатывает создание, истечение срока, отмену, расчет, роялти, индексацию и pause-поведение без опоры на предположения.

Часто задаваемые вопросы

Какая информация хранится в NFT smart contract?

Обычно контракт записывает token ID, владение, balances, approvals, правила передачи, supply и metadata URI. Изображение или видео часто хранятся отдельно и связываются через metadata.

Управляет ли NFT-контракт также листингами на маркетплейсе?

Не обязательно. NFT-контракт управляет токеном, а отдельный маркетплейс-контракт обычно управляет листингами, офферами, аукционами, оплатой, комиссиями и расчетами.

Может ли маркетплейс передать NFT без разрешения?

Для этого нужно разрешение через владение, token-specific approval или operator approval, распознанный NFT-контрактом. Покупателям и продавцам следует проверять утвержденного spender перед подписью.

Гарантирует ли поле роялти в NFT оплату?

Нет. Стандарт роялти может сообщать получателя и сумму, но фактическая оплата зависит от политики маркетплейса и пути расчета.

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