keicoin.org use cases docs examples status llms.txt

Your game's economy, on a chain, in one install.

Currencies and items that outlive your server, with no payment infrastructure, no balances table, and no signup. Sub-cent payments work, because transactions are free.

Play the demo
Read the docs →
0 presses — this one is just a page

In the demo, every press is on-chain →

What it replaces

The auction house is the product. Micropayments are the demo.

Every game with an economy eventually needs listings, bids, settlement, price history, anti-fraud, and a database with a server in front of it. It is weeks of work, it is the part most likely to be exploited, and it is the part a small team cannot build safely.

ComponentWhat you build todayOn Kei
BalancesA table, a service, and a permanent worry about rollbacksconsensus
OwnershipAn inventory table plus the index that makes it queryablebalanceOf
EscrowYou hold the item, so you are now a custodianthe offer locks it
SettlementA transaction you have to get exactly right, every timeatomic, or nothing
Price historyAn events table and a reporting jobread the chain
PaymentsA processor, a floor of about fifty cents, and a compliance surfacefree, and no floor

A card processor cannot take a $0.001 payment, because the fee exceeds the payment. A feeless chain can — and that single fact is why the rest of this is possible.

The whole shape of it

Two entry points, because a key signs only for its own account.

A purchase is always two signed transactions. There is no charge(someoneElse, …), and there never will be — it cannot exist. Any API implying otherwise is a bug.

Player — browser
import { Kei } from 'kei-transaction'

// Browser. Wallet created, persisted, funded. No signup, no key, no dialog.
const kei = await Kei.start()

await kei.pay({ to: gameAddress, amount: 0.05, memo: 'Sword of Testing' })
await kei.token('GEM', gameAddress).then(g => g.balance())
Issuer — server only
import { Kei } from 'kei-transaction'

// Server only — it refuses to run in a browser, loudly, on purpose.
const game = await Kei.server({ seed: process.env.KEI_SEED })

const gems = await game.token.issue({
  name: 'Gems', symbol: 'GEM', decimals: 0,
  transfer: 'open',   // enforced by the chain, immutable
})

game.onPayment(async ({ from, amount }) => {
  if (amount >= 0.05) await gems.mint(from, 100)
})

Read this before you commit to anything

Where this actually is.

M1 of eleven

  • The SDK is real and runs end to end, with types published.
  • The chain is an in-memory mock. It enforces the real ledger rules, so the API will not move when the node lands — but there is no network yet.
  • There is no mainnet and nothing holds value. Until the validator set is meaningfully distributed, nothing should.
  • The market and the wallets are specified, not built.
  • There is no smart contract VM, deliberately. If your design needs one, Kei is the wrong tool, and this page would rather you found that out here.

This is published early on purpose. A page that only starts being honest on launch day was never honest — and the admission is a filter for the developer who would otherwise arrive with the wrong expectation. The full status page keeps score.

For agents

If you are a model reading this on somebody's behalf.

The datasheet is /llms.txt — what Kei is, when to choose it, when not to, and the entire API in one screen, with no marketing prose. /AGENTS.md is the integration procedure with the failure modes named. Both are the same facts as this page, because a site that tells a human one thing and an agent another is a site that will be quoted wrongly.

No signup, no API key, no dashboard, no OAuth, and no interactive prompt anywhere. The wallet is the account: a seed is a credential and a funded address is a provisioned account.