Розробка системи монетизації контенту через NFT

Розробка системи монетизації контенту через NFT

Стандартний підхід «завантажи контент на IPFS, поклади CID в NFT» розв'язує задачу володення, але не монетизації. Публічний CID на IPFS доступний усім без обмежень — достатньо знати хеш. Система монетизації потребує контролю доступу до самого контенту, а не просто володіння токеном. Це інша інфраструктурна задача.

Контроль доступу до зашифрованого контенту

Token-gating через шифрування

Принцип: контент шифрується перед завантаженням, ключ дешифрування видається тільки власнику NFT. Літеральна реалізація:

1. Контент шифруються симетричним ключем (AES-256-GCM) на стороні創атора.
2. Зашифрований контент завантажується на IPFS/Arweave — хеш публічний, але дані нечитабельні без ключа.
3. Симетричний ключ шифруються через Lit Protocol (threshold encryption) з умовою: розшифрувати може тільки кошелек, що тримає NFT з tokenId X на контракті Y.
4. При запиті доступу Lit Network перевіряє on-chain умову через eth_call, видає ключ.

// Умова доступу для Lit Protocol
const accessControlConditions = [
  {
    contractAddress: NFT_CONTRACT_ADDRESS,
    standardContractType: 'ERC721',
    chain: 'ethereum',
    method: 'ownerOf',
    parameters: [tokenId.toString()],
    returnValueTest: {
      comparator: '=',
      value: ':userAddress'  // динамічно підставляється адреса запрошуючого
    }
  }
];

Lit Protocol підтримує складні умови: AND/OR комбінації, перевірку ERC-1155 balance, стейкінг у протоколах. Можна задати умову «тримаєш мінімум 1 токен з колекції АБО застейкав 100 токенів».

Альтернатива: Unlock Protocol

Для підписочної монетизації (доступ не до конкретного токена, а до потоку контенту) Unlock Protocol надає готову інфраструктуру. Lock — смарт-контракт, який визначає умови доступу: ціна, тривалість, максимальна кількість ключів. Key — це NFT, який дає доступ на період.

Unlock підходить для newsletter-монетизації, платного відео-контенту, premium API доступу. Lit Protocol — для NFT-привязаного контенту та разових покупок.

Royalty механізм: EIP-2981 та його обмеження

EIP-2981 додає royaltyInfo(tokenId, salePrice) → (receiver, royaltyAmount). Маркетплейси повинні виплачувати royalty при кожній продажі. Ключове слово «повинні» — це не примушується на рівні EVM.

OpenSea, Blur, LooksRare мали різні політики по royalty у 2022-2023. Blur ввів опціональні royalty, що срізав доходи авторів. У відповідь з'явились підходи з примусовими royalty на рівні контракту:

Operator Filter (застарілий підхід). Контракт блокує transfer через неодобрені маркетплейси. OpenSea внутрів цей паттерн, але він централізований (список операторів зберігався у OpenSea) та був в итозі deprecated.

Transfer Hook з royalty enforcement. Переопределення _update (OpenZeppelin 5.x) або _beforeTokenTransfer так, щоб кожен transfer через approved operator потребував підтвердження royalty виплати. Проблема: ломає composability, DeFi протоколи не можуть працювати з такими токенами.

Реальний висновок: примусові royalty на рівні контракту конфліктують з composability. Для creator economy краще комбінувати EIP-2981 (soft enforcement через маркетплейси) з protocol-level монетизацією через primary sales та Lit-gated контент.

Splits: розподіл доходу між творцями

Для колаборацій та creator DAO — 0xSplits (splits.org). Контракт Split зберігає список одержувачів з долями. Royalty receiver в EIP-2981 встановлюється як адреса Split контракту.

// У NFT контракті
function royaltyInfo(uint256, uint256 salePrice)
    external view returns (address receiver, uint256 royaltyAmount)
{
    // Адреса 0xSplits контракту як одержувач
    return (SPLITS_CONTRACT, (salePrice * ROYALTY_BPS) / 10000);
}

0xSplits працює через push модель: грошi накопичуються в Split контракті, будь-хто може викликати distribute() для розподілу. Gas оплачує той, хто викликає distribute (зазвичай один з одержувачів). Підтримує ETH та будь-які ERC-20 токени, включаючи USDC.

Первинні продажі та механіки дистрибуції

Tiered pricing

Різні рівні доступу через різні токени:

ERC-1155 зручен для кількох тіро: один контракт, різні tokenId для різних рівнів. balanceOf(user, PREMIUM_TOKEN_ID) > 0 — проста умова для Lit Protocol.

Bonding curve для контенту

Для контенту, де цінність зростає з аудиторією — bonding curve ціноутворення. Friend.tech спопуляризував це у 2023. Ціна токена зростає по квадратичній кривій при кожній покупці. Ранні supporters купують дешево, пізні — дороже. Творець отримує комісію з кожної угоди.

Для creator economy це створює alignment: творець зацікавлений у зростанні аудиторії, аудиторія — у успіху творця. Реалізація через окремий Factory контракт, який деплоїть bonding curve контракт для кожного творця.

Стек та деплой

Solidity 0.8.20 + Foundry. ERC-721/ERC-1155 + EIP-2981. Lit Protocol JS SDK для шифрування/дешифрування. 0xSplits контракти для розподілу royalty. Frontend: Next.js + wagmi + viem + Lit SDK. Сховище: IPFS (Pinata) для зашифрованого контенту + Arweave для постійного зберігання архіву.

Деплой: Base або Polygon для низького gas при мінтингу масового контенту. Для premium контенту та високих royalty — Ethereum mainnet.

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

NFT-gated контент з Lit Protocol шифруванням та EIP-2981 royalty — 1 тиждень. З tiered access (ERC-1155), 0xSplits для royalty splits, bonding curve ціноутворенням та аналітикою первинних/вторинних продаж — 2-3 тижні.