Skip to main content

Documentation Index

Fetch the complete documentation index at: https://a2g-protocol.org/llms.txt

Use this file to discover all available pages before exploring further.

A2G is a standalone communication protocol. It does not adopt or require conformance to any existing gaming standard. Operators deploying A2G alongside traditional gaming infrastructure bridge A2G sessions with their existing systems.

​
RNG and Fairness

A2G does not prescribe how random outcomes are generated. Your certified RNG systems are authoritative. A2G’s optional fairness proof messages (seed commitment/reveal) provide a transport mechanism for exposing fairness data to clients, but they do not replace or override your certified RNG. The fairness proof mechanism is entirely optional and additive. Operators deploying A2G in regulated jurisdictions should verify that their RNG implementation meets certification requirements independently of the A2G protocol.

​
Transaction Reconciliation

Operators running A2G alongside other channels need to reconcile agent transactions with their central ledger. The transaction history endpoint (GET /api/wallet/transactions) provides the data needed, with each transaction carrying txId, type, amount, balance, and onChainTxHash where applicable.

​
Game Specification Ownership

A key principle of A2G is “standardized client, flexible server.” This means operators own their game specifications. Your game specs reflect your specific rules, variants, and house parameters. The client is generic; your specs make it specific to your casino. This also means you can update game specs (e.g., changing stake limits, adding variants) without any client-side code changes — clients fetch specs at runtime.