A web3 game is not "a game with NFTs": it is a normal game whose economy — items, in-game currency, ownership of assets — lives partly on a blockchain. The decision that separates projects that work from projects that get abandoned is exactly that one: what goes on-chain and what does not. This guide covers the usual architecture, where the budget goes and what to ask before hiring.
What goes on-chain and what does not
On-chain go the assets the player must truly own: skins, characters, land or collectibles as NFTs, and the in-game currency as a fungible token. Everything else — physics, matches, matchmaking, rankings, combat logic — stays on the classic game server. Putting game logic on-chain is the most expensive and most common mistake: blockchains are slow and costly for that, and it gives the player nothing. The basics are in our blockchain gaming entry.
The usual four-layer architecture
1. Engine and game server (Unity, Unreal, Godot or in-house): the game itself. 2. Blockchain layer: the smart contracts for assets (ERC-721/1155 for items, ERC-20 for currency), the marketplace and the bridge for moving assets in and out. 3. Account layer: how a player gets a wallet without knowing they have one — today that means account abstraction or embedded wallets, social login and gas sponsored by the game, because asking a player to install MetaMask kills conversion. 4. Indexer backend: reads the chain and serves asset state to the game in milliseconds, which the chain alone cannot do.
Choosing the chain
Pick the chain on cost per transaction, latency and ecosystem, not on hype. For games with thousands of daily operations, Ethereum layer 2s and gaming-focused chains (sponsored gas, cheap transactions) are the default; Ethereum mainnet only makes sense for the single highest-value asset. Switching chains mid-project is possible, but migrating assets already sold to players is delicate: decide with the game economy on the table.
Where the budget goes
The blockchain layer is usually the cheapest part of a web3 game and the scariest. Item and currency contracts are standard and well documented: the real cost sits in the audit (non-negotiable once assets carry economic value), the account layer and the indexer. Engine and art remain, as in any game, the bulk of the spend.
The mistakes we keep seeing
Designing the token economy before the game (and ending up with a game nobody plays without a reward). Launching the token before having players. Putting game logic on-chain. Requiring an external wallet at onboarding. And skipping the audit "because it is a game": if an item is worth money, its contract is a target.
What to ask a development studio
What they have shipped with assets in production, how they solve the player account, which chain they propose and why, who audits, and what happens to the assets if the studio closes. We have gathered the reference studios in our guide to blockchain game development companies. We build the blockchain layer, the account layer and the indexer and integrate with the engine the studio already has — the terrain of our web3 development and decentralized applications services. Have a game and want to know what should go on-chain? Talk to us.