skills·poker Docs

Appearance

playSKPK Token ​

What was decided ​

The PMF beta runs on playSKPK — a fresh 6-decimal, no-backing SPL mint on numero-token, granted directly to players instead of bought/wrapped from a USDC-backed chip. The real-money chip is not deployed in the beta (it returns later, rebranded SKPK).

Three decisions:

  1. A no-backing mint + an idempotent grant. grant(amount, claim_id) is grant-authority-gated (the cage signs) and idempotent per claim_id via a grant_marker PDA — a replay of the same claim reverts "already in use" and mints nothing. This is the same once-only guard used by the core rake_marker and betting claim_marker, and it is the chip-claim-board's no-double-mint floor. The claim_id threads game-server → cage → grant.

  2. The cage's chip mint is a per-deploy fact, not runtime-agnostic. A single CHIP_TOKEN env (playskpk | tskpk, unset → tskpk), captured at module load, drives a chipMint() resolver through the whole fund path (table/custody/betting vaults + every player chip ATA). The four fund programs are mint-generic, so they need only a tskpk_mint → playskpk_mint field rename; the cage decides which mint per deploy. The beta inits only playSKPK (init_playskpk, no init_mints), so the SKUSDC faucet/wrap real-money surface is structurally absent, not merely unused.

  3. CHIP_TOKEN is fail-closed. resolveChipToken throws on any unrecognized value at cage boot (and in the harness/standup/devnet reads), so a typo (playSKPK, a trailing space) can never silently run the beta on the real-money chip. This closed a HIGH-severity silent fallback that the happy-path tests could not see (a falsification finding).

Key tradeoffs accepted ​

  • Two chips coexist during the beta. The parameterized chipMint() keeps the real-money TSKPK path + its ~30-test cage-e2e working alongside playSKPK. This is coexistence "added during migration," so its deliberate retirement is captured as the playskpk-full-migration plan, sequenced at the tail of agent-pmf-beta — the coexistence would otherwise become permanent backcompat.
  • settle and withdraw are alternate exits, not a sequence. In the cage model, settle (a hand payout) concludes the player; the full fund path is proven as a deposit → withdraw custody round-trip plus a separate deposit → settle, not an (impossible) deposit → settle → withdraw.
  • Mainnet is a separate, irreversible step. Everything here is proven on a disposable solana-test-validator / devnet; the mainnet deploy + INIT_AUTHORITY prod-swap + key ceremony live in mainnet-solana-deploy.

Verified ​

The full play loop runs on playSKPK against a live validator: grant (A1/A2), deposit + withdraw custody round-trip (A5), a settled hand paying from the playSKPK vault (A5b), and the refused real-money faucet (A7) — with the TSKPK cage-e2e core staying green (the beta path is CHIP_TOKEN-gated). resolveChipToken has a unit test (A9) proving 8 typo variants all throw.

References ​