Embeddable Game Standard: FAQ

Developer-oriented FAQ for the Embeddable Game Standard (EGS) on Starknet. For deeper dives, follow the links to the relevant guide pages.

General

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. See the Overview.

On-chain games are silos. Each game reinvents token minting, score tracking, and settings management. Platforms that want to embed multiple games must write custom integration code for each one. EGS provides a common interface so games can be listed in tournaments, embedded as quests, and tracked across platforms without per-game integration work.

Denshokan is the turnkey implementation of EGS — a deployed token contract, registry, indexer, API, and client. If you don't want to deploy your own token contract, you can register your game with the existing Denshokan deployment and start minting immediately.

The game-components library provides modular Cairo components (MinigameComponent, MetagameComponent, SettingsComponent, etc.) that you compose into your contracts. See the Reference.

A TypeScript SDK with React hooks and WebSocket subscriptions for querying games, tokens, players, and activity. See Frontend Integration.

Dark Shuffle, Loot Survivor, zKube, Nums, and Dope Wars all implement the EGS interface. See Games.

Building a Game

1. Implement IMinigameTokenData — expose score() and game_over() for your game
2. Register IMINIGAME_ID via SRC5
3. Register with the game Registry
4. Call assert_token_ownership, pre_action, and post_action in every player-facing action

See the Quick Start for a full walkthrough.

pre_action validates that a token is playable (not game over, not expired, objective not already completed). post_action syncs your game's score and game_over state back to the token contract. Every player-facing action must call both. See Lifecycle & Playability.

A player should never be able to act on a token they don't own. This should be the first check in every action function, before pre_action.

Import the library functions directly and pass the denshokan token address:

use game_components_embeddable_game_standard::minigame::minigame::{
    assert_token_ownership, pre_action, post_action,
};
 
fn action(ref self: ContractState, token_id: felt252) {
    let token_address = self.minigame_token_address.read();
    assert_token_ownership(token_address, token_id);
    pre_action(token_address, token_id);
    // ... game logic ...
    post_action(token_address, token_id);
}

Only the contract initialized with the MinigameComponent can use self.minigame.pre_action(token_id). See the Quick Start.

The token contract won't know when scores change or games end. Score updates won't be emitted, game_over transitions won't be recorded, and platform callbacks won't fire.

No. Settings (difficulty modes) and objectives (achievements) are optional extensions. Your game works without them. See Settings & Objectives.

Your contract implements score() and game_over(). The token contract reads these via post_action and emits ScoreUpdate events. You define the scoring formula — EGS doesn't prescribe one. See Score & Game Over.

No. Once game_over() returns true, it should stay true. The token contract treats this as a permanent state transition. Reversing it would break platform integrations and tournament results.

Token Lifecycle

A platform (or the player directly) calls mint() on the token contract, specifying the game address, optional settings, start/end times, and other parameters. The token ID is a packed felt252 encoding all this metadata.

The minter provides start and end as absolute Unix timestamps. The contract converts these to relative delays for packing into the token ID. A token is playable when the current time is between start and end. start=0 means immediately playable, end=0 means never expires. See Lifecycle & Playability.

Token IDs encode game metadata (game ID, minter, settings, lifecycle, objective, flags) into a single felt252. This allows reading token properties without any storage lookups or RPC calls. See Packed Token IDs.

Specific messages for each case:

• "Token is not playable - game is over"
• "Token is not playable - objective already completed"
• "Token is not playable - game has not started (now={}, start={})"
• "Token is not playable - game has expired (now={}, end={})"

Building a Platform

A platform contract (tournament system, quest platform, social app) that mints game tokens and orchestrates gameplay. It uses the MetagameComponent to track its token contract and receive callbacks. See Building a Platform.

When post_action updates a token, the token contract checks if the minter supports IMetagameCallback via SRC5. If so, it dispatches on_game_action, on_game_over, or on_objective_complete. The MetagameCallbackComponent handles caller verification automatically — you just implement the MetagameCallbackHooksTrait. See Callbacks.

No. The MetagameCallbackComponent enforces assert_only_token automatically before delegating to your hooks. You just implement the business logic.

A contract that maps game addresses to incrementing IDs, enabling multi-game token contracts. Games register once, and the registry provides discovery for platforms. See Registry & Discovery.

• Budokan: Permissionless tournament protocol. Any EGS game can be used in tournaments with custom entry fees and prize pools.
• Eternum: MMO that embeds EGS games as quests, extending gameplay through mini-game integrations.

Frontend

Use the denshokan-sdk to query games, tokens, players, and activity through the Denshokan API. The SDK provides typed responses and handles pagination. See denshokan-sdk.

Subscribe via WebSocket hooks (useScoreUpdates, useGameActivity, etc.) for live score changes, game completions, and minting events. See WebSocket Subscriptions.

Yes. The SDK provides decodeTokenId() which unpacks the felt252 into all its fields (game ID, minter, settings, lifecycle, etc.) without any RPC calls. See Types Reference.

More Resources

• Quick Start — Build a Number Guess game step by step
• Architecture — How the layers fit together
• game-components Reference — Interface and struct documentation
• Games — Live games built with EGS
• Applications — Platforms using EGS