Embeddable Game Standard
The Embeddable Game Standard (EGS) is an open protocol for building composable, provable on-chain games on Starknet. It defines how games expose their logic, how platforms mint and manage game tokens, and how frontends display real-time game state.
For a high-level overview of why EGS matters, see the EGS presentation deck.
The Problem
On-chain games are silos. Each game reinvents token minting, score tracking, settings management, and leaderboard logic. Platforms that want to embed multiple games must write custom integration code for each one. There's no standard way for a tournament system, a quest platform, or a social app to discover, launch, and validate games.
Three Pillars
EGS is built on three layers:
| Layer | What It Is | Who Uses It |
|---|---|---|
| game-components | Modular Cairo component library for Starknet | Game and platform developers writing contracts |
| Denshokan | Turnkey implementation: token contract, registry, indexer, API, and client | Teams that want a ready-made deployment |
| denshokan-sdk | TypeScript SDK with React hooks and WebSocket subscriptions | Frontend developers integrating game data |
What You Can Build
Games that are automatically compatible with any EGS platform:
- Implement a single trait (
IMinigameTokenData) to expose score and game-over status - Optionally add settings (difficulty modes), objectives (achievements), and custom metadata
- Your game becomes mintable, trackable, and embeddable anywhere
Platforms that aggregate and orchestrate games:
- Mint game tokens on behalf of users with a single
mint()call - Receive automatic callbacks when scores update or games complete
- Run tournaments, quests, and reward systems across any EGS-compliant game
Frontends that display real-time game data:
- Query games, tokens, players, and activity through a unified API
- Subscribe to live score updates and game completions via WebSocket
- Decode packed token IDs client-side for instant display without RPC calls
Architecture at a Glance
Metagame ──→ MinigameToken (ERC721) ──→ Minigame
│ ▲ │ │
│ │ └── Registry ├── Settings (optional)
│ │ └── Objectives (optional)
│ └── IMetagameCallback (on_game_action, on_game_over, on_objective_complete)
└── Context (optional)Game Lifecycle: Setup → Mint → Play → Sync (update_game()) → Complete (game_over())
Learn more about the architecture →
AI-Assisted Development with Context7
All EGS repositories are indexed on Context7 and can be queried by AI coding assistants (Claude, Cursor, Copilot, etc.) for up-to-date documentation and code examples.
| Library | Context7 ID | Snippets |
|---|---|---|
| This documentation | /provable-games/docs | 1289 |
| game-components | /provable-games/game-components | 183 |
| denshokan | /provable-games/denshokan | 270 |
| denshokan-sdk | /provable-games/denshokan-sdk | 80 |
Claude Code
Context7 is available as an MCP server. Add it to your Claude Code config:
claude mcp add context7 -- npx -y @upstash/context7-mcpThen ask questions referencing the library — for example: "Using /provable-games/game-components, how do I implement IMinigameTokenData?"
OpenAI Codex
Add Context7 to your codex.md or system prompt:
When working with EGS, fetch up-to-date docs via Context7 MCP using these library IDs:
- /provable-games/docs
- /provable-games/game-components
- /provable-games/denshokan
- /provable-games/denshokan-sdkOther tools
Any tool that supports MCP servers (Cursor, Windsurf, etc.) can use Context7. See the Context7 docs for setup instructions.
Quick Links
| I want to... | Start here |
|---|---|
| Build a game | Building a Game |
| Build a platform that embeds games | Building a Platform |
| Integrate game data in my frontend | Frontend Integration |
| Look up a specific interface or struct | game-components Reference |
| See working examples | Games and Applications |
| Understand packed token IDs or SRC5 | Advanced Topics |