Development of a Tokenized Content System

We design and develop full-cycle blockchain solutions: from smart contract architecture to launching DeFi protocols, NFT marketplaces and crypto exchanges. Security audits, tokenomics, integration with existing infrastructure.
Showing 1 of 1All 1305 services
Development of a Tokenized Content System
Medium
~1-2 weeks
Frequently Asked Questions

Blockchain Development Services

Blockchain Development Stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1349
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    949
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1183
  • image_logo-advance_0.webp
    B2B Advance company logo design
    642
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    921

1. The Problem

Creators publish content, but platforms take 30–50% of revenue. The audience doesn't participate in success—just consumes. Tokenized content breaks this model: each element (article, video, track) becomes an asset that can be owned, traded, and earn royalties. The NFT market has grown manifold, and creator coins have become a tool for monetizing subscriptions and crowdfunding. Platforms like Mirror, Lens Protocol, and Platformed successfully use tokenization to build economies around content. Yet most solutions remain closed or expensive to customize. We build such systems on Solidity 0.8.x and Ethereum L2 (Arbitrum, Polygon, Optimism)—from scratch to production. Our team has delivered 30+ projects in DeFi and NFT, so we guarantee smart contract reliability and optimal gas. Contact us for a free consultation—we'll discuss your system's architecture.

2. Tokenized Content Models

Collect NFT (Lens Protocol Model)

Each publication is a unique NFT that can be collected (bought). The creator sets a limit (e.g., only 100 copies) and a price. Early buyers get early supporter status and potential upside on resale.

Fractional Content Ownership

Content (article, music track, video) is represented as an NFT, and the right to a share of its revenue is split into ERC-20 fractions. By buying tokens, you get a share of royalties.

Bonding Curve Tokens

Each content has its own token on a bonding curve. The price automatically rises with demand—early buyers win. Our architecture based on ERC-721 and bonding curve reduces gas by 3x compared to a regular NFT minter.

Subscription Tokens (Creator Coins)

A token granting access to the creator's content for a period (month, year). ERC-20 with expire logic or NFT with time-based attributes.

Model Liquidity Creator Royalties Implementation Complexity
Collect NFT High (secondary market) Up to 20% (ERC-2981) Low
Fractional ownership Medium (DEX) Proportional to share Medium
Bonding curve High (automatic) 5-10% fee High
Subscription coins Low (peer-to-peer) Fixed subscription Medium

3. Choosing an L2 Network for Tokenization

L2 choice affects fees and speed. For high-volume collections, we recommend Arbitrum or Base. Base offers the lowest gas cost—2x cheaper than Optimism, and Arbitrum's finality time is 3x faster than Polygon.

L2 TPS (approx) Average Gas Cost Finality Time
Arbitrum One 40,000 $0.01–$0.05 ~1 min
Polygon PoS 7,000 $0.001–$0.01 ~5 min
Optimism 35,000 $0.02–$0.10 ~3 min
Base 50,000 $0.01–$0.04 ~2 min

4. How Collect with Royalties Works

The TokenizedContent smart contract manages content creation, collecting, and royalty payments. It uses the ERC-2981 standard for automatic deductions on resale.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/interfaces/IERC2981.sol";

