Checklist · upgradeable contracts
Proxy Upgrade Audit Verification Checklist
Verify whether an audit still applies after a proxy upgrade by checking the implementation, admin, storage layout, change history, and new review evidence.
Reviewed 23 July 2026 · Primary sources linked below
Direct answer
After a proxy upgrade, verify the new implementation address and bytecode, compare the changed source with the last reviewed commit, check storage compatibility and initialization, and refresh the audit record. A stable proxy address does not mean the audited code stayed the same.
Evidence workflow
What to check, in order
Freeze a reference block
Record the chain and finalized block used for the check so implementation and admin observations can be reproduced.
Evidence to keep: Chain ID, block number, block timestamp, and RPC method.
Read proxy implementation and admin state
Resolve the implementation, beacon where applicable, and admin using the proxy pattern's storage slots or verified interface.
Evidence to keep: Proxy type, implementation slot, beacon slot, admin slot, and resolved addresses.
Identify the upgrade transaction
Find the event or transaction that changed the implementation and connect it to the governance, multisig, or admin action that authorized the change.
Evidence to keep: Upgrade event, transaction hash, caller, proposal or multisig record, and execution time.
Compare old and new source
Review the changed code paths, dependencies, compiler inputs, and deployment parameters. The new implementation should be bound to a source snapshot.
Evidence to keep: Old and new commits, source diff, compiler configuration, and runtime bytecode hashes.
Validate storage and initialization
Check that storage layout remains compatible and that initializer functions cannot be replayed or left exposed. Include inherited contracts and renamed or reordered variables.
Evidence to keep: Storage layout diff, initializer state, upgrade validation output, and review notes.
Refresh audit and fix evidence
Determine whether the changed paths received a new review and whether findings were fixed. Carry forward only evidence that still applies.
Evidence to keep: New report or fix review, updated scope, remediation status, and explicit inherited evidence.
Recheck powers and user exits
Confirm whether the upgrade changed pause controls, oracle roles, treasury access, withdrawal logic, fees, or emergency paths.
Evidence to keep: Role map, critical configuration diff, exit-path test, and open operational gaps.
Use the product
Inspect a public proxy snapshot
The Aave V4 evidence record resolves two implementation slots at an exact Ethereum block and keeps the missing source mapping visible.
Open Aave V4 evidenceSource ledger
Primary references and working records
ERC-1967: Proxy storage slots
Defines standard implementation, beacon, admin slots, and upgrade events.
OpenZeppelin Upgrades Plugins
Covers upgrade deployments and automated compatibility checks.
OpenZeppelin Upgrades FAQ
Explains common upgradeability, validation, and storage questions.
Aave V4 public evidence record
Shows exact implementation-slot observations at a fixed block.
Specific answers
Frequently asked questions
Does an audit still apply after a proxy upgrade?
Only to the extent that the reviewed code and assumptions remain unchanged. New or modified implementation code needs an explicit comparison and often a focused new review.
Why is the proxy address not enough?
The proxy can keep the same address while delegating execution to a different implementation. Users see the same address even though the running logic changed.
What storage checks are required?
Check variable order and types, inherited layouts, gaps, namespaces, initialization, and any tool warnings for the specific proxy framework.
Should every upgrade get a full audit?
Review depth should follow the change and risk. At minimum, every material upgrade needs source and bytecode binding, a scoped diff review, storage validation, and refreshed control evidence.
Continue the cluster