What actually works

Published early and updated as it changes, including the parts that say "not yet". A page that only becomes honest at launch was never honest.

Status: Public testnet · no mainnet · nothing here holds value. The installable SDK is kei-transaction@0.8.0, published 4 August 2026 — a clean bun add kei-transaction reaches @keicoin/market@0.4.0, @keicoin/player-economy@0.1.2 and loot-table drops in @keicoin/economy@0.2.2. Since 3 August 2026 the public testnet settles rooted claims and atomic swaps end to end over https://testnet.keicoin.org/rpc. It is one rate-limited, best-effort node with weak consensus, published dev keys and no uptime promise. There is no mainnet. The demos are demos: Carpet Markets rebuilds its no-value mock from a Durable Object event log across eviction; the hosted World of Wonder uses a process-local mock that resets. Create Kei MMO is an unpublished draft; at integration checkpoint b6edae7, fresh blank 2D and 3D projects meet criteria 2–6 only at construction scope, including clean-restart server-authored character persistence and a separate player-custodied atomic trade on a private mock chain. Criteria 1, 7, 8, and 9 remain open. A resume token is not account recovery, socket identity is not bound to a Kei wallet, and SQLite WAL does not establish multi-writer or crash-loss guarantees; scale and public hosting, harness-deletion proof, and presentation also remain open.

The installable SDK is kei-transaction@0.8.0, @keicoin/market is 0.4.0 and a plain install reaches it, and since 3 August 2026 the public testnet settles rooted claims and atomic swaps end to end. Everything below is either something you can install, something you can run, or something this page says is not built.

Milestone numbers are gone. The M0–M10 ladder was retired on 3 August 2026 because the work stopped being a sequence — four tracks now run at once, each finished by its own condition rather than by its turn.

The four tracks

Mainnet is not a fifth track, and it is not a build task. It is gated by validator distribution, reserve governance, and a legal conversation — none of which any repository can ship its way through. Nothing here is mainnet-ready, and no amount of work in a demo makes it so.

What you can install and run today

Carpet Markets is a mock-chain demo, and a weak one

It is playable at /examples/carpet-markets and it is the worked demo of @keicoin/market: every trade is an offer one player wrote and another accepted, settled in one block, and whether a market can exist at all is the coin’s immutable transfer policy. That argument holds, and its tests assert it at the ledger rather than in the client.

The interface around that argument remains materially weaker than the launchpads it is modelled on, but it is less weak after the merged and deployed product-UX work. Six of its nine criteria now have committed checks. The remaining three are browser behaviours that were reported passing once, but that walk was never committed and there is no Playwright dependency in the repository, so a clean clone cannot reproduce the evidence.

1. A first-time visitor with no wallet completes one buy in five interactions or fewer. Open: reported passing, but the browser walk is not committed.
2. Every state that can refuse a trade — an unsynced receivable, units locked in an open offer, spendable below the ask — is named on screen *before* the action, not surfaced as a failure after it. Met — lib/refusals.ts and its tests name each state before the action.
3. A trade’s result appears without a manual refresh, and pending stays visually distinct from confirmed throughout. Met — lib/balance.ts carries the three numbers all the way to the screen.
4. Price, volume and holder panels say "no trades yet" rather than showing a zero. Met.
5. No horizontal scroll at a 360 px viewport, with the primary action reachable. Open: reported passing, but the browser walk is not committed.
6. Launch → sell → buy → cancel completable by keyboard alone. Open: reported passing, but the browser walk is not committed.
7. The transfer-policy badge is the loudest element on a card and links to the ledger fact behind it. Met.
8. Every claim the interface makes is asserted at the ledger by a test. Met for the claims that exist.
9. Each known hole — the account-bounded book, one open quote per address, off-chain replies — is stated on the screen where it bites, not only in the README. Met.

Create Kei MMO does not build a complete MMO yet

