Why a router upgrade can change the risk of an old approval

An approval can remain attached to the same spender address while an upgrade changes the code executed behind that address. The familiar address therefore does not always imply unchanged behavior.

Identify whether the spender is upgradeable

OpenZeppelin’s proxy documentation describes patterns in which a proxy delegates execution to an implementation that authorized parties can replace. Other contracts may be immutable or use different mechanisms; check the exact deployment.

Do not confuse changing a front-end route to a new address with upgrading implementation behind an existing address. The effects on an existing allowance can differ.

Review upgrade authority

Who can authorize an upgrade? Is there a multisignature threshold, a timelock or another constraint? Can those controls themselves change? A governance label does not answer those questions.

Compare the current implementation with the version covered by any audit. An older report may remain useful background but cannot automatically cover new behavior.

Manage permission over time

A limited allowance bounds token access through that permission, while revocation can remove unused access after confirmation. Neither choice proves the implementation is safe; they change your exposure.

For recurring users, monitor official upgrade notices and review whether the new design still fits the reason you approved it. For an account you no longer use with the protocol, keeping broad dormant permissions offers little operational value.

If an incident involves upgrade authority, follow verified instructions for the exact affected spender and chain. A general protocol name is not enough to identify which allowances matter.