Metaverse Development with Web3 Economy and NFT Assets

Metaverse Development

The term "metaverse" is overloaded. Before designing, we always clarify: is it a persistent 3D world with real-time interaction (like Decentraland, The Sandbox), a social layer over applications, or virtual offices for enterprise? Each model has its own stack. Here we break down the architecture of a web3-native persistent world: a multiplayer 3D environment with NFT land, on-chain economy, and decentralized governance. This is the most technically complex and in-demand option.

We have five completed metaverse projects and over 5 years of experience in Web3. We share our experience so you can assess the scope of work and avoid common mistakes. However, it's important to understand: an empty world without content and community is dead. In parallel with development, we launch a program for early LAND holders and creators. Contact us to discuss the strategy for attracting creators.

Metaverse Architecture: Blockchain, Content, and Real-Time

Everything of value lives on-chain. The rest (3D assets, scenes) is off-chain on IPFS or Arweave. Here are the key layers.

How Are Ownership and Economy Separated?

• LAND NFTs — virtual land parcels (ERC-721).
• Avatar NFTs — characters with attributes.
• Wearables — items (ERC-1155 or ERC-721).
• Governance token — votes in the DAO.
• In-world currency — ERC-20 for internal transactions.

Content on LAND is not on-chain. The owner deploys 3D scenes and scripts to IPFS — this is flexible and cheap.

LAND System: Coordinate Grid and Estate

A classic model — a map of square parcels with coordinates. As noted in official Decentraland documentation, the coordinate grid is built from the center. Decentraland uses (-150,-150) to (150,150). We apply the same approach:

contract LandRegistry is ERC721 {
    int16 public constant MIN_X = -100;
    int16 public constant MAX_X = 100;
    int16 public constant MIN_Y = -100;
    int16 public constant MAX_Y = 100;
    
    function coordinatesToId(int16 x, int16 y) public pure returns (uint256) {
        require(x >= MIN_X && x <= MAX_X, "X out of range");
        require(y >= MIN_Y && y <= MAX_Y, "Y out of range");
        return uint256(uint16(x - MIN_X)) * 201 + uint256(uint16(y - MIN_Y));
    }
    
    function idToCoordinates(uint256 tokenId) public pure returns (int16 x, int16 y) {
        y = int16(int256(tokenId % 201)) + MIN_Y;
        x = int16(int256(tokenId / 201)) + MIN_X;
    }
    
    function isAdjacent(uint256 tokenId1, uint256 tokenId2) public pure returns (bool) {
        (int16 x1, int16 y1) = idToCoordinates(tokenId1);
        (int16 x2, int16 y2) = idToCoordinates(tokenId2);
        int16 dx = x1 - x2;
        int16 dy = y1 - y2;
        return (dx == 0 && (dy == 1 || dy == -1)) || (dy == 0 && (dx == 1 || dx == -1));
    }
}

To merge adjacent parcels, an Estate composite NFT is used. Ownership of a parcel gives control over the scene content.

Why Is Content Stored Off-Chain?

Storing 3D models and scripts on the blockchain is prohibitively expensive. One gigabyte on Ethereum costs thousands of dollars. Off-chain storage on IPFS or Arweave solves the problem: the LAND owner publishes a scene hash, and the network loads content through a gateway.

Content System: What Is Deployed on LAND

Each LAND has a scene — a JSON descriptor with links to 3D models, scripts, and portals. Publishing through a simple contract:

contract LandContent {
    mapping(uint256 => string) public sceneHash;
    mapping(uint256 => uint256) public sceneVersion;
    
    function publishScene(uint256 landId, string calldata ipfsHash) external {
        require(landRegistry.ownerOf(landId) == msg.sender, "Not owner");
        require(bytes(ipfsHash).length == 46, "Invalid IPFS hash");
        sceneHash[landId] = ipfsHash;
        sceneVersion[landId]++;
        emit ScenePublished(landId, msg.sender, ipfsHash, sceneVersion[landId]);
    }
}

Developers write interactive scripts in a sandbox environment via an SDK. Example — a door that opens on click, or an NFT gate for access.

How Does Real-Time Avatar Synchronization Work?

Players see each other through game servers, each region (N×N LAND) served by a separate server. When crossing a border — handoff.

Area Server on Node.js

class AreaServer {
  private players = new Map<string, PlayerState>();
  private physicsWorld = new World({ x: 0, y: -9.81, z: 0 });
  
  handlePlayerJoin(playerId: string, ws: WebSocket, position: Vector3) {
    // ... add player, send snapshot, broadcast
  }
  
  handleMovement(playerId: string, movement: MovementPacket) {
    // server-side validation, broadcast with delta compression
  }
  
  private tick() {
    this.physicsWorld.step();
    const updates = this.getDirtyPlayerStates();
    if (updates.length > 0) this.broadcast({ type: 'batch_update', updates });
  }
}

To reduce load, we use proximity-based broadcasting — visibility is limited by a radius (e.g., 100 meters). This turns O(N²) into O(N×K).

Metaverse Economy and Governance

In-World Marketplace with Royalties

A LAND owner earns 2.5% on sales on their land:

contract InWorldMarketplace {
    uint256 public constant LAND_ROYALTY = 250;
    
    function buy(uint256 listingId) external {
        // checks, calculations, transfer of tokens and NFT
    }
}

Play-to-earn generates in-world currency for attending events, completing quests, participating in mini-games. Emission is controlled by a weekly cap and halvening.

DAO and Voting

Governance via Compound-style Governor. LAND ownership gives voting power (1 LAND = 1 vote + bonus for staking governance token). Decisions include: map expansion, economic parameters, contract upgrades.

Technology Stack and Development Process

Full Stack

Note: Choosing an L2 (Polygon or Arbitrum) dramatically reduces gas — 100x cheaper than Ethereum. This is critical for mass adoption.

What's Included in the Work

• Smart contract audit (LAND, marketplace, token) — we guarantee absence of reentrancy and typical vulnerabilities.
• Full documentation for content creator SDK integration.
• Infrastructure setup: IPFS pinning, game servers, databases.
• Post-launch support: monitoring, hotfixes, economy adjustments.

Phases and Timelines

Realistic timeline: 12–18 months to public alpha for a team of 8–12 people. This is one of the most ambitious projects in Web3.

The main risk is not technical but product-oriented: without content and community, the world will be empty. Therefore, in parallel, we launch a program for early LAND holders and creators. To assess your project and propose the optimal architecture, request a consultation.

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:

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.

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%.

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.