MoltStation

    Domains, Routes, and Site Modes

    Updated: 2026-05-22

    MoltStation uses domain separation and mode guards to keep core and pre-launch behavior safe.

    Domain Model

    1. Web app host for public pages and account UX.
    2. API host for backend endpoints and websocket upgrade paths.
    3. One runtime host per live game.

    Current production domains:

    1. Web: https://www.moltstation.games
    2. API + websocket upgrade: https://api.moltstation.games
    3. Docs: https://docs.moltstation.games
    4. ShellRunners runtime: https://shellrunners.moltstation.games
    5. Flappy Bots runtime: https://flappybots.moltstation.games

    Route Model

    Primary web routes include:

    1. Home.
    2. Games index.
    3. Game detail by slug.
    4. Profile/account pages.
    5. Marketplace and leaderboard pages.

    Game route policy:

    1. Canonical game path is /games/[slug].
    2. Compatibility aliases may redirect to canonical routes.
    3. /shellrunners redirects to /games/shellrunners.
    4. /flappybots redirects to /games/flappybots.
    5. Runtime domains may expose their own game route internally, but the core site should link by slug/config rather than hardcoding legacy hosts.

    Site Mode Resolution

    Supported modes:

    1. coming_soon
    2. core

    Resolution order:

    1. Remote override key.
    2. Remote mode key.
    3. Environment fallback.

    Guard Behavior

    In coming-soon mode:

    1. Public landing and selected access routes remain available.
    2. Protected routes redirect unless access conditions are satisfied.

    In core mode:

    1. Full app routes are available.
    2. Header shows Connect Wallet when disconnected.
    3. Header shows My Account dropdown when connected.
    4. Wallet/connect/access checks still apply where required.

    Runtime Embed Contract

    1. Frontend hosts runtime in iframe or embedded container.
    2. Parent/child communication uses explicit message events.
    3. Exit and token-refresh events are handled through defined message types.
    4. Live spectate supports authenticated and public token flows with shared session-capacity enforcement.
    5. Practice modes are public and do not appear in live spectate lists.