A feeless blockchain with native tokens, and a TypeScript SDK that puts a browser game's
currency, items, loot and player market on-chain — without the developer ever running
payment infrastructure.

keicoin.org · Docs · Live examples · llms.txt

PlayFab is the category. One primitive is the product.

The reason Kei can exist is a single gap: a card processor cannot take a $0.001 payment, because the fee exceeds the payment. A feeless chain can. Every repository here follows from that one sentence.

import { Kei } from 'kei-transaction'

const kei = await Kei.start()          // wallet created, persisted, funded on testnet
await kei.send('kei_3abc...', 0.001)   // sub-cent, instant, feeless

No signup, no API key, no wallet extension, no dashboard, no database.

The honest boundaries are stated here as prominently as the capabilities, because someone adopting Kei on a false premise builds something broken and has a worse time than someone who passed.

The hosted demos currently run against in-memory mock ledgers rather than the public testnet, so they reset. The code in the repositories talks to the real node.

npm create kei-game        # scaffolds a project you own, then gets out of the way
bun add kei-transaction    # or add the SDK to a game you already have

kei-transaction@0.3.0 is on npm, along with every @keicoin/* package — core, tokens, claims, market, wallet, and work. The umbrella package is the default install; the scoped ones exist for people who care about bundle size.

Five products and two supporting repositories. They are deliberately separate: a consensus bug fix and an SDK typo fix must never share a release, and a developer cloning the game template must not download a blockchain.

Token balances are enforced by consensus. Not by an SDK ledger, not by the developer's Postgres, and not by an indexer's interpretation of ordinary transactions. That is the whole reason a fork was necessary rather than a meta-protocol.

An item is a native token with supply 1. Ownership is balanceOf — one call, no crawling, no background indexer. Item transfer is token transfer, so there is one code path rather than two.

The transfer policy is the argument. Every token declares open, issuer-only, or none at issuance; the node enforces it and it is immutable thereafter. open means a permissionless market will eventually appear whatever the developer would prefer. issuer-only means players genuinely cannot trade with each other. none is soulbound. There is no fourth option and no way to have two of them.

Loot is one issuer block and a thousand player claims. The issuer publishes a Merkle root committing to an entire batch of entitlements; each player proves membership and writes the claim to their own chain. Because every account in a block-lattice has its own chain, those claims happen in parallel with no ordering contention — a monolithic chain would serialise them and charge gas for the privilege.

Each of these was considered and rejected for cause. Please do not open a pull request adding one.

• No smart contract VM. No EVM, no Solidity, no gas. A native token primitive is not a VM and must not grow into one.
• No play-to-earn. "Earning" requires money to exit, which requires perpetual new buyers. Anyone may build it on Kei; this project does not ship or promise it.
• No on-chain exchange, AMM, or order book. The chain moves assets; it does not price them. A swap settles a trade two parties already agreed on.
• No game world of our own. Anything that needs a population before it has value is out of scope by definition.
• No general game-backend features. Leaderboards, matchmaking, analytics, and cloud save are ordinary database work. Use PlayFab alongside Kei — that is a feature, not a gap.

The test for whether something belongs: does it need consensus or custody? If yes, it is in scope. If no, it is someone else's database.

Contributions are welcome, and the fastest way to have one merged is to know which of these you are working on.

1. The design specification is the brief, and anything not in it is out of scope until it is in it. If a change needs the scope widened, open an issue arguing for the spec change before writing the code — that conversation is much cheaper than a rejected pull request.
2. Open an issue before a large change. A one-line fix needs no ceremony. A new package, a new block type, or a new dependency does.
3. CI is the gate. kei-node, kei-transaction, carpet-markets, and world-of-wonder build in CI; the node's build is slow, so expect a long loop on consensus changes and make each run count.
4. State what is not true. Status claims across this project are deliberately narrow — "merged" is not "deployed", and "published" is not "in production". Keep that habit in documentation and pull request descriptions.
5. Security issues are not normal issues. A defect in block validation, token policy enforcement, or key handling should not go in a public issue tracker. Use private vulnerability reporting on the affected repository, or contact a maintainer directly.

kei-transaction, kei-wallet, and carpet-markets are MIT. kei-node is BSD-3-Clause, inherited from the Nano and Banano lineage. world-of-wonder carries its upstream terms from orion3dgames/t5c, with attribution preserved. button and keicoin-site do not carry a LICENSE file yet — if you intend to reuse either, ask first.

_{Built on Banano, itself a fork of Nano. Wallet forked from BananoVault, itself forked from NanoVault. Game template forked from orion3dgames/t5c.}