Upgrade Flow¶

sequenceDiagram
    participant Build as Release build
    participant Review as Independent review
    participant Proposer as PROPOSER_ROLE
    participant Governor as CenturionUpgradeGovernor
    participant Queuer as QUEUER_ROLE
    participant Guardian as CANCELLER_ROLE
    participant Executor as EXECUTOR_ROLE
    participant Target as Proxy or beacon

    Build->>Review: implementation, metadata, policy hash, calldata
    Review->>Proposer: approved evidence bundle
    Proposer->>Governor: proposeUpgrade(...)
    Governor-->>Governor: validate registration + implementation metadata
    Queuer->>Governor: queueUpgrade(operationId)
    Governor-->>Governor: readyAt = now + minDelay
    Guardian-->>Governor: cancelUpgrade(operationId) if unsafe
    Executor->>Governor: executeUpgrade(operationId) after readyAt
    Governor->>Target: upgradeToAndCall or upgradeTo
    Governor-->>Governor: approve implementation policy record

Source-Enforced Checks¶

• minDelay must be at least MINIMUM_LONG_TIMELOCK at construction.
• A target must be registered as the expected transparent proxy or beacon.
• Runtime code hash checks prove the target wrapper is a Centurion proxy or beacon shape.
• Implementation metadata must match contract kind, implementation version, and economic policy hash.
• Operation hash binds target type, target, implementation, kind, version, policy hash, salt, calldata, and expected initialized version.
• Transparent proxy execution can require proxyInitializedVersion >= expectedInitializedVersion.
• Beacon upgrades reject non-empty calldata; per-vault reinitialization is not atomic.
• notFinalFrozen blocks proposal, queue, execution, target registration, and genesis approval after final freeze.

Final Freeze¶

finalFreeze(reasonHash) still exists in CenturionUpgradeGovernor. It iterates the governor-maintained registered-beacon list, calls freezeForever() on each beacon, then sets finalFrozen = true. It is optional emergency machinery and is not a deposit prerequisite in the current refactor.

Post-Execution Assertions¶

After execution, archive:

• operation id and decoded payload;
• target type and address;
• implementation code hash and metadata;
• proxy implementation or beacon implementation after execution;
• initialized version if applicable;
• relevant smoke tests and policy assertion outputs;
• signer evidence and monitoring transcript.