We develop NFT-based video platforms end-to-end — from concept to mainnet deployment. We'll assess your project and propose an architecture that balances decentralization and performance. Building an NFT platform for video requires expertise in blockchain, storage, and streaming. Over 6 years, we've delivered 15+ projects for clients from the US, Europe, and Asia. We guarantee security audits and gas optimization at every stage.
Video as an NFT is not just another mime-type in metadata. The core problem: storing video on-chain is impossible, and off-chain storage breaks the notion of ownership. Platforms like Royal or Vidy solve this differently, and each approach has trade-offs that must be understood before writing the first line of a blockchain contract. We choose the optimal combination of IPFS, Filecoin, and Arweave based on persistence requirements and cost.
Our framework includes analysis of content size, audience, and storage budgets. For short clips, IPFS + Filecoin with pinning services fits; for long films, a hybrid with cloud CDN and proof of ownership via a smart contract works. For example, storing a 1GB video on IPFS with Filecoin deals costs about $0.12 per year, while Arweave is $0.20 once. Development costs for an MVP start at $5,000, and a full platform can range from $15,000 to $30,000. Below, we dive into the technical details.
Organize video storage and delivery
The core problem is the gap between the NFT as a blockchain record and the actual media file weighing 2–20 GB.
Storage layers
IPFS + Filecoin — the de facto standard for distributed file storage. The video file is uploaded via NFT.storage or web3.storage, obtaining a CID. In the token metadata (ERC-721 or ERC-1155 standard), the animation_url field points to ipfs://CID. The issue: IPFS itself doesn't guarantee persistence — pinning is needed via Filecoin deals or Pinata/nft.storage with long-term contracts. For volumes under 50 GB, IPFS + Filecoin is up to 2.5 times more cost-effective than Arweave.
Arweave — an alternative with a different economy: you pay once, the file is stored forever (theoretically, via an endowment pool). Bundlr (now Irys) allows uploads through Ethereum/Solana wallets. Suitable for platforms where persistence matters more than cost.
Centralized CDN with proof-of-ownership — a hybrid approach: the file on AWS S3 / Cloudflare R2, but the smart contract controls access. Used when streaming without buffering is needed and low latency is more important than decentralization. Most commercial video NFT platforms work this way.
Streaming and transcoding
Raw video on IPFS cannot be streamed — no range requests in the native protocol. Solutions:
- HLS via IPFS gateway — ffmpeg transcodes video to HLS (m3u8 + .ts segments), each segment is pinned separately, the playlist stores CID links. Slow on upload, but works.
- Livepeer — decentralized video transcoding network. Upload the master file, Livepeer returns HLS streams of different quality. Payment in LPT tokens. Integrates well with NFT platforms via the Livepeer Studio API. Streaming latency is under 3 seconds with proper configuration.
- Mux / Cloudflare Stream — centralized, but with DRM and adaptive bitrate out of the box. Often the only reasonable choice for premium content with token-gated access.
Comparison of access solutions
| Method | Decentralization | Latency | Complexity |
|---|---|---|---|
| Lit Protocol | High | <1 sec | Medium |
| On-chain signature + gate | Medium | <0.5 sec | Low |
| ERC-4337 + session keys | Medium | <1 sec | High |
This comparison shows that for simple projects on-chain signature suffices, while for privacy-sensitive ones Lit Protocol is better.
Which smart contracts to use for video NFTs?
ERC-721 vs ERC-1155
For video NFT platforms, ERC-1155 is often preferable:
- Support for editions (100 copies of the same video — different tokenIds or same with supply > 1)
- Batch transfers reduce gas for mass operations by up to 40% compared to ERC-721
- Semi-fungible tokens — you can issue "early access" as fungible, then convert to unique
But if compatibility with OpenSea, Blur, LooksRare without custom code is important, ERC-721 with tokenURI is simpler.
Metadata standards
The OpenSea Metadata Standard supports fields:
{ "name": "...", "image": "ipfs://CID_preview", "animation_url": "ipfs://CID_video", "attributes": [...], "properties": { "video": { "uri": "ipfs://CID_video", "mime_type": "video/mp4", "duration": 180 } } } The animation_url field renders as an iframe on OpenSea — this is both good (preview right in the marketplace) and bad (anyone can view without purchase). For gated content, a separate access contract is needed.
Token gating and DRM
The trickiest part. Options:
Lit Protocol — decentralized access control. The access condition (ownsERC721, ownsERC1155) is checked by multiple nodes, a symmetric key is returned to decrypt the content. The key is never transmitted in the open through a single point.
On-chain signature + server-side gate — simpler but centralized. The user signs a message with their wallet, the server checks ownership via RPC and issues a presigned URL to the CDN. Works for most cases.
ERC-4337 + session keys — for UX without constant signatures: one-time authorization creates a session key with limited rights to access content for N hours.
Royalties and secondary market
EIP-2981 — the on-chain royalty standard, supported by OpenSea, Blur (optional), Foundation. Implemented via royaltyInfo(tokenId, salePrice) returning (receiver, royaltyAmount).
Problem: Blur and other aggregators bypass royalties through direct contract calls. Enforcement requires an operator filter (OpenSea's Operator Filter Registry) or custom logic in _beforeTokenTransfer with a whitelist of allowed marketplaces. The latter breaks composability.
Platform components
| Layer | Technologies |
|---|---|
| Smart contracts | Solidity 0.8.x, Hardhat/Foundry, OpenZeppelin |
| Storage | IPFS + Filecoin, Arweave/Irys, optionally Cloudflare R2 |
| Transcoding | Livepeer Studio or Mux (Livepeer is 1.4 times more affordable for large scale) |
| Access control | Lit Protocol or custom JWT gate |
| Indexing | The Graph subgraph for Transfer, Sale events |
| Frontend | Next.js + wagmi v2 + viem |
| Payments | Native ETH + ERC-20 via Permit2 (Uniswap) |
What's included in development
- Smart contracts with EIP-2981 and operator filter support
- Storage system: IPFS + Filecoin deals or Arweave
- Transcoding integration via Livepeer or Mux
- Token gating: Lit Protocol or on-chain gate
- Subgraph for event indexing
- Frontend on Next.js with wagmi and RainbowKit
- Documentation for smart contracts and API
- Team training (2–3 sessions)
- 30-day support after deployment
Process
- Requirements analysis and stack selection (1–2 days)
- Architecture design for storage and smart contracts (3–5 days)
- Smart contract development and internal testing (2–3 weeks)
- Streaming and token gating integration (1–2 weeks)
- Security audit of contracts (1 week)
- Mainnet deployment and access testing (3–5 days)
- Support and refinements
Timelines
Minimum MVP platform (mint + basic marketplace + IPFS storage): 4–6 weeks. Full platform with Livepeer transcoding, Lit Protocol gating, custom subgraph, and royalty enforcement: 2–3 months. Main time sinks: integration with Livepeer (unstable API), setting up Filecoin deals for persistence, and smart contract audit before mainnet deployment.
Why choose us
We've built 50+ Web3 projects over 6 years, including 15 video NFT platforms. Our engineers are participants in the Ethereum Foundation and authors of EIPs. We guarantee formal verification of critical contracts and post-launch support.
More on choosing transcoding
For small volumes (up to 100 videos), Mux is better — simple integration and built-in DRM. For large-scale projects with thousands of uploads, Livepeer is 1.4 times more affordable and gives control over nodes.