On-chain роялті для NFT: розробка за стандартом ERC-2981

До появи ERC-2981 кожен маркетплейс реалізовував роялті по-своєму: OpenSea зберігав список оффчейн, Rarible використовував власний контракт, LooksRare — свою схему. У результаті творець NFT втрачав до 30% доходів від вторинних продажів через ручну реєстрацію. Ми розробляємо смарт-контракти з вбудованим стандартом ERC-2981, що гарантує автоматичні відрахування на всіх популярних площадках — OpenSea, Rarible, LooksRare, Blur та X2Y2. Працюємо під ключ: від прототипу смарт-контракту до аудиту безпеки та розгортання в обраній мережі. ERC-2981 став галузевим стандартом для on-chain роялті, і ми допомагаємо впровадити його з мінімальними газовими витратами та максимальною прозорістю. Економія на маркетплейсових комісіях сягає 30%. Наша команда має 5+ років досвіду в Web3 і виконала 15+ аудитів, що дозволяє швидко знаходити оптимальне рішення для кожного проекту. У середньому творець економить $2,000–5,000 на місяць на ручному адмініструванні.

Докладніше про стандарт: EIP-2981

Чому ERC-2981 став стандартом для on-chain роялті?

До стандарту творцю доводилося реєструватися в кожному маркетплейсі окремо. ERC-2981 робить роялті переносимими: розгорнули контракт — і всі площадки, що підтримують інтерфейс, автоматично застосовують ваші умови. Це економить сотні годин ручного адміністрування. On-chain роялті з ERC-2981 у 5 разів прискорює інтеграцію з новими маркетплейсами порівняно з off-chain підходом.

Порівняння: on-chain vs off-chain роялті

Off-chain підхід був популярним, але творець втрачав контроль. On-chain з ERC-2981 — галузевий стандарт, який ми рекомендуємо всім клієнтам.

Як працює ERC-2981

Стандарт додає одну функцію в контракт:

function royaltyInfo(
    uint256 tokenId,
    uint256 salePrice
) external view returns (address receiver, uint256 royaltyAmount);

Маркетплейс при продажу викликає royaltyInfo(tokenId, salePrice), отримує адресу отримувача та суму роялті. Все. Стандарт навмисно мінімалістичний — він не примушує до виплати (enforcement off-chain), лише надає дані.

Базова реалізація через OpenZeppelin:

import "@openzeppelin/contracts/token/common/ERC2981.sol";

contract MyNFT is ERC721, ERC2981 {
    constructor() ERC721("MyNFT", "MNFT") {
        _setDefaultRoyalty(msg.sender, 500); // 500 basis points = 5%
    }
    
    function setTokenRoyalty(uint256 tokenId, address receiver, uint96 feeNumerator) 
        external onlyOwner {
        _setTokenRoyalty(tokenId, receiver, feeNumerator);
    }
}

feeNumerator — чисельник від знаменника _feeDenominator() (за замовчуванням 10000). Отже, 500 = 5%, 250 = 2.5%, максимум 10000 = 100% (не використовуйте). Ми оптимізуємо контракт для мінімальної витрати газу при виклику royaltyInfo.

Розширені патерни роялті

Splitter роялті для декількох отримувачів

Стандарт підтримує лише одного receiver. Для спліту між творцем, командою, фондом — потрібен додатковий контракт. Два підходи:

• PaymentSplitter: receiver в ERC-2981 вказує на PaymentSplitter контракт (OpenZeppelin). Маркетплейс переводить всю суму на спліттер, спліттер розподіляє за shares. Простий, перевірений, але додатковий газ на release.
• Push royalty splitter: вбудований в NFT контракт механізм, який при кожному надходженні автоматично розподіляє за адресами. Економить один виклик, але ускладнює контракт.

Динамічні роялті

ERC-2981 дозволяє royaltyInfo повертати різні значення для різних tokenId. Це відкриває можливості:

• Зниження роялті зі зростанням ціни продажу (прогресивна шкала)
• Різні ставки для різних категорій токенів (tier system)
• Нульові роялті для primary sale, 5% для secondary

Приклад реалізації динамічних роялті з прогресивною шкалою:

function royaltyInfo(uint256 tokenId, uint256 salePrice) 
    public view override returns (address, uint256) {
    uint96 rate;
    if (salePrice <= 1 ether) rate = 500;      // 5% до 1 ETH
    else if (salePrice <= 10 ether) rate = 300; // 3% до 10 ETH
    else rate = 100;                            // 1% вище 10 ETH
    return (_royaltyReceiver, (salePrice * rate) / _feeDenominator());
}

Як реалізувати динамічні роялті з гнучкими ставками?

Вибір між базовою реалізацією, спліттером та динамічними ставками залежить від вашої бізнес-моделі. Якщо у вас один автор і фіксована комісія — достатньо базового ERC-2981. Для команд з декількома отримувачами використовуйте PaymentSplitter. Якщо хочете стимулювати торгівлю — впровадьте динамічні ставки. Ми допоможемо проаналізувати ваш кейс і вибрати оптимальне рішення. Отримайте безкоштовну оцінку вашого проекту за 24 години — напишіть нам.

