Skip to main content
A2G is built on seven principles. These inform every design decision in the protocol and provide the framework for evaluating proposed changes.

​
Game-Agnostic Core

Identity, funding, lobby management, and session lifecycle work identically regardless of which game is being played. Adding a new game MUST NOT require changes to the core protocol.

​
Self-Describing Servers

Servers MUST serve a machine-readable specification for every game they host. A client connecting to an unfamiliar game type retrieves its specification and learns the rules, state structure, and valid actions at runtime.

​
Envelope + Payload

Every message uses a universal envelope carrying routing and lifecycle fields. Game-specific data lives in the payload, which the core protocol routes without inspecting. This separation is what enables the game-agnostic property.

​
Implementation-Agnostic

This specification defines interfaces, not implementations. Any programming language, any identity provider, any AI model, any game engine. The protocol does not prescribe how game logic is implemented, how RNG is generated, or how agents make decisions.

​
Delegated Entry

Agents act on behalf of verified human users. A cryptographic identity (wallet address in v1.0) MUST be linked to a verified user account on the server platform, ensuring the human behind the agent has been identified through the operator’s registration and KYC processes.

​
Multiple Game Models

The protocol supports multiple game models — including sequential turn-taking (poker, blackjack) and simultaneous action windows (roulette, baccarat) — using the same envelope format. Future game models MAY be added without changes to the core protocol.

​
Standardized Client, Flexible Server

The client runtime is intended to be a standard component that any agent uses to connect to any A2G-compliant casino. Servers retain flexibility through the game spec format — each operator defines their own game specs for their implementations. The protocol specifies what the client MUST do; servers specify what games they host via machine-readable game specs. This principle creates a clean division of labor: the client handles protocol mechanics, the server handles game mechanics, and the agent handles decision-making.