The boundary, concretely
| On-chain | Backend services |
|---|---|
| Which wallet owns which item | Player position, health, cooldowns, match state |
| Provenance and mint history | Matchmaking, sessions, progression |
| Trades and transfers between players | Inventory reads during play |
| Scarcity guarantees and supply caps | Anti-cheat and authoritative validation |
| Royalty enforcement on secondary sales | Live ops, events, remote config |
The rule underneath the table: something belongs on-chain when a player would reasonably want to verify it without trusting you, and when it changes rarely enough that a transaction per change is acceptable. Everything else is a backend concern, and treating it otherwise imports every constraint of a distributed ledger into a system that needs none of them.
Why crossing the line is so expensive
The costs of putting gameplay on-chain arrive in a predictable order, and each is individually survivable, which is what makes the pattern dangerous — teams keep going.
- Latency. Block times are measured in seconds. Gameplay is measured in milliseconds — the match service behind Metarun answers in 60 ms average round-trip, and no block on any chain is going to meet that. The gap gets papered over with optimistic updates, which means the client is now the source of truth for something the chain will later contradict.
- Cost per action. Any per-action fee, however small, changes player behaviour — and a game where players avoid actions because they cost money is a different game from the one that was designed.
- Reconciliation. Once optimistic updates exist, so does the case where the transaction fails after the player saw the outcome. Handling that correctly is a distributed systems problem sitting inside a gameplay loop.
- Irreversibility. A duplication bug in a normal game is a rollback. A duplication bug that minted assets is a permanent supply change and, frequently, a legal conversation.
Point four is the one that turns an engineering mistake into a business event. It is also the strongest argument for keeping the on-chain surface deliberately small: less surface, fewer irreversible failure modes.
Adding Web3 to a game that already exists
This is the more common request, and it is more tractable than a ground-up Web3 title. The pattern that works:
1. Backend mediates, always
The game client never talks to a chain directly. A backend service holds the integration, watches for events, and exposes ordinary API responses to the client. The client keeps working the way it already does, and the chain becomes one more upstream system rather than a rewrite.
2. Ownership is read, not enforced, in the loop
The backend resolves what a player owns at session start and caches it for the session. Mid-match gameplay reads that cache. Ownership changes take effect at the next session boundary rather than mid-fight — which is both dramatically simpler and, for players, entirely unremarkable.
This is not a hypothetical shape. It is what Metarun runs in production: hero ownership sits on BNB Chain, the backend resolves it once at session start, and the 1v1v1 races themselves held 39,000 concurrent players at peak, at 60 ms average round-trip and 99.8% uptime. The chain does not appear anywhere in the race loop, and that separation is the reason those three numbers are achievable at all.
3. Start with cosmetics
Cosmetic ownership has no balance implications, so it exercises the entire pipeline — wallet, mint, trade, display — without touching the authoritative state model. It is the cheapest possible way to find out whether your players want this at all, which is a question worth answering before the expensive version is built.
4. Make the wallet optional
A title that requires a wallet to play has narrowed its market to people who already have one. A title where the wallet unlocks ownership for those who want it has not. This is a product decision rather than a technical one, and it is the one most often made by default rather than deliberately.
What the contracts still have to get right
A small on-chain surface is not a licence to be careless with it, because that surface is the irreversible part. What we treat as standard: reentrancy and access-control review, supply and mint-authority constraints written down before implementation, upgradeability decided at deployment (it cannot be added to a deployed contract retroactively), and an external audit for anything holding meaningful value — we arrange these with specialist firms such as Trail of Bits, OpenZeppelin or Certik, and they are quoted separately rather than folded into a build price.
More on how we scope contract work in Smart contracts, and on the game side in game development. For a shipped example of the marketplace half of this — gas-optimised contracts, real-time indexing, and $2.4M in first-month trading volume — see the NFT marketplace case study.