Register Implementation Approvals¶

Purpose¶

Register targets and genesis implementation approvals so the governor can enforce policy assertions.

Required Authority¶

REGISTRAR_ROLE.

Preconditions¶

• Proxy admin or beacon authority is the governor.
• Runtime code hash matches Centurion transparent proxy or upgradeable beacon shape.
• Implementation metadata and code hash match reviewed artifacts.
• Genesis approval phase has not been sealed if using recordGenesisImplementation.

Procedure¶

1. For each transparent proxy, verify proxyAdmin() == governor.
2. Call registerTransparentProxy(proxy, contractKind).
3. For each beacon, verify upgradeAuthority() == governor and current implementation has code.
4. Call registerBeacon(beacon, contractKind).
5. For genesis implementations, call recordGenesisImplementation(kind, implementation, version, policyHash).
6. Re-read implementationPolicy(implementation).
7. When all genesis approvals are complete, call sealGenesisApprovals().

Abort Conditions¶

Abort if admin/authority is not the governor, runtime code hash mismatches, target kind is wrong, implementation metadata differs, or any component has no code.

Post-Checks¶

• registeredTransparentProxy or registeredBeacon true.
• registeredTargetKind[target] matches.
• implementationPolicy matches approved metadata.
• genesisApprovalsSealed is true after sealing.

Evidence To Archive¶

Runtime codehash proof, admin/authority reads, metadata reads, registration txs, approval txs, seal tx, and post-state readback.

Operational Procedure¶

Purpose¶

Use this runbook to register proxy, beacon, and genesis implementation policy entries during launch or controlled onboarding.

When To Use¶

Use it for production, staging, or rehearsal actions that affect live authority, validator custody, economic accounting, claims, or incident response. Do not use it as a substitute for source review; deployed-state evidence remains Evidence required unless captured for the exact chain and address set.

Required Authority¶

Required authority: REGISTRAR_ROLE. Read-only preparation can be performed by an operator or auditor, but transaction submission must come from the documented production holder in the permission matrix.

Preconditions¶

• The current source manifest and generated inventory are up to date.
• The acting Safe or owner has been verified against the current permission matrix.
• No unresolved incident is active for the same contract, validator, role, or operation.
• The reviewer can identify which layer is affected: Upgrade governance, Deposit permissioning, Custody/readiness, or Economic/claim safety.

Inputs Required¶

• t.
• a.
• r.
• g.
• e.
• t.
• .
• a.
• d.
• d.
• r.
• e.
• s.
• s.
• ,.
• .
• k.
• i.
• n.
• d.
• .
• h.
• a.
• s.
• h.
• ,.
• .
• i.
• m.
• p.
• l.
• e.
• m.
• e.
• n.
• t.
• a.
• t.
• i.
• o.
• n.
• .
• a.
• d.
• d.
• r.
• e.
• s.
• s.
• ,.
• .
• c.
• o.
• d.
• e.
• .
• h.
• a.
• s.
• h.
• ,.
• .
• v.
• e.
• r.
• s.
• i.
• o.
• n.
• ,.
• .
• p.
• o.
• l.
• i.
• c.
• y.
• .
• h.
• a.
• s.
• h.

Step-By-Step Procedure¶

1. verify target code and admin/authority.
2. register proxy or beacon.
3. record genesis implementation when launch-only.
4. seal approvals only after complete inventory review.

Independent Review Requirement¶

A second reviewer must check the decoded calldata, expected state transition, affected role or validator, and expected events before submission. For emergency use, capture the reviewer identity and incident ticket before or immediately after the transaction.

Abort Conditions¶

• Source manifest hash drift or unexpected implementation metadata.
• Caller or Safe does not match the permission matrix.
• Revert reason points at a different layer than the runbook is trying to change.
• Any required input is missing or only inferred.
• A guardian, canceller, or incident commander has frozen the action window.

On-Chain Pre-Checks¶

Read current role/owner/admin state, operation status, target code hash where applicable, validator/vault mapping where applicable, and the latest readiness or claim state that the action depends on. Record block number and RPC endpoint.

On-Chain Post-Checks¶

Confirm the intended state changed, no adjacent authority changed unexpectedly, and no pending operation or stale intent was left active. Re-read the affected contract rather than relying only on transaction success.

Events Or Logs To Monitor¶

• TransparentProxyRegistered.
• BeaconRegistered.
• GenesisImplementationApproved.
• GenesisApprovalsSealed.

Evidence To Archive¶

Archive calldata, transaction hash, decoded event logs, pre/post reads, reviewer approval, incident or change ticket, and any source-manifest or release-artifact references used to justify the action.

Escalation Path¶

Escalate to governance signers for authority or upgrade anomalies, to controller/risk owners for economic or claim anomalies, to admission operators for intent mistakes, and to security incident response for unexpected code, role, or event drift.