Solana on-chain layer — four programs at parity (validator)

The live EVM on-chain surface has been rebuilt on Solana as four separate Anchor programs at complete parity, behind the same cage interface so the off-chain solana-bank will be a drop-in swap. Built grant-first and verified end-to-end on solana-test-validator (16/16). Devnet deployment of the four .so is the one deferred operational step.

See the current-state reference: Solana Programs (on-chain) and the decision record: Solana Programs ADR.

What shipped

• numero-token — SKUSDC (test-USDC SPL mint + an admin-gated faucet) + TSKPK, a 1:1 USDC-backed wrapper (wrap/unwrap). The chip is fully backed. The faucet's eligibility policy (invite codes, social rewards, limits) lives off-chain in the cage; the chain enforces "only the admin mints."
• numero-core (the grant milestone) — cage-gated deposit (SPL delegate), ed25519-receipt settle
  • rake, withdraw, collect_rake; Table/Position/vault PDAs; the keccak position chain; conservation. The cage's receipt is verified via the Ed25519 native program + instructions-sysvar introspection (no ecrecover), binding signer == the cage AND message == the reconstructed receipt.
• numero-custody — move_to_custody (escape / idle-kick → FREE per-user claims), redeem (signed receipt, entry-capped, redeemed-once, conservation), set_disputed + release_disputed (cage + arbiter dual-sig). Claims are keyed by user_id (any linked wallet redeems) and identified by a cage-assigned unique entry_id. The core → custody seam is a cage-gated release_to_custody_vault on the core, invoked atomically by custody so the debit + the claim-write can't drift.
• numero-betting — create_market, cage-gated deposit (delegate → pool), claim (betting ed25519 receipt, pool-capped + single-use), withdraw (cage-gated reclaim of unbet funds, the cash-game-table model), and the freeze → custody seam (release_market_to_custody_vault, invoked by custody's move_market_to_custody). Per-bettor shares stay off-chain; the chain holds the pool total + the single-use claim guard. Entry-only is preserved — only uncommitted deposits are withdrawable; staked funds stay locked until settlement.

Fund-safety properties (re-proven on Solana)

• Receipt binding — settle / custody-redeem / betting-claim all verify signer == the platform signer AND message == the exact receipt; forged, tampered, missing-verify-ix, and expired all reject.
• Conservation triad — no core / custody / betting payout exceeds its vault / pool.
• Dual-sig release — a disputed custody claim releases only with both the cage and the arbiter signatures, bound to a per-entry dispute_nonce (no stale-signature replay).
• Single-use — settlement receipts and betting claims each pay exactly once.

A hardening pass added four fixes (22/22 green): settle binds its payout to the receipt identity (a signature-gated payout can't be redirected with a swapped destination); init_* is deploy-gated on a hardcoded INIT_AUTHORITY (blocks init front-running; a documented pre-mainnet key swap); deposit sources are owner-bound; and init_custody requires signer != arbiter (the dual-sig can't collapse to one key). See the decision record for details.

Parity note (Solana ≠ EVM at hand-off)

The EVM diamond commingles balances, so escape/freeze are pure internal-ledger moves (no token transfer). Solana has no shared storage — each vault is its own SPL account — so the faithful analog moves tokens source-vault → custody-vault at hand-off. The funds never leave the protocol until redeemed; the EVM "no token move at escape" sub-clause does not translate, while every meaningful invariant does.