Architecture
Source: denshokan — turnkey implementation of the EGS architecture (token contract, registry, indexer, API, and client).
The Embeddable Game Standard is built around three contract roles: Metagame (the platform), MinigameToken (the shared ERC721), and Minigame (the game logic). These roles communicate through well-defined interfaces discovered via SRC5.
System Diagram
┌─────────────┐ ┌──────────────────┐ ┌─────────────┐
│ Metagame │──mint──▶│ MinigameToken │◀──reg───│ Registry │
│ (Platform) │ │ (ERC721) │ │ │
│ │◀callback│ │──read──▶│ Minigame │
│ │ │ ┌────────────┐ │ │ (Your Game)│
└─────────────┘ │ │ CoreToken │ │ └─────────────┘
│ │ Minter │ │
│ │ Settings │ │
│ │ Objectives │ │
│ │ Context │ │
│ │ Renderer │ │
│ │ Lifecycle │ │
│ └────────────┘ │
└──────────────────┘MinigameToken (Center)
The MinigameToken is an ERC721 contract that composes multiple game-components. Each token represents a single game session. The token ID is a packed felt252 encoding immutable game data (game ID, settings, timestamps, flags) directly into the ID itself.
- CoreTokenComponent - Base lifecycle: mint, update, game over
- MinterComponent - Tracks who minted each token (platforms, users)
- SettingsComponent - Stores game setting configurations
- ObjectivesComponent - Tracks achievement completion
- ContextComponent - Optional mutable context data
- RendererComponent - Custom token URI rendering
- SkillsComponent - Per-token AI agent skills address override
- ERC721EnumerableComponent - On-chain token iteration
Minigame (Right)
Your game contract implements IMinigameTokenData to expose score and game-over status. When the token contract calls update_game(), it reads your game's state and syncs it to the token.
Metagame (Left)
A platform contract that mints tokens and optionally receives callbacks. If the minter implements IMetagameCallback (discoverable via SRC5), the token automatically dispatches:
on_game_action(token_id, score)on everyupdate_game()callon_game_over(token_id, final_score)when a game completeson_objective_complete(token_id)when an objective is met
Registry
The registry maps game contracts to metadata (name, description, developer, genre, image, royalties). Games self-register and receive a creator NFT that controls royalty payments.
Game Lifecycle
1. Setup Game contract deploys and registers with the Registry
2. Mint Platform or user calls mint() on MinigameToken
→ Creates packed token ID with game_id, settings, timing
3. Play Player interacts with the Minigame contract
→ Game updates its internal state (score, progress)
4. Sync Anyone calls update_game(token_id) on MinigameToken
→ Token reads score/game_over from Minigame via IMinigameTokenData
→ If minter supports IMetagameCallback, dispatches callbacks
5. Complete Game marks game_over = true
→ Final sync writes permanent result to tokenComponent Relationships
| Component | Depends On | Purpose |
|---|---|---|
| CoreTokenComponent | ERC721, SRC5 | Base mint/update/lifecycle |
| MinterComponent | CoreToken | Track minting addresses with incrementing IDs |
| SettingsComponent | Minigame (IMinigameTokenSettings) | Store named setting configurations |
| ObjectivesComponent | Minigame (IMinigameTokenObjectives) | Track named objectives and completion |
| ContextComponent | Metagame (IMetagameContext) | Store per-token context from platform |
| RendererComponent | - | Delegate token URI to external contract |
| SkillsComponent | - | Per-token AI agent skills address override |
SRC5 Interface Discovery
EGS uses SRC5 (Starknet's equivalent of ERC-165) for runtime interface detection. Before calling an interface method, contracts check supports_interface(interface_id).
This enables safe, optional integration: a token can check if a minter supports callbacks before dispatching, and a platform can check if a game supports settings before querying them.
Interface IDs are defined alongside their traits in the game-components source. See the SRC5 reference → for a full listing.
Deployed Contracts
| Contract | Sepolia Address |
|---|---|
| MinigameRegistry | 0x040f1ed9880611bb7273bf51fd67123ebbba04c282036e2f81314061f6f9b1a1 |
| Denshokan Token (MinigameToken) | 0x0142712722e62a38f9c40fcc904610e1a14c70125876ecaaf25d803556734467 |
| DefaultRenderer | 0x035d01a7689ade1f5b27e50b07c923812580bb91bd0931042a9a2f8ff07dc7ec |
| DenshokanViewer | 0x025d92f18c6c1ed2114774adf68249a95fc468d9381ab33fa4b9ccfff7cf5f9f |
| Number Guess | 0x04484ca347cd957b9d591890ac7488ce0c0cd7920819f0c6376aedb953458a38 |
| Tic Tac Toe | 0x072bf4d1484599165731399c38f1c3aa27dcb31f88dac80b31098c925d7843a5 |
Denshokan Token = minigame_token_address
The Denshokan Token contract above is the shared MinigameToken (ERC721) that all EGS games can use. Whenever you see minigame_token_address in the docs or in code (e.g. the game initializer, pre_action, post_action), this is the address to pass.
Using the shared Denshokan contract gives you:
- Indexing & API — your game is automatically indexed by the Denshokan indexer, giving you REST API, WebSocket, and SDK access out of the box
- Registry integration — your game appears in the shared game registry alongside all other EGS games
- Platform compatibility — any EGS platform (tournaments, quests, arcades) can mint tokens for your game immediately
- Token rendering — default SVG rendering and metadata for all tokens
You can deploy your own MinigameToken contract if you need custom behavior, but most games should use the shared Denshokan contract.
Data Flow
┌─────────────────────────────────────────┐
│ Starknet Blockchain │
│ │
mint() ──────────▶│ MinigameToken ◀──── Minigame │
update_game() ───▶│ │ │ │
│ ▼ │ │
│ Events (Transfer, │ │
│ ScoreUpdate, │ │
│ GameOver) │ │
└───────┬──────────────────┘ │
│
┌───────▼───────┐
│ Indexer │ (Apibara)
│ ┌───────┐ │
│ │ Decode│ │
│ │ Events│ │
│ └───┬───┘ │
└───────┼──────┘
│
┌───────▼───────┐
│ PostgreSQL │
└───────┬───────┘
│
┌───────────┼───────────┐
│ │ │
┌──────▼─────┐ ┌──▼──┐ ┌──────▼──────┐
│ REST API │ │ WS │ │ RPC (direct) │
└──────┬─────┘ └──┬──┘ └──────┬───────┘
│ │ │
┌──────▼───────────▼───────────▼──────┐
│ denshokan-sdk │
│ (DenshokanClient + React hooks) │
└─────────────────────────────────────┘The SDK provides three data paths:
- REST API - Indexed data with filtering, pagination, and aggregation
- WebSocket - Real-time event subscriptions (scores, mints, game over)
- RPC - Direct contract reads for on-chain truth (ERC721 methods, batch queries)
Smart fallback: if the API is unavailable, the SDK automatically falls back to RPC.