Proxy Contracts: Who Can Actually Change the Logic?

The address you see may not contain the logic that runs

Proxy contracts allow a team to upgrade application logic without moving the address or state. That is practical for builders. For users, it means one important thing: the code you read today may not be the code running tomorrow.

The important question is not only “is this contract verified?” It is: who can replace the implementation?

---

The simple model

A proxy stores state and receives calls. It forwards those calls to an implementation with delegatecall. The logic runs as if it were in the proxy, while storage belongs to the proxy.

wallet -> proxy address -> implementation address
state logic

If the implementation changes, the address and balances may remain the same while the rules change.

---

Four addresses to separate

The proxy address is what users call. The implementation address contains the logic. The proxy admin can usually change the implementation. A timelock or multisig may add review and shared control.

Do not assume the deployer is the only important party. Control can move to another role or contract after deployment.

---

My inspection checklist

1. Confirm that the contract is a proxy or has an upgrade mechanism.
2. Record the current implementation address.
3. Read the implementation source, not only the proxy source.
4. Find upgradeTo, upgradeToAndCall, or an equivalent pattern.
5. Identify the admin, owner, or role allowed to upgrade.
6. Inspect upgrade events and implementation history.
7. Look for timelock, multisig, pause, and emergency paths.
8. Compare storage layouts before and after an upgrade.

Upgradeability is not automatically a bug. Protocols may need it for security fixes. The risk appears when one key can upgrade without a delay, transparency, or a way for users to understand the change.

---

What does renounced ownership mean here?

It is easy to misunderstand. Ownership on the implementation may be renounced while the proxy admin still controls upgrades. The proxy may also use a different admin address. Inspect the upgrade path actually used by the proxy.

My conclusion: an immutable address does not necessarily mean immutable logic. An audit of an upgradeable contract must include the upgrade mechanism and its controller.

---

Sources

• OpenZeppelin: Proxy upgrade patterns
• Ethereum: Smart contract security
• EIP-1967: Proxy Storage Slots

*Written after realizing that the same address does not necessarily mean the same logic.*