EVM & Cross-Chain
The game runs on three surfaces: Solana same-chain, EVM same-chain (Base + Ethereum), and cross-chain (a Solana leg matched against an EVM leg). The surfaces are held behaviorally identical except where the chains force a difference — the payoff matrix is one shared definition, verified by exhaustive golden vectors across all nine outcome kinds.
Same-chain EVM (Base + Ethereum)
Section titled “Same-chain EVM (Base + Ethereum)”Live on mainnet. The production contracts are the CoordinationGameV4 UUPS proxies (running v6 logic: stake escrow + openSessionAndDeposit):
| Chain | V4 proxy |
|---|---|
Base (eip155:8453) | 0xd585baE48901513202dAEb7d4feE4Af508a96234 |
Ethereum (eip155:1) | 0x265818b054E8413Bab870e0Ce0D8aB68400CF0F9 |
The canonical address source is the chain-registry crate in the public swarm-tips repo (coordination_game_v4_proxy, keyed by CAIP-2) — treat the table above as a snapshot, the registry as truth. The earlier v3 contracts (Base 0x567e…a4F8, Ethereum 0x1b75…917d, registry key coordination_game_contract) stay live only for residual state; new games go to V4.
Auto-payout at resolve. Winnings are pushed to the winner inside the resolve transaction — there is no separate claim step. (Escrowed stakes from unconsumed deposits remain withdrawable via withdrawFor.)
Agents play the EVM legs through the MCP server with an 0x wallet — see the generated EVM game tool reference. The lifecycle (create/join → commit → reveal → resolve, plus resolveTimeout) mirrors the Solana lifecycle.
Where EVM differs from Solana (structural)
Section titled “Where EVM differs from Solana (structural)”| Behaviour | Solana | EVM |
|---|---|---|
| Stake intake | deposit_stake, a separate transaction before pairing | inline at createGame/joinGame (escrow-debited under v6; a raw msg.value mismatch against the contract’s configured stakeWei reverts at the door) |
| Stake source | GlobalConfig.stake_lamports, read live per deposit | stakeWei held literally in the contract, changed only by an owner setConfig transaction — see Stakes & Payoffs |
| Wrong price | deposit succeeds, rejected one step later at create_game (StakeMismatch) — recoverable via withdraw_stake | reverts immediately |
| Abandoned pairing | refund_pending | cancelPending (deliberately mirrored) |
| Emergency pause | none | Pausable on createGame/joinGame; resolution and refunds deliberately unpausable |
| Rent reclaim | close_game / withdraw_stake | n/a — no EVM analogue |
| Session model | per-instruction *_session variants | openSession delegate registration — see Session Keys |
Cross-chain matches (Solana ↔ Base)
Section titled “Cross-chain matches (Solana ↔ Base)”A cross-chain match pairs a player staking on Solana against a player staking on an EVM chain. Design principles (org-wide locked decisions):
- Per-leg staking — each player stakes on their own chain, in that chain’s native asset. The two legs are held economically equal by pricing the Solana leg dynamically against the EVM leg’s live USD value (Stakes & Payoffs).
- Mutual-signature checkpoints — game progress and the outcome are adjudicated by signatures from both sides (the
xchain_sign_checkpointstep in the agent flow), not by an external bridge. No external-validator bridges, ever (no Wormhole/LayerZero-style trust roots). - Operator float pools — settlement on each leg pays out from a pre-funded per-chain float pool, so no value crosses chains at resolve time.
Current status
Section titled “Current status”| Surface | Status |
|---|---|
| User-facing cross-chain path | Testnet: Solana devnet ↔ Base Sepolia — full games settle both legs |
Mainnet CrossChainGame UUPS proxies | Deployed with small float; gated on operator-pool liquidity — not yet the user-facing path |
Leg ownership
Section titled “Leg ownership”Who drives which leg is a deliberate split, not a gap:
- The browser frontend is always the EVM leg of a cross-chain match.
- The Solana leg is an agent path over MCP — the
xchain_build_create_xmatchfamily of tools, which rejects EVM callers outright. See the generated cross-chain tool reference, includingxchain_supported_chainsfor the currently enabled chain pairs.