ERC-2981: Как определяются и реализуются роялти для NFT

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

Что стандартизирует ERC-2981

ERC-2981 — это стандарт Ethereum, который определяет одну функцию для невзаимозаменяемых токенов:

• royaltyInfo(tokenId, salePrice) → (receiver, royaltyAmount)

Торговые площадки, поддерживающие роялти, вызывают royaltyInfo во время продажи для расчета выплаты. Стандарт не обеспечивает принудительного исполнения — он только описывает интерфейс. Вопрос принудительного исполнения является политикой торговой площадки.

Ключевые решения при разработке:

• Процентная основа: Роялти рассчитываются как функция цены продажи, обычно с использованием дроби, такой как базисные пункты (например, 500 = 5%).
• Гибкость получателя: Получателем роялти может быть адрес создателя, мультиподписной кошелек, сплит-контракт или обновляемый адрес выплаты.
• Совместимость с ERC-721 и ERC-1155: ERC-2981 совместим с распространенными стандартами NFT и использует ERC-165 для обнаружения интерфейса.

Для готовых к использованию реализаций многие команды используют ERC2981 от OpenZeppelin.

Почему это важно сейчас

Начиная с 2023 года, несколько ведущих маркетплейсов перешли к необязательному исполнению роялти. Наиболее заметным изменением стало решение OpenSea отказаться от своего Operator Filter, который ранее позволял создателям ограничивать торговлю площадками, соблюдающими роялти; см. анонс OpenSea. В результате ончейн-стандарты, такие как ERC-2981, стали стандартным способом получения данных о роялти на различных платформах, даже при различном исполнении.

С тех пор экосистема отреагировала:

• Инфраструктура реестров, чтобы маркетплейсы могли унифицированно обрабатывать логику роялти, например, Royalty Registry и связанная с ним спецификация.
• Программируемые стандарты для ончейн-исполнения или ограничений, в частности ERC-721C (Creator Token Standards).
• Альтернативные модели заработка, такие как вознаграждения на уровне протокола и стимулы для создателей, например, Creator Rewards от Zora.

В 2024–2025 годах внедрение ERC-2981 остается широко распространенным в сетях L1 и L2, и маркетплейсы, которые решат соблюдать роялти, как правило, будут запрашивать этот интерфейс при расчетах сделок.

Как работает интерфейс (без сюрпризов)

Во время продажи соответствующий требованиям маркетплейс выполняет следующие действия:

1. Проверяет, поддерживает ли токен IERC2981 через ERC-165 (ID интерфейса 0x2a55205a).
2. Вызывает royaltyInfo(tokenId, salePrice) для получения:
   • receiver: Адрес для получения выплаты.
   • royaltyAmount: Сумма к выплате, рассчитанная на основе salePrice.

Создатели или владельцы коллекций обычно устанавливают «роялти по умолчанию» и, при желании, «роялти на токен». Многие реализации используют знаменатель 10 000 для базисных пунктов. Затем система учета маркетплейса распределяет выручку от продажи между продавцом, комиссиями протокола и получателем роялти.

Советы по реализации:

• Избегайте ошибок (reverts) в royaltyInfo — маркетплейсы могут пропустить выплаты, если ваш вызов завершится с ошибкой.
• Сделайте получателя роялти обновляемым (например, через Ownable или административные средства управления) для смены ключей или миграции на сплит-контракт.
• Установите разумный максимальный предел роялти (многие проекты остаются ≤10%) для стимулирования ликвидности на вторичном рынке.

