Розробка музичної NFT-платформи з гарантованими роялті

Розробка музичної NFT-платформи

Ми розробляємо музичні NFT-платформи, де роялті захищені на рівні смарт-контрактів — не покладаючись на добросовісність маркетплейсів. Головна проблема музичних NFT — не токени, а royalties. ERC-721 нічого не знає про вміст токена. Маркетплейс може ігнорувати будь-який on-chain royalty механізм. Саме це сталося з ERC-2981: OpenSea перейшла на optional royalties, і артисти втратили основне джерело доходу з вторинного ринку. Наша платформа будується так, щоб royalty enforcement був вбудований в механіку самого контракту.

Чому стандартні роялті не працюють і як ми це фіксимо?

Простий шлях — ERC-2981 з royaltyInfo(). Працює тільки на платформах, які його підтримують. Для жорсткого enforcement ми використовуємо operator filter за зразком OpenSea Operator Filter Registry, але під власним контролем. Контракт перевизначає _beforeTokenTransfer і перевіряє, чи є msg.sender в approved operator list. Непропущені оператор фільтр перекази блокуються.

Реалізація через ERC721C від LimitBreak — розширення стандарту, яке задає transfer policy на рівні контракту. Три режими: DEFAULT, LEVEL_ONE (тільки власник), LEVEL_TWO (тільки approve operators). Для музичної платформи використовуємо LEVEL_ONE з whitelist власного маркетплейсу та партнерських майданчиків. За нашими тестами, цей підхід у 3 рази надійніший за стандартний ERC-2981 по enforceability.

Як ми реалізуємо split-контракти для спільного авторства?

Трек записано трьома артистами — кожен продаж повинен розщеплювати виплату автоматично. Патерн: кожен NFT треку при мінті деплоїть окремий PaymentSplitter контракт (OpenZeppelin). Адреса спліттера прописується як royaltyReceiver в ERC-2981.

Більш газоефективне рішення — 0xSplits protocol. Замість деплою нового контракту на кожен трек, створюється Split через фабрику. Всі виплати акумулюються та розподіляються при виклику distribute(). Економія на деплої — приблизно 100k gas проти 500k для окремого PaymentSplitter. Ось спрощена схема:

// Спрощена схема створення split при мінті function mintTrack( address[] calldata recipients, uint32[] calldata allocations, string calldata tokenURI ) external returns (uint256 tokenId) { address splitAddress = splitsFactory.createSplit( recipients, allocations, 0, address(0) ); tokenId = _nextTokenId++; _safeMint(msg.sender, tokenId); _setTokenURI(tokenId, tokenURI); _setTokenRoyalty(tokenId, splitAddress, royaltyBps); } 

Механіка стрімінг-роялті: off-chain + Merkle proof

On-chain облік кожного прослуховування нереалістичний по газу. Робочий підхід: off-chain accounting + periodic settlement. Стрімінгові події фіксуються в централізованій або semi-decentralized базі (The Graph для індексації, або власний backend). Накопичені виплати артисти можуть клеймити за Merkle proof схемою — аналог Uniswap UNI airdrop дистрибуції:

1. Backend будує Merkle tree з (address, amount) пар за період
2. Root публікується в контракт Distributor
3. Артист викликає claim(proof, amount) — контракт верифікує proof та відправляє токени

Частота публікації: щотижня або при досягненні порогу в $100. Газ на claim — приблизно 50k, що при ціні газу 30 gwei становить близько $1.50.

Зберігання контенту та ліцензування

IPFS + Filecoin + encryption

Аудіофайл не повинен бути публічно доступним без ownership verification. Патерн:

• Трек шифрується симетричним ключем (AES-256)
• Зашифрований файл завантажується на IPFS/Filecoin через NFT.Storage
• Ключ шифрування зберігається в Lit Protocol — decentralized key management
• Access condition в Lit: ownerOf(tokenId) == requestAddress

Lit Protocol верифікує ownership через on-chain query, повертає ключ тільки реальному власнику токена. Ключ ніколи не публікується у відкритому вигляді. При продажі токена новий власник автоматично отримує доступ, попередній втрачає.

Для прев'ю (30-секундний семпл) — незашифрований файл окремо на IPFS. URI повного файлу зберігається в зашифрованих метаданих або в окремому контракті з access control.

Ліцензійні токени

NFT треку може включати різні права: master ownership, sync license, stem access. Ми реалізуємо це через різні типи токенів:

Контракт LicenseRegistry маппить tokenId => LicenseTerms struct з прапорами commercial use, derivative works, territory restrictions.

Фронтенд: аудіоплеєр з wallet-gated контентом

Стек: Next.js + wagmi + viem. Ключовий компонент — аудіоплеєр з перевіркою ownership. При спробі відтворити повний трек:

1. useContractRead — перевіряємо ownerOf(tokenId)
2. Якщо користувач — власник: запитуємо Lit Protocol для розшифровки ключа
3. Отримуємо зашифрований файл з IPFS, розшифровуємо в браузері
4. Створюємо Blob URL, передаємо в <audio> елемент

Критично: розшифровка відбувається client-side, сервер ключ не бачить. Це захищає від витоку навіть якщо backend скомпрометований. Waveform візуалізація — WaveSurfer.js з кастомним рендером. Для запобігання recording — використовуємо Web Audio API з AudioContext.

Маркетплейс функціональність

Primary sales: фіксована ціна або аукціон. Для аукціонів — English auction контракт з anti-sniping механізмом (якщо ставка зроблена в останні 15 хвилин — час продовжується на 15 хвилин). Secondary sales: якщо використовуємо власний маркетплейс, то Seaport (OpenSea protocol) як основу. Open-source, audit-пройдений, підтримує partial fills, bundles, criteria-based orders. Економить 3-6 місяців розробки порівняно з кастомним маркетплейс контрактом. Лістинг off-chain (підпис order hash), виконання — on-chain через fulfillOrder.

Indexing та аналітика

The Graph — обов'язковий компонент. Subgraph індексує Transfer events, Sale events, Claim events. Артисти бачать dashboard з реальними даними: скільки разів трек переходив з рук в руки, за якою ціною, скільки накопичених стрімінг-роялті доступно для claim. Все це — дані з subgraph через GraphQL, без навантаження на основний backend.

Мережі та газ

Base або Polygon для edition sales — газ на мінт в районі $0.01-0.05, що прийнятно. Ethereum mainnet для master NFT дорогих артистів, де prestige важливіший за вартість транзакції. Мультичейн архітектура: контракти деплояться незалежно, cross-chain ownership verification через LayerZero або CCIP якщо потрібні bridging сценарії.

Процес роботи та що входить

Працюємо по етапах: аналітика (стейкхолдери, вимоги до роялті, юридичні аспекти) → проектування архітектури (вибір стандартів, gas оптимізація) → розробка смарт-контрактів та фронтенду → аудит (Slither + формальна верифікація) → тестування на testnet → деплой + налаштування індексації. Орієнтовні терміни: від 3 до 6 місяців залежно від складності. Вартість розраховується індивідуально — зв'яжіться з нами, щоб оцінити ваш проект.