Skip to main content
The fresh Universal Lookup has no mandatory upgrade delay. That decision applies to Lookup’s upgrade proposal, not Allocator claims, objections, reopening rules or namespace permanence.

​
Universal Lookup upgrade flow

  1. Governance authorizes propose_upgrade(wasm_hash) for one exact code hash.
  2. The proposal records execute_after as the current ledger timestamp. It is immediately eligible.
  3. Anyone may call execute_upgrade(expected_hash). The hash must equal the pending proposal.
  4. A successful execution replaces the contract’s Wasm at the same contract address and consumes the proposal. A failed replacement rolls back the transaction.
Governance can call cancel_upgrade() while a proposal is pending, but there is no guaranteed time in which cancellation can beat immediate execution. Read governance(), upgrade_delay() and pending_upgrade() when assessing a deployment. A stable Lookup address makes integration routing consistent. Its Registry/version checks establish reported wiring and ABI compatibility, not a pin of the executable code. Integrators requiring reviewed code need their own current-code verification policy.

​
Other contracts

Replacing a Resolver with a different contract creates separate storage. Its records do not migrate automatically. An in-place upgrade preserves the address, but compatible storage and access rules are still required. A permanently locked old Resolver cannot be upgraded to gain memo support. The fresh testnet rollout uses a new setup and does not change the existing deployment in place. See release status.