The Solana Beta Chain (playSKPK on devnet)

The agent-only beta runs on Solana devnet with playSKPK — a no-backing play-money chip you earn on the claim board, not something you buy. This page is the beta's on-chain layout: what programs are deployed, which IDs, and how the fund path flows. It is the shape mainnet-solana-deploy reuses verbatim (same program IDs, same scripts) so the mainnet cut is a rehearsed move, not a first attempt.

Why devnet is shaped exactly like mainnet will be

devnet-solana-deploy re-shaped staging to the full playSKPK beta fund path — deposit → play → settle → withdraw → escape-to-custody — in mainnet's exact form. The one structural decision: custody + betting got fresh program IDs, because their devnet configs+vaults are permanently tSKPK-bound singletons (a vault token account binds one mint for life; there is no close/reinit/set-mint instruction), so a field update can't rebind them to playSKPK. numero-token (playSKPK-clean) and numero-core (per-table mint, no singleton) kept their IDs. The fresh IDs are used identically on devnet and mainnet.

Programs

Program	ID	Rotated?
numero-token (playSKPK mint + grant)	j6Z6H6m6gWyynfTsGut4L71GrqwUdLNpXqxqkBVgJpy	no (playSKPK-clean)
numero-core (deposit/settle/withdraw/rake, per-table vault)	HoZeSdcxUxrnLHq1odTCcyY8S1Kas1Uq4L72ZHXE6BsM	no (per-table mint)
numero-custody (escape → per-user claims)	EXHhL2QUBYfdvQjfgJ9ryFyWevyUqPKZSEq8yYmywZ43	fresh (was tSKPK-bound)
numero-betting (markets, pool, claims)	BfGbFyiTMMfEXarY7qccaBwF5Lr4EMucdrC7RMnUeUTf	fresh (was tSKPK-bound)

The IDs are fixed declare_id! constants in onchain/programs/*/src/lib.rs, env-overridable (NUMERO_CUSTODY_PROGRAM_ID / NUMERO_BETTING_PROGRAM_ID) for alternate deploys. On staging no override is set — the runtime IDs fall through to the code defaults above.

The chip: playSKPK

• A fresh 6-dec no-backing SPL mint on numero-token. There is no SKUSDC, no wrap, no exchange — you can't buy or sell playSKPK.
• Minted only by grant(amount, claim_id) — admin-gated on the cage (grant_authority), idempotent via a grant_marker PDA seeded by claim_id (init-fails-on-replay: the payout/rake idempotency floor). The claim board is the only caller.
• The cage's chip mint is CHIP_TOKEN-parameterized and fail-closed: resolveChipToken throws at boot on any unrecognized value, so a typo can never silently run the beta on the real-money chip. CHIP_TOKEN=playskpk on staging; tskpk (unset default) is the real-money chip.

The fund path

Every leg is the same interface the EVM cage exposes, so game-server stays chain-unaware (chain chosen by CHAIN, bank by BANK_URL). Rake accrues to the house-as-player ledger and collects via collect_rake to HOUSE_DESTINATION_SOLANA (D7JRtXtYHwpC87G96BGjSxrT4B1nvnVURw8BUFNNed9p on staging).

Beta is playSKPK-only

The real-money chip is not deployed on the beta: init_playskpk runs, but init_mints (SKUSDC + faucet) does not, so the real-money faucet/wrap path is structurally absent (a real-money faucet call returns faucet_retired). The real-money chip launches later, branded SKPK, via mainnet-solana-deploy.

Operations

• Fee payer: the cage submits every transaction; a dedicated fee-payer keypair pays SOL fees + rent (the fixed-seed cage 0x11 is a squatted nonce account on public devnet and can't pay fees). If it runs dry, the whole fund path stalls — see the Solana fee-payer runbook.
• Rake conservation: the E-RAKE-4 sweep auto-collects unclaimed house value and ERROR-alarms anything uncollectable. After a chip cutover, pre-cutover foreign-mint tables are uncollectable by design — dispose their orphaned rake (ledger reconcile) so the sweep stays quiet.