> ## 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.

# Boundary Matrix

> What A2G defines vs. what is left to implementations.

A2G is a communication protocol. This matrix defines what belongs in the protocol specification versus what is left to implementations.

## In the Protocol (Layer 1)

| Component                                | Notes             |
| ---------------------------------------- | ----------------- |
| Envelope format                          | Section 5         |
| Message types + state machines           | Section 7         |
| Message ordering + forward compatibility | Section 5.4, 5.5  |
| Identity (SIWE)                          | Section 6         |
| Account linkage                          | Section 6.5       |
| Session lifecycle + inactivity timeout   | Section 6.4       |
| Funding (EVM/ERC-20)                     | Section 11        |
| Funding operations API                   | Section 9.3       |
| Lobby REST API                           | Section 9         |
| Game spec format                         | Section 10        |
| JSON Schema requirement for specs        | Section 10.5      |
| availableActions in payloads             | Section 7.2, 7.3  |
| Client runtime responsibilities          | Section 18        |
| Game spec schema parsing                 | Section 10.5      |
| Default timeout actions                  | Section 10.2      |
| Balance query                            | Section 7.1       |
| Transaction history                      | Section 9.3       |
| Provably fair format (optional)          | Section 7.4, 14.4 |
| Replay protection                        | Section 14.2      |
| Error codes + format                     | Section 13        |
| Reconnection + seat recovery             | Section 8         |
| Fee model in results                     | Section 12        |
| Multi-table play                         | Section 7.6       |
| Extension messages                       | Section 7.7       |

## NOT in the Protocol

| Component                          | Why                                            |
| ---------------------------------- | ---------------------------------------------- |
| **RNG implementation**             | Operator's certified systems are authoritative |
| **Game engine logic**              | Server implementation (Layer 4)                |
| **AI decision-making**             | Agent implementation (Layer 4)                 |
| **Identity verification / KYC**    | Operator's existing registration process       |
| **Smart contract internals**       | Implementation choice (Layer 3)                |
| **SDK implementation**             | Convenience library (Layer 3)                  |
| **TypeScript types / Zod schemas** | Language-specific convenience (Layer 2)        |
| **Infrastructure requirements**    | Deployment concern (jurisdiction-dependent)    |
| **Agent personality / profiles**   | Agent implementation (Layer 4)                 |
| **Client autonomy model**          | Implementation Guide guidance                  |
| **Tournament structure**           | Future extension                               |
| **Game history / audit log**       | Future extension (SHOULD)                      |

## The Key Boundary

A2G defines the **interface** between clients and servers. Everything behind the interface — how the server generates random numbers, how the agent makes decisions, how the operator verifies identity — is outside the protocol's scope.

This boundary is what makes A2G adoptable by existing gaming platforms: they keep their certified systems and add A2G as a communication channel. It's also what makes A2G agent-friendly: agent developers focus on decision-making, not protocol plumbing.