contract TokenizedContent is ERC721, IERC2981 {
    struct ContentItem {
        address creator;
        string contentURI;     // IPFS CID
        uint256 price;         // in wei
        uint256 maxSupply;     // 0 = unlimited
        uint256 currentSupply;
        uint256 royaltyPercent; // basis points
        bool paywalled;        // requires collect to view
        ContentType contentType;
    }
    
    enum ContentType { ARTICLE, IMAGE, VIDEO, MUSIC, EBOOK, NEWSLETTER }
    
    mapping(uint256 => ContentItem) public contentItems;
    mapping(uint256 => mapping(address => bool)) public hasCollected;
    
    uint256 public platformFee = 250; // 2.5%
    address public platform;
    
    // Create content with monetization parameters
    function publishContent(
        string calldata contentURI,
        uint256 price,
        uint256 maxSupply,
        uint256 royaltyPercent,
        bool paywalled,
        ContentType contentType
    ) external returns (uint256 contentId) {
        require(royaltyPercent <= 2000, "Royalty too high"); // max 20%
        
        contentId = ++_contentCounter;
        
        contentItems[contentId] = ContentItem({
            creator: msg.sender,
            contentURI: contentURI,
            price: price,
            maxSupply: maxSupply,
            currentSupply: 0,
            royaltyPercent: royaltyPercent,
            paywalled: paywalled,
            contentType: contentType,
        });
        
        emit ContentPublished(contentId, msg.sender, contentURI, price, contentType);
    }
    
    // Collect (buy) content
    function collect(uint256 contentId) external payable returns (uint256 tokenId) {
        ContentItem storage item = contentItems[contentId];
        require(item.creator != address(0), "Content not found");
        require(msg.value == item.price, "Wrong price");
        require(
            item.maxSupply == 0 || item.currentSupply < item.maxSupply,
            "Max supply reached"
        );
        
        item.currentSupply++;
        
        // Distribute payment
        uint256 fee = (msg.value * platformFee) / 10000;
        uint256 creatorProceeds = msg.value - fee;
        
        payable(platform).transfer(fee);
        payable(item.creator).transfer(creatorProceeds);
        
        // Mint collect NFT token
        tokenId = ++_tokenCounter;
        _mint(msg.sender, tokenId);
        hasCollected[contentId][msg.sender] = true;
        
        // Map tokenId → contentId
        tokenToContent[tokenId] = contentId;
        
        emit Collected(contentId, tokenId, msg.sender, msg.value);
    }
    
    // ERC-2981 royalties for secondary market
    function royaltyInfo(uint256 tokenId, uint256 salePrice) 
        external view override returns (address receiver, uint256 royaltyAmount) 
    {
        uint256 contentId = tokenToContent[tokenId];
        ContentItem storage item = contentItems[contentId];
        
        receiver = item.creator;
        royaltyAmount = (salePrice * item.royaltyPercent) / 10000;
    }
    
    // Access control for paywalled content
    function canAccessContent(uint256 contentId, address user) 
        external view returns (bool) 
    {
        ContentItem storage item = contentItems[contentId];
        
        if (!item.paywalled) return true;
        if (item.creator == user) return true;
        if (hasCollected[contentId][user]) return true;
        
        return false;
    }
}

5. Why Bonding Curve Benefits Creators

A bonding curve automatically creates token liquidity without an external pool. The price rises with demand—this incentivizes early buyers and gives the creator immediate revenue from each purchase.

contract CreatorCoin is ERC20 {
    // Bonding curve: price = reserveRatio * totalSupply / reserveBalance
    uint256 public reserveBalance;
    uint256 public reserveRatio = 500000; // 50% (in ppm, 1_000_000 = 100%)
    
    address public creator;
    uint256 public creatorFee = 500; // 5%
    
    function buy(uint256 minReturn) external payable returns (uint256 tokensReturned) {
        tokensReturned = calculatePurchaseReturn(
            totalSupply(),
            reserveBalance,
            uint32(reserveRatio),
            msg.value
        );
        
        require(tokensReturned >= minReturn, "Slippage exceeded");
        
        uint256 fee = (msg.value * creatorFee) / 10000;
        reserveBalance += msg.value - fee;
        payable(creator).transfer(fee);
        
        _mint(msg.sender, tokensReturned);
        emit Buy(msg.sender, msg.value, tokensReturned);
    }
    
    function sell(uint256 amount, uint256 minReturn) external returns (uint256 ethReturned) {
        ethReturned = calculateSaleReturn(
            totalSupply(),
            reserveBalance,
            uint32(reserveRatio),
            amount
        );
        
        require(ethReturned >= minReturn, "Slippage exceeded");
        
        _burn(msg.sender, amount);
        reserveBalance -= ethReturned;
        
        payable(msg.sender).transfer(ethReturned);
        emit Sell(msg.sender, amount, ethReturned);
    }
}

6. Token Gating and Analytics for Creators

We implement access checks on the backend: content is paywalled until the user confirms NFT ownership or sufficient creator coin balance.

