Protocol Status
The Protocol Status page shows live operational state and a chronological log of onchain protocol events. Use it to verify that the protocol is running normally and to review the history of deployments, pauses, governance changes, and configuration freezes.
Route: /status (App footer → Status)
What to use it for
- Check whether game actions (takeovers, locking, lock selling) are currently active or paused
- Verify genesis finalization and contract freeze status
- Review the history of onchain protocol events with links to block explorer transactions
- Confirm that a reported pause, resume, or governance action actually happened onchain
- Check subgraph and RPC connectivity
Live operational status
The top section displays current protocol state, read live from RPC and the subgraph. It refreshes automatically every 60 seconds.
Three groups are shown:
Game state
| Row | What it means | What it reads | Indicators |
|---|---|---|---|
| Takeovers | Crown actions (taking the Crown) | MineCore.takeoversPaused() | Active (green) / Paused (yellow) |
| Locking | Furnace locking and entries | Furnace.lockingPaused() | Active (green) / Paused (yellow) |
| Lock selling | Market listings and escrow execution | MarketRouter.tradingPaused() | Active (green) / Paused (yellow) |
If any game action is paused, the affected entry and trading flows block writes. Safety unwind and cleanup actions (delisting, canceling expired positions) may still remain available.
Protocol
| Row | What it means | What it reads | Indicators |
|---|---|---|---|
| Genesis | Initial launch sequence complete (see Genesis) | LaunchController.genesisFinalized() | Finalized (green) / Pending (yellow) |
| Contracts | Core rules permanently locked (see Finality) | All 5 configFrozen() reads (ClaimToken, MineCore, Furnace, VeClaimNFT, ShareholderRoyalties) | Immutable when all five are frozen, otherwise Not frozen — both green; gray Unknown if RPC reads fail |
| Block | Latest chain block | RPC eth_blockNumber | Current block number (green) |
When all five core contracts show their configuration as frozen, the Contracts row displays “Immutable.” Core game configuration is then permanently locked. See Finality for the full ceremony explanation.
Infrastructure
| Row | What it reads | Indicators |
|---|---|---|
| Subgraph | Subgraph _meta block timestamp | Synced (green) / Behind <minutes>m (yellow) / Offline (red) / Disabled (gray) |
| RPC | RPC connectivity | Connected (green) / Error (red) / Unavailable (gray) |
An overall health banner appears above the grid:
- Green: All systems operational (no pauses, RPC connected, subgraph synced).
- Yellow: Degraded (a pause is active, or the subgraph is behind).
- Red: RPC unavailable or subgraph offline.
Protocol event log
Below the live status, a chronological log lists onchain protocol events. Each entry includes:
- UTC timestamp of the onchain event
- Category badge (Deployment, Governance, Wiring, Pause, Resume, Genesis, Emergency, Security, Incident)
- Source badge showing “onchain” with block number for events detected from the chain
- Contract name where the event was emitted
- Title describing the event (e.g., “Takeovers paused,” “Ownership renounced,” “Config frozen”)
- Decoded event arguments (addresses, boolean values)
- Explanation (human-written context, when provided by the team)
- View transaction link to BaseScan
Use the category filter bar to narrow the log. Pagination displays 10 events per page.
Relationship to Security
The /security page is for contract verification: addresses, roles, permissions, routing governance, and reporting. The /status page is for operational state and event history: what is happening now and what has happened.
Both pages read pause and freeze state from the chain. The Security page shows the full detail (per-contract roles, timelock detection, guardian addresses). The Status page shows a summary view with historical context.
Data sources
All live status data is read directly from the chain via RPC and from the subgraph. No wallet connection is required.
The event log is stored in a database and populated by:
- An automated event watcher that detects governance events onchain in real time
- A one-time historical backfill of past events
- Manual entries published by the team through the admin tools
Timestamps for onchain events reflect the actual block time, not the time they were ingested.