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

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

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

Архітектура смарт-контрактів

Royalty enforcement через operator filter

Простий путь — 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 власного маркетплейса та партнерських площадок.

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);
}

Механіка стриміння роялті

Це складніше завдання. On-chain облік кожного прослухування — нереалістичний по газу. Робочий підхід: off-chain облік + періодичне 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 та надсилає токени

Частота публікації: щотижня або при досягненні порогу. Газ на claim — приблизно 50k, що прийнятно.

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

IPFS + Filecoin + шифрування

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

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

Lit Protocol верифікує власництво через 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.

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

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

При спробі відтворення повного треку:

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

Критично: розшифровка відбувається client-side, сервер ключ не видит. Це захищає від утечки навіть якщо backend скомпрометирован.

Waveform візуалізація — WaveSurfer.js з кастомним рендером. Для запобігання запису — не використовуємо стандартний <audio>, а Web Audio API з AudioContext. Повністю зупинити запис екрану неможливо, але піднімаємо поріг.

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

Primary sales: фіксована ціна або аукціон. Для аукціонів — English auction контракт з anti-sniping механізмом (якщо ставка у останні 15 хвилин — час продовжується на 15 хвилин). Це стандартна практика, запобігає last-second bid griefing.

Secondary sales: якщо використовуємо власний маркетплейс, то Seaport (OpenSea protocol) як основу. Open-source, audit-пройдений, підтримує partial fills, bundles, criteria-based orders. Економить 3-6 місяців розробки порівняно з кастомним маркетплейс контрактом.

Листинг off-chain (підпись order hash), виконання — on-chain через fulfillOrder. Signature expiry вбудований в order struct.

Індексація та аналітика

The Graph — обов'язковий компонент для продуктивності. Subgraph індексує:

• Transfer события → історія володіння
• Sale события → цінова історія
• Claim события → royalty аналітика для артистів

Артисти бачать dashboard з реальними даними: скільки разів трек переходив з рук в руки, за якою ціною, скільки накопленных стриміння-роялті доступно для claim. Все це — дані з subgraph через GraphQL, без нагрузки на основний backend.

Мережі та газ

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