Процес роботи

1. Аналітика: розбираємо вимоги до роялті, сценарії торгів, цільову аудиторію.
2. Проектування: обираємо архітектуру (базовий, splitter, динамічний), готуємо специфікацію.
3. Розробка: пишемо контракт на Solidity 0.8.x, використовуємо Foundry для тестів та верифікації.
4. Тестування: coverage >95%, фаззинг на Echidna, перевірка реентерабельності та gas-оптимізація.
5. Аудит: внутрішній та зовнішній аудит безпеки (слайзери, формальна верифікація).
6. Деплой: розгортання на Ethereum/Polygon, верифікація в Etherscan, налаштування supportsInterface.
7. Підтримка: моніторинг, оновлення при форках мережі, консультації щодо інтеграції.

Що входить у розробку?

• Вихідний код контракту з тестами (репозиторій GitHub)
• Документація щодо розгортання та налаштування
• Розгортання в обраній мережі (Ethereum, Polygon, Arbitrum, BNB Chain)
• Верифікація контракту на блокчейн-експлорері
• Інтеграція з маркетплейсами (OpenSea, Rarible, LooksRare)
• Аудит безпеки (звіт про вразливості)
• Доступ до приватного репозиторію для подальших доопрацювань
• Підтримка протягом місяця після деплою

Орієнтири за строками

Вартість розраховується індивідуально виходячи зі складності. Отримайте оцінку за 1 день — напишіть нам, і ми підготуємо пропозицію. Наша команда має 5+ років досвіду в Web3, виконала 15+ аудитів смарт-контрактів і розгорнула десятки ERC-2981 токенів для клієнтів з США, Європи та Азії. Зв'яжіться з нами для обговорення архітектури.

Чому розробка NFT маркетплейсів потребує комплексного підходу?

Ми бачимо, що на перший погляд NFT-контракт виглядає просто: ERC-721, mint(), IPFS для метаданих, і все. На практиці саме в цій «простоті» ховається більшість проблем — від ботів, які скуповують весь mint у першому блоці, до зламаних роялті на вторинному ринку. Типовий запит: «Зробіть колекцію як у інших за тиждень», а через місяць з'ясовується, що газ виріс втричі через неоптимізований for-цикл, а OpenSea не бачить метадані після reveal. Ми знаємо кожні з цих граблів і будуємо процеси так, щоб їх уникнути.

За 5 років роботи з блокчейнами ми реалізували 40+ NFT-проектів, включаючи маркетплейси з динамічними атрибутами та cross-chain мостами. Накопичили бібліотеку перевірених шаблонів — частину з них розберемо нижче.

Який стандарт вибрати: ERC-721 чи ERC-1155?

ERC-721 — кожен токен унікальний, один owner. Підходить для колекцій, де кожен NFT має індивідуальні атрибути та пряму прив'язку owner → tokenId.
ERC-1155 — multi-token стандарт: один контракт зберігає і fungible, і non-fungible токени. Використовує balanceOf(address, tokenId) замість ownerOf(tokenId). Одна транзакція може передати кілька різних токенів через safeBatchTransferFrom. Це економить газ при масових операціях — важливо для ігрових айтемів, квитків, edition-колекцій.

Конкретний кейс: ігровий проект з 50 видами айтемів, кожен у тиражі 10 000. ERC-721 — 500 000 унікальних токенів, величезний overhead на маппінги. ERC-1155 — 50 tokenId, balanceOf на кожного гравця. Газ на transfer нижче в 2–3 рази, деплой контракту дешевший. Для таких задач ми використовуємо OpenZeppelin ERC-1155 з кастомними модифікаціями.

Метадані: on-chain vs IPFS vs centralized

Стандартний шлях — tokenURI() повертає посилання на JSON з полями name, description, image, attributes. Три варіанти зберігання:

• Centralized server — найдешевший і гнучкий. Ризик: сервер падає, компанія закривається — NFT втрачає метадані. Не підходить для колекцій з претензією на довгострокову цінність.
• IPFS + Pinning — контентно-адресоване сховище, посилання прив'язане до хешу вмісту. Pinata або NFT.Storage забезпечують pіннінг. Важно: IPFS не гарантує доступність сам по собі — потрібен активний pinning service. Якщо він закриється, дані можуть зникнути, якщо ніхто не зберігає копію.
• On-chain metadata — base64-encoded SVG або JSON прямо в tokenURI. Максимальна надійність, але дорого: для колекції з 10 000 токенів витрати на газ можуть перевищити $5000. Підходить для generative art проектів, де візуал генерується з on-chain атрибутів (Nouns, Loot).

Для більшості колекцій ми вибираємо IPFS з Pinata для images + on-chain атрибути для трейтів — хороший баланс. Файли перед завантаженням перевіряємо через валідатор JSON Schema; типова помилка — неекрановані лапки, через які маркетплейси показують порожній екран.

Dynamic NFT: метадані, які змінюються

