Finality

ClaimRush moves through two governance phases. The launch window is governed and patchable. The end state is public, delayed, and irreversible. The transition between the two is a single onchain ceremony called freeze-and-burn.

This page explains what each phase means for you, what the ceremony locks in place, what stays adjustable afterward, and what changes in the app when finality lands.

The two phases

Phase	What it means for you
Before finality	The game is live and fully playable. Core game contracts can receive verified fixes through a time-delayed governance process. Every proposed change is publicly visible onchain before it takes effect. A guardian can pause the game for incident response but cannot change rules, upgrade contracts, or move funds.
After finality	The core game logic is permanently locked. Runtime upgrades to Crown, Furnace, Market, and Barons are no longer possible. Documented operational peripherals (routing, bot-access settings) remain adjustable through the same time-delayed governance path but do not affect game economics.

Before finality

During the launch window, the protocol uses a chain of timelocked authority:

Permanent roots from day one. CLAIM token and Locks (veCLAIM) are not upgradeable.
Upgradeable runtime contracts. Crown, Furnace, Market, and Barons are governed through a timelock.
Governance chain. Multisig Safe → TimelockController → ProxyAdmin → runtime proxy.

What this means in practice:

Any proposed change is scheduled through the timelock, waits the delay, then executes. The exact calldata is visible onchain before execution. The Safe can cancel during the waiting period.
A separate guardian key handles pause / unpause for incident response. The guardian cannot upgrade contracts, change rules, or move funds.

The freeze-and-burn ceremony

When the protocol is ready for permanent runtime finality, the team schedules a single onchain batch through the same timelock. The batch does two things:

Freezes configuration on five core contracts so their wiring cannot be re-pointed.
Burns the runtime upgrade keys by renouncing ownership of the runtime ProxyAdmin contracts.

The five freeze-gated contracts are:

Contract	Lore alias
ClaimToken	(CLAIM)
MineCore	Crown
Furnace	Furnace
VeClaimNFT	Locks
ShareholderRoyalties	Barons

ClaimToken freezes earlier (at wire time, before launch) and is already frozen when the ceremony runs. The remaining four freezes execute in the batch, followed by renouncing the runtime ProxyAdmin owners for MineCore, Furnace, MarketRouter, and ShareholderRoyalties. If any freeze step fails, the entire batch reverts and no ProxyAdmin is ever burned.

What is locked forever

After the batch executes:

The four runtime contracts (Crown, Furnace, Market, Barons) cannot be upgraded. Their proxy addresses remain the canonical live addresses, but no new logic can replace them.
All five core configurations cannot be re-pointed. The wiring that connects Crown to Furnace, Furnace to Locks, and so on is permanent.
CLAIM token and Locks (veCLAIM) remain direct permanent roots, as they have been since launch.

What stays adjustable

Finality is permanent for game logic. It is not a full ownership renounce on every operational surface. A small set of operational peripherals remains adjustable through the timelock so the protocol can keep working as the surrounding ecosystem changes.

Examples:

Entry-token routing (which tokens the Furnace and Crown accept on entry, and how they route to CLAIM)
Bot-access hub configuration (the contract powering delegated automation)
Market policy (settlement keepers, bonus-target escrow parameters)
Guardian rotation (so pause authority can be moved if needed)

These knobs do not change game economics: takeover splits, lock mechanics, the bonus engine, royalty distribution, and the freeze gates themselves are permanent. Every surviving change still goes through the full schedule → wait → execute timelock cycle. There is no instant setter after finality.

The waiting period

The freeze-and-burn batch is timelocked before it runs. That delay is part of the protocol’s credibility commitment:

It creates a public onchain countdown to permanent finality.
The exact batch calldata is visible before execution. Anyone can read what the ceremony will do.
The Safe can cancel during the delay if anything looks wrong.
Players, integrators, and operators get a final review window before runtime immutability lands.

What you will see in the app

When the ceremony executes, the app reflects the new state automatically. No manual refresh, no version bump.

On Security:

The Upgradeable column flips from Yes to No for Crown, Furnace, Market, and Barons.
Each row in the Configuration freeze section flips to Frozen.
Operational peripherals that remain reconfigurable through the timelock display as Configurable.

On Protocol Status:

The Contracts row in the live status panel reads Immutable once all five configFrozen() reads are true.
The protocol event log records the ceremony with a Governance category badge and a link to the BaseScan transaction.