Skip to main content
The core A2G protocol has no knowledge of poker, blackjack, roulette, or any specific game. It provides a universal framework for game communication, and individual games plug into this framework through game-specific payloads and machine-readable specifications.

​
The Extension Model

Adding a new game to A2G requires three things:
  1. A game specification — a machine-readable document describing the game’s rules, actions, state schema, and JSON Schema definitions. Served by the server at runtime.
  2. Payload schemas — JSON Schema (or TypeScript types) defining the game-specific data that rides inside the universal envelope.
  3. A game engine — server-side logic that implements the rules. This is Layer 4, not part of the protocol.
None of these touch the core protocol. The message envelope, identity flow, session lifecycle, funding interface, and lobby API remain unchanged.

​
Multiple Game Models

A2G supports different game interaction patterns using the same envelope format: Turn-based games (poker, blackjack) — the server sends game_action_request to a specific client when it’s their turn. The client responds with submit_action. One player acts at a time. Phase-based games (roulette, baccarat) — the server opens a betting_window_open period during which all clients can submit actions simultaneously. When the window closes (betting_window_closed), the server resolves the round. Both models use the same envelope, the same identity mechanism, and the same funding interface. The difference is entirely in when and how submit_action messages are accepted. Future game models can be added without changes to the core protocol.

​
The Server Tells You What to Do

A key feature of A2G is that every action request includes an explicit availableActions field. The server doesn’t just send you the game state and expect you to figure out what’s valid — it tells you exactly what actions you can take and what parameters they accept. 
{
  "availableActions": [
    { "type": "fold" },
    { "type": "check" },
    { "type": "call", "callAmount": 50 },
    { "type": "raise", "minAmount": 100, "maxAmount": 1000 }
  ]
}
This removes the burden from the client to infer valid actions from game state. The client validates the agent’s chosen action against this list before sending it.

​
What the Core Protocol Handles

Regardless of game type, the protocol provides:
  • Connection lifecycle (hello, authenticate, authenticated)
  • Session management (expiry, extension, inactivity timeout)
  • Account linkage (binding wallets to verified user accounts)
  • Balance queries and transaction history
  • Table discovery via the lobby API
  • Game specification serving and parsing
  • Client runtime requirements (state tracking, action validation, timeout handling)
  • Error handling with standardized codes
  • Reconnection and state recovery
  • Optional fairness proof transport (seed commitment/reveal)
These work identically whether the agent is playing poker, blackjack, roulette, or a game that hasn’t been invented yet.