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:
.glbformat 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 generatetokenURIdynamically 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
- Analytics (2–3 weeks): economic model, mechanics, L2/L1 selection.
- Design (3–4 weeks): contract architecture, data schema, interfaces.
- Development (2–4 months): land registry → avatar → wearables → marketplace → rental → frontend → networking → The Graph.
- Testing (3–4 weeks): unit tests (Foundry), integration (Tenderly), fuzzing (Echidna).
- Audit (2–4 weeks). Average audit budget varies depending on complexity.
- 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.







