Розробка підписочного рішення на базі NFT та смарт-контрактів

Ми регулярно бачимо проєкти, які намагаються натягнути тимчасовий доступ на стандартний ERC-721 і отримують головний біль: race condition при перевірці терміну, перевитрати газу через неоптимальне зберігання дат або повну відсутність механізму продовження. Проблема в тому, що ERC-721 не має вбудованого поняття «закінчення». Рішення — використовувати спеціалізований стандарт ERC-5643 або побудувати свою логіку на базі mapping. Ми у своїй практиці віддаємо перевагу першому варіанту: він перевірений аудитами і скорочує час розробки на 30%. Давайте розберемо, як це працює і як уникнути типових помилок. Ми спеціалізуємося на розробці NFT підписок і розробці NFT сервісів під ключ.

Як ERC-5643 вирішує проблему тимчасового доступу?

У 2022 році з'явився ERC-5643 — розширення ERC-721 спеціально для підписочних NFT. Стандарт додає два ключові методи:

interface IERC5643 {
    event SubscriptionUpdate(uint256 indexed tokenId, uint64 expiration);

    function renewSubscription(uint256 tokenId, uint64 duration) external payable;
    function cancelSubscription(uint256 tokenId) external payable;
    function expiresAt(uint256 tokenId) external view returns (uint64);
    function isRenewable(uint256 tokenId) external view returns (bool);
}

expiresAt повертає unix timestamp закінчення підписки для конкретного токена. Зберігання — mapping(uint256 => uint64). uint64 достатньо для часових міток на тисячі років вперед і займає один storage slot разом з іншими packed змінними.

Критична деталь: expiresAt — це view функція, вона не блокує transfer. Якщо на рівні контракту потрібно запобігти передачі простроченого токена, потрібно перевизначити _beforeTokenTransfer в OpenZeppelin ERC-721:

function _beforeTokenTransfer(
    address from,
    address to,
    uint256 tokenId,
    uint256 batchSize
) internal virtual override {
    super._beforeTokenTransfer(from, to, tokenId, batchSize);
    if (from != address(0) && to != address(0)) {
        require(
            block.timestamp < _expirations[tokenId],
            "Subscription expired"
        );
    }
}

Альтернатива: дозволити transfer прострочених токенів, але не давати доступ. Це залежить від бізнес-моделі — іноді корисно передати токен і відновити підписку вже новому власнику.

Off-chain перевірка доступу

On-chain стан — джерело істини. Але викликати expiresAt при кожному HTTP-запиті — повільно. Стандартна архітектура:

Backend middleware для NFT підписки читає стан контракту через multicall при першому зверненні, кешує результат у Redis з TTL, що дорівнює терміну закінчення підписки. При спробі доступу до захищеного ресурсу:

1. Користувач підписує повідомлення (EIP-4361 Sign-In With Ethereum) — це забезпечує NFT авторизацію.
2. Backend верифікує підпис, витягує адресу гаманця
3. Перевіряє кеш Redis → якщо промах, запитує контракт
4. Якщо expiresAt(tokenId) > block.timestamp — видає JWT з expiry = min(subscription_expiry, JWT_max_age)

JWT інвалідується сам по собі, коли закінчується. Немає потреби тримати blacklist, якщо JWT TTL вирівняний за терміном підписки. Така система доступу на блокчейні забезпечує децентралізацію та прозорість.

Продовження та оплата

renewSubscription приймає duration у секундах та ETH/токен для оплати. Подовження NFT підписки має додавати до поточного терміну, а не до block.timestamp:

function renewSubscription(uint256 tokenId, uint64 duration) external payable {
    require(ownerOf(tokenId) == msg.sender, "Not owner");
    require(msg.value >= _price * duration / 30 days, "Insufficient payment");

    uint64 current = _expirations[tokenId];
    // Якщо підписка вже прострочена — продовжуємо від поточного моменту
    // Якщо ще активна — додаємо до існуючого терміну
    uint64 newExpiry = (current < uint64(block.timestamp))
        ? uint64(block.timestamp) + duration
        : current + duration;

    _expirations[tokenId] = newExpiry;
    emit SubscriptionUpdate(tokenId, newExpiry);
}

Це принципово для користувача: якщо він продовжує активну підписку на місяць, він не втрачає дні, що залишилися.

Чому Soulbound (ERC-5192) не завжди підходить?

Вибір між non-transferable (ERC-5192, Soulbound) та transferable доступом — архітектурний, не технічний. Soulbound зручний для персоналізованих підписок (курси, ліцензії на конкретну особу). Transferable — для корпоративних ліцензій або коли перепродаж доступу є частиною моделі. ERC-5192 реалізується просто: locked() повертає true, всі transfer функції revert. Однак для тимчасового доступу часто потрібна можливість продовження, що простіше реалізувати на ERC-5643. NFT доступ до контенту при цьому залишається гнучким залежно від бізнес-моделі.

Стек та інтеграція

Solidity 0.8.20+ з Foundry. ERC-5643 + ERC-5192 (опціонально). Off-chain: Node.js/TypeScript, viem для читання контракту, Redis для кешу доступу, JWT (jose) для сесій. Frontend: wagmi + RainbowKit для wallet connection, react-query для стану підписки.

Для оплати в ERC-20 (USDC/DAI) додається Permit2 — користувач підписує approval та виклик renewSubscription в одній операції, без попереднього approve. ERC-5643 краще кастомного рішення в 2 рази за швидкістю розробки та в 1.5 рази за газовою ефективністю.

Що входить у розробку системи тимчасового доступу через NFT

• Аудит вимог та проєктування архітектури (on-chain + off-chain)
• Розробка смарт-контракту на Solidity з підтримкою ERC-5643 (або кастомної логіки)
• Розробка backend middleware для перевірки підписок (Node.js + Redis)
• Інтеграція з гаманцями (wagmi + RainbowKit)
• Написання документації та тестів (unit + integration)
• Розгортання та підтримка (1 місяць супроводу)

Орієнтири за термінами

Базовий контракт з ERC-5643 + backend middleware перевірки доступу + frontend компонент управління підпискою — 3-4 дні. З Permit2 оплатою, мультирівневим доступом (декілька тарифів) та аналітикою продовжень — 5-7 днів.

Як ми працюємо

Наша команда має 8+ років досвіду в блокчейн-розробці, випустила 50+ смарт-контрактів у mainnet, сумарно проаудована на $5M+ TVL. Ми підходимо до кожного проєкту з урахуванням ваших бізнес-завдань і пропонуємо рішення під ключ із гарантією якості та сертифікованими аудитами.

Зв'яжіться з нами для обговорення вашого завдання — ми запропонуємо оптимальне рішення під ваш бюджет і терміни. Пишіть у Telegram або на пошту, отримайте безкоштовну оцінку проєкту.

Чому розробка 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-проекту. Отримайте консультацію з архітектури маркетплейсу — залиште заявку, і ми оцінимо проект за три дні.