A safe view of the architecture
Technical Overview
See how Starville separates presentation, realtime delivery, trusted operations, durable state, and disabled token-claim research without exposing sensitive internals.
On this pageOne platform, distinct applications
One platform, distinct applications
Starville is organized as a pnpm and Turborepo monorepo. The landing application provides the public village entrance, wallet-access presentation, How to Play guide, and documentation. The game client renders the isometric world and player interfaces. The administrator portal is a separate protected application for authorized operations staff.
A backend API handles trusted player and administrator workflows. A dedicated realtime server handles live session presence, movement delivery, chat, social events, and cooperative activity events. A worker performs bounded background maintenance and scheduled operations. Shared packages carry validation, contracts, design tokens, game definitions, wallet access, economy logic, and testing helpers.
Separating these applications avoids turning the public website into an administrator surface or the browser into the authority for balances. Shared contracts reduce drift without exposing private staff functions to player navigation.
Supabase, PostgreSQL, and access control
Supabase provides PostgreSQL, authentication, and storage foundations. PostgreSQL Row Level Security (RLS) and backend authorization separate player-owned data, public safe views, and authorized administrator operations. Passing the player token gate does not grant administrator access.
Important currency and receipt records are append-only after completion. Published maps, policies, shop versions, and platform configuration use immutable version history rather than silent in-place edits. Draft, validation, review, approval, scheduling, publication, and rollback are explicit lifecycle concepts.
Official game assets use controlled storage and versioned metadata. World maps remain structured tile, object, collision, spawn, interaction, zone, and version data rather than one flattened image. Avatar definitions pin approved asset versions and closed catalog keys; a browser cannot provide raw asset URLs, scripts, render order, or administrator-only cosmetics. This supports safe updates and predictable client compatibility.
Solana wallet verification
Reown AppKit provides the Solana wallet connection presentation. A one-time challenge proves control of the selected address, and the trusted access boundary checks the configured network, mint, token program, decimals, and raw balance. A short-lived game session records the verified context.
The browser does not submit a trusted eligibility boolean, and an RPC failure is not treated as a zero balance. Current access does not require an on-chain transaction, wallet custody, seed phrase, private key, token approval, or asset transfer.
Disabled token-claim architecture
Disabled token-claim research is an offline design and testing boundary, separate from current wallet access and off-chain DUST. Typed models describe possible future eligibility, mock claim intent, immutable authorization fields, layered caps, treasury reserves, quarantine, disputes, and exactly-once reconciliation. They create no player entitlement or financial promise.
The game client could only present status and a future intent request; it could never choose reward amount, mint, network, treasury, or eligibility. Trusted services could validate bounded state but could not hold the final treasury signing key. A future authorization boundary would bind recipient, mint, network, amount, policy, nonce, and expiry. No such live authorization or signer exists now.
Offline instruction planning deliberately stops before a recent blockhash, wallet signature, treasury signature, serialized transaction, RPC submission, or confirmation. Fixture treasury and simulation values are labeled Mock or Offline Simulation and never represent live funds. The preferred future model remains pending owner, security, treasury, legal, and compliance review.
| Boundary | May model | Cannot do while disabled |
|---|---|---|
| Client and wallet | Public disabled status and existing access proof | Choose a reward or sign a claim transaction |
| API, worker, and database | Typed offline state, uniqueness, caps, and receipt concepts | Create live eligibility or sign and submit a payout |
| Authorization and signer | Disabled or deterministic mock interfaces | Load a secret, connect a treasury, or produce a live signature |
| Solana | Network and instruction-plan validation without RPC | Receive any claim transaction |
Receipts, configuration, and operations
Currency, item purchase, cooperative completion, gift, trade, and correction operations are designed around idempotent request identities and transactional settlement. A retry resolves to one authoritative outcome. Reconciliation detects mismatches without silently rewriting an account.
Configuration is versioned and reviewed. Published versions remain immutable, and scheduled activation is handled by trusted operations rather than a public browser clock. Audit records capture sensitive changes and remain append-only for normal administration.
Maintenance controls can deny new playable-world entry or pause a module while preserving durable balances and receipts. White-label platform modules allow presentation and selected capabilities to be configured without granting permissions or deleting underlying player data.
What this overview leaves out
Public architecture explains responsibility without publishing credentials, private database locations, raw access policies, staff recovery paths, internal moderation evidence, private user data, or exact anti-abuse thresholds. Those details would not help a player understand the system and could weaken security.
The overview also keeps future-facing economy and avatar work separate from current player availability. Token reward, claim, signer, and treasury systems are not active.