Comparison criterion: where state is stored and where rules are executed
“On-chain games vs Web2 games” compares the architecture of on-chain and Web2 games: where rules are executed and where game state (progress, inventory, character parameters) is stored.
The key difference between “games with NFTs” and fully on-chain is that the token can be on-chain while progress and rules remain on a server.
- Web2 → items and progress are records in the developer’s database; access is determined by the account and the service rules.
- On-chain → part of the logic and/or state is recorded on the blockchain; assets can be NFTs, and actions can be transactions.
- Web3 hybrid → an NFT can be stored in a wallet, but gameplay and progress are usually updated on a server.
- Fully on-chain → rules and state live in smart contracts; client applications can change, while enforcement rules and contract state (events and contract records) remain on the network.
Key takeaway: when Web2 servers go offline, access and progress usually stop. In a Web3 hybrid, an NFT often remains in the wallet, but game utility disappears if usage rules and progress were server-side.
The “source of truth” is the layer that stores asset rights and the final state: the studio server/database or the smart contract and network data.
Update: definitions of the Web3 hybrid and fully on-chain models have been clarified; criteria for checking the “source of truth” and the consequences of the “server off” scenario have been added.
TL;DR in 4 points: Web2, hybrid, and fully on-chain
Comparison criteria: where progress (state) is stored and who validates the rules (a server or a smart contract).
- What matters is not the presence of NFTs but where progress is stored and which layer executes the rules.
- Web2 → the server is the only source of truth and the single point of failure.
- Web3 hybrid → the token can remain in the wallet, but usage rules are often defined by the server.
- Fully on-chain → rules and state are in contracts, and the client is an interface to network data.
Model comparison: assets, progress, server dependency
A layer-by-layer comparison: source of truth, assets, progress, server dependency, and what happens when the service is shut down.
| Parameter | Web2 | Web3 hybrid (partially on-chain) |
Fully on-chain |
|---|---|---|---|
| Source of truth | Studio server/database | Server + blockchain for part of rights/assets | Smart contracts and network data |
| Assets | In-game record | NFTs/tokens in a wallet; utility is often defined by the server | NFTs/tokens + usage rules in the contract |
| Progress (state) | Server-side | Usually server-side | On-chain (contract state) |
| “Server off” | Access and progress usually stop | An NFT may remain, but modes/rules/progress can disappear | Rules and state remain on the network; the interface can change |
| UX/speed | Maximum | Medium (wallet, signatures) | Trade-off (fees, latency, access infrastructure) |
| Main risks | Centralization: the studio can change rules and access | The token exists, but utility depends on servers | Contract security + scaling and UX |
Terms for reading: NFT, on-chain/off-chain, smart contract, state
A minimal set of concepts for comparison: what the asset is, where state is stored, and where rules are executed.
- NFT — a unique token on the blockchain that proves ownership of a digital object (for example, an item).
- Smart contract — code on the blockchain that executes rules and stores/updates data.
- On-chain — an action or data is recorded on the blockchain network.
- Off-chain — an action or data is stored outside the blockchain (server, client, private database).
- Fully on-chain — game logic and state are on the blockchain; the client is an interface to contract data and rules.
- Source of truth — the layer that determines the final state: who owns the asset, what level, what inventory.
Model boundaries: Web2 game, Web3 hybrid, fully on-chain
The split is by the execution criterion: “tokenized assets” and “rules and state in contracts” are different models.
Web2 games: state (progress, inventory, character parameters) is stored and updated on centralized servers.
On-chain games: actions and/or state are recorded on the blockchain, and rules are executed by smart contracts.
Web3 hybrid: assets are tokenized (NFTs/tokens), but a significant part of logic and progress remains off-chain.
Fully on-chain: the blockchain is used as an execution layer: logic and state are in contracts, and interfaces can vary.
Key thesis: having an NFT does not guarantee persistent utility. Utility persists only if usage rules and/or critical state are anchored in contracts, or if a compatible client exists that reads contract state and applies the same rules.
Asset rights: “in a database” vs “in a wallet”
Token ownership and game utility are different states because they are defined by different layers.
Web2: an asset as a record in the developer’s system
The item exists as a row in a database, and access is the account’s right to use the service features.
- The account and platform rules determine which items and modes are available.
- Account bans or service shutdowns usually end access to items and progress.
- Transfers and trading are often limited by product rules and the studio’s infrastructure.
Implication: the asset remains a database record, not an independent object outside the service.
Web3: an asset as a token (NFT/token) on a wallet address
The owner controls the token with keys, but utility depends on where token usage rules are executed.
- The token can remain regardless of a game account because the record lives on the network.
- If token usage rules are enforced by a server, a studio can disable utility without affecting the token itself.
- After a service shutdown, the token price can drop if there are no compatible clients or on-chain usage rules.
Implication: the token can stay at the address, but “game utility” disappears when server-side rules and progress are turned off.
Distinction: “an NFT in a wallet” means token ownership. “the token grants game rights” depends on the layer where usage rules are defined and executed.
Key idea: an NFT can remain even if utility is no longer served by the server.
Progress and verification: server-side state vs contract state
The key question: where state is updated and which layer validates state transitions — a server or a smart contract.
Server-side state: progress is stored in the service database; the server defines the “official version.”
Contract state: progress is recorded in smart contract data and network events; transitions are validated by contract logic.
| What is compared | Server-side state | Contract state |
|---|---|---|
| Where progress is stored | Service database | Contract data + network events |
| Who validates transitions | Server logic and service rules | Smart contract logic (what is allowed and what is forbidden) |
| Who defines the final version | The server as the sole arbiter | The network and the contract as the source of truth |
| Admin changes | Possible (for example, rolling back a reward) | Limited by contract rules and transactions |
| How the result is verified | By service and account data | By network data (contract state and events) |
| If the service is shut down | Progress and the “official version” can disappear with the database | State and events remain on the network; the interface can change |
Example: if a season result (ranking and reward) is recorded on-chain, it can be verified from network data even if the client changes; if a season result is stored on a server, the “official version” disappears when the service is shut down.
Trade-off: on-chain rights and on-chain outcomes, off-chain gameplay
- On-chain: ownership, rare rewards, and season outcomes (what must be verifiable independently of the server).
- Off-chain: high-frequency actions (combat, movement, matchmaking) for speed and UX.
- Implication: on-chain anchors rare but meaningful events, not every gameplay action.
The more rights and final outcomes are recorded in contracts, the less server dependency there is for verifying ownership and season results.
Service shutdown scenario: what is lost in each model
Turning servers off affects assets and progress differently because each model has a different source of truth.
Web2: shutting down infrastructure stops server-side state updates and account data delivery.
Implication: access to progress and items usually ends with the service.
Web3 hybrid: the NFT remains at the address as a network record, but server-side elements (progress, modes, usage rules) can disappear.
Implication: the token exists, but utility ends when servers are turned off.
Fully on-chain: logic and state live in contracts, so data remains on the network independent of a single company.
Limitation: convenient access depends on client applications and read infrastructure (RPC and indexers).
On-chain constraints: fees, latency, UX, and contract risk
On-chain improves verifiability, but adds fees, latency, and requirements for key management.
- Throughput and latency: recording actions requires transactions and confirmations.
- Operational costs: storing and updating state on-chain can be expensive.
- UX barriers: wallets, keys, signatures, and access recovery add an additional layer of risk.
- Access infrastructure: RPC, indexers, and interfaces affect the convenience and availability of state reads.
- Contract security: code bugs and incorrect permissions can cause irreversible consequences for state and assets.
Design implication: frequent micro-actions are rarely moved on-chain; on-chain more often anchors rare but meaningful events (rights, rewards, season outcomes).
Why hybrids are popular: the blockchain is used for rights and economic events, while high-frequency gameplay stays off-chain to avoid fees and latency on every action.
Key trade-off: on-chain verifiability is paid for with fees and UX friction.
Selection criteria: when on-chain adds value, and when it doesn’t
An architecture filter: where asset rights and verifiable outcomes matter, and where speed and seamless UX matter more.
On-chain is more often justified
When value is tied to asset ownership, provenance, and secondary markets.
- Collectibles and cards where a secondary market matters.
- Resource economies and crafting with rules verifiable from network events.
- Long-lived worlds where preserving asset rights and season outcomes is critical.
Web2 is more often the practical choice
When speed, minimal friction, and no fees on every action matter more.
- Real-time genres (shooters, action) where latency is critical.
- Casual games with mass onboarding without wallets and signatures.
- Projects where items have no value outside the service.
Examples (reference points by approach)
This is not a recommendation and not a quality assessment. The goal is to show how the market typically labels different architectures.
Criteria check: (1) is progress stored in an account or in a contract? (2) is there an alternative client/state view without the official website? (3) is NFT utility defined by a contract or by server-side rules?
- Tokenized assets (often hybrid) → items and characters as NFTs, while gameplay and progress are off-chain.
- Economic and collectible formats → more often anchor on-chain asset rights and market rules around assets.
- Fully on-chain directions → try to keep rules and state in contracts, with the client as an interface to network data.
Verification criterion: where progress is stored and which layer executes the rules matters more than the presence of NFTs.
Three common perception mistakes
Expectation errors are usually caused by mixing “token ownership” with “working utility” and the “source of truth.”
“There’s an NFT — so the game can’t be shut down”
A token can exist on the network while server-side gameplay and server-side progress can disappear.
- Token ownership does not create an obligation for a service to keep game rules running.
- Risk is defined by where progress is stored and where token usage rules are executed.
Implication: checks should start with progress and rules, not with the presence of NFTs.
“On-chain = fully decentralized”
On-chain can be used selectively: for assets, but not for progress and match rules.
- On-chain assets do not mean on-chain progress.
- A hybrid model can retain critical server dependencies.
Implication: the “source of truth” for progress and rules must be identified on the server or in the contract.
“Fully on-chain has no constraints”
Contract state stays on the network, but fees, latency, and access via read infrastructure affect UX.
- Fees and confirmations limit the frequency of on-chain actions.
- Client availability, RPC, and indexers affect the convenience of reading state.
Implication: it is important to assess how many actions are on-chain and whether state can be viewed without a single frontend.
FAQ
What is on-chain gaming?
What is the difference between Web2 and Web3 games in simple terms?
What happens to an NFT if the game shuts down?
Can Web3 games be played without a wallet?
Can progress be preserved without servers?
Why are there still so few fully on-chain games?
Final check: on-chain vs Web2 in three signs
Assessing a model comes down to one question: where the “source of truth” is for progress and rules.
- Progress: season outcomes and key rewards are recorded in the contract or remain in the service database.
- Rules: state transitions are validated by a smart contract or by server-side logic.
- Shutdown risk: when the service disappears, only network data and compatible access to it remain.
If progress and rules live on a server, on-chain elements remain assets but do not preserve the game’s “official version.”