Build "Squeekville", a charming mobile-first interactive hamster town. ALL user-facing text must be English.

CORE

Real hamster work settled on Squeekchain's Sepolia contracts supplies local game energy. The player connects a wallet, signs a mayor order, and chooses where that energy goes. This must be a functional chain-driven experience, not a dashboard or decorative wallet demo.

SCENE

One original illustrated miniature town at dusk:

• Central hamster-wheel power station
• Bakery
• Park with a fountain
• Town Square with festive lights
• Paths, trees and expressive hamster residents

All buildings exist from the start. No construction, planting, harvesting, trading, complex upgrades, countdowns or losing.

Use cohesive SVG/CSS artwork, cream/sage/terracotta/amber colors, soft shadows and warm lighting. No emoji as main artwork, stock photos or generic dashboard layout. Keep the town prominent and comfortable on phones.

PLAY

One resource: Town Energy, maximum 12.

Each mayor order costs 3 energy.

Only one pending order per wallet.

Three choices:

1. "Fire Up the Oven": glowing oven, smoke and a hamster carrying a large loaf.
2. "Start the Fountain": flowing water and hamsters gathering.
3. "Light Up the Square": string lights and a cheerful hamster gathering.

Each event lasts 8-12 seconds, then returns to idle.

Flow: Connect wallet > switch to Sepolia > select location > explicitly sign mayor order > wait for enough chain-derived energy > execute once.

If enough energy already exists, execute after the signature is verified.

CHAIN INTEGRATION

Read official documentation first: https://docs.squeekchain.com/developers/

https://docs.squeekchain.com/developers/core/

Resolve the official Sepolia SqueekCore address and published ABI. Investigate documented state() and roundPage() reads. Never invent addresses, ABI fields, endpoints, work units or settlement rules.

Read verified settled rounds through a browser-compatible Sepolia RPC using a dedicated adapter. Do not assume the public REST API permits browser cross-origin requests.

Pending/unknown rounds are NOT zero-work rounds. Distinguish Ethereum confirmations, Squeekchain round settlement and Squeek block completion. Apply the official confirmation policy if documented; otherwise disclose the chosen policy.

Local GAME balance, not protocol rewards:

• Newly verified settled round with zero work: +1 energy.
• Newly verified settled round with positive work: +3 energy. Use only the officially documented work field. Cap at 12.

First successful initialization per wallet: start at 0 energy and checkpoint the latest verified settled round. Do not credit earlier history.

Later sessions: process newly settled rounds after that saved checkpoint, in order, with bounded pagination. Deduplicate round IDs.

On connection failure, preserve progress and pause energy accrual. Never fabricate rounds or silently switch to simulation.

WALLET AND SIGNING

Support injected EIP-1193 wallets and Sepolia switching using a standard Ethereum library.

Handle rejection, disconnection, account changes and wrong network.

Use readable EIP-712 typed mayor orders:

mayor address, location, energyCost=3, unique nonce, issuedAt, expiresAt (24 hours), actual site origin.

Domain: name "Squeekville", version "1", Sepolia chainId. Do not invent a verifyingContract for local orders.

Recover and verify the signer. Reject wrong-account, expired or reused orders. No automatic wallet prompts.

Before signing show: "Sign a local mayor order. This does not send a transaction, transfer assets or grant approvals. Your order and town progress are saved in this browser."

Signing confirms a LOCAL instruction, not an onchain transaction, block validation or round settlement. Never show fake transaction hashes.

No seed phrases, private keys, approvals, transfers, minting or badge/reward promises.

EXECUTION AND STORAGE

Before animation, persist the 3-energy deduction and completed order ID. Prevent duplicate execution after refresh, repeated polls or multiple tabs.

Verify saved signatures before use.

Separate saves by wallet and chain.

Persist energy, checkpoint, pending order, completed IDs and settings.

Account changes must never execute another account's orders.

Explain: "Town progress is saved in this browser and does not sync across devices."

"Town Energy is a local game resource with no monetary value."

PRACTICE

Separate Practice mode, no wallet required, independent save, unsigned demo orders and "Simulate a settled round" button.

Always show "Practice mode - simulated data".

Never mix practice and connected progress.

If real integration fails, mark connected mode unavailable; do not present Practice as real.

UI

Compact energy meter, wallet button, location choices, signing button and pending-order status.

Small expandable Town Journal distinguishing verified chain events from local orders/animations.

Show last verified round ID and last successful refresh inside "How it works".

Provide loading, waiting, rejection, wrong-network and connection-error states.

Intro: "The hamster powers the town."

"Choose where to send energy."

"Watch your neighborhood come alive."

TECHNICAL

Static IPFS-compatible frontend, relative asset paths, no mandatory backend or secret API keys. Use sensible polling/backoff and accessible touch targets. Respect reduced motion. Optional sound muted by default.

TEST

Verify all three actions, wallet switching, rejected signatures, account changes, persistence, deduplication and no energy accrual during failures. All visible text English.

Deliver working app, source and short README listing official address/ABI sources, reads used, confirmation policy, local storage, tests performed and honest limitations. Prioritize a complete three-location town over extra features.