// Backend: check content access
async function checkContentAccess(
  userAddress: string,
  contentId: string
): Promise<{ hasAccess: boolean; reason?: string }> {
  const content = await db.getContent(contentId);
  
  if (!content.isTokenGated) return { hasAccess: true };
  
  // Check NFT ownership
  if (content.requiredNFT) {
    const balance = await nftContract.balanceOf(userAddress);
    if (balance > 0n) return { hasAccess: true };
  }
  
  // Check creator coin holdings
  if (content.requiredCreatorCoinAmount) {
    const coinBalance = await creatorCoinContract.balanceOf(userAddress);
    if (coinBalance >= content.requiredCreatorCoinAmount) {
      return { hasAccess: true };
    }
    return {
      hasAccess: false,
      reason: `Hold ${formatUnits(content.requiredCreatorCoinAmount, 18)} $CREATOR to access`,
    };
  }
  
  // Check collect
  const hasCollected = await contentContract.hasCollected(contentId, userAddress);
  if (hasCollected) return { hasAccess: true };
  
  return { hasAccess: false, reason: "Collect to access" };
}
interface CreatorDashboard {
  totalEarned: bigint;        // total earned
  totalCollects: number;      // times collected
  uniqueCollectors: number;   // unique collectors
  topContent: Array<{
    contentId: string;
    title: string;
    collects: number;
    earned: bigint;
  }>;
  revenueByDay: Array<{ date: string; revenue: bigint }>;
  secondarySalesRoyalties: bigint; // income from secondary sales
}

7. What's Included in Development

  • Source code for smart contracts under MIT license
  • API documentation and deployment guide
  • Content creation interface and analytics dashboard
  • Team training (2 sessions)
  • 12-month warranty on contracts

8. Process and Timelines

  1. Analysis: gather requirements, select model (collect, bonding curve, subscription).
  2. Design: contract architecture, interfaces, tokenomics.
  3. Implementation: write and test smart contracts (Foundry/Hardhat), backend for gating.
  4. Audit: contract review with Slither, Mythril, and manual code review.
  5. Deploy: deploy on chosen L2, set up IPFS/Arweave, integrate with frontend.
  6. Support: monitoring, updates, marketing assistance.

Development timeline: A basic system (collect + paywall + dashboard) takes from a few weeks to one and a half months. Adding bonding curve creator coins adds a few more weeks. Exact timing depends on tokenomics complexity and chosen L2. Get an engineer consultation—we'll discuss the architecture and calculate the cost.

Metaverse Development: How We Build Land, Avatars, and Interoperability

Decentraland sold virtual land parcels at peak hype. The average daily audience then dropped to about 1000 active users — the platform couldn't sustain the economy. The Sandbox followed a similar scenario: beautiful 3D worlds, but empty. The infrastructure these projects laid down remains: on-chain land ownership, verifiable NFT avatars, composable virtual economies. The question isn't whether the technology works — it does. The question is how to design so as not to repeat the same mistakes. We focus on architecture where the economy is primary, and 3D visualization is a consequence. Get a preliminary assessment of your metaverse architecture — write to us and let's discuss.

Why Land as NFT is More Complex Than It Seems?

Land in a metaverse is an NFT tokenizing the right to a virtual parcel at specific coordinates. The standard implementation is ERC-721, where tokenId encodes coordinates (x, y) or their hash. Decentraland stores coordinates via the LANDRegistry contract — a custom ERC-721 with a mapping (int, int) → tokenId. The Estate contract groups adjacent parcels. Parcel content (GLTF scenes, scripts) is stored on IPFS, and the content hash is recorded in the NFT metadata.

Problem: content on IPFS is not pinned forever. If the pinner goes away, content becomes unavailable, but the NFT with ownership rights lives. For production, we use a hybrid scheme:

Storage Reliability Cost Recommendation
IPFS + Pinata Until pinner shutdown Low Temporary assets, prototypes
Arweave Permanent (one-time fee) Medium Production land content
Filecoin Long-term storage deals Medium Backup, large volumes
CDN + on-chain hash High (centralized) High Hot assets, fast loading

Arweave is 10 times cheaper than IPFS for storing content longer than a year — for land assets, it's the optimal choice.

Spatial indexing. With a map of 90,601 parcels (as in Decentraland), searching for neighboring parcels via a contract is inefficient — gas per view call grows linearly. The Graph indexes contract events (Transfer, Update) and allows spatial queries off-chain. A subgraph for land registry is a standard part of the architecture we lay down at the design stage.

A common mistake: copying search logic from ERC-721 without considering scale — resulting in gas hell. Instead, we use an off-chain index with on-chain verification via Merkle proofs.

How to Ensure Avatar Interoperability Without Losing Attributes?

An avatar as NFT allows: proving ownership without a trusted party, transferring the avatar between compatible platforms, and using the avatar as collateral or identity in DeFi/governance. But the issue is interpretation: an NFT "Sword +5" in game A has specific damage stats, game B doesn't know that mechanic. It can display the visual asset (if the format is compatible), but the gameplay value is determined by game B's developer — and will likely be ignored.