The harness’s headline promise is that you describe an MMO and get one. That promise is currently far from met, and "early" was not a thing anybody could check, so it now has nine criteria that are.

Where it actually is at draft integration head b6edae7: the repository’s default branch still carries the retired three-template scaffolder. The unpublished work behind PR #1 resolves an intent, plans it, prepares the project, and then runs one bounded engine pass over the first step of that plan — a real provider call, three workspace-scoped tools, at most 24 model round-trips and thirty minutes — and stops. Fresh blank 2D and Babylon.js 3D generated projects now install, build, and start a loopback-only authoritative 20 Hz game server. The First Shared Encounter uses the generated project’s shared browser/headless connection, assigns player IDs on the server, and proves two headless clients observe each other move. PR #16 makes those server-assigned characters restart-safe, and PR #15 adds a separate generated economy proof using the published kei-transaction@0.6.0 package. There is no Kei terminal UI, no session past that one pass, and no package published under either name.

Criteria 2, 3, 4, 5, and 6 are met at this unpublished draft integration checkpoint, only for fresh blank 2D and 3D construction scope. The committed smoke installs and builds fresh blank projects, starts the generated game server, connects clients through the same module the browser uses, and proves two clients see each other’s server-authored movement. The generated bun run restart-proof crosses clean process restarts with the exact server-assigned player ID, position, XP, and server-derived level intact. A forged identity, position, progression, inventory, balance, currency, or settlement field changes neither live memory nor SQLite. The browser receives a 32-byte opaque resume token while SQLite stores only its SHA-256 hash and the character fields; the database schema stores no Kei economy state. It also runs the generated bun run economy:check proof: a separate issuer provisions GOLD and a Founder’s Sword directly to two player wallets, a mismatched expectation changes nothing, and the correct player-signed acceptance settles both legs atomically while the game server holds no Kei asset or credential. This is construction-scale proof on private local state and a deterministic mock chain, not a runtime trade UI or public deployment.

Criteria 1, 7, 8, and 9 remain open. One invocation still stops after its first plan step; capability coverage remains open end to end; the incomplete criteria cannot yet keep passing after the harness is deleted; and there is no release-quality 30-second presentation proof. A resume capability is not account recovery, and a socket character is not cryptographically bound to a Kei wallet. SQLite WAL is not a multi-writer store or a guarantee against crash loss. Scale, public hosting, prediction/reconciliation, and cross-shard migration remain outside this checkpoint.

Criterion 4 is the one that decides whether the MMO boundary exists, and this checkpoint crosses that boundary for fresh blank projects. Criterion 5 now proves the narrow clean-restart character boundary, and criterion 6 proves a separate custody boundary: player wallets, not the game server, sign and hold the trade assets. Together they preserve the ownership split — SQLite owns character position and progression but no economy; Kei owns currency, items, and trade — without establishing account recovery, socket-to-wallet identity, crash-safe distributed persistence, scale, public hosting, or a finished game.

Criterion 9 decides whether it is worth showing anyone. Issue #17 is the detailed target: one recordable 30-second encounter with admitted art, blended motion, real audio and synchronized feedback inside a declared frame budget. A gray box with working netcode and atomic trade is still not a game anybody would play, so a T-pose, a silent hit or a placeholder beep is an honest state to build through and not a state to finish in. It is also why criterion 8 covers 2–7 *and* the presentation proof: deleting the harness has to leave the look and sound of the thing standing, not only its systems tests.

If you want a running Kei MMO today, fork World of Wonder. That is a real one, and it is what the harness may eventually plan with.

Run the evidence yourself

Every claim above that is about behaviour has a command behind it. These are the commands, not a summary of them.

bun add kei-transaction@0.8.0

git clone https://github.com/keicoin-org/kei-transaction
cd kei-transaction && bun install
bun run check            # typecheck + the hermetic suite
bun run test:m3-live     # against https://testnet.keicoin.org/rpc — needs the internet, no key

