Blockchain Gaming Basics

Blockchain Gaming Basics

This page explains the core idea behind Xaya before you touch any tooling: how a blockchain — an ordered, tamper-proof log of transactions — can run an entire game with no game servers, no admins, and no trusted third parties. By the end you'll understand what "fully on-chain" actually means, why determinism is the rule that makes it all work, what a reorg is and why your game software has to survive one, and what it costs to play. If you already know all this, skip ahead to Xaya-Architecture.

A blockchain is an ordered log

Strip away the hype and a blockchain is a surprisingly simple data structure: an append-only log of transactions, grouped into blocks, in one agreed-upon order.

Three properties matter for games:

1. Ordered. Every transaction sits at a definite position in the log. Block 1000 comes before block 1001, and within a block, transactions have a fixed order too. Everyone who reads the log reads the same sequence.
2. Immutable. Each block cryptographically commits to the block before it. Once a block is buried under enough later blocks, changing it would mean redoing everything after it — which the network's consensus rules make practically impossible. History doesn't get edited.
3. Replicated. Thousands of independent nodes each hold a full copy of the log and verify every new block. No single party controls it, and no single party can take it offline.

Most people meet blockchains as payment systems, where the log entries are "Alice pays Bob 5 coins." But the log doesn't care what the entries mean. An entry can just as easily be:

Player alice moves two squares north.

And that observation is the entire foundation of blockchain gaming.

From a log of moves to a running game

Think about what a traditional game server actually does. It receives player inputs, applies the game rules to them in order, and keeps the resulting state — positions, inventories, scores. The state at any moment is nothing more than the product of every input so far, applied in order, by fixed rules.

Now notice what we just said about blockchains: they're a shared, tamper-proof record of every input so far, in order. So here's the trick:

Put the moves on the chain. Derive the state off it.

A fully on-chain game works like this:

• Players write moves to the blockchain as ordinary transactions. A move is just a small piece of data ("go north 2 steps", "attack the goblin", "bid 50 gold") attached to the player's on-chain identity.
• Game rules are published as open-source software. Anyone can run this software. It reads the chain from the game's starting block, processes every move in order, and computes the current game state.
• The state is a pure function of the move log. Same moves in, same rules applied — same world out. There is nothing else: no hidden server-side database, no privileged process that knows something the chain doesn't.

flowchart LR
    subgraph chain["Blockchain (shared, ordered, immutable)"]
        B1["Block n<br/>alice: north 2"] --> B2["Block n+1<br/>bob: east 5"] --> B3["Block n+2<br/>alice: attack"]
    end
    chain --> R["Game rules<br/>(open-source, run by anyone)"]
    R --> S["Game state<br/>(identical on every node)"]

Loading

In the Xaya world, the software that does this replay is called a Game State Processor (GSP) — you'll meet it properly in Xaya-Architecture and What-Makes-a-GSP. For now, just hold onto the concept: moves in, deterministic state out.

What this buys you

No game servers

There is no central machine that "is" the game. The game exists as data on the chain plus rules anyone can run. If the studio that wrote the game disappears tomorrow, the game keeps running — players keep sending moves, and anyone running the rules keeps computing the state. Nobody can shut it down, because there's nothing to shut down.

This also changes the economics for you as a developer: you don't operate (or pay for, or defend, or scale) authoritative game servers. You publish rules.

No admin who can alter outcomes

In a traditional game, whoever runs the server has root. They can grant items, roll back a fight, ban a winner, or quietly tweak drop rates. Players have no way to even detect it, let alone prevent it.

On-chain, there's no lever to pull. The move log is immutable, and the state is recomputed from it by every participant independently. If someone publishes a doctored version of the game state, it simply won't match what everyone else computed, and it gets ignored. "Cheating" would require convincing every independent node to run different rules at once — at which point it isn't cheating, it's a different game that nobody agreed to play.

Invalid moves get the same treatment. Anyone can write any data to a public blockchain, including garbage or attempted exploits. The rules decide what counts: a move that doesn't conform is simply ignored by every honest node. Validity is enforced by math and replication, not by a moderator.

Player-owned identity

Your account on a traditional game is a row in the operator's database. It can be suspended, deleted, or repossessed.

On-chain, a player's identity is an asset they hold — on Xaya, a name like p/alice is an NFT in the player's own wallet (details in Names-and-Moves). Moves are transactions signed with the player's own keys. Nobody can impersonate them, confiscate the identity, or lock them out of the game. And because the identity lives on the chain rather than inside one game's database, the same identity can play every game on the platform.

Determinism: the one rule that makes it work

Everything above hinges on a single requirement: every node that replays the move log must compute exactly the same state. Not similar. Not equivalent-in-spirit. Bit-for-bit identical — because "the game state" is, by definition, whatever everyone independently agrees it is.

That means game rules must be strictly deterministic:

• No wall-clock time. "Now" differs between machines. Time is measured in blocks instead — block height is part of the shared log, so everyone agrees on it.
• No external inputs. No web API calls, no reading files, no "ask the server." The chain is the only input.
• No unseeded randomness. random() gives every node a different answer. Games that need chance derive it from on-chain data (like block hashes), so every node draws the same "random" number.
• No ambiguous arithmetic. Floating-point results can differ subtly across compilers and CPUs; deterministic games stick to integers or other operations that behave identically everywhere.

This sounds restrictive, but it's the same discipline used by lockstep multiplayer RTS games for decades — and it works. As a concrete demonstration: in preparing these tutorials, two completely independent instances of the same Xaya game processor were synced from the chain on the same machine, and they produced byte-identical game state. That's not luck; it's the design.

Determinism is covered in practical depth in What-Makes-a-GSP.

Reorgs: when recent history gets revised

There's one wrinkle every blockchain application must handle, and games are no exception.

Blockchains are built by a decentralized network, and occasionally two valid "latest blocks" appear at roughly the same time. The network briefly disagrees about the tip of the chain, then converges on one branch; the other branch is abandoned. From your software's point of view, a few of the most recent blocks detach (they're no longer part of the chain) and are replaced by different ones. This is called a chain reorganization, or reorg.

flowchart LR
    A[Block 100] --> B[Block 101]
    B -.-> C["Block 102<br/>(abandoned — detaches)"]
    B --> D["Block 102'"]
    D --> E["Block 103'<br/>(new tip)"]
    style C stroke-dasharray: 5 5

Loading

For a game, the consequence is direct: state derived from abandoned blocks must be rolled back, then recomputed along the winning branch. If your game processed "alice moves north" in a block that later detached, that move un-happens — and may or may not reappear in a block on the new branch.

Two practical takeaways:

• Game software must be able to rewind. A well-built game state processor keeps just enough "undo" information per block to step backwards efficiently when a reorg hits, then replays forward on the new branch. On Xaya, the libxayagame framework detects reorgs and drives the rewind for you — your game code just supplies the per-block undo logic (What-Makes-a-GSP shows how).
• Recent state is provisional; buried state is final. Reorgs are shallow and rare in practice — usually a block or two near the tip. Anything buried under a healthy number of blocks is settled for good. Game designs simply treat the last few blocks as "pending confirmation," the same way exchanges wait for confirmations on deposits.

You don't need to fear reorgs; you need to handle them — and on Xaya, the framework does the heavy lifting.

What does it cost?

"Every move is a blockchain transaction" used to be a deal-breaker: on early chains, that meant minutes of waiting and meaningful fees per move. This is exactly why Xaya games today run on Polygon PoS:

• Blocks arrive roughly every 2 seconds, so a move you send is typically reflected in the game state within a few seconds.
• Transaction fees are sub-cent. A real game move sent while verifying these tutorials cost well under $0.01 in POL. Players can make hundreds of moves for pennies.

That's fast and cheap enough for turn-based and many tick-based games to live entirely on-chain. For genuinely real-time gameplay — where even two seconds per action is too slow — Xaya adds game channels, which move rapid back-and-forth play off-chain between players while keeping the blockchain as the final arbiter. That's a topic for later; see Game-Channels for the overview.

Where Xaya fits

None of the ideas on this page are hypothetical. Xaya is a platform built around exactly this model — its team has been doing decentralized gaming since Huntercoin in the early 2010s — and provides the machinery so you don't build it from scratch:

• an on-chain identity and move system (names as NFTs, moves as transactions on Polygon),
• a bridge (XayaX) that delivers ordered moves to your game in a chain-agnostic way,
• and a battle-tested framework (libxayagame) that handles syncing, reorg rewinding, storage, and the client-facing API, leaving you to write only the game rules.

Continue with Xaya-Architecture to see how these pieces fit together — and check the Glossary any time a term on this wiki is unfamiliar.