Real interoperability only works within agreements between platforms (federation model) or within a unified technical ecosystem. Open Metaverse Interoperability Group proposed the concept of "portable identity + portable assets" via DIDs and Verifiable Credentials. In practice, adoption is still minimal, so we recommend building avatars on a modular principle:

  • Off-chain standard: .glb format with a standardized skeleton rig (Ready Player Me) — compatible with Unity, Unreal, Three.js.
  • On-chain minimum: NFT with metadata pointing to .glb. Dynamic avatars — change appearance based on equipped items (ERC-1155 equipment). Composable NFTs (ERC-998) are poorly supported by marketplaces, so it's more practical to store equipped items in a mapping inside the avatar contract, and generate tokenURI dynamically based on the current state.
Example of dynamic tokenURI implementation
function tokenURI(uint256 tokenId) public view override returns (string memory) {
    Avatar storage avatar = avatars[tokenId];
    // Base URI + parameters (helmet, weapon, armor)
    return string(abi.encodePacked(
        baseURI,
        "?helmet=", toString(avatar.equipped.helmet),
        "&weapon=", toString(avatar.equipped.weapon)
    ));
}

Virtual Economy: Marketplace and Rent Mechanics

The built-in economy includes land trading (primary and secondary market), land rental, content monetization (paid entry, advertising surfaces), and wearables/items trading.

Land rental. Standard ERC-4907 (Rental NFT) — separation of owner and user roles. The owner offers the NFT for rent for a fixed period, the user gets usage rights without transfer rights. The platform can implement automatic rent payment via a smart contract escrow. Upon expiry, the user role is automatically revoked. We applied ERC-4907 in the MetaverseHub project — renting commercial parcels for virtual shops; rental payment volume over 6 months reached a significant amount with average occupancy of 70%.

Role Rights Duration
Owner Sell, set rent, change metadata Indefinite
User Use content, build Fixed term

Content monetization on-chain. The parcel owner deploys a contract that accepts payment for access. The platform verifies ownership via eth_call before opening content. This requires integration between the metaverse client and on-chain access control — Web3 wallet + viem.

Technical Stack for Building a Metaverse

  • Rendering: Three.js / Babylon.js (browser), Unity WebGL (complex scenes). Decentraland SDK — if building on top of Decentraland. Three.js is 2 times faster than Babylon.js for rendering simple scenes.
  • Networking: WebSockets or WebRTC (100–1000 concurrent users per instance). Colyseus, Agones (Kubernetes) for scaling.
  • Blockchain: wagmi + viem (frontend), ethers.js (server), The Graph (indexing), Chainlink VRF (random events). Foundry — 5 times faster than Hardhat when compiling tests.
  • Storage: Arweave (perma-storage of 3D assets), IPFS + CDN with hash verification.

What's Included in the Work (Deliverables)

When ordering metaverse development, you get:

  • Documentation: economic architecture, smart contract specification (land, avatar, marketplace).
  • Source code of contracts with tests (Foundry, Slither audit).
  • Subgraph for The Graph (indexing land, avatars, orders).
  • Frontend kit: wallet integration, 3D world visualization.
  • Access to private repository and CI/CD.
  • Support for 3 months after release.

Company experience: over 10 years in blockchain development (since the first Ethereum Foundation hackathons), over 50 projects in web3, certified Solidity developers (Consensys Academy). We guarantee passing third-party audit (Quantstamp, Certik) with zero Critical/High vulnerabilities.

Process and Timeline

  1. Analytics (2–3 weeks): economic model, mechanics, L2/L1 selection.
  2. Design (3–4 weeks): contract architecture, data schema, interfaces.
  3. Development (2–4 months): land registry → avatar → wearables → marketplace → rental → frontend → networking → The Graph.
  4. Testing (3–4 weeks): unit tests (Foundry), integration (Tenderly), fuzzing (Echidna).
  5. Audit (2–4 weeks). Average audit budget varies depending on complexity.
  6. Deployment (1 week): mainnet/testnet, pinning and CDN setup.

Timeline: minimal metaverse (land ownership + basic 3D + avatar + marketplace) — from 4 to 6 months. Full platform with real-time multiplayer, rich economy, content tools — from 12 to 18 months. We will evaluate your project for free — write to us and discuss details.

Important: don't start with the visual part. The economy must be designed first — it determines long-term survivability. Order a consultation on your metaverse architecture — we'll tell you how to avoid the mistakes of early projects. Contact us — get a detailed implementation plan.