Минимальный пример на Solidity

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

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC721/ERC721.[sol](https://onekey.so/blog/ru/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/token/common/ERC2981.[sol](https://onekey.so/blog/ru/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/access/Ownable.[sol](https://onekey.so/blog/ru/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";

[contract](https://onekey.so/blog/ru/ecosystem/what-is-a-smart-contract/) MyNFT is ERC721, ERC2981, Ownable {
    uint256 private _nextTokenId;

    constructor([address](https://onekey.so/blog/ru/ecosystem/what-is-a-crypto-wallet-address/) defaultReceiver, uint96 defaultBps)
        ERC721("MyNFT", "MYN")
    {
        // Установить роялти по умолчанию (например, 500 = 5%)
        _setDefaultRoyalty(defaultReceiver, defaultBps);
    }

    function mint([address](https://onekey.so/blog/ru/ecosystem/what-is-a-crypto-wallet-address/) to) external onlyOwner {
        _safeMint(to, _nextTokenId);
        _nextTokenId++;
    }

    // Необязательно: установить роялти на токен для специальных предметов
    function setTokenRoyalty(uint256 tokenId, [address](https://onekey.so/blog/ru/ecosystem/what-is-a-crypto-wallet-address/) receiver, uint96 bps)
        external
        onlyOwner
    {
        _setTokenRoyalty(tokenId, receiver, bps);
    }

    // Обязательно: ERC-165 supportsInterface
    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC721, ERC2981)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }
}

Для более подробной документации см. руководство OpenZeppelin по ERC-2981.

Обработка сплитов, обновлений и крайних случаев

Реальные потоки роялти редко имеют одного получателя. Рассмотрите:

• Сплит-контракты: Направляйте выручку нескольким сторонам в фиксированных пропорциях, используя проверенную инфраструктуру, такую как 0xSplits.
• Запросы к реестру: Некоторые маркетплейсы обращаются к реестру для получения актуальных данных о роялти (Royalty Registry).
• Обновляемые получатели: Сохраняйте возможность обновления адреса получателя в случае смены ключей или организационных изменений.
• Переопределения на токен: Специальные издания могут иметь уникальные ставки роялти по сравнению с настройками по умолчанию.

Технические примечания:

• Единый знаменатель: Используйте базисные пункты (10 000) для ясности в офчейн-интеграциях.
• Учет типа токена: Реализации ERC-1155 должны рассчитывать роялти на основе цены продажи каждого токена, а не общей цены пакета.
• Корректное резервирование: Если получатель роялти не установлен, верните ноль, чтобы избежать сбоев вызовов маркетплейса.

Реальность маркетплейсов: сигнализация против принуждения

ERC-2981 сигнализирует о намерениях создателя; он не обеспечивает принудительной оплаты. Различные площадки:

• Могут полностью соблюдать ERC-2981.
• Могут ограничивать или снижать роялти при определенных условиях.
• Могут полностью игнорировать роялти.

Учитывая эту вариативность, многие создатели экспериментируют с гибридными моделями:

• Ончейн-ограничения через ERC-721C для ограничения передач операторам, соблюдающим роялти.
• Вознаграждения на уровне протокола, такие как Zora’s Creator Rewards.
• Общественные нормы и социальное давление, направленное на соблюдение заработка создателей.

Решение OpenSea 2023 года об отказе от операторского фильтра отражает более широкую тенденцию к выбору рынка вместо принуждения на уровне протокола, подробно описанную в их анонсе. В 2024–2025 годах этот баланс сохраняется: ERC-2981 остается каноническим интерфейсом для метаданных роялти, в то время как принуждение фрагментировано.

Тестирование, проверка и мониторинг

Для обеспечения надежного поведения роялти:

• Проверьте поддержку интерфейса: Убедитесь, что ваш контракт сообщает supportsInterface(0x2a55205a) == true согласно ERC-165.
• Симулируйте вызовы: Протестируйте royaltyInfo для крайних значений цен продажи и токенов.
• Совместимость индексации: Зарегистрируйте свой контракт в соответствующих реестрах, таких как Royalty Registry, если ваши партнеры-маркетплейсы полагаются на него.
• Четко документируйте: Опубликуйте свою политику роялти, ограничения и логику получателя, чтобы минимизировать сюрпризы для покупателей и маркетплейсов.
• Изучите стандарт: Если вы новичок в ERC-2981, этот обзор от Alchemy станет полезным введением: Что такое ERC-2981?.

Безопасность и управление ключами для создателей

Конфигурации роялти управляются администратором. Если злоумышленник получит доступ к ключам развертывания или администратора, он сможет перенаправить роялти или отключить их. Лучшие практики:

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

Для создателей и студий, которым требуется безопасное, переносимое подписание без ущерба для пользовательского опыта, аппаратные кошельки OneKey предлагают:

• Автономное хранение приватных ключей с прошивкой с открытым исходным кодом и прозрачными практиками безопасности.
• Бесшовную интеграцию с распространенными инструментами Ethereum для развертывания контрактов и административных операций.
• Межсетевую поддержку, что полезно, если ваши NFT минтятся в L2 или нескольких сетях EVM.

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

Заключение

ERC-2981 — это базовый уровень для роялти NFT: простой, универсальный интерфейс, который маркетплейсы могут читать для определения выплат создателям. Он не гарантирует принудительного исполнения — это делают политики маркетплейсов — но он стандартизирует сигнал. В мире, где принуждение необязательно и постоянно развивается, сочетание ERC-2981 с реестрами, сплит-контрактами и программируемыми ограничениями, такими как ERC-721C, предоставляет создателям практические инструменты для поддержания их работы.

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