Dynamic NFT оновлює метадані у відповідь на зовнішні події — результати матчів, рівень персонажа, реальні дані через Chainlink. Архітектурно це зв'язка: смарт-контракт зберігає state → tokenURI() генерує метадані з state on-chain. Проблема з кешуванням: OpenSea та інші маркетплейси агресивно кешують. Стандартний механізм інвалідації — MetadataUpdate(tokenId) event з ERC-4906. OpenSea слухає цей event і скидає кеш. Без нього оновлені метадані можуть не відображатися тижнями.

Chainlink Automation (колишній Keepers) для автоматичного оновлення state на контракті за розкладом або за умовою — стандартне рішення для динаміки.

Як захистити mint від ботів?

Allowlist через merkle tree — стандарт. Список адрес хешується в merkle root, зберігається в контракті. При mint користувач надає merkle proof — контракт перевіряє без зберігання повного списку. Використовуємо OpenZeppelin MerkleProof library.

Reveal механіка — при mint видається placeholder, реальні трейти reveal-яться після закінчення продажу. Інакше боти можуть сканувати pending транзакції і снайперити рідкісні трейти через frontrunning. Але reveal вимагає commitment scheme — випадковий seed має бути зафіксований до mint або використовувати Chainlink VRF.

Chainlink VRF для чесної рандомізації трейтів. VRF request в момент mint → callback з verifiable random number → assign traits. Це додає ~2 транзакції та latency, але гарантує чесність. Посилання на Chainlink VRF v2.5.

Rate limiting — require(mintedPerWallet[msg.sender] < maxPerWallet). Не захищає від мульти-гаманців, але піднімає вартість атаки. Для преміум-проектів часто додаємо proof-of-work прямо в контракт (через EIP-2612 signatures).

Royalties: реальний стан ринку

ERC-2981 — on-chain стандарт роялті. Контракт повертає (recipient, amount) для будь-якої sale price через royaltyInfo(tokenId, salePrice). Маркетплейси опитують це при кожному продажу. Проблема: дотримання роялті — добровільне рішення маркетплейсу. Blur запустився з нульовими роялті, що викликало хвилю інших платформ. Зараз ситуація частково стабілізувалася: OpenSea підтримує ERC-2981, Blur додав опціональні.

Спроби enforce роялті on-chain через обмеження transfers тільки на approved маркетплейси (operator filtering) OpenSea пропонував через OperatorFilterRegistry. Це ламає composability — не можна передати NFT через кастомний контракт. Більшість серйозних проектів відмовилися від цього підходу. Для проектів, де роялті критичні, ми будуємо кастомний маркетплейс всередині екосистеми + incentive structure для користувачів торгувати саме там.

Lazy minting та gas-free mint

Gas-free mint через підпис: творець підписує voucher (tokenId, tokenURI, price, signature), покупець надає voucher в mint() — контракт верифікує підпис через ECDSA.recover() і минтить. Працює на OpenSea через їх Seaport протокол. Seaport — оптимізований контракт з мінімальним gas usage. Розуміння його механіки важливе при інтеграції custom marketplace логіки.

Стек для NFT-проектів

• Контракти: Solidity 0.8.x, OpenZeppelin ERC721Enumerable або ERC721A (Azuki) для gas-оптимізованого batch mint, ERC1155 від OpenZeppelin
• VRF та автоматизація: Chainlink VRF v2.5, Chainlink Automation
• Зберігання: Pinata (IPFS pinning), NFT.Storage, Arweave для постійного зберігання
• Маркетплейс: OpenSea Seaport protocol, кастомна інтеграція
• Фронтенд: wagmi v2 + viem, RainbowKit для wallet connection, React + TypeScript

Процес розробки

1. Проектування mint-механіки — allowlist, public sale, price curve (Dutch auction або фіксована), limits per wallet
2. Контракти — з Foundry fuzz-тестами на mint limits, merkle proof-верифікацію, royalty calculations
3. IPFS деплой — завантаження метаданих та images до reveal, піннінг на мінімум двох сервісах
4. Reveal — якщо використовується Chainlink VRF, тест на testnet обов'язковий: VRF subscription має бути funded LINK токенами
5. Маркетплейс-інтеграція — верифікація колекції на OpenSea, налаштування роялті, тест MetadataUpdate events
6. Деплой та моніторинг — Tenderly для відлову reentrancy, Etherscan API для верифікації контракту, налаштування оповіщень за подіями

Що входить в роботу (deliverables)

• Вихідний код смарт-контрактів (Solidity, Rust для Solana) з коментарями
• Тест-сьют (Foundry/Hardhat) з покриттям ≥90%
• Документація розгортання та інструкції з інтеграції
• Доступи до pinning-сервісів (Pinata/Pinfluence)
• Скрипти для генерації метаданих (Python/JS)
• Підтримка при верифікації на маркетплейсах
• 30 днів технічної підтримки після деплою

Строки

Вартість розраховується індивідуально після аудиту вашого завдання. Надішліть brief з описом проекту — оцінимо прозоро протягом 3 робочих днів. Для постійних клієнтів діє гнучка система знижок на пакетні замовлення. Зв'яжіться з нами для детального обговорення вашого NFT-проекту. Отримайте консультацію з архітектури маркетплейсу — залиште заявку, і ми оцінимо проект за три дні.