Skip to Content
Security

Security

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: App footer → Security (/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 (MineCore, Furnace, MarketRouter)
    • timelock / proxy-admin governance metadata for the runtime quartet 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 MineCore contract address once MineCore is wired, and cannot be changed to any other value. The human-controlled pause key for locking is the MineCore guardian, not the Furnace guardian directly.
  • Report phishing or bugs via security@claimru.sh (the page also links to the contact form)
  • Manage:
    • Delegations (bots) → /security/bot
    • Approvals (token allowances) via revoke.cash link

Protocol status (pauses)

The page shows pause flags like:

  • 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.

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 cannot drift or accidentally mirror placeholder manifests before deployment is finalized.

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

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 whether the contract is upgradeable (when detectable)

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 + freeze/finality 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.
  • During the launch bootstrap, the MineCore guardian may temporarily show the LaunchController contract after an owner-initiated handoff, until genesis finalization completes and the long-term guardian handoff is done.
  • If the RPC provider is behind, the page will warn that reads may be stale.

Governance and finality

ClaimRush uses this governance model:

  • direct permanent roots: ClaimToken and VeClaimNFT
  • proxy-backed runtime quartet: MineCore, Furnace, MarketRouter, and ShareholderRoyalties
  • governance chain: Safe -> TimelockController -> ProxyAdmin -> runtime proxy, plus Safe -> TimelockController -> protocol owner()

Permanent runtime finality arrives only when governance executes the freeze-and-burn batch:

  1. ClaimToken is already frozen and ownerless from Wire.s.sol
  2. freezeConfig() runs on MineCore, Furnace, VeClaimNFT, and ShareholderRoyalties
  3. the four runtime ProxyAdmin owners are renounced

When that batch is queued through the timelock, the delay becomes a public onchain countdown to finality. The calldata is visible before execution, and the Safe can still cancel during the waiting period if anything looks wrong.

After execution:

  • runtime logic upgrades are impossible
  • documented post-finality admin knobs such as entryTokenRegistry, delegationHub, guardian rotation, and MarketRouter policy updates still remain available
  • those surviving admin actions all go through the timelock as schedule -> wait -> execute

The Security page serves three purposes:

  • a pause view
  • a governance view
  • a finality view

Indexing status (subgraph)

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

The app may show an indexing indicator like:

  • Online: indexer is close to chain tip
  • Delayed: indexer is behind chain tip by more than a small threshold (default 3 minutes / 180s)
  • Offline: indexer is unreachable

When Delayed/Offline:

  • recent actions may not show up yet in activity feeds or leaderboards
  • treat the UI as lagging, not the protocol
  • OFFLINE 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)

See also

Radar & NotificationsBots & Automation