git clone https://github.com/keicoin-org/carpet-markets
cd carpet-markets && bun install
bun run check     # typecheck, worker typecheck, and the tests

# test/registry.test.ts is where the transfer-policy badge is either true or
# marketing: a soulbound coin cannot be offered, an issuer-only coin cannot move
# between two holders, an open one settles peer to peer, and the launch fee does
# not drift as coins pile up.

git clone -b codex/m9-game-harness https://github.com/keicoin-org/create-kei-game
cd create-kei-game

# Pin the unpublished integration checkpoint described above and run its
# exact protocol plus generated-project smoke.
git checkout b6edae7
bun install
bun run test:generated     # clean 2D/3D; each runs restart-proof + economy:check

# --plan-only needs no provider, no credential, and touches no directory.
bun run src/index.ts -- "Salvage Run" --3d \
  --gameplay "Crews salvage derelict stations and haul cargo home." \
  --plan-only

--plan-only prints the engine decision and its reasons, every reference candidate and its score, the capability packets selected and deferred, the constraints, the acceptance criteria, and the build order. It is the honest thing to run first, because it shows you what is deferred before anything is written.

What was measured, and when

This section used to say a public claims-and-swaps deployment was "not evidenced here", which was a polite way of saying nobody had checked. It was checked on 3 August 2026, from a clean npm install kei-transaction against https://testnet.keicoin.org/rpc.

• Payments, automatic receive, issuance and its burn, mint and balanceOf all work against the public node. Re-issuing the same symbol returns the same asset id; the issuer’s balance really does drop by 1 on its first asset.
• token.commit() — rooted claims — works. The conformance suite passes against the node: one issuer block, three player claims, correct balances, and a second claim from the same account refused.
• market.sell() / accept() — atomic swaps — work, and the whole flow passes over the public URL: offer, lock, refused double-sale, settlement.
• The first rows of that list were Block is invalid the same morning, on a node predating both block types. Evidence about a deployment is behavioural: store_version and a passing suite, not build_info, which is stamped at configure time and lied for several hours.
• The exact SDK suite is shared from a pinned revision, so the node gate and the live check run the same contract. The pinned run: 11 pass on the base surface, 2 on claims, 3 on the market.

What this means for you

What you can do today is build against the published 0.8.0 API and a public testnet that carries claims and swaps, keep tests deterministic with Kei.mock(), and fork a worked example that already runs.

Known and stated plainly

• Network security. The public testnet is one best-effort dev node with weak consensus, not a production network.
• No inherited liquidity. Kei launches with no users, no exchanges, and no market.
• No global order book. An offer lives on its author’s chain and there is no indexer, so discovery is explicit — a registry, or account-scoped reads. Every front end shows the accounts it has heard of, and says so.
• No pool, curve, or AMM. @keicoin/market is bilateral. A pump-style venue would need a node-enforced pool primitive, which means reopening a settled decision; it is backlog, not planned work.
• The 0.8.0 SDK release is installable, and every namespace is present — but it is not the newest of every part. Re-run on 5 August 2026 in an empty directory — npm init -y && npm install kei-transaction — rather than read off a checkout or off registry metadata. The resolved tree is kei-transaction@0.8.0 over @keicoin/core@0.5.0, work@0.4.2, claims@0.5.1, tokens@0.5.3, market@0.4.0, wallet@0.5.1, economy@0.2.2 and player-economy@0.1.2, and importing the umbrella from that install gives a client whose shop, economy, market, items and claims namespaces are all present. core@0.6.0, claims@0.6.0 and market@0.5.0 are also on npm and a plain install does not reach them, because a 0.x caret does not cross the minor; the next umbrella is what moves those, not a reinstall. Create Kei MMO is not released; npm still serves the superseded create-kei-game@0.2.0 scaffolder, which is a different product, and nothing is published as create-kei-mmo.
• No smart contract VM, deliberately. If your design needs one, Kei is the wrong tool and this page would rather you found out here.