Web3 Game Development

What Is Actually Stored On-Chain

A token contract holds less than people expect. The common standards, ERC-721 for unique items and ERC-1155 for stacks and mixed batches, store a mapping from token id to owner address, a set of transfer approvals, and a URI string. The art, the stats, the animations, and the rules that make an item mean anything live off-chain, in a JSON file and asset files that the URI points at. On-chain storage is paid for per write, so almost nothing that can be held elsewhere is held there.

That indirection produces two failure modes worth designing against. If the host named by the URI stops answering, the token still exists and now refers to nothing; an IPFS CID resolves only while something is pinning it, and pinning is a service someone has to keep funding and monitoring. Separately, if the base URI is mutable, whoever holds that permission can change what every token appears to be. Immutable URIs close that hole and also remove any ability to correct a bad file later, so pick the side of that tradeoff deliberately.

The record also outlives the game in a way the item does not. After a shutdown the wallet still holds the token, but nothing renders it, nothing gives it stats, and no server accepts it. State plainly, in the language players see at the point of purchase, what the token is a record of and where the entitlement stops.

Where the Chain Sits in the Runtime

Gameplay runs on a frame budget and a chain runs on a block interval, and the two are orders of magnitude apart. Sixty frames per second leaves roughly 16 ms per frame, while block intervals on most networks are measured in seconds and practical finality sits several blocks past inclusion, which is why the input-to-response path cannot contain a transaction confirmation. The shape that holds up is an authoritative game server owning live state, with the chain written to asynchronously as a settlement layer and ownership read through an indexer rather than from an RPC node queried by the client.

Reads dominate the traffic. Every inventory screen, market panel, and profile view is a read, and a client-side design multiplies request volume by concurrent players against a provider that rate limits per API key. Routing reads through one service of your own gives you a single place to cache, retry, fail over to a second provider, and serve a degraded but honest view when the upstream is unavailable. It also keeps chain access out of a binary that players can modify.

• Transaction pending and never confirming: compare the sending account's pending nonce with its confirmed nonce. A gap means an earlier transaction is stuck and everything behind it is queued; no gap points instead at a fee below what the network is currently including.
• Player holds the item on-chain but does not have it in game: check how far behind the head block the indexer is before reading any game code. Indexer lag and a genuine sync bug look identical from the player's side.
• An item that appeared and then vanished: a reorg dropped the block the UI had already treated as done. Confirmation depth has to be a number you chose, applied consistently by both the UI and the server.
• Intermittent read failures during launches and events: per-key rate limits and provider incidents. Log provider response codes separately from your own errors, or every upstream outage arrives as a game bug report.

Permissionless Transfer Cuts Both Ways

The property a public chain provides that your database cannot is transfer that does not require your permission. That is the actual feature, and it arrives with its opposite. You cannot reverse a transfer, undo a duplication exploit once the items have moved, or pull an asset back from an account you banned. When an account is compromised the items are gone the moment they leave, and a chargeback on the payment side does not follow them.

Every mitigation subtracts from what was sold. Transfer hooks and allowlisted destinations limit where an asset can go. Non-transferable tokens remove the secondary market outright. A pause or freeze function makes ownership conditional on whoever holds that key. These are contract-level decisions, and adding one after deployment means a new contract and a migration, so the position has to be taken before launch rather than after the first incident.

Where a design calls for refunds, reversals, moderation of fraudulent transfers, and no per-transaction fee on ordinary play, a database is what the design is asking for. Putting a chain underneath it removes those capabilities without supplying one the design wanted.

Interoperable Items Are a Content Problem

Interoperability gets read as a data problem, and the data half is the easy half: anyone can read a contract's ownership records without cooperation from you. The hard half is that a second game needs art at its own fidelity and style, a mesh and rig matching its skeleton and animation set, a stat that maps onto its systems, and a willingness to accept an item it never balanced. None of that arrives with the token.

Scope interoperability against a named second title and a written list: what it reads, what it renders, what it honors, and what happens when your item outclasses its own. In practice the portable part is provenance, a proof that a wallet held a particular thing, which the second game can honor with a cosmetic, a badge, or a starting bonus of its own making. Equippable items carrying stats are the version that rarely survives contact with someone else's balance work.

Metadata is a public interface whether or not it is treated as one. Third-party marketplaces render your JSON in their own UI using the conventional fields, name, description, image, and an attributes array. Field names, image aspect ratio, and trait structure are effectively frozen once listings exist, because changing them changes how every existing listing looks.

Contracts After Deployment

Deployed contract code cannot be patched. There is no equivalent of shipping a client hotfix, and the address players and marketplaces have already recorded is the address that stays. Upgradeability, where it exists, is usually a proxy: a storage contract that delegates execution to a logic contract an admin can repoint. That trades a code risk for a key risk, and the arrangement is publicly readable, so it belongs in what you tell holders rather than in an implementation note.

Custody of that key is a governance question with a technical answer. Admin functions behind a multisignature wallet, named signers, an agreed quorum, and a plan for a signer who leaves, all settled before deployment, because a live contract is a poor place to work out the process. A timelock on admin actions puts a fixed delay between announcing a change and executing it, which is the only mechanism that lets holders see one coming.

Two assumptions are worth checking early. EIP-2981 reports a royalty for a sale, but it is a value a marketplace can query and choose to honor, not something the token transfer enforces, so any revenue plan resting on secondary royalties should be tested against venues that ignore it. And sponsoring transaction fees so players never hold the network's own token runs through a relayer or paymaster that you fund and operate, an operating expense that scales with active players and with fee levels you do not control, which needs a per-action ceiling and abuse controls, because anything you pay for gets scripted.