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) |