Upgradeable proxy patterns store state at one address while delegating logic to an implementation that can change. Reviewing only the proxy's verified surface can miss the current implementation, upgrade authority or initialization risks.
This concept matters because Resolve the active implementation.
A proxy preserves address/state while executable logic can change behind it.
Resolve current implementation, verification state, upgrade admin and timelock.
At protocol and execution level, inspect proxy and implementation and admin and storage and upgrade path. Protocol identifiers remain untranslated because they are part of the technical payload.
proxyuser-facing state address
implementationdelegated logic
adminupgrade authority
storageproxy state layout
upgrade pathlogic can change after review
A previously reviewed address can execute newly upgraded logic controlled by a single compromised admin.
The practical consequence is that Identify who can upgrade it. Unknown is not equivalent to safe.
Treat implementation and upgrade authority as first-class evidence for critical calls.
The practical consequence is that Identify who can upgrade it.
Escalate when evidence is contradictory, incomplete or the consequence exceeds routine policy.
Verify the request through independent evidence before irreversible authorization.
identify proxy pattern
read implementation slot / resolver
verify implementation code
identify admin / timelock
record upgradeability as ongoing trust
Record the facts, assumptions, unknowns and decision so another analyst can reproduce the review.
Resolve the active implementation. and Treat upgradeability as an ongoing trust assumption.
Resolve the active implementation.
user-facing state addressdelegated logicupgrade authorityproxy state layoutlogic can change after reviewproxy verified / implementation unknown
admin untrusted
recent implementation change
initialization ambiguity
upgradeable spender
identify proxy pattern
read implementation slot / resolver
verify implementation code
identify admin / timelock
record upgradeability as ongoing trust
facts → material evidence
evidence → consequence / authority
consequence → explicit decision + next action
proxy trust-boundary mapproxy / upgradeabilityverified0xImplV7yessingle EOA2 days agononeBefore answering the checkpoint, identify the authority being granted, the trust boundary that can fail, and the consequence that becomes irreversible.
Separate identity, authority, execution and context before reaching a security decision.
Who or what is requesting, receiving or representing authority?
What capability can be granted, retained or exercised?
single EOAWhat will the payload, route or system actually do?
verified0xImplV7yesWhich surrounding facts can materially change the decision?
2 days agononeDo not answer from memory. Use the case, protocol fields and verification procedure above to write a reproducible finding.
Resolve the active implementation.
Identify who can upgrade it.
Treat upgradeability as an ongoing trust assumption.
Record your reasoning before the checkpoint. Finish with an explicit decision or next action. Notes stay on this device.
Develop all three sections before completion.
Trace execution through upgradeable contracts and delegatecall instead of trusting the visible proxy address.