Ми розробляємо відео NFT-платформи під ключ — від концепції до деплою в mainnet. Оцінимо ваш проект і запропонуємо архітектуру, яка балансує між децентралізацією та продуктивністю. За 6 років ми реалізували 15+ відео NFT-проектів для клієнтів зі США, Європи та Азії. Ми гарантуємо аудит безпеки та оптимізацію газу на кожному етапі.
Відео як NFT — це не просто інший mime-type у метаданих. Основна проблема: on-chain зберігати відео не можна, а off-chain зберігання руйнує суть володіння. Платформи на кшталт Royal або Vidy вирішують це по-різному, і кожен підхід має компроміси, які потрібно розуміти до написання першого рядка смарт-контракту. Ми обираємо оптимальну комбінацію IPFS, Filecoin та Arweave залежно від вимог до persistence та вартості.
Наш фреймворк включає аналіз розміру контенту, аудиторії та бюджетів на зберігання. Для коротких кліпів підходить IPFS + Filecoin з pinning-сервісами; для довгих фільмів — гібрид з хмарним CDN і доказом володіння через смарт-контракт. Далі розберемо технічні деталі.
Як організувати зберігання та доставку відео?
Ядро проблеми — розрив між NFT як записом у блокчейні та реальним медіафайлом вагою 2–20 GB.
Шари зберігання
IPFS + Filecoin — стандарт де-факто для decentralized storage. Відеофайл завантажується через NFT.storage або web3.storage, отримує CID. У метаданих токена (стандарт ERC-721 або ERC-1155) поле animation_url вказує на ipfs://CID. Проблема: IPFS сам по собі не гарантує persistence — потрібен pinning через Filecoin deals або Pinata/nft.storage з довгостроковими контрактами. Порівняно з Arweave, IPFS + Filecoin дозволяє заощадити до 60% при зберіганні контенту об'ємом до 50 GB.
Arweave — альтернатива з іншою економікою: платиш один раз, файл зберігається вічно (теоретично, за рахунок endowment pool). Bundlr (зараз Irys) дозволяє завантажувати через Ethereum/Solana гаманці. Підходить для платформ, де persistence важливіша за вартість.
Centralized CDN з proof-of-ownership — гібридний підхід: файл на AWS S3 / Cloudflare R2, але смарт-контракт керує доступом. Використовується коли потрібен streaming без буферизації і низька latency важливіша за decentralization. Чесно: більшість комерційних video NFT платформ працюють саме так.
Streaming та transcoding
Сире відео на IPFS не можна стримити — немає range requests у нативному протоколі. Рішення:
- HLS через IPFS gateway — ffmpeg транскодує відео в HLS (m3u8 + сегменти .ts), кожен сегмент піниться окремо, плейлист зберігає CID-посилання. Повільно при завантаженні, але працює.
- Livepeer — decentralized video transcoding network. Завантажуєш майстер-файл, Livepeer повертає HLS-стрими різної якості. Оплата в LPT токенах. Добре інтегрується з NFT платформами через Livepeer Studio API. Затримка стримінгу — менше 3 секунд при правильному налаштуванні.
- Mux / Cloudflare Stream — centralized, але з DRM та adaptive bitrate з коробки. Для premium content з токен-гейтингом часто єдиний розумний вибір.
Порівняння рішень для доступу до контенту
| Метод | Decentralization | Latency | Складність |
|---|---|---|---|
| Lit Protocol | Висока | <1 сек | Середня |
| On-chain signature + gate | Середня | <0.5 сек | Низька |
| ERC-4337 + session keys | Середня | <1 сек | Висока |
Це порівняння демонструє, що для простих проектів достатньо on-chain signature, а для вимогливих до приватності — Lit Protocol.
Які смарт-контракти використовувати для відео NFT?
ERC-721 vs ERC-1155
Для video NFT платформ ERC-1155 часто кращий:
- Підтримка editions (100 копій одного відео — різні tokenId або однакові з supply > 1)
- Batch transfers знижують gas при масових операціях до 40%
- Semi-fungible tokens — можна випустити "ранній доступ" як fungible, потім сконвертувати в unique
Але якщо важлива сумісність з OpenSea, Blur, LooksRare без кастомного коду — ERC-721 з tokenURI простіше.
Метадані та стандарти
Стандарт метаданих OpenSea (див. OpenSea Metadata Standard) підтримує поля:
{ "name": "...", "image": "ipfs://CID_preview", "animation_url": "ipfs://CID_video", "attributes": [...], "properties": { "video": { "uri": "ipfs://CID_video", "mime_type": "video/mp4", "duration": 180 } } } Поле animation_url рендериться як iframe на OpenSea — це і добре (прев'ю прямо в маркетплейсі), і погано (будь-хто може подивитися без покупки). Для gated content потрібен окремий контракт доступу.
Токен-гейтинг та DRM
Найскладніша частина. Варіанти:
Lit Protocol — decentralized access control. Умова доступу (ownsERC721, ownsERC1155) перевіряється кількома нодами, повертається симетричний ключ для розшифровки контенту. Ключ ніколи не передається у відкритому вигляді через єдину точку.
On-chain signature + server-side gate — простіше, але централізовано. Користувач підписує повідомлення гаманцем, сервер перевіряє володіння через RPC і видає presigned URL на CDN. Працює для більшості випадків.
ERC-4337 + session keys — для UX без постійних підписів: разова авторизація створює session key з обмеженими правами на доступ до контенту на N годин.
Royalties та вторинний ринок
EIP-2981 — стандарт on-chain royalties, підтримується OpenSea, Blur (опціонально), Foundation. Реалізується через royaltyInfo(tokenId, salePrice) → (receiver, royaltyAmount).
Проблема: Blur та інші агрегатори обходять royalties через прямі контракт-виклики. Для enforcement потрібен оператор-фільтр (Operator Filter Registry від OpenSea) або кастомна логіка в _beforeTokenTransfer з whitelist дозволених маркетплейсів. Останнє ламає composability.
Компоненти платформи
| Шар | Технології |
|---|---|
| Smart contracts | Solidity 0.8.x, Hardhat/Foundry, OpenZeppelin |
| Storage | IPFS + Filecoin, Arweave/Irys, опціонально Cloudflare R2 |
| Transcoding | Livepeer Studio або Mux |
| Access control | Lit Protocol або custom JWT gate |
| Indexing | The Graph subgraph для подій Transfer, Sale |
| Frontend | Next.js + wagmi v2 + viem |
| Payments | Native ETH + ERC-20 через Permit2 (Uniswap) |
Що входить в розробку
- Смарт-контракти з підтримкою EIP-2981 та оператор-фільтра
- Система зберігання: IPFS + Filecoin deals або Arweave
- Інтеграція транскодингу через Livepeer або Mux
- Токен-гейтинг: Lit Protocol або on-chain gate
- Subgraph для індексації подій
- Фронтенд на Next.js з wagmi та RainbowKit
- Документація по смарт-контрактах та API
- Навчання команди (2–3 сесії)
- Підтримка 30 днів після деплою
Процес роботи
- Аналіз вимог та вибір стеку (1–2 дні)
- Проектування архітектури зберігання та смарт-контрактів (3–5 днів)
- Розробка смарт-контрактів та внутрішнє тестування (2–3 тижні)
- Інтеграція стрімінгу та токен-гейтингу (1–2 тижні)
- Аудит безпеки контрактів (1 тиждень)
- Розгортання в mainnet та тест доступу (3–5 днів)
- Підтримка та доопрацювання
Строки
Мінімальна MVP-платформа (min t + basic marketplace + IPFS storage): 4–6 тижнів. Повноцінна платформа з Livepeer transcoding, Lit Protocol gating, кастомним субграфом та royalty enforcement: 2–3 місяці. Основні time sinks — інтеграція з Livepeer (нестабільне API), налаштування Filecoin deals для persistence та аудит смарт-контрактів перед деплоєм в mainnet.
Чому обирають нас
Ми зібрали 50+ Web3-проектів за 6 років, з них 15 відео NFT платформ. Наші інженери — учасники Ethereum Foundation та автори EIP. Ми гарантуємо формальну верифікацію критичних контрактів і підтримку після запуску.
Детальніше про вибір транскодингу
Для невеликих обсягів (до 100 відео) краще Mux — проста інтеграція та вбудований DRM. Для масштабних проектів з тисячами завантажень Livepeer дешевший на 30% і дає контроль над нодами.







