Необязательные роялти NFT простыми словами

2026-09-03

Коллекция заявляет роялти автора в размере 5%. Токен из неё продаётся за 10 ETH, значит автору причитается 0,5 ETH. Дойдут ли эти 0,5 ETH до него, решает вовсе не контракт токена. Это решает тот, кто рассчитывает сделку, и стандарт, задающий роялти, говорит об этом собственными словами.

Необязательные роялти NFT простыми словами: ключевые моменты кратко

Что такое ончейн-роялти на самом деле

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

Интерфейс состоит из одной функции только для чтения. Вызывающая сторона передаёт идентификатор токена и цену продажи, а контракт возвращает два значения: адрес, который должен получить роялти, и причитающуюся сумму. Он отвечает на вопрос. Он ничего не перемещает.

Пропустите через него пример. Вызывающая сторона передаёт цену продажи 10 ETH, коллекция настроена на 5%, и функция возвращает 0,5 ETH вместе с адресом получателя. В этот момент покупатель по-прежнему держит средства, продавец по-прежнему держит токен, и никому ничего не выплачено.

Почему стандарт делает выплату добровольной

Спецификация не оставляет это на усмотрение читателя. В ней сказано, что выплата роялти должна быть добровольной, поскольку механизмы передачи вроде transferFrom() включают переводы NFT между кошельками, а их выполнение не всегда означает, что продажа состоялась.

Это рассуждение опирается на то, что видит блокчейн. В ERC-721 событие Transfer возникает при смене владельца любого NFT любым способом, и это же событие покрывает создание и уничтожение. Оно фиксирует, что владелец сменился. Оно не несёт ни цены, ни причины.

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

Кто вообще способен заплатить

Тот, кто знает о состоявшейся продаже, — это тот, кто её рассчитывает. Маркетплейс как смарт-контракт принимает оплату от покупателя, передаёт ему токен и отправляет выручку продавцу. Это единственное место во всей последовательности, где цена и передача существуют одновременно.

ERC-2981 обращается к этой стороне напрямую и обращается в форме рекомендации: маркетплейсам, поддерживающим стандарт, следует реализовать какой-либо способ передачи роялти получателю. Рекомендация — не требование, да и пути принуждения всё равно нет, потому что контракт токена никогда не находится в цепочке платежа.

Одно указание в стандарте сформулировано жёстче, и стоит прочитать, что оно раскрывает. Маркетплейсы обязаны выплачивать роялти в той же единице обмена, что и цена продажи, переданная в функцию роялти. Даже самая сильная фраза документа адресована стороне, которую контракт токена принудить не может.

Где роялти теряется

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

Маршрут расчёта	Кто решает вопрос о роялти	Что доходит до автора
Прямой перевод между кошельками, цена согласована вне сети	Никто; расчётного контракта нет	Ничего
Площадка, которая никогда не вызывает функцию роялти	Площадка, по умолчанию	Ничего
Площадка, которая её вызывает, но оставляет выплату трейдеру	Покупатель или продавец, в каждой сделке	Столько, сколько они выберут
Площадка, которая её вызывает и переводит сумму полностью	Площадка, согласно своей политике	0,5 ETH

Обязательство есть только в последней строке, и принадлежит оно площадке, а не токену. Смените площадку — и тот же токен по тому же контракту даст другой ответ; именно это на практике и значит «необязательный».

Принуждение на уровне контракта

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

Цену такой конструкции платит держатель. Контракт токена теперь решает, где его держателям торговать, кто-то должен вести список и поддерживать его в актуальном виде, а токен, который не может переместить неодобренный оператор, по-прежнему может переместить его собственный владелец. Любой маршрут, где оператор не нужен вовсе, остаётся незатронутым.

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

Что стандарт всё же решает

Список того, что фиксирует ERC-2981, короток, и, прочитанный столбцом, он показывает форму стандарта.

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

Первые четыре строки описывают число. Последние три касаются получения денег, и стандарт отказывается от всех трёх. Это спецификация о том, как описать роялти, а не о том, как его собрать.

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

Как читать число на странице коллекции

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

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

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

Итог

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

Значит, смотреть нужно на маркетплейс, а не на контракт. Роялти выплачивается тогда, когда площадка, рассчитывающая сделку, решает его выплатить, а описанные выше схемы принуждения работают через ограничение того, где токен может торговаться, а не через автоматизацию выплаты. Чтобы продолжать изучать основы, следите за материалами Bitbase Academy.