Request a new listing or update by opening a Game submission issue on GitHub. You need a GitHub account. Running your own arcade server is optional.
What to send
| Item | What we need |
|---|---|
| Repository | The game source, accessible to reviewers. If private, arrange read access. |
| Full commit hash | The pushed version you tested. One commit must identify the frontend, rules source, compiled WASM and build instructions. Do not submit a moving branch name. |
| WASM file and SHA-256 | Usually blob/rules.wasm and blob/rules.wasm.sha256, committed together. Include the file path and hash in the issue. |
| Game details | Title, description, controls, supported devices and player counts. |
| Registration details | Proposed slug, game type (GAME_KEY in the template), and cfgSuffix in hex or none. These must match the rules you tested. |
| Test results | Build/rebuild checks, rules tests, frontend tests and deterministic replay results. Include tested player counts and devices, and any known gaps. |
| Wagering request | Say whether you want WCHI wagering. Free play is required; wagering needs separate approval. If you ask for it, give the Polygon address your game's 5% match fee is paid to: one you control (you will be asked to prove it). You can move it later from that address, and so can the arcade, for a lost key or a delisting. |
Keep the frontend and rules in the same game repository, as the template does. If your build uses additional source dependencies, pin them and explain how to reproduce the build at the submitted commit.
We build the frontend for the target arcade from your source. You do not need to upload a production frontend bundle or supply its hash. The compiled WASM hash identifies the exact rules we must reproduce and verify.
Before submitting
Commit and push the tested version. For a game based on the template, run:
bash blob/check-blob.sh --rebuild --strict
bash blob/tests/run-tests.sh
npm test
npm run e2e
npm run e2e:determinism
If your game uses different commands, document the equivalent checks in its README. Include the result summaries in the issue. The checks should cover legal and illegal moves, native/WASM agreement, deterministic replay, timeouts and the player counts your game supports. State what you could not test.
Try the controls and instructions with someone unfamiliar with the game. Include touch controls and test them on a touch device. Report missing or untested input support accurately so it can be addressed in review. Integration testing on a playground (the public one, or your own) is useful but is not a submission requirement.
Open the issue
- Open the Game submission form.
- Complete the fields and click Submit new issue.
- Follow that issue for questions, requested changes and the review result.
We review the source at the named commit, rebuild it, verify the rules hash and test the game on a disposable playground. Approved games are listed on the public arcade. Wagering is enabled only if requested and separately approved. Opening an issue does not publish a game automatically.
If changes are requested, push a new tested commit and add its full hash and test results to the same issue. For an update to a game already listed, open a new Game submission issue, link the earlier one and summarize the changes. The operator reviews and schedules the update, including any coordination needed for open matches.
Registration and build requirements
Use the template's build scripts and SDK. The operator builds the frontend with the
arcade's move namespace and registers it under the approved slug. The bundle must
use the /__arcade_base__ placeholder so it can be mounted correctly. Do not hardcode
the production hostname or add wallet signing to the game; the shell handles signing.
Choose a distinct slug and game type, and keep cfgSuffix consistent with your
rules. The slug can also name your game's own hostname, so it must be a DNS label:
lowercase letters and digits, with single hyphens between them, up to 32 characters
(my-game). The submit form fills one in from your title. A successful local test
does not reserve a production name. The review checks availability and compatibility
before registration; publication and changes to live rules are operator actions.
Artifact and registration limits are checked during review. For the ABI and build contract, see The rules blob and The SDK.