Security

Most players need to know three things:

1. Only use the official domain: claimru.sh. If the app shows a red banner or a “Use claimru.sh” button, move to the canonical site before connecting your wallet.
2. Check pause status in the app footer under Security. If a pause is active, the affected actions (Crown, Furnace, or Market) will block writes until the pause is lifted.
3. Report phishing, bugs, or suspicious activity via the contact form .

Everything below covers the full verification surface for users who want to go deeper.

The Security page is the protocol verification surface. Use it to cross-check official contract addresses, live pause status, routing-governance addresses, and bot access. For critical actions, verify the same facts on the block explorer too.

Route: /security  (App footer → Security)

What to use it for

• Verify you’re on the official domain and using the correct network
• If the wallet button says Use claimru.sh, treat the current host as read-only and move to the canonical site before connecting or signing
• On a non-canonical public host you should see a prominent red unverified-domain warning banner immediately at the top of the page. This banner appears automatically when the host does not match the canonical claimru.sh domain.
• Copy/verify official contract addresses on the block explorer
• Check whether critical actions are paused
• Understand whether the protocol is still in the timelocked governance window or has already reached permanent runtime finality
• Review the live routing-governance and pause-control addresses:
  • core owner / guardian addresses for pause-bearing contracts (Crown, Furnace, Market)
  • timelock and proxy-admin governance metadata for the four upgradeable contracts when present onchain
  • routing-registry owner / guardian addresses
  • routing-registry owner delay when it is detectable onchain
  • Note: The Furnace guardian is unconditionally pinned to the Crown contract address once wired, and cannot be changed to any other value. The human-controlled pause key for locking is the Crown guardian, not the Furnace guardian directly.
• Report phishing via the contact form  or bugs via the contact form 
• Manage:
  • Delegations (bots) → /security/bot 
  • Approvals (token allowances) via revoke.cash link

Emergency pause

The Permissions section shows pause flags:

• Takeovers paused (Crown)
• Locking paused (Furnace / lock-related actions)
• Trading paused (Market / listings and escrow execution)

If a pause is active, expect the affected entry and trading flows to block writes. Safety unwind and cleanup actions, such as delisting or canceling expired market positions, may still remain available.

When takeovers are paused, the current King stops accruing CLAIM immediately. Mining time lost during a pause is not compensated after unpausing.

Configuration freeze

For the conceptual explanation of what configuration freeze means, the freeze-and-burn ceremony, and what stays adjustable afterward, see Finality.

Below the pause flags, the page shows per-contract freeze state for the five core contracts. The UI labels track contract names; lore aliases are shown in parentheses:

• ClaimToken frozen — freezes at wire time, before launch
• MineCore frozen (Crown) — freezes during the ceremony
• Furnace frozen — freezes during the ceremony
• VeClaimNFT frozen (Locks) — freezes during the ceremony
• Royalties frozen (Barons) — freezes during the ceremony

Once a contract is frozen, its core configuration is permanently locked. The freeze is one-way and irreversible.

Governance and finality

The two governance phases, the freeze-and-burn ceremony, and what stays adjustable after finality are covered in Finality.

What the Security page itself reads onchain:

• Per-contract freeze flag for the five core contracts (Configuration freeze section above).
• Upgradeable status for each contract, detected live from proxy-admin ownership (Contracts and verification section below).
• Routing-governance and pause-control owners for proxies, registries, and the bot-access hub.

The page reflects the true current state. When the freeze-and-burn batch executes, the Upgradeable column flips from Yes to No for Crown, Furnace, Market, and Barons, and each freeze row flips to Frozen — no manual refresh, no static labels.

Canonical contract addresses

Use the in-app Security page  as the canonical address list for the active deployment. This manual intentionally does not print static mainnet address tables, so it stays aligned with the live address surface.

Cross-check every address against the in-app Security page  and on BaseScan . If any address doesn’t match, stop and report via the contact form .

Contracts and verification

• Contracts are grouped (Crown, Furnace + Locks, LP Vault, Routers, etc.).
• Each row lets you:
  • Copy address
  • Verify on the explorer (external link)
  • See the contract’s upgradeability status

The Upgradeable column shows one of five statuses, detected live from onchain state:

These statuses update automatically. When the freeze-and-burn ceremony executes, proxy-backed contracts change from “Yes” to “No” and frozen redeploy contracts change from “Redeploy” to “No” without any manual intervention.

Delegations (bots)

• “Delegations (bots)” links to Bot access management: /security/bot 
• Use it to allow a bot to perform specific actions on your behalf (and revoke any time)
• Sessions are time-limited: each delegation has an expiry after which the bot can no longer act
• Permissions are granular: you choose exactly which actions a bot can perform
• See the Bots & Automation guide for a full list of delegatable actions and their risk profiles

See: Bots & Automation

Approvals (allowances)

If your wallet is connected, the Security page shows a link to manage approvals via revoke.cash.

Use this if you want to revoke token allowances you no longer need.

Data sources and freshness

• Contract addresses come from the active deployment manifest.
• Pause flags, per-contract freeze state, upgradeability status, core owner/guardian addresses, runtime proxy-admin ownership state, and routing-registry owner/guardian/detected-owner-delay status are read live from chain RPC and include an as-of block/time.
• The page does not enumerate every owner-managed operational allowlist or ancillary role surface. Operational keeper allowlists remain separate onchain controls.
• Queued timelock operations are their own onchain source of truth. If governance has scheduled the final freeze-and-burn batch or another admin change, verify that queue directly on the explorer or timelock interface too.
• Before genesis finalization, the Crown guardian field reflects the current launch guardian contract. After genesis finalization, it reflects the long-term guardian assignment.
• If the RPC provider is behind, the page will warn that reads may be stale.

Indexing status (subgraph)

Some screens use an indexer/subgraph for history and aggregates (example: Activity, Leaderboards, and some Crown history views).

The app surfaces an indexing freshness chip with three states:

• Live — indexer is close to chain tip
• Late — indexer is behind chain tip by more than the staleness threshold (default 3 minutes)
• Off — indexer is unreachable

When Late or Off:

• recent actions may not show up yet in activity feeds or leaderboards
• treat the UI as lagging, not the protocol
• Off should be treated as an indexer outage immediately, even if the last indexed block still looks recent
• verify critical state on the explorer or on /security  (which reads live from chain RPC, not the indexer)

See also

• Safety & Risk — Protocol phases and risk factors
• Genesis — Launch event and the 24-month genesis LP lock
• Finality — Freeze-and-burn ceremony and post-finality governance
• Bots & Automation — Managing bot access sessions
• Core Concepts — Understanding the protocol