The fallacy of "Real-Time" in on-chain gaming

If the chain is your source of truth, the fastest you can safely move canonical game state is one block at a time; on many EVM chains that is ~12 seconds.

You cannot commit every move, bullet, or pickup on chain at 60fps; players would click and wait. Calling that "real-time" is wishful naming.

Local simulation with periodic on-chain checkpoints: the game runs client-side or on a server, then settles results to the chain at milestones.

Server-authoritative with on-chain receipts: a central server decides outcomes and writes only the economic parts to the chain.

Faster L2s still do not hit 60fps; they just shrink the gap. All three approaches are valid as long as we name them honestly.

We predict locally, update the UI as if the action succeeded, fire the transaction, and reconcile when the chain confirms.

It is the same pattern as chat apps that show messages immediately. The design work is in how you surface pending states and retries, not in the promise that nothing will ever roll back.

Desync: if two players claim the same loot, the chain's version wins and the "losing" client rolls back with a clear UI cue.

Cheating: contracts enforce legal transitions; off-chain servers add checks or signatures; some modes require proofs.

User confusion: pending and confirmed states are explicit so a player understands why a score adjusted after finality.

Outcomes and economics: final scores, rankings, ownership, entry fees, payouts, rewards.

Not every keystroke or position update. On chain is the ledger; off chain is the render loop. Accept that split and build the UX to bridge it.