Other Chains

Other Chains

Everything in these tutorials targets Polygon, because that is where Xaya games run in production today. But the Xaya stack itself is chain-agnostic: your GSP talks to XayaX, and XayaX presents the exact same JSON-RPC + ZMQ interface no matter which blockchain sits behind it. This page explains what that means in practice — which chains are supported, how the XayaX connectors differ, and (the punchline) how little of your game code actually changes per chain.

The GSP never sees the chain

Recall the data flow from Xaya Architecture: the chain feeds XayaX, XayaX feeds your GSP, and your GSP serves clients. The GSP's only upstream dependency is XayaX's interface — the same Xaya-Core-style JSON-RPC and ZMQ notifications regardless of the underlying chain.

graph LR
    subgraph Chains
        PG[Polygon PoS]
        EVM[Any EVM chain<br/>with XayaAccounts]
        XC[Xaya Core]
        GA[Ganache / local EVM]
    end
    subgraph XayaX
        ETH[eth connector]
        CORE[core connector]
    end
    PG --> ETH
    EVM --> ETH
    GA --> ETH
    XC --> CORE
    ETH --> RPC[Identical JSON-RPC + ZMQ interface]
    CORE --> RPC
    RPC --> GSP[Your GSP]

Loading

This is why the same GSP codebase can run against multiple chains unchanged: the chain is just a configuration detail behind XayaX's interface.

The Chain enum

libxayagame tells your game which chain it is running on via GetContext().GetChain(), which returns a value of the xaya::Chain enum (from xayagame/gamelogic.hpp):

enum class Chain
{
  UNKNOWN = 0,

  /* Chains based on Xaya Core */
  MAIN,
  TEST,
  REGTEST,

  /* Polygon network chains */
  POLYGON,
  MUMBAI,

  /* Ganache for EVM-based regtests */
  GANACHE,
};

• MAIN, TEST, REGTEST — the original Xaya Core blockchain (mainnet, testnet, and local regression-test mode).
• POLYGON — Polygon PoS mainnet, the chain these tutorials use. MUMBAI is the corresponding Polygon Mumbai testnet.
• GANACHE — a local EVM instance (ganache/anvil-style) for fully local EVM testing.

Your game decides where it "begins" on each chain it supports, in GetInitialState (see What Makes a GSP). Any chain you don't handle simply isn't supported by your game.

The eth connector: any EVM chain

xayax eth is what you ran in Running XayaX. It works with any EVM-compatible chain that has an XayaAccounts contract deployed — names and moves are contract events, and the connector translates them into Xaya blocks and moves. To run your game on another EVM chain you need exactly three things:

1. An RPC node for that chain (--eth_rpc_url=...).
2. The XayaAccounts contract address on that chain (--accounts_contract=0x...).
3. A Chain:: case in your GSP's GetInitialState with a start height on that chain — moves before that height are invisible to your game.

For Polygon, that third item is the patch you applied in the mover tutorial:

    case Chain::POLYGON:
      height = 88365000;
      hashHex = "";
      break;

Nothing else in your game logic changes. ProcessForward, ProcessBackwards, your move parsing, your state format — all identical, because the moves arriving from XayaX look the same on every chain.

The core connector: the original Xaya Core chain

xayax core bridges the original Xaya Core blockchain, where names and moves are native chain features rather than a smart contract — Xaya Core is where this whole design originated, and its daemon defined the very RPC interface that XayaX reproduces for other chains.

The stock mover in libxayagame supports all three Xaya Core chains out of the box. From mover/logic.cpp:

    case Chain::MAIN:
      height = 125000;
      hashHex
          = "2aed5640a3be8a2f32cdea68c3d72d7196a7efbfe2cbace34435a3eef97561f2";
      break;

    case Chain::TEST:
      height = 10000;
      hashHex
          = "73d771be03c37872bc8ccd92b8acb8d7aa3ac0323195006fb3d3476784981a37";
      break;

    case Chain::REGTEST:
      height = 0;
      hashHex
          = "6f750b36d22f1dc3d0a6e483af45301022646dfc3b3ba2187865f5a7d6d83ab1";
      break;

Note that these cases pin an exact genesis block hash, while the Polygon case leaves the hash empty and trusts the connected XayaX instance — both styles are supported.

Xaya Core's regtest mode deserves a special mention: it is a fully local, deterministic chain where you mine blocks on demand, which makes it ideal for automated integration tests. libxayagame ships a Python test framework, xayagametest, built on exactly this — the stock mover's gametest/ directory uses it to drive the GSP through scripted moves and reorgs. We don't cover that workflow in these tutorials, but if you want serious end-to-end tests for your game, that is the place to look.

Ganache: local EVM testing

The GANACHE chain value exists so you can run the EVM flavor of the stack entirely locally: a ganache/anvil-style local EVM node, an XayaAccounts deployment on it, and xayax eth pointed at it. That gives you a Polygon-like environment with instant blocks and free transactions. We mention it here as a possibility only — the workflow is not covered in these docs.

What actually changes per chain

For you as a game developer, supporting another chain comes down to:

What	Change
Game logic	One case Chain::... in GetInitialState with a start height
XayaX flags	--eth_rpc_url + --accounts_contract (eth connector), or point the core connector at a Xaya Core node
GSP flags	None — same --xaya_rpc_url, same everything
Clients	None — the GSP RPC interface is identical; only the chain field in responses differs (e.g. "polygon")

That's the whole list. The move envelope format, the GSP callbacks, undo data, reorg handling, storage — all chain-independent.

Where to actually deploy

To be clear about the practical picture: Polygon PoS mainnet is where Xaya games currently run in production, with the team-operated public RPC node, the deployed XayaAccounts contract, WCHI for registrations, and ~2-second blocks at sub-cent move costs. It is what every tutorial in this wiki targets, and unless you have a specific reason to do otherwise, it is where you should deploy. The value of the chain-agnostic design is insurance and flexibility — your game is one switch case away from anywhere